A bootimage generation method for multi-core DSP same-engineering program

Abstract

The invention discloses a method for generating a bootimage of a multi-core DSP with the same project program. The method burns the generated bootimage image file into the ROM area of ​​the DSP, so as to automatically load and run the program when the DSP is powered on. Different from multi-core programs based on different projects, the method for generating a bootimage based on the multi-core program with the same project needs to be processed in a targeted manner. A CMD file is configured for each core to generate a .out file of each core and a bootimage image file. The corresponding contents of the .cinit segment and the .text segment of different bootimages are further replaced. All bootimages are connected to generate a final bootimage image file for burning. The method is applicable to all multi-core processors with KeyStone Ι architecture of TI (Texas Instruments) company.

Description

Technical Field

[0001] The invention relates to a bootimage generation method for a multi-core DSP same-engineering program, and belongs to the technical field of DSP multi-core processing. Background Art

[0002] When developing multi-core DSP multi-core programs, you can develop independent projects for different cores, that is, different cores load different .out to run; you can also develop a project, and all the cores load the .out of this project to run, and then distinguish the program functions to be executed by each core in the program by the core number. The latter has the advantage of easy maintenance and simulation debugging in software development, and is also the most commonly used development method at present. When the multi-core program is running without the simulator, it is necessary to generate the corresponding bootimage (image file), such as using the hex6x tool of TI (Texas Instruments) to generate the corresponding bootimage from the .out of the project, burn it into the ROM area such as NORFLASH of the DSP, and power it on and boot it three times before it can run. The first boot program RBL of the DSP loads and moves each segment of data according to the format of the bootimage. This is different from using different projects to generate bootimage. When based on the same project, targeted processing is required to make the generated multi-core bootimage data structure correct, and then after being loaded by RBL, each segment of data in the corresponding memory of each core is correct, and then it continues to run correctly after booting. The current problem with RBL is that if a bootimage is generated for the same project with multiple cores, and the project configures L2SRAM as a relative address, RBL will only load the data configured in L2SRAM into the L2SRAM of core 0, and no data will be loaded into the L2SRAM of other cores. Therefore, in order to use RBL to correctly load data, the L2SRAM address in the CMD file of each core in the original project needs to be configured as an absolute address, and independent projects are formed to generate corresponding bootimages and connected together for burning. However, if the relative address of the original L2SRAM in the project is modified to an absolute address, the data in the .cinit segment and the .text segment may change, which will cause errors in the operation of each core. Therefore, the corresponding contents of these segments in the bootimage files generated for each core need to be modified to achieve correct loading and operation. Summary of the invention

[0003] The technical problem solved by the present invention is: aiming at the problem that the bootimage generated by multi-core same project cannot be correctly loaded and run through RBL in the traditional DSP technology in the current prior art, a bootimage generation method of multi-core DSP same project program is proposed.

[0004] The present invention solves the above technical problems by the following technical solutions:

[0005] A method for generating a bootimage of a multi-core DSP same engineering program, the steps are as follows:

[0006] (1) Take the multi-core DSP project as the original project, configure the CMD file for each core, form an independent project for each core, and generate the .out file for each core accordingly;

[0007] (2) Generate the corresponding bootimage file from the .out file of each core, and find the starting address of the .cinit segment in the .map file of the original image file. According to the address and the configuration of the original project CMD file, determine whether to replace the content of the .cinit segment in the bootimage file corresponding to other cores except core 0 with the content of the .cinit segment of core 0;

[0008] (3) Based on the configuration of the original project CMD file, determine whether to replace the content corresponding to the .text segment of the bootimage image files of other cores except core 0 with the content corresponding to the .text segment of core 0;

[0009] (4) Connect the bootimage files of each core replaced in step (3) to generate a final bootimage file for burning.

[0010] In the step (4), the burned image file is solidified in the ROM area of ​​the DSP when it is powered on, and is directly loaded and run by the primary boot program of the DSP.

[0011] In the step (1), during the process of configuring the CMD file of each core, the CMD file of core 0 configures the L2SRAM address as a relative address, and the other cores configure it as an absolute address.

[0012] In the step (2), if the .cinit segment is placed in L2SRAM in the original project CMD file, the .cinit segment content in the bootimage image files corresponding to the cores other than core 0 is replaced with the .cinit segment content of core 0; otherwise, the .cinit segment does not need to be replaced;

[0013] In step (2), if the .cinit segment is replaced, the data length of the new .cinit segment is smaller than the data length of the original .cinit segment, and the data of the segment following the .cinit segment in the image file is moved forward as a whole to cover the excess data of the original .cinit segment.

[0014] In the step (3), if the data segment, including the .bss segment, the .data segment or the code segment .text segment, is placed in the L2SRAM in the original project CMD file, then the .text segment content in the bootimage image file corresponding to other cores except core 0 is replaced with the .text segment content of core 0; otherwise, the .text segment does not need to be replaced.

[0015] In the step (3), the data length does not change when the .text segment is replaced, and has no effect on the subsequent segments of data in the image file.

[0016] The advantages of the present invention compared with the prior art are:

[0017] The present invention provides a method for generating a bootimage for a multi-core DSP same-engineering program, which proposes a universal bootimage file generation scheme for all situations in programming scenarios, is based on the existing TI bootimage generation tool on the market, and further processes the generated bootimage according to the configuration of the CMD file in the actual project, and the processing method is simple and feasible; finally, a bootimage for burning is obtained, which can be correctly loaded and run using the DSP's own boot program RBL. Thus, the problem that the original RBL program cannot correctly load and run the bootimage generated by the multi-core same-engineering program is solved, without the need to develop a corresponding new boot program; the method is easy to operate and realizes the solidified operation of the multi-core same-engineering program. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 Flowchart of algorithm implementation provided for the invention;

[0019] Figure 2 The bootimage data structure diagram provided for the invention; DETAILED DESCRIPTION

[0020] A method for generating a bootimage of a multi-core DSP with the same engineering program, using the multi-core same engineering program of the multi-core DSP, generates a bootimage and burns it into the ROM area of ​​the DSP to realize automatic loading and running of the program upon power-on. The specific steps are as follows:

[0021] (1) Configure the CMD file for each core to generate the .out file for each core;

[0022] (2) Generate the corresponding bootimage file from the .out file of each core, find the starting address of the .cinit segment in the .map file of the original image file, and replace the content of the .cinit segment in the bootimage file corresponding to the cores except core 0 with the starting address of the .cinit segment of core 0 according to the address;

[0023] (3) Replace the contents of the .text segment in the bootimage image files of other cores except core 0 with the contents of the .text segment in core 0;

[0024] (4) Connect the bootimage files of each core replaced in step (3) to generate a final bootimage file for burning.

[0025] Wherein, in step (1), during the process of configuring the CMD file for each core, the address of the independent memory area in the CMD file configuration of core 0 is a relative address, and the addresses of other cores are absolute addresses;

[0026] In step (2), the contents of the .cinit segment in the bootimage file corresponding to the cores other than core 0 are replaced if they are different from those of core 0.

[0027] In step (3), the contents of the .text segment in the bootimage file corresponding to the cores other than core 0 are replaced if they are different from those of core 0.

[0028] The following is further described in conjunction with specific embodiments:

[0029] A method for generating bootimage (image file) for multi-core DSP multi-core same-project programs is proposed. The generated bootimage is burned into the ROM area of ​​DSP, and the program can be automatically loaded and run each time the DSP is powered on. Different from multi-core programs based on different projects, the bootimage generated by multi-core programs based on the same project needs to be processed in a targeted manner. This paper studies it in principle and provides a method for generating the corresponding bootimage using existing tools on the market. It is applicable to all TI (Texas Instruments) KeyStone Ι-type multi-core processors.

[0030] In the current embodiment, the process is as follows Figure 1 As shown, the bootimage data structure is as follows Figure 2 As shown, where:

[0031] (1) If the program is to be automatically loaded and run when powered on without the emulator, it is necessary to use tools such as TI's hex6x to generate the corresponding bootimage from the project's .out and burn it into the DSP's ROM area; the DSP is booted three times to run the program. The data structure of the bootimage is divided into three parts: header address, segment, and end mark. The segment is the segment of the project corresponding to the .out file, and the content of the segment includes the segment length (number of bytes), segment start address, and segment data. After power-on, the DSP's first boot program RBL continuously reads and moves the data of each segment. When it encounters the end mark, it jumps to the initial header address to execute the program corresponding to .out. The data structure of the bootimage is as follows Figure 2 As shown. RBL moves segment data based on absolute addresses. If a multi-core program uses one project, the independent memory area of ​​each core (such as L2SRAM, L1SRAM) will be written as a relative address in the CMD file of the project. The relative address will be considered by RBL as the address of the memory corresponding to core 0, so only the segment data will be moved into the L2SRAM of core 0, etc., and the data will not be moved into other cores, resulting in the inability to run other cores except core 0 after power-on loading. Therefore, it is necessary to modify the CMD file for other cores except core 0, rewrite the above relative addresses into the absolute addresses corresponding to each core and generate the corresponding .out files; generate the corresponding bootimage for each .out file, and finally connect all bootimages, so that RBL can move each segment data into the memory of each core.

[0032] (2) Since the same project program, each core shares the code segment (.text segment), so the addresses of program data in the code segment are all relative addresses; if the original project places the data segment in an independent memory area such as L2SRAM, each core will operate global variables and other data in its own L2SRAM when the program is executed. If the relative address of L2SRAM in each core's CMD file is rewritten as an absolute address to generate .out, the .cinit segment will change, and its segment start address offset will remain unchanged, but its segment length will be longer than the .out generated based on the relative address, and the segment data will also be different, while other data segments such as the .data segment will not change. When the offset address is the same, after each segment data is moved into the L2SRAM of each core, each core will have the same addressing effect using absolute or relative addresses, but due to different segment lengths and segment data, when executing the program, other cores except core 0 will have errors when using the .cinit segment; therefore, the contents of the .cinit segments of other cores except core 0 need to be replaced with the contents of the segment of core 0, that is, the data content corresponding to the CMD file when the relative address is configured. The method is to find the starting address of the .cinit segment in the .map file of the original project, and convert this address into the absolute address corresponding to each core, find the corresponding .cinit segment in the bootimage corresponding to each core according to this absolute address, and replace the segment length and segment data of the .cinit segment with the corresponding content of the .cinit segment of core 0; here, since the length of the replaced data is smaller than the length of the original data, it has no effect on the subsequent segments of the bootimage. However, after RBL reads and moves the replaced .cinit segment, the next instruction must be the length information of the next segment, so the content of the next segment needs to be moved forward as a whole to cover the redundant data of the original .cinit segment.

[0033] (3) Due to the same project program, each core shares the code segment (.text segment), so the address of the program data in the code segment is a relative address, so the content of the .text segment of each core should be the same as the content of the .text segment of core 0. Therefore, the content of the .text segment of other cores except core 0 needs to be replaced to be consistent with the content of the segment of core 0. The method is to find the starting address of the .text segment in the .map file of the original project. If the .text segment is in an independent memory area such as L2SRAM, then convert the starting address of this segment into the absolute address corresponding to each core; if the .text segment is in a shared memory area (such as DDR3, etc.), no conversion is required; in the corresponding bootimage of each core, find the corresponding .text segment according to the segment starting address of the .text segment, and replace the segment data of the .text segment with the .text segment data of core 0.

[0034] Among them, configuring the address of independent memory areas such as L2SRAM in each core CMD file as a relative address or an absolute address will not affect the segment start address offset and segment length of the .text segment.

[0035] The modified bootimages of each core are connected using commercial tools to generate the final bootimage to be burned; in fact, after testing the multi-core DSP C6678 8 cores based on the same engineering program, the bootimage generated by the method of the present invention can be automatically loaded and run correctly after power-on.

[0036] Although the present invention has been disclosed as above in the form of a preferred embodiment, it is not intended to limit the present invention. Any person skilled in the art may make possible changes and modifications to the technical solution of the present invention by using the methods and technical contents disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope of the technical solution of the present invention.

[0037] The contents not described in detail in the specification of the present invention belong to the common knowledge of those skilled in the art.

Claims

1. A method for generating a bootimage for a multi-core DSP same engineering program, characterized in that Here are the steps: (1) Take the multi-core DSP project as the original project, configure the CMD file for each core, form an independent project for each core, and generate the .out file for each core accordingly; (2) Generate the corresponding bootimage file from the .out file of each core, and find the starting address of the .cinit segment in the .map file of the original image file. According to the address and the configuration of the original project CMD file, determine whether to replace the content of the .cinit segment in the bootimage file corresponding to other cores except core 0 with the content of the .cinit segment of core 0; (3) Based on the configuration of the original project CMD file, determine whether to replace the content corresponding to the .text segment of the bootimage image files of other cores except core 0 with the content corresponding to the .text segment of core 0; (4) Connect the bootimage image files of each core replaced in step (3) to generate a final bootimage image file for burning; In step (1), when each core configures the CMD file, the CMD file of core 0 configures the L2SRAM address as a relative address, and the other cores configure it as an absolute address; In the step (2), if the .cinit segment is placed in L2SRAM in the original project CMD file, the .cinit segment content in the bootimage image file corresponding to the cores other than core 0 is replaced with the .cinit segment content of core 0; Otherwise, there is no need to replace the .cinit section; In the step (2), if the .cinit segment is replaced, the data length of the new .cinit segment is smaller than the data length of the original .cinit segment, and the data of the segment following the .cinit segment in the image file is moved forward as a whole to cover the excess data of the original .cinit segment; In the step (3), if the data segment, including the .bss segment, the .data segment or the code segment .text segment, is placed in the L2SRAM in the original project CMD file, then the .text segment content in the bootimage image file corresponding to the cores other than core 0 is replaced with the .text segment content of core 0; Otherwise, there is no need to replace the .text section; In the step (3), the data length does not change when the .text segment is replaced, and has no effect on the subsequent segments of data in the image file.

2. The method for generating a bootimage of a multi-core DSP same engineering program according to claim 1, characterized in that: In the step (4), the burned image file is solidified in the ROM area of ​​the DSP when it is powered on, and is directly loaded and run by the primary boot program of the DSP.

Images