A multi-partition boot method for heterogeneous SOC chips

Abstract

This application relates to a multi-partition boot method for heterogeneous SOC chips. The method includes: a ROM bootloader first reads and parses header file partition data from a fixed address in the boot memory to obtain the number of multiple independent image files, their storage offset addresses, and corresponding processor core identifiers. Based on this information, the number of image files to be loaded is determined, and the image files are read one by one according to their offset addresses. Each image file is parsed to obtain the target processor core identifier, program entry address, and at least one program data block. Each program data block is loaded into a specified address in the SOC memory, and each entry address is written to the entry address register of the corresponding processor core. After all data is loaded, each processor core is started to read its entry address from its register and execute the program, achieving efficient and independent multi-core booting and updating. This method significantly improves the efficiency of the upgrade program.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a multi-partition boot method for heterogeneous SOC chips. Background Technology

[0002] With the continuous application of large-scale and very-large-scale integrated circuits, major chip manufacturers are pursuing higher processor performance, integrating multiple processor cores into a single System-on-a-Chip (SoC). SoCs using the same processor core are called homogeneous SoCs, while SoCs using different processor cores are called heterogeneous SoCs. Homogeneous SoCs have identical processing cores and instruction sets, allowing different cores to execute the same code. However, heterogeneous SoCs have different processor cores and instruction sets, preventing them from using the same code. Therefore, during the boot process of a heterogeneous SoC, code data from multiple cores needs to be transferred. Common heterogeneous SoC architectures include ARM+DSP and ARM+FPGA architectures. In a certain ARM+FPGA heterogeneous SoC, the ROM bootloader of the boot system only handles the secondary boot software. The secondary boot software then loads the FPGA bitstream and the ARM application into memory for execution. The BOOT.bin image data format does not distinguish between the secondary bootloader and the application; instead, it packages the secondary bootloader, the FPGA bitstream, and the ARM application into a single BOOT.bin image file.

[0003] Existing heterogeneous SoC boot solutions require packaging the FPGA and ARM applications into a single BOOT.bin file. In large technology companies, designers often have clearly defined roles, with FPGA and ARM development handled by different developers, possibly from different departments or companies. When upgrading product software, typically only one side's program needs updating. However, existing solutions require executable programs from both sides to generate a complete BOOT.bin file. Therefore, in actual development, this inevitably increases communication costs between the two parties and adds time costs associated with burning a significant amount of unmodified data to the SoC's boot flash device during program upgrades. Summary of the Invention

[0004] Therefore, it is necessary to provide a multi-partition boot method for heterogeneous SOC chips that can greatly improve the efficiency of the upgrade process, addressing the aforementioned technical problems.

[0005] A multi-partition boot method for a heterogeneous SOC chip, the method comprising:

[0006] Step S1: Read and parse the header file partition data from the preset fixed address of the boot memory according to the ROM boot program of the heterogeneous SOC chip; the header file partition data records the number of multiple independent image files stored in the boot memory, the storage offset address of each image file in the boot memory, and the identification information of the target processor core corresponding to each image file.

[0007] Step S2: The ROM bootloader determines the number of image files to be loaded based on the header file partition data, and reads the corresponding image files one by one from the boot memory according to the storage offset address;

[0008] Step S3: Parse each read image file to obtain the identifier of the target processor core, the program entry address, and at least one program data block corresponding to the image file;

[0009] Step S4: Based on the parsed program data block information, load each program data block into the specified address in the heterogeneous SOC chip memory;

[0010] Step S5: Write the program entry address corresponding to each image file into the entry address register in the heterogeneous SOC chip that corresponds to the target processor core identifier of the image file;

[0011] Step S6: After all the program data blocks of the image files have been loaded, the target processor core starts reading the program entry address from its respective entry address register and begins executing the program.

[0012] The above-mentioned multi-partition boot method for heterogeneous SOC chips lays the foundation for efficient upgrades by utilizing the header file partition data read by the ROM boot program. This data clearly records the number of independent image files, storage offset address, and corresponding core identifier, which is equivalent to establishing a precise address file for the program data of each core, replacing the traditional method of packaging all core programs into a BOOT.bin file. Based on this address file, the ROM bootloader determines the number of image files to be loaded according to the header file partition data, and reads the corresponding image files one by one from the boot memory according to the storage offset address. It can directly locate the storage location of each core image file without loading and processing the entire image package. Each image file is parsed to obtain the identifier of the target processor core, the program entry address, and at least one program data block. According to the parsed program data block information, each program data block is loaded into the specified address in the heterogeneous SOC chip memory. The program entry address corresponding to each image file is written into the entry address register in the heterogeneous SOC chip corresponding to the identifier of the target processor core of the image file. The parsing, loading, and entry address configuration are completed for a single image file, and the entire process does not require association with the program data of other cores. The program data of each core is stored separately in independent partitions, and each partition has sufficient space reserved to avoid code overflow. When upgrading the program, the developers only need to find the offset address of the image file corresponding to the core to be upgraded and directly update the data of that partition. There is no need to repackage the programs of all cores to generate a complete image file like in traditional solutions, nor is it necessary to burn a large amount of unmodified data. This not only eliminates the communication costs associated with coordinating and packaging between different development teams, but also significantly reduces the amount of data burned, thereby significantly shortening the upgrade time and ultimately achieving a substantial improvement in the efficiency of the upgrade program. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a multi-partition boot method for a heterogeneous SOC chip in one embodiment;

[0014] Figure 2 This is a schematic diagram illustrating the binary data allocation of each core in a Flash memory in one embodiment;

[0015] Figure 3 This is a schematic diagram of the header file format in one embodiment;

[0016] Figure 4 This is a schematic diagram of the data mirror file format in another embodiment;

[0017] Figure 5 This is a flowchart illustrating the main process of starting a heterogeneous SOC in one embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] In one embodiment, such as Figure 1 As shown, a multi-partition boot method for heterogeneous SOC chips is provided, including the following steps:

[0020] Step S1: Read and parse the header file partition data from the preset fixed address of the boot memory according to the ROM boot program of the heterogeneous SOC chip; the header file partition data records the number of multiple independent image files stored in the boot memory, the storage offset address of each image file in the boot memory, and the identification information of the target processor core corresponding to each image file.

[0021] The boot memory is a non-volatile memory such as SPI Flash, and the default fixed address is address 0 of the boot memory. The structure of the header file partition data is as follows: Figure 3 As shown, it includes a magic word, the number of images, the offset address and core type of each image, and a checksum. The magic word is used to verify the validity of the header file, and the checksum is used to verify the integrity of the header file data.

[0022] Figure 3 In the image, MAGIC_WORD represents the magic word, Image_Count represents the number of image data, Image_Data_x_Offset represents the offset address of the x-th data image file in memory, Image_Data_x_Offset represents the category of the x-th data image file, i.e., which core the program belongs to, such as DSP0, ARM1, and Checksum represents the checksum value.

[0023] Step S2: The ROM bootloader determines the number of image files to be loaded based on the header file partition data, and reads the corresponding image files one by one from the boot memory according to the storage offset address.

[0024] The boot memory is pre-divided in terms of physical storage space into a header file partition and multiple image file partitions, such as Figure 2 As shown, the header file partition is located at the starting address of the boot memory. Each image file partition is associated with the program data of a processor core and is allocated a fixed range of reserved storage space. The ROM bootloader can accurately locate the storage location of each core image file based on the offset address recorded in the header file.

[0025] Step S3: Parse each image file to obtain the identifier of the target processor core, the program entry address, and at least one program data block corresponding to the image file.

[0026] The data image file format is used to represent the data segments of a data image file. It is represented in ImageData format and consists of MAGIC_WORD, the program entry address, the Block data block, and an end marker. One ImageData block may contain multiple Block data blocks. For example, a DSP's compiled executable file contains multiple data segments, each of which needs to be loaded into different memory locations for execution. Each Block needs to determine its data segment length and destination address. See the data format section for details. Figure 4 As shown, it contains a magic word, the program entry address, at least one Block data block, and an end marker. The magic word has a value of 0x43435940 and is used to identify the image file format. The end marker has a value of 0x00000000. Each Block data block contains the data length, the destination address of the data in memory, and the program data content. During parsing, the corresponding information can be extracted according to this format.

[0027] Step S4: Based on the parsed program data block information, load each program data block into the specified address in the heterogeneous SOC chip memory.

[0028] Program data blocks for different processor cores need to be loaded into different specified addresses in memory. For example, the compiled executable file of a DSP contains multiple data segments, each of which needs to be loaded into a different memory region. By parsing the destination address information in the block data block, precise loading can be achieved.

[0029] Step S5: Write the program entry address corresponding to each image file into the entry address register in the heterogeneous SOC chip that corresponds to the target processor core identifier of the image file.

[0030] Each processor core is equipped with a corresponding entry address register. After the parsed program entry address is written into the register, the processor core can directly read the address and jump to execute after power-on.

[0031] Step S6: After all the program data blocks of the image files have been loaded, the target processor core starts reading the program entry address from its respective entry address register and begins executing the program.

[0032] The boot process of a heterogeneous SOC chip is as follows Figure 5As shown, a processor core from the SoC is required as the main boot core. In the 7-core SoC example above, the first ARM core can be used as the boot core to control the chip's boot process. This mainly includes initializing the chip's phase-locked loop, peripheral clock, and reading, parsing, and loading Image data from the non-volatile memory used for booting into memory for execution. In the Image format, a segment of data is read from memory address 0, parsed according to the header file format, first determining whether the magic word is determined, then determining the number of image data (how many kernel programs need to be booted), the number of image file data saved by the boot program, the offset of the data's storage space, and the kernel type to which the image data belongs; secondly, the memory where the data of each image file is located, as determined by the above steps. The system reads data from the address offset of each image file, parses the data according to the ImageData format, and obtains which kernel's program data and kernel's entry address the ImageData represents. All block data of each ImageData is loaded into the chip's memory according to the format requirements, and the entry address of each kernel is written into the corresponding entry address register. Next, after all data loading is complete, the clock is turned on for all slave cores (except the master core). The slave cores read their respective entry addresses from their entry address registers and jump to the entry address to execute the user program. Finally, the master boot core completes the data loading required for the boot process and starts the slave cores, reading the entry address from the master core's entry address register and entering the user program.

[0033] The above-mentioned multi-partition boot method for heterogeneous SOC chips lays the foundation for efficient upgrades by utilizing the header file partition data read by the ROM boot program. This data clearly records the number of independent image files, storage offset address, and corresponding core identifier, which is equivalent to establishing a precise address file for the program data of each core, replacing the traditional method of packaging all core programs into a BOOT.bin file. Based on this address file, the ROM bootloader determines the number of image files to be loaded according to the header file partition data, and reads the corresponding image files one by one from the boot memory according to the storage offset address. It can directly locate the storage location of each core image file without loading and processing the entire image package. Each image file is parsed to obtain the identifier of the target processor core, the program entry address, and at least one program data block. According to the parsed program data block information, each program data block is loaded into the specified address in the heterogeneous SOC chip memory. The program entry address corresponding to each image file is written into the entry address register in the heterogeneous SOC chip corresponding to the identifier of the target processor core of the image file. The parsing, loading, and entry address configuration are completed for a single image file, and the entire process does not require association with the program data of other cores. The program data of each core is stored separately in independent partitions, and each partition has sufficient space reserved to avoid code overflow. When upgrading the program, the developers only need to find the offset address of the image file corresponding to the core to be upgraded and directly update the data of that partition. There is no need to repackage the programs of all cores to generate a complete image file like in traditional solutions, nor is it necessary to burn a large amount of unmodified data. This not only eliminates the communication costs associated with coordinating and packaging between different development teams, but also significantly reduces the amount of data burned, thereby significantly shortening the upgrade time and ultimately achieving a substantial improvement in the efficiency of the upgrade program.

[0034] In one embodiment, the structure of the header file partition data includes:

[0035] The magic word field is used to validate the validity of the header file format;

[0036] The Image Count field indicates the total number of independent image files stored in the boot memory;

[0037] At least one set of image information fields, each set corresponding to one image file, including a storage offset address field and a processor core identifier field;

[0038] The validation field is used to verify the integrity of the header file data.

[0039] Specifically, the header file format is as follows: Figure 3As shown, the magic word value is 0x43435948. The image quantity field records the total number of program images that need to be loaded, such as FPGA cores, ARM cores, and DSP cores. Each image information field specifies the processor core type corresponding to the image, such as DSP0, ARM1, etc., and the offset address of the image in the boot memory. The checksum field is used to verify the integrity of the header file data to avoid boot failure due to data corruption. Using this data structure in the header file enables unified management and precise location of each core image file, improving the reliability of the boot process.

[0040] In one embodiment, the image file has a modular structure, including:

[0041] The image header contains a magic word that identifies the image file format and the program entry address;

[0042] At least one data block, each data block containing the data length, the destination address of the data in memory, and the program data content;

[0043] End marker.

[0044] Specifically, the format of the image file is as follows: Figure 4 As shown, the magic word value is 0x43435940, used to distinguish files of different formats. The program entry address is the starting address of the program executed by the processor core. The number of data blocks can be flexibly set according to program requirements. The length and destination address of each data block are independently configurable. The end flag value is 0x00000000, used to identify the end of the image file data. This modular structure makes the parsing and loading of image files more flexible and efficient, adapting to the program data requirements of different processor cores.

[0045] In one embodiment, the boot memory is pre-divided in physical storage space into a header file partition and multiple image file partitions; wherein the header file partition is located at the starting address of the boot memory; each image file partition is associated with the program data of a processor core and is allocated a reserved fixed range of storage space.

[0046] Specifically, the partition layout of the boot memory is as follows: Figure 2 As shown, the header file partition stores the header.bin file, while the remaining partitions store the image files for each core, such as fpga.bin, dsp_0.bin, arm_0.bin, etc. Each image file partition allocates storage space to meet the current program's requirements, with a reserve of some spare space. For example, if the bitstream of a typical FPGA is 4MB, 4MB of space is allocated, with 1MB reserved. This partitioning method reserves expansion space for program updates of each core, avoiding memory overflow issues during program updates, while also achieving physical isolation of program data across cores.

[0047] In one embodiment, when it is necessary to update the program of a specific processor core in a heterogeneous SOC chip, the following steps are performed:

[0048] Read the header file partition data from the starting address of the boot memory; find the corresponding storage offset address from the header file partition data based on the identifier of the target processor core corresponding to the image file to be updated; burn the updated image file data only to the corresponding storage offset address found in the boot memory, overwriting the original image file data.

[0049] Specifically, during product software upgrades, if only the ARM core program needs updating, developers do not need to obtain program data for other cores such as the FPGA core and DSP core. They only need to read the header file partition data, find the corresponding storage offset address of the ARM core image file, and burn the updated ARM core image file to that address. This update method eliminates the need to repackage the program data for all cores, reducing communication costs between different development teams and avoiding the burning of large amounts of unmodified data, thus significantly shortening the time cost of program updates.

[0050] In one embodiment, when the target processor core includes a field-programmable gate array (FPGA) core, its corresponding image file data is a bitstream file; the ROM bootloader loads the bitstream file into memory and then configures it into the FPGA core.

[0051] Specifically, the FPGA core's program data is a bitstream, typically up to 4MB in size. The ROM bootloader loads this bitstream file into a specified memory address and then configures it into the FPGA core, enabling the FPGA core's program to start. This method allows for independent loading and updating of the FPGA core program compared to other processor core programs, adapting to the specific needs of the FPGA core program.

[0052] In one embodiment, the process of booting the target processor core is performed sequentially, including the ROM bootloader enabling the clock of each target processor core or releasing its reset signal according to a predetermined boot order, so that they start executing in sequence.

[0053] Specifically, the ROM bootloader can set the boot order of the processor cores according to actual needs. For example, the ARM main core can be started first, followed by the DSP core, FPGA core, etc. By enabling the clock of each processor core or releasing the reset signal one by one, the boot order of each processor core can be ensured, thus avoiding resource conflicts caused by simultaneous startup.

[0054] In one embodiment, one processor core in the heterogeneous SOC chip is designated as the master boot core to execute the ROM boot program to complete steps S1 to S5; in step S6, after the master boot core completes the loading of program data and setting of entry addresses for all slave processor cores, it finally starts the slave processor cores other than itself, and then the master boot core jumps to execute its own user program.

[0055] Specifically, the primary boot core is preferably an ARM core. The primary boot core first completes its own initialization, then performs the reading, parsing, and loading of the image file. After all slave cores' program data has been loaded and their entry addresses have been set, the primary boot core starts the slave cores' clocks, enabling them to begin executing their programs. Finally, the primary boot core reads its own entry address register value and jumps to execute its own user program. This boot method, with unified scheduling by the primary boot core, ensures the orderliness and stability of multi-core booting.

[0056] In one embodiment, the target processor core includes any combination of the following types: ARM processor core, digital signal processor core, graphics processor core, neural network processor core, or field-programmable gate array core.

[0057] Specifically, a typical embedded heterogeneous SoC chip may include FPGA cores, DSP cores, ARM cores, AI cores, etc., and there can be more than one of each type of core. For example, an ARM core may have four A15 cores, and a DSP core may have eight C66x cores. Among them, the AI ​​core does not have the ability to actively load data and can only be loaded and run by other processor cores. The multi-partition boot method of this application is adapted to the combination scenarios of various types of processor cores and has wide applicability.

[0058] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0059] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0060] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A multi-partition boot method for a heterogeneous SOC chip, characterized in that, The method includes: Step S1: Read and parse header file partition data from a preset fixed address in the boot memory according to the ROM boot program of the heterogeneous SOC chip; the header file partition data records the number of multiple independent image files stored in the boot memory, the storage offset address of each image file in the boot memory, and the identification information of the target processor core corresponding to each image file; Step S2: The ROM bootloader determines the number of image files to be loaded based on the header file partition data, and reads the corresponding image files one by one from the boot memory according to the storage offset address; Step S3: Parse each read image file to obtain the identifier of the target processor core, the program entry address, and at least one program data block corresponding to the image file; Step S4: Based on the parsed program data block information, load each program data block into the specified address in the heterogeneous SOC chip memory; Step S5: Write the program entry address corresponding to each image file into the entry address register in the heterogeneous SOC chip that corresponds to the target processor core identifier of the image file; Step S6: After all the program data blocks of the image files have been loaded, the target processor core is started to read the program entry address from its respective entry address register and begin executing the program.

2. The method according to claim 1, characterized in that, The structure of the header file partition data includes: The magic word field is used to validate the validity of the header file format; The image quantity field indicates the total number of independent image files stored in the boot memory; At least one set of image information fields, each set corresponding to one image file, including a storage offset address field and a processor core identifier field; The validation field is used to verify the integrity of the header file data.

3. The method according to claim 1, characterized in that, The image file has a modular structure, including: The image header contains a magic word that identifies the image file format and the program entry address; At least one data block, each data block containing the data length, the destination address of the data in memory, and the program data content; End marker.

4. The method according to claim 1, characterized in that, The boot memory is pre-divided in physical storage space into a header file partition and multiple image file partitions; wherein, the header file partition is located at the starting address of the boot memory; each image file partition is associated with the program data of a processor core and is allocated a reserved fixed storage space range.

5. The method according to claim 1, characterized in that, When it is necessary to update the program of a specific processor core in a heterogeneous SOC chip, perform the following steps: Read the header file partition data at the starting address of the boot memory; find the corresponding storage offset address from the header file partition data according to the identifier of the target processor core corresponding to the image file to be updated; burn the updated image file data only to the corresponding storage offset address found in the boot memory, overwriting the original image file data.

6. The method according to claim 1, characterized in that, When the target processor core includes a field-programmable gate array (FPGA) core, its corresponding image file data is a bitstream file; after the ROM bootloader loads the bitstream file into memory, it configures it into the FPGA core.

7. The method according to claim 1, characterized in that, The process of starting the target processor core is performed sequentially, including the ROM boot program enabling the clock of each target processor core or releasing its reset signal according to the predetermined boot order, so that they start executing in sequence.

8. The method according to claim 1, characterized in that, One of the processor cores in the heterogeneous SOC chip is designated as the main boot core to execute the ROM boot program to complete steps S1 to S5; in step S6, after the main boot core completes the loading of program data and setting of entry addresses for all slave processor cores, it finally starts the slave processor cores other than itself, and then the main boot core jumps to execute its own user program.

9. The method according to claim 1, characterized in that, The target processor core includes any combination of the following types: ARM processor core, digital signal processor core, graphics processor core, neural network processor core, or field-programmable gate array core.

Images