CN114138360B

CN114138360B - Multi-core programming starting method and system for DSP (digital Signal processor) on Flash

Info

Publication number: CN114138360B
Application number: CN202111342349.XA
Authority: CN
Inventors: 张鹏程; 肖博峰; 周舟; 张昭
Original assignee: Shanghai Huayuan Chuangxin Software Co ltd
Current assignee: Shanghai Huayuan Chuangxin Software Co ltd
Priority date: 2021-11-12
Filing date: 2021-11-12
Publication date: 2024-03-26
Anticipated expiration: 2041-11-12
Also published as: CN114138360A

Abstract

The utility model provides a method and a system for starting multi-core programming of a DSP (digital signal processor) on Flash, wherein the method comprises the following steps: the method comprises the steps of (1) burning an environment variable, a secondary BootLoader, a main core operating system image and a preset number of secondary core bare metal programs into Flash; loading and operating a secondary Bootloader from a 0 address of Flash by utilizing a ROM Bootloader built in the DSP; the secondary Bootloader reads environment variables from the Flash to obtain the address of the main kernel operating system mirror image in the Flash; the secondary Bootloader loads the main core operating system image and jumps to the main core operating system image address for running; the method comprises the steps that a main core operating system mirror reads environment variables from Flash at a preset time point according to service requirements, and the programming addresses of a preset number of slave core bare metal programs in the Flash are obtained; and selecting a secondary core bare metal program according to the environment variable, starting the secondary core bare metal program, loading the started secondary core bare metal program by the main core operating system image, setting the running ADDRESS of the secondary core bare metal program to the BOOT_MAGIC_ADDRESS ADDRESS of the secondary core, interrupting the IPC of the secondary core, and running the secondary core.

Description

Multi-core programming starting method and system for DSP (digital Signal processor) on Flash

Technical Field

The utility model relates to the technical field of power-on self-guide of embedded equipment, in particular to a method and a system for starting multi-core programming of a DSP (digital signal processor) on Flash.

Background

At present, DSP is increasingly widely used in the field of signal processing with its high performance. The commercially available high-performance DSP is TMS320C6678 chip of TI company and the replaced domestic DSP chip. Their start modes all include EMIF, SRIO, ethernet, PCIE, I, 2, C, SPI, UART, NAND, etc. Local boot is typically initiated using SPI Flash or EMIF Flash. The TMS320C6678 chip and the alternative domestic DSP chip are used for describing the two starting modes in detail, but the two starting modes jump to the loaded program execution after the ROM Bootloader is loaded with the program, so that the control right is given out, and a large playing space is provided for users. The user only needs to make the program loaded by the ROM Bootloader meet the required format. The program loaded by the ROM Bootloader can be a secondary Bootloader or a service program. In some scenarios, the master core is required to run an operating system and the slave core is required to run a bare metal program. Searching for existing patents, no solution directly to this scenario has been found. On the other hand, for the programming method, the official example of the TMS320C6678 chip provides a method for programming one file by running an example program through a JTAG simulator, and a plurality of files are required to be programmed by running for a plurality of times, so that the method is not flexible; the domestic DSP manufacturer provides a multi-core programming example based on SPI Flash starting, combines and converts the format of the out file in the ELF format generated by each core by using a special tool to obtain a dat file to be programmed, and cannot independently write the programs of each core, so that the method is not flexible.

Patent document CN101178658A (application No. 200710171619.9) discloses a DSP-based upgrade system and an upgrade method for upgrading a DSP-based embedded system, which includes: the demultiplexing module is used for obtaining upgrade data from the transport stream; the method comprises the steps that a starting loading module is utilized to execute initialization of hardware equipment, and flash memories storing a starting loading program and a DSP main program are distributed; the interactive module provides the user with real-time knowledge of the upgrading condition of the embedded system, and the upgrading system and the upgrading method can solve the manual service problem of the existing upgrading system, thereby saving the later labor cost and providing a convenient, reliable and low-cost implementation method for project implementation and the upgrading of the later value-added module.

Patent document CN111506334a (application number: 202010345859.1) discloses a method and a system for online upgrading a DSP chip program, which receives an online upgrade instruction and a program file sent by an upper computer through a FLASH of the DSP chip, updates a start program in the FLASH according to the online upgrade instruction, and writes storage position data of the start program in the FLASH into a CMD file; restarting the DSP chip, leading the R AM of the DSP chip into an updated starting program in the FLASH according to an instruction of the CMD file and running the starting program, thereby carrying the DSP program from the FLASH to the RAM for running, improving the running rate of the program, automatically running from a new upgrading program when the next power-on is performed, and preventing the running program from crashing when an error occurs in the upgrading process.

Patent document CN110427223a (application number: 201910587781.1) discloses a method for dynamically loading a multi-core DSP based on a PCIE bus of an upper computer, the method comprising: the multi-core DSP is in communication connection with the upper computer; transmitting a program to the multi-core DSP; triggering PCIE MSI interruption to enable the multi-core DSP to run the program; and the multi-core DSP receives data from the upper computer in a PCIE DMA mode and returns the operation result of running the program to the upper computer. The method and the system have the advantages of low cost, low power consumption, small system volume and convenient carrying, and can be separated from an external field to quickly carry out relevant debugging; the quick loading and starting of the program can be realized under the condition that the system is not restarted, so that the application is flexible, and the debugging time is saved; and the system data transmission efficiency is higher, and the actual transmission efficiency is far higher than that of a common gigabit network interface due to the adoption of PCIE2.0 protocol.

Patent document CN103955376a (application number: 201410056275.7) discloses a DSP self-starting secondary on-demand loading method, comprising: the method comprises the steps that programs stored in ROM externally connected with a DSP are modularized according to functions, and are divided into an initial BOOT module BOOT, a main frame BOOT module BOOT2 and an application module, wherein the application module comprises sub-application program modules with different functions; after the DSP is powered on and reset, an initial BOOT module BOOT is automatically loaded from the ROM, and the initial BOOT module BOOT is used for loading a main frame BOOT module BOOT2; the DSP runs an initial BOOT module BOOT, and then loads a main frame BOOT module BOOT2 from the ROM; the DSP runs a main frame guide module BOOT2, and then loads a corresponding sub-application program module from the ROM application module according to the requirement of the main control unit. The utility model effectively avoids the function module integration process brought by the traditional one-time program loading method, thereby maximally using the internal resources of the DSP hardware.

Patent document CN205692152U (application number: CN 201521044700.7) discloses an improved structure of a DSP starting mode, which comprises a Flash and a DSP which are connected in one way, wherein the DSP comprises a CPU and a memory; the Flash is connected with the DSP through an EMIF bus; the Flash comprises a moving program block and an application program block; the application program block enters the memory in the DSP through the moving program block; the utility model stores boot program in Flash, DSP executes boot program after power-on, and moves application program from Flash to DSP memory, and then starts executing program from memory, thus making executing speed faster and improving operating efficiency.

Patent document CN106293807a (application number 201610595947.0) discloses a Flash chip boot loading method based on DSP. The utility model adopts a method of programming the Flash chip in the process of boot loading to the monitoring program, uses the serial port to carry out data transmission, firstly writes a monitoring program into the front half part of the Flash chip, then re-electrifies and self-starts the monitoring program, writes the application program into the rear half part of the Flash chip, and electrifies the change-over switch again to realize the self-starting of the application program. The whole process breaks away from the constraint of the JTAG simulator when the application program is programmed, so that the upgrade and maintenance of the system software in the outfield test are more convenient and operable. Meanwhile, the Bootloader program is controlled within 1K byte, so that the trouble of writing and running the Bootloader twice is avoided.

Patent document CN106569833a (application number: 201610998885.8) discloses an online upgrade method of a DSP program having a secondary BOOT, first copying a section of the secondary BOOT program from a ROM area to a RAM area and executing from the first address of the secondary BOOT program; then the DSP guides the online upgrade program from the ROM area to the RAM area and operates; the upper computer transmits a data frame of the program through the communication module; after the ROM operation module writes the data frame into the ROM area, replying a confirmation frame to the upper computer until the data frame is issued; the functional program area in the ROM area performs verification and transmits the verification result to the upper computer. The online upgrading program and the functional program provided by the utility model are relatively independent, so that RAM overhead in operation can be effectively saved. The secondary BOOT program section provided by the utility model is short and small, can be started quickly, guides the programs of the functional area or the online upgrading area to the RAM and operates, and is very suitable for industrial occasions with strict requirements on real-time performance.

Patent document CN107506208A (application number: 201710574750.3) discloses an online upgrade method for a DSP firmware of an anti-burn device, and two partitions are divided into FLASH: an application partition and a secure programming firmware partition; the application program partition is used for installing DSP application program firmware for realizing the product function; the safe programming firmware partition is used for installing safe programming firmware which is used for realizing online upgrading of the DSP application program firmware; the firmware of the safe programming firmware partition is programmed before leaving the factory, and the content of the partition cannot be changed in subsequent use or upgrading. The utility model uses the DSP firmware installation mode of FLASH double partition, and the firmware upgrading operation is executed by the safe programming firmware, so that the problems that the DSP firmware cannot be started and the subsequent firmware programming cannot be performed due to the abnormal upgrading firmware are avoided.

Patent document CN108038067a (application number: CN 201711447008.2) discloses a method for programming DSP user programs through serial ports, which belongs to the field of information technology, and is characterized by comprising the following steps: (1) configuring the DSP to boot from Flash; (2) Dividing Flash into a plurality of sectors, and selecting any sector to solidify Bootloader program; (3) The upper computer is connected with the DSP through a serial port for data communication; (4) Executing the Bootloader program solidified in Flash and the control instruction transmitted by the upper computer until the programming of the user program data is completed. Only one GPIO is needed for configuration, so that the programming flexibility is improved; the RS422 is used for data transmission, so that the transmission distance and the data transmission reliability can be increased, and the update requirement of the outfield program can be met.

Patent document CN108762828A (application number: 201810372343.9) discloses a method and device for two-stage starting of a DSP multi-core array, the method comprising: solidifying the preloaded user main program into a FLASH memory of an external host; solidifying the preloaded secondary bootstrap program into an EEPROM memory of the DSP multi-core array; when the DSP multi-core array is started, a power-on reset signal is generated, and whether a DSP secondary starting mode is started or not is confirmed; according to a power-on reset signal and DSP secondary starting mode information, a secondary bootstrap program is called from the EEPROM memory to a RAM random access memory of a DSP multi-core array, the secondary bootstrap program is started and operated, and a user main program in the FLASH memory is loaded into a processor of the DSP multi-core array through the secondary bootstrap program; and starting and running the user main program in a processor of the DSP multi-core array. The utility model adopts a two-level program loading starting mode to realize that the DSP multi-core array directly loads the user main program, and can realize loading without depending on an external network and an external control device.

Patent document CN109213531A (application number 201811015884.2) discloses a simplified implementation method of power-on self-starting of a multi-core DSP based on EMIF16, and belongs to the technical field of power-on self-guiding of embedded equipment. According to the utility model, through a three-level loading process, the multi-core program is stored in a segmented mode by modifying the CMD file, and the programming function and the secondary bootstrap program are written, so that the compiling and programming processes of the multi-core program can be completed under the same CCS engineering, and finally the power-on self-starting of the multi-core DSP program is correctly realized. The method provided by the utility model eliminates the complicated processing procedure of the current multi-core DSP power-on self-starting, does not need to build engineering for compiling respectively for multi-core programs, omits the step of manually synthesizing a plurality of image files, and improves the loading efficiency of the multi-core programs; the programming function is written in the engineering, so that the programming of the multi-core program is convenient; the power-on loading process is simple, the program readability is stronger, the debugging period is greatly shortened, and the correct and reliable loading operation of the multi-core DSP software can be realized.

Patent document CN107656773a (application number: 201710898403.6) discloses a multi-core DSP starting method, which includes the steps of: s1, setting a ROM region in a multi-core DSP chip, loading a pre-established boot loader in the ROM region, wherein the boot loader comprises a plurality of boot modes of the multi-core DSP chip for a plurality of peripheral devices, and configuring the peripheral devices required to be adopted when the chip is started and the boot modes required to be adopted by the peripheral devices through a boot mode register; s2, after the chip is reset, the main core executes a starting loading program, reads a starting mode register, obtains a target peripheral needing to be adopted currently and a target starting mode needing to be adopted, loads a user program, and enables the other cores to jump to a designated address to start executing the respective user program in an interrupt mode after the user program is loaded. The utility model can realize the multi-peripheral multi-mode multi-core DSP start, and has high memory utilization rate and efficiency, wide application range and strong flexibility.

Patent document 103064806B (application number 201210589013.8) discloses a method for controlling DSP to realize secondary start by CPLD, and the programs of the digital signal processor DSP in the embedded system of the present utility model are all stored in the off-chip program memory; each power-on DSP program loading needs to be divided into a first-stage loading stage and a second-stage loading stage; the first stage is automatically carried out by the DSP through a DMA or EDMA mode, a section of code at the beginning of an off-chip program memory is transmitted to an on-chip address 0x00 for execution, and the whole transmission process is not controlled by a user; the second loading is performed based on the success of the first loading, and the code executing the first loading copies the user's application program from the loading address to the running address. The utility model has the advantages of short secondary starting, high reliability of judging mode, easy code writing and convenient debugging, can conveniently monitor signals on IO pins by using an oscilloscope, and is convenient and flexible to connect wires with the DSP, thereby being convenient for wiring of the printed board.

Patent document CN111190772a (application number: CN202010004472. X) discloses a DSP two-level starting system and method for anti-space single event upset, which solidifies three identical user main programs into two independent external NOR FLASH memories; solidifying the monitoring program into an external PROM memory; determining to enter a three-out-two loading main program or enter an on-orbit programming state according to an on-orbit programming register in the FPGA; the anti-fuse FPGA receives an RS422 instruction and a uploading program; the FPGA plug-in SRAM is used as an upper-injection program cache; after receiving the on-orbit programming instruction, the FPGA monitors the program to enter an on-orbit programming mode; and after receiving the FLASH switching instruction, the FPGA controls the chip selection signal switching of FLASH1 and FLASH 2. Compared with the existing two-stage starting method for performing three-mode redundancy on the whole FLASH or DSP minimum system, the utility model can reduce the occupied printed board area and obviously reduce the hardware cost on one hand, and can save three programs in one FLASH chip on the other hand, so that lower single event upset failure rate can be obtained by using two FLASH chips.

In summary, the existing DSP startup scheme focuses on the manner of expanding DSP upgrades (such as online upgrades, expanding hardware interface types of transmission program files, increasing upgrade options during startup), improving the running speed, enhancing the startup stability, and simplifying the operation. Only CN201811015884.2, a simplified implementation method of power-on self-starting of multi-core DSP based on EMIF16, is used for simplifying operation, programs of each core are divided into different segment spaces by modifying a cmd file of a single CCS project, program segments of an out file generated by compiling the CCS project can be copied to addresses appointed by the cmd file in the loading process of a simulator, and loaded program segments are burnt into Flash by forcing a PC pointer to a programming function in the same project, so that the method has good originality. But usually, users are more familiar with using development tools to directly compile generated out files, the out files are in ELF format, the utility model provides a scheme for directly programming out files, and the out files of a single core can be independently programmed, and simultaneously provides a scheme for enabling a main core to run an operating system and a slave core to run bare metal programs.

Disclosure of Invention

Aiming at the defects in the prior art, the utility model aims to provide a multi-core programming starting method and system for a DSP (digital signal processor) on Flash.

The method for starting the multi-core programming of the DSP on the Flash comprises the following steps:

step S1: the method comprises the steps of (1) burning an environment variable, a secondary BootLoader, a main core operating system image and a preset number of secondary core bare metal programs into Flash;

step S2: loading and operating a secondary Bootloader from a 0 address of Flash by utilizing a ROM Bootloader built in the DSP;

step S3: the secondary Bootloader reads environment variables from the Flash to obtain the address of the main kernel operating system mirror image in the Flash;

step S4: the secondary Bootloader loads the main core operating system image and jumps to the main core operating system image address for running;

step S5: the method comprises the steps that a main core operating system mirror reads environment variables from Flash at a preset time point according to service requirements, and the programming addresses of a preset number of slave core bare metal programs in the Flash are obtained;

step S6: and selecting and starting the slave bare metal program according to the environment variable, loading the started slave bare metal program by the main core operating system image, setting the running ADDRESS of the slave bare metal program to the BOOT_MAGIC_ADDRESS ADDRESS of the slave core, and interrupting IPC (IPC) of the slave core to run the slave core.

Preferably, the DSP is a TMS320C6678 chip or a domestic alternative chip; the Flash is SPI Flash or EMIF Flash.

Preferably, the step S1 includes:

step S1.1: planning environment variables, secondary BootLoader, operating system images of a main core and the space occupied by bare metal programs of a preset number of auxiliary cores in Flash;

step S1.2: and using a JTAG simulator to burn the environment variable, the secondary BootLoader, the operating system image of the master core and the bare metal programs of the preset number of slave cores into Flash at one time.

Preferably, the space occupied by the environment variable, the secondary BootLoader, the operating system image of the master core and the bare metal programs of the preset number of slave cores in Flash are not overlapped with each other; the preset number of bare metal programs of the slave cores occupy a preset number of Flash spaces.

Preferably, the step S2 includes: the file format generated by the secondary Bootloader compiling is converted according to the requirement of the ROM Bootloader loader built in the DSP.

Preferably, the burning the environment variable into Flash includes: the environment variable is programmed to a corresponding address in Flash, and the operating system mirror image of the master core and the programming address of the bare metal programs of the preset number of slave cores in Flash are set according to the environment variable; and selecting to load the bare metal programs of the corresponding secondary cores according to the environment variable settings.

Preferably, the primary core operating system image and the bare metal programs of the preset number of secondary cores are in an ELF format, and the ELF format is generated by default compiling of the CCS development environment and the Rede development environment without format conversion.

Preferably, the secondary Bootloader and the primary kernel operating system image execute file parsing and loading the ELF format file according to the ELF V1.2 standard.

The utility model provides a multi-core programming starting system of a DSP on Flash, which comprises the following steps:

module M1: the method comprises the steps of (1) burning an environment variable, a secondary BootLoader, a main core operating system image and a preset number of secondary core bare metal programs into Flash;

module M2: loading and operating a secondary Bootloader from a 0 address of Flash by utilizing a ROM Bootloader built in the DSP;

module M3: the secondary Bootloader reads environment variables from the Flash to obtain the address of the main kernel operating system mirror image in the Flash;

module M4: the secondary Bootloader loads the main core operating system image and jumps to the main core operating system image address for running;

module M5: the method comprises the steps that a main core operating system mirror reads environment variables from Flash at a preset time point according to service requirements, and the programming addresses of a preset number of slave core bare metal programs in the Flash are obtained;

module M6: and selecting and starting the slave bare metal program according to the environment variable, loading the started slave bare metal program by the main core operating system image, setting the running ADDRESS of the slave bare metal program to the BOOT_MAGIC_ADDRESS ADDRESS of the slave core, and interrupting IPC (IPC) of the slave core to run the slave core.

Preferably, the module M1 comprises:

module M1.1: planning environment variables, secondary BootLoader, operating system images of a main core and the space occupied by bare metal programs of a preset number of auxiliary cores in Flash;

module M1.2: using a JTAG simulator to burn the environment variable, the secondary BootLoader, the operating system image of the main core and the bare metal programs of the preset number of secondary cores into the Flas once;

the space occupied by the environment variable, the secondary BootLoader, the operating system mirror image of the main core and the bare metal programs of the preset number of auxiliary cores are planned in Flash and are not overlapped with each other; the bare metal programs of the secondary cores occupy a preset number of Flash spaces;

the module M2 includes: the file format generated by the secondary Bootloader compiling is converted according to the requirement of the ROM Bootloader loader built in the DSP.

Preferably, the DSP is a TMS320C6678 chip or a domestic alternative chip; the Flash is SPI Flash or EMIF Flash;

the environment variable burning Flash comprises the following steps: the environment variable is programmed to a corresponding address in Flash, and the operating system mirror image of the master core and the programming address of the bare metal programs of the preset number of slave cores in Flash are set according to the environment variable; according to the environment variable setting, selecting to load and start the bare metal program of the corresponding slave core;

the main core operating system images and the bare metal programs of the preset number of the secondary cores are in ELF formats, and the ELF formats are generated by default compilation of a CCS development environment and a Rede development environment without format conversion;

and the secondary Bootloader and the main core operating system image execute file analysis and load ELF format files according to the ELF V1.2 standard.

Compared with the prior art, the utility model has the following beneficial effects:

1. providing a programming starting scheme for an application scene of a DSP main core running an operating system slave core running a bare metal program;

2. the Bootloader, the main core operating system mirror image, the programming address of each slave core bare engine program and which cores to start can be controlled by environment variables, and the programming parts can be controlled by a custom programming engineering, so that the system has high flexibility;

3. the operating system image of the master core and the bare metal program of the slave core are both in ELF format and can be generated by default compiling of the CCS development environment of TI and the Rede development environment of the Chinese electric department 32 without format conversion, so that the operation is simplified.

Drawings

Other features, objects and advantages of the present utility model will become more apparent upon reading of the detailed description of non-limiting embodiments, given with reference to the accompanying drawings in which:

FIG. 1 is a general block diagram of a multi-core programming starting method of a DSP on Flash;

FIG. 2 is an implementation of a secondary Bootloader;

FIG. 3 is a step of a master kernel operating system booting a slave kernel;

FIG. 4 is an ELF executable file format;

FIG. 5 is a diagram of the parsing and loading steps of an ELF executable.

Detailed Description

The present utility model will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the present utility model, but are not intended to limit the utility model in any way. It should be noted that variations and modifications could be made by those skilled in the art without departing from the inventive concept. These are all within the scope of the present utility model.

Example 1

step S1: the method comprises the steps of (1) burning an environment variable, a secondary BootLoader, a main core operating system image and 7 secondary core bare metal programs into Flash;

step S2: loading and operating a secondary Bootloader from a 0 address of Flash by utilizing a built-in ROM Bootloader (RBL) of a DSP manufacturer;

step S5: the main core operating system mirror image reads environment variables from the Flash at a preset time point according to service requirements, and obtains the programming addresses of 7 slave core bare metal programs in the Flash;

Specifically, the DSP is TMS320C6678 chip of TI company or domestic substitute chip; the Flash is SPI Flash or EMIF Flash.

Specifically, the main core runs a secondary Bootloader and an operating system, and the slave core runs a bare metal program; the bare metal program refers to a program that does not run an operating system.

Specifically, the step S1 includes:

step S1.1: planning environment variables, a secondary BootLoader, an operating system image of a main core and spaces occupied by bare metal programs of 7 auxiliary cores in Flash;

step S1.2: and using a JTAG simulator to burn the environment variable, the secondary BootLoader, the operating system image of the master core and the bare metal programs of 7 slave cores into Flash at one time.

Specifically, the space occupied by the environment variable, the secondary BootLoader, the operating system image of the master core and the bare metal programs of the 7 slave cores respectively planned in Flash are not overlapped with each other; the bare metal programs of the 7 slave cores occupy 7 Flash spaces. The JTAG simulator is used for loading the self-defined programming engineering for one-time programming.

Specifically, the step S2 includes: the secondary Bootloader is independently developed by the Chinese electric department 32, and the file format generated by compiling is converted according to the requirement of a built-in ROM Bootloader of a DSP manufacturer.

Specifically, the burning of the environment variable into Flash includes: and programming the environment variable to a determined address in the Flash, setting the operating system image of the master core and the programming address of the bare metal program of the slave core in the Flash according to the environment variable, and setting which slave cores are loaded and started.

Specifically, the primary core operating system image and the bare metal program of the secondary core are both in an ELF format, and the ELF format is generated by default compiling of the CCS development environment of TI and the Rede development environment of China electric department 32, and format conversion is not needed.

Specifically, the process of loading the ELF format file by the secondary Bootloader and the main core operating system is independently developed by the Chinese electric department 32, and the file analysis and loading are performed according to the ELF V1.2 standard.

module M1: the method comprises the steps of (1) burning an environment variable, a secondary BootLoader, a main core operating system image and 7 secondary core bare metal programs into Flash;

module M2: loading and operating a secondary Bootloader from a 0 address of Flash by utilizing a built-in ROM Bootloader (RBL) of a DSP manufacturer;

module M5: the main core operating system mirror image reads environment variables from the Flash at a preset time point according to service requirements, and obtains the programming addresses of 7 slave core bare metal programs in the Flash;

Specifically, the module M1 includes:

module M1.1: planning environment variables, a secondary BootLoader, an operating system image of a main core and spaces occupied by bare metal programs of 7 auxiliary cores in Flash;

module M1.2: and using a JTAG simulator to burn the environment variable, the secondary BootLoader, the operating system image of the master core and the bare metal programs of 7 slave cores into Flash at one time.

Specifically, the module M2 includes: the secondary Bootloader is independently developed by the Chinese electric department 32, and the file format generated by compiling is converted according to the requirement of a built-in ROM Bootloader of a DSP manufacturer.

Example 2

Example 2 is a modification of example 1

The overall frame diagram of the present utility model is shown in fig. 1. And planning environment variables, a secondary Bootloader, an ELF format operating system mirror image of a main core and spaces respectively occupied by ELF format bare metal programs of 7 auxiliary cores in Flash, and loading programming engineering by using a JTAG simulator to burn the Flash once. The Flash can be SPI Flash or EMIF Flash, and the hardware correspondingly sets the starting mode of the DSP. When the host is powered on and started, a ROM Bootloader (RBL) built in a DSP manufacturer loads and operates a secondary Bootloader from a 0 ADDRESS corresponding to Flash according to the content of a starting mode register, the secondary Bootloader reads an environment variable from Flash to obtain a programming ADDRESS of an operating system mirror image of a main core in Flash, loads the operating system, jumps to the operating system ADDRESS to operate, the operating system of the main core reads the environment variable from Flash at proper time, obtains programming addresses of bare metal programs of 7 slave cores in Flash and which slave cores are started, loads the slave core programs according to the programming addresses of the slave cores to a BOOT_MAGIC_ADDRESS ADDRESS of the slave cores, and interrupts the slave cores to enable the slave cores to operate.

Flash takes the S29GL256S chip of the space company as an example, which illustrates the space occupied by the environment variable, the secondary Bootloader, the operating system image of the master core, and the bare metal programs of 7 slave cores, respectively, as shown in table 1. The S29GL256S chip is 32MB in total, one sector size is 128KB (=0x20000), and is connected with the DSP through an EMIF interface. The position of the secondary Bootloader is determined to be 0 address, and the environment variable, the mirror image of the main core operating system and the address space occupied by the secondary core bare metal program can be adjusted according to specific situations.

TABLE 1 Flash space planning (taking the S29GL256S chip as an example)

Content	Flash offset address	Length (byte)
			Two-stage Bootloader	0x0	0xE0000
Environmental variable	0xE0000	0x20000
			Main core operating system image	0x100000	0x300000
Bare metal program for core 1	0x400000	0x180000
			Bare metal program for core 2	0x580000	0x180000
Bare metal program for core 3	0x700000	0x180000
			Bare metal program for core 4	0x880000	0x180000
Bare metal program for core 5	0xA00000	0x180000
			Bare metal program of core 6	0xB80000	0x180000
Bare metal program for core 7	0xD00000	0x180000
			Flash reserved space	0xE80000	0x1180000

The structure of the environment variables is shown in the following code. Wherein core_mask controls which slave cores are loaded and started in a bitmask mode, bit N controls Core N, a bit N value of 1 indicates that Core N is loaded and started, and a value of 0 indicates that Core N is not loaded and started. For example, if cores 0-6 need to be started, core_mask=0x7f. The dev_offset array is used for storing an operating system image of the main core and offset addresses of bare metal programs of the slave cores in Flash, wherein dev_offset [0] represents the offset addresses of the operating system of the main core in Flash, and dev_offset [1] to dev_offset [7] represent the offset addresses of the bare metal programs of the cores 1 to 7 in Flash. The magic_id is obtained by performing CRC operation on other members except the magic_id in the environment variable structure body, and is used for checking the environment variable to ensure that the environment variable is valid.

The implementation of the secondary Bootloader includes the following steps, as shown in fig. 2.

Step one: initializing a main PLL clock of a DSP chip;

step two: initializing a DDR PLL clock of a DSP chip and initializing the DDR;

step three: initializing an EMIF interface;

step four: reading environment variables from Flash, and obtaining an address of an ELF format operating system mirror image of a main core in Flash;

step five: reading the operating system image from Flash, analyzing ELF format head, obtaining the entrance address of the operating system image, analyzing the information of each program segment, and copying each program segment into memory.

Step six: and jumping to the entry address execution of the operating system image, and ending the secondary Bootloader operation.

The secondary Bootloader is loaded by a ROM Bootloader (RBL) built in the DSP manufacturer. The RBL of the TMS320C6678 chip and the RBL of the domestic DSP chip have different requirements on the loaded file formats, for example, for an EMIF interface, the RBL of the TMS320C6678 chip directly directs a program counter PC to the 0 address of Flash, an executable code segment needs to be stored at the 0 address, the file loaded by the RBL of the domestic DSP chip is in a Boot Table format, and the domestic DSP chip can analyze the content of the Boot Table format to complete the copying of the program segment. After the compiling of the secondary Bootloader is completed, conversion is required according to the RBL requirement of a DSP manufacturer.

The main core operating system adopts a domestic Reworks operating system which is independently developed by the Chinese electric department 32. The steps of loading the slave cores are as follows, as shown in fig. 3.

Step one: at proper time (usually after initializing the hardware resource needed to be used by the slave core), the master core operating system reads the environment variable from the Flash, obtains the programming addresses of ELF format bare metal programs of 7 slave cores in the Flash and starts the slave cores;

step two: starting from Core 1, checking core_mask to determine if the Core is started;

step three: if the core is started, further reading a bare metal program of the core from Flash, analyzing an ELF (executable file function) head, acquiring an entry ADDRESS, setting the entry ADDRESS at a BOOT_MAGIC_ADDRESS ADDRESS of the core, analyzing program segment information, copying the program segment into a memory, interrupting IPC (Internet protocol) of the core, and enabling the core to operate; if the core does not start, the next core is checked directly.

Step four: and the cores 2 to 7 execute the second step and the third step. And (5) ending.

The default compiling and generating out files of the CCS development environment of TI and the Rede development environment of China electric department 32 are in ELF format, so that the consistency of the JTAG simulator debugging program and the burnt files is ensured, and the ELF format files are directly used by the main core operating system image and the bare metal programs of the secondary cores. The secondary Bootloader loads the operating system image of the main core, and the operating system of the main core loads the bare metal program of the auxiliary core, which all need to analyze and load the executable file in the ELF format. The ELF format executable file is constructed as shown in FIG. 4, and the parsing and loading process includes the following steps, as shown in FIG. 5.

Step one: and reading the ELF header from the Flash, and analyzing the ELF header. The structure of the ELF header is shown in the code below, where e_entry is the program's entry address, e_phoff is the offset address of the program header table in the ELF file, e_phentsize is the length of each program header in the program header table, and e_phnum is the number of program headers in the program header table.

#define EI_NIDENT 16

typedef struct{

unsigned char e_ident[EI_NIDENT]；

Elf32_Half e_type；

Elf32_Half e_machine；

Elf32_Word e_version；

Elf32_Addr e_entry；

Elf32_Off e_phoff；

Elf32_Off e_shoff；

Elf32_Word e_flags；

Elf32_Half e_ehsize；

Elf32_Half e_phentsize；

Elf32_Half e_phnum；

Elf32_Half e_shentsize；

Elf32_Half e_shnum；

Elf32_Half e_shstrndx；

}Elf32_Ehdr；

Step two: and reading the program header table from the Flash according to the information of the ELF header. The length of the program header table is e_phentsize multiplied by e_phnum.

Step three: and analyzing each program head in the program head table, and loading the program segments into the memory. A program header describes information of a program segment. The format of the program header is shown in the code below, where p_offset is the offset address of the program segment in the ELF file, p_vaddr is the virtual memory address to which the program segment needs to be loaded, p_paddr is the physical memory address to which the program segment needs to be loaded, and p_filesz is the length of the program segment. For a program segment with the length p_filesz >0, the loading of the program segment is completed by reading the segment content from Flash to the memory physical address specified by p_addr.

typedef struct{

Elf32_Word p_type；

Elf32_Off p_offset；

Elf32_Addr p_vaddr；

Elf32_Addr p_paddr；

Elf32_Word p_filesz；

Elf32_Word p_memsz；

Elf32_Word p_flags；

Elf32_Word p_align；

}Elf32_Phdr；

Step four: after the secondary Bootloader loads the program segment of the main core operating system, jumping to an entry address pointed by the e_entry of the ELF head for continuous execution; after the operating system of the main core loads the program segment of the auxiliary core, the BOOT_MAGIC_ADDRESS ADDRESS of the auxiliary core is set as the e_entry value of the ELF head of the bare metal program of the auxiliary core, and the IPC is interrupted to the auxiliary core, so that the auxiliary core runs. And (5) ending.

The procedures of programming the secondary Bootloader, the operating system image of the master core and the bare metal programs of 7 slave cores are consistent, and only the programmed addresses and lengths are different. For either of them, the programming steps are as follows:

step one: loading the file to be programmed into the determined memory by using a JTAG simulator;

step two: and (5) running a programming function to finish erasing, writing, reading and checking.

The programming function is executed for multiple times in the self-defined programming engineering, and the files to be programmed are loaded into the memory by the cooperation of manual operation through single-step execution of the JTAG simulator, so that the programming of all contents can be completed by executing one-time engineering.

The programming environment variable is executed through a special function, and the values of all members of the environment variable are set before programming into Flash. In particular, it is possible to set up which of the slave cores is started and loaded, and the addresses of the operating system of the master core and the bare metal programs of the slave cores to write in Flash. When the programming function is called, the address parameter of the programming function needs to be consistent with the setting of the environment variable, and the length parameter and the data source address parameter need to be consistent with the size of the file to be programmed and the address loaded into the memory.

The code can be conveniently modified through the custom programming engineering, and only part of the content can be programmed at one time, for example, only a bare metal program of a slave core can be programmed, so that the method is very flexible.

Those skilled in the art will appreciate that the systems, apparatus, and their respective modules provided herein may be implemented entirely by logic programming of method steps such that the systems, apparatus, and their respective modules are implemented as logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc., in addition to the systems, apparatus, and their respective modules being implemented as pure computer readable program code. Therefore, the system, the apparatus, and the respective modules thereof provided by the present utility model may be regarded as one hardware component, and the modules included therein for implementing various programs may also be regarded as structures within the hardware component; modules for implementing various functions may also be regarded as being either software programs for implementing the methods or structures within hardware components.

The foregoing describes specific embodiments of the present utility model. It is to be understood that the utility model is not limited to the particular embodiments described above, and that various changes or modifications may be made by those skilled in the art within the scope of the appended claims without affecting the spirit of the utility model. The embodiments of the present application and features in the embodiments may be combined with each other arbitrarily without conflict.

Claims

1. A method for starting multi-core programming of a DSP on Flash is characterized by comprising the following steps:

2. The method for starting multi-core programming of a DSP on Flash according to claim 1, wherein the DSP is a TMS320C6678 chip; the Flash is SPI Flash or EMIF Flash.

3. The method for starting multi-core programming of a DSP on Flash according to claim 1, wherein the step S1 comprises:

4. The method for starting multi-core programming of a DSP on Flash according to claim 3, wherein the space occupied by the environment variable, the secondary BootLoader, the operating system image of the master core, and the bare metal programs of the preset number of slave cores, respectively, are planned in Flash, and do not overlap each other; the preset number of bare metal programs of the slave cores occupy a preset number of Flash spaces.

5. The method for starting multi-core programming of a DSP on Flash according to claim 1, wherein the step S2 comprises: the file format generated by the secondary Bootloader compiling is converted according to the requirement of the ROM Bootloader loader built in the DSP.

6. The method for starting multi-core programming of a DSP on Flash according to claim 1, wherein the programming of the environment variable into Flash comprises: the environment variable is programmed to a corresponding address in Flash, and the operating system mirror image of the master core and the programming address of the bare metal programs of the preset number of slave cores in Flash are set according to the environment variable; and selecting to load the bare metal programs of the corresponding secondary cores according to the environment variable settings.

7. The method for starting multi-core programming of a DSP on Flash according to claim 1, wherein the master operating system image and the bare metal programs of the preset number of slave cores are both in an ELF format, and the ELF format is generated by default compilation of a CCS development environment and a trade development environment without format conversion.

8. The method for starting multi-core programming of a DSP on Flash according to claim 7, wherein the secondary Bootloader and the primary operating system image perform file parsing and load an ELF format file according to the ELF V1.2 standard.

9. A multi-core programming starting system of a DSP on Flash is characterized by comprising the following steps:

10. The system for starting multi-core programming of a DSP on Flash according to claim 9, wherein said module M1 comprises:

the module M2 includes: the file format generated by compiling the secondary Bootloader is converted according to the requirement of a ROM Bootloader built in the DSP;

the DSP is a TMS320C6678 chip; the Flash is SPI Flash or EMIF Flash;