Embedded chip board level configuration management method and system, chip and storage medium

Abstract

The application relates to the technical field of Internet of Things and industrial control chips, in particular to an embedded chip board-level configuration management method and system, a chip and a storage medium, the method comprises the following steps: obtaining target chip hardware information, performing hardware version matching based on the target chip hardware information and a pre-constructed differential resource table chain to obtain a matching table; when the type of the matching table is a differential resource table, obtaining an offset array based on the offset position of the differential resource table in a differential data buffer, generating a differential application index array based on the offset array and the differential resource table chain, and generating a chip configuration table based on the differential application index array; when the type of the matching table is a differential chain baseline table, generating the chip configuration table based on the differential chain baseline table; and performing hardware resource initialization based on the chip configuration table to obtain embedded chip board-level configuration. The application can realize the storage, adaptive loading and version chain management of multi-hardware version board-level configuration with minimum Flash cost.

Description

Technical Field

[0001] This invention relates to the fields of Internet of Things and industrial control chip technology, specifically to embedded chip board-level configuration management methods, systems, chips, and storage media. Background Technology

[0002] In the design and manufacturing of Internet of Things (IoT) and industrial control SoC (System on a Chip) chips, the same chip often needs to be adapted to multiple hardware revisions of circuit boards. Different circuit board versions differ in GPIO (General Purpose Input / Output) pin assignments, peripheral channel mappings (UART / PWM / ADC / SPI / I2C, etc.), DMA (Direct Memory Access) channel allocation, and multi-core resource allocation. At startup, the chip needs to load the corresponding board resource configuration table based on the actual hardware version to correctly initialize each peripheral. Existing board configuration management solutions mainly include the following methods: Static configuration during compilation determines board-level configuration through conditional compilation macros or configuration header files during the firmware compilation phase. However, this method cannot adapt the same firmware image to multiple hardware versions, requiring firmware recompilation for each hardware update, complicating production line and field upgrade management.

[0003] Runtime full-table storage stores a complete board-level resource table for each hardware version within the Flash OEM (Flash Original Equipment Manufacturer) partition. Assuming a single table is 642 bytes, 10 hardware versions would require 6420 bytes of Flash space. For IoT MCU (Microcontroller Unit) level chips with limited Flash resources (typical Flash capacity 128KB–512KB), this method incurs excessive Flash overhead, which expands linearly with the number of versions. With full-table storage, the Flash space occupied by multiple version configurations increases linearly with the number of versions, while actual differences between versions often involve only a few field changes.

[0004] Linux Device Tree Overlay (DTO) manages hardware differences in embedded devices running operating systems such as Linux using a base device tree file plus overlay files. However, DTO relies on a file system and a relatively heavy parsing framework, making it unsuitable for MCU-level chips (typically 64KB to 256KB of SRAM) with no file system and extremely limited RAM (Random Access Memory) resources.

[0005] General binary differential methods (such as Binary Diff / Binary Patch) use a general binary differential algorithm to manage patches for configuration tables. However, general differential methods are not aware of the data structure layout, patch sizes may become bloated, and they lack version chaining management and integrity verification mechanisms.

[0006] In summary, in embedded SoC chips with limited Flash resources, how to achieve storage, runtime adaptive loading, and version chain management of board-level configurations for multiple hardware versions with minimal Flash overhead, while ensuring the integrity of configuration data and compatibility between new and old formats, is a technical problem that urgently needs to be solved in the current embedded chip board-level configuration management. Summary of the Invention

[0007] The purpose of this invention is to provide an embedded chip board-level configuration management method, system, chip, and storage medium to solve the technical problem that existing embedded chip board-level configuration management cannot achieve storage, runtime adaptive loading, and version chaining management of multiple hardware version board-level configurations with minimal Flash overhead in embedded SoC chips with limited Flash resources.

[0008] In a first aspect, the present invention provides an embedded chip board-level configuration management method, comprising the following steps: Obtain the target chip hardware information, and perform hardware version matching based on the target chip hardware information and the pre-built differential resource table chain to obtain a matching table, wherein the matching table is a differential chain baseline table or a differential resource table; Determine the type of the matching table. When the type of the matching table is a differential resource table, obtain the offset array based on the offset position of the differential resource table in the differential data buffer. Generate a differential application index array based on the offset array and the differential resource table chain. Traverse the differential application index array in reverse order and overwrite it with the configuration buffer to generate a chip configuration table. When the matching table is of type differential chain baseline table, a chip configuration table is generated based on the differential chain baseline table; Hardware resource initialization is performed based on the chip configuration table to obtain the embedded chip board-level configuration.

[0009] The significant effects of this invention are: Compared to existing technologies, this invention stores board-level configuration information through a pre-built differential resource table chain. Only one differential chain baseline table is stored as the complete configuration, while other versions are stored as differential resource tables. When the matching table is a differential resource table, the chip configuration table is generated by overlaying differential data onto the baseline table using an offset array and a differential application index array during the loading process. When the matching table is a differential chain baseline table, the chip configuration table is directly generated based on the baseline table. Compared to the scheme of storing a chip configuration table for each hardware version, this invention significantly reduces flash memory usage in multi-version scenarios.

[0010] During the chip startup phase, the target chip hardware information is acquired, and a matching table corresponding to the current hardware version is obtained from the differential resource list based on the target chip hardware information, thereby generating the chip configuration table. Regardless of how many hardware version configuration information is stored in the differential resource list, the loading process dynamically selects the corresponding matching table and assembles the configuration according to the actual hardware information of the current chip. The same firmware can adapt to multiple hardware versions without recompiling.

[0011] After obtaining the matching table, the type of the matching table is determined. If the matching table is a differential chain baseline table, the chip configuration table is directly generated based on the baseline table without performing additional assembly operations, resulting in the shortest loading path. If the matching table is a differential resource table, the differential data is assembled onto the baseline table using an offset array and a differential application index array to generate the chip configuration table. By determining the branch based on the matching table type, this invention employs differentiated optimal processing paths for different matching scenarios, avoiding redundant operations caused by a uniform process.

[0012] When the matching table is a differential resource table, an offset array is first generated to record the offset position of the differential resource table in the differential data buffer. Then, a differential application index array is generated based on the offset array and the differential resource table chain. Finally, a chip configuration table is generated based on the differential application index array. Through the above steps, the differential resource tables stored in the differential data buffer can be located, indexed, and assembled in the correct order, ultimately resulting in a complete board-level configuration table.

[0013] After generating the chip configuration table, hardware resource initialization is performed based on the chip configuration table. Since the chip configuration table is assembled by matching the corresponding version from the differential resource table chain according to the target chip hardware information, the initialized chip hardware resource configuration is strictly consistent with the actual hardware version of the target chip, ensuring that all peripherals and pins operate correctly according to the target version configuration after the chip starts up.

[0014] Secondly, the present invention provides an embedded chip board-level configuration management system for implementing the embedded chip board-level configuration management method described above, comprising: The differential resource list module is used to store differential resource list chains, including chip-level configuration structures and multiple differential resource tables. Chip hardware information acquisition module, used to acquire target chip hardware information; The matching table generation module is used to obtain a matching table by performing hardware version matching in the differential resource list chain based on the target chip hardware information. The chip configuration table generation module is used to generate a chip configuration table based on the matching table; The embedded chip board-level configuration generation module is used to perform hardware resource initialization based on the chip configuration table to obtain the embedded chip board-level configuration.

[0015] Thirdly, the present invention provides an embedded chip, including a memory, a processor, and a computer program stored in the memory, characterized in that the processor executes the computer program to implement the steps of the above-described embedded chip board-level configuration management method.

[0016] Fourthly, the present invention provides a computer-readable storage medium containing a computer program, wherein the computer program is stored thereon, characterized in that, when the computer program is executed by one or more processors, it implements the steps of the above-described embedded chip board-level configuration management method. Attached Figure Description

[0017] Figure 1 This is a flowchart of the embedded chip board-level configuration management method in an embodiment of the present invention; Figure 2 This is a schematic diagram of the differential resource list structure in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the construction of the differential application index array in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, a clear and complete description will be provided below in conjunction with the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0019] See appendix Figure 1 The embedded chip board-level configuration management method shown includes the following steps: S1. Obtain target chip hardware information, and based on the target chip hardware information, obtain the chip configuration table of the target hardware version from the pre-built differential resource table chain; The differential resource list is pre-built in the offline stage before chip configuration. The structure of the differential resource list is shown in the attached figure. Figure 2 As shown, when constructing the differential resource table chain, multiple hardware version configuration parameters are obtained, and a chip-level configuration structure and multiple differential resource tables are constructed based on these parameters to obtain the differential resource table chain. Within the chip-level configuration structure, a 642-byte space is shared through a union, compatible with both the first-generation complete table format (V0, storing two complete board-level resource configuration tables) and the differential table format (V1, storing one baseline table and subsequent differential chains). The total space of the union is determined by the largest member; that is, the 1284 bytes storing the first-generation complete table format cover the 642 bytes storing the differential table format, with remaining space. However, the differential chain itself is stored after the chip-level configuration structure and does not occupy union space. This ensures that the first-generation complete table format and the differential table format structures are exactly the same size, with zero change to the physical layout of the OEM partition start position.

[0020] Specifically, the chip-level configuration structure includes basic and miscellaneous configuration information, board identification ID, board-level configuration format version number (the lower 6 bits represent the version number of the board-level configuration format, the middle 10 bits are reserved, and the higher 16 bits are used to store the CRC (Cyclic Redundancy Check) check value of the entire configuration area), core union, and subsequent configuration information. When the board-level configuration format version number is the first-generation complete table format, the core union stores two complete configuration tables. When the board-level configuration format version number is the differential table format, the core union stores one differential chain baseline table. The core union only stores the "differential chain baseline table" information, and the actual differential chain data is not included in this structure, but is stored in the storage space immediately following the entire chip-level configuration structure.

[0021] Subsequent configuration information includes IP information, customer-defined configurations, and pad configurations.

[0022] The chip-level configuration structure is stored at the beginning of the partition defined by the flash memory original equipment manufacturer (OEM). Specifically, the chip-level configuration structure is written to the Flash OEM partition in one go by the OEM (Original Equipment Manufacturer) programming tool during the chip manufacturing stage. The programming tool serializes and writes the corresponding baseline board-level resource table and differential list chain (if any) according to the target hardware version of the chip. The specific writing process of the OEM programming tool is existing technology and will not be described in detail here.

[0023] The complete board-level resource configuration table in the first-generation complete table format includes CRC32 checksum (a cyclic redundancy check algorithm with a generator polynomial of 32 bits), hardware version number, pin configuration of 62 pins, configuration of 8 UARTs (Universal Asynchronous Receiver / Transmitter), configuration of 12 PWMs (Pulse Width Modulation), and configuration of 20 ADCs (Analog-to-Digital Converter). The specific structure and storage content of the complete board-level resource configuration table are existing technologies and will not be described in detail here.

[0024] The differential chain baseline table is a complete board-level configuration. Its stored fields include a pin configuration array, peripheral configuration data, and padding fields. The pin configuration array is used to define the physical electrical characteristics and functional multiplexing of individual pins of the chip. The peripheral configuration data is used to define the peripheral connection and / or function configuration information of peripherals such as UART controller, PWM channel, ADC channel, LED gradient controller channel, SPI bus (Serial Peripheral Interface Bus), I2C bus (Inter-Integrated Circuit Bus), spinlock, DMA channel (Direct Memory Access Channel), general-purpose timer, mailbox channel, and watchdog timer. The padding fields are byte-aligned padding and reserved areas.

[0025] The differential resource table consists of a header and a body. The fields in the header are shown in Table 1. Table 1. Header Fields of Differential Resource Table The body of the differential resource table consists of one or more consecutive differential entries. Each differential entry uses a flexible array member design, and the field information in the differential entries is shown in Table 2. Table 2. Differential Resource Table Body Fields The differential resource table describes the changes made to this hardware version relative to its parent version. Each differential entry precisely specifies which bytes in the board-level configuration table need to be modified and their new values. During loading, the differential chain baseline table (the complete table of the parent version) is first copied to a memory buffer, and then the data field of each differential entry is applied to overwrite the specified differential start offset position in the buffer.

[0026] When obtaining the chip configuration table for the target hardware version, a board-level configuration loading function is executed during chip startup to load configuration from the differential resource table chain. This function is responsible for loading the correct board-level resource configuration table from the flash OEM partition, based on the actual hardware version number of the chip, into the global memory variable using a four-stage algorithm, and performing Cyclic Redundancy Check (CRC) integrity verification. This function has no explicit parameters; internally, it obtains the current hardware version number by reading the chip ID register. It returns 0 on success (at which point the memory configuration buffer is filled with the complete board-level configuration matching the current hardware version), and returns an error code on failure. This function is called during the chip power-on startup process, after the secondary bootloader initialization is completed, and before the peripheral driver initialization, and is a key link in the board-level initialization chain. Specifically, it includes the following steps: S101. Based on the target chip hardware information and the differential resource list chain, perform hardware version matching to obtain a matching table; specifically, read the hardware version number in the resource table header, compare it with the actual hardware version number of the chip, and use the table with the same hardware version number as the matching table, and record the position number of the table in the chain; specifically including the following steps: A1. Obtain the actual hardware version number based on the target chip's hardware information; whereby the actual hardware version number can be obtained by reading and parsing the corresponding field parameters from the target chip's hardware ID register, and the specific content of obtaining the hardware version number from the chip's hardware ID register is existing technology.

[0027] A2. Traverse the differential link baseline table within the chip-level configuration structure, obtain the hardware version number from the table header, and compare the hardware version number in the differential link baseline table with the actual hardware version number. If the comparison result is equal, use the current differential link baseline table as the matching table and end the traversal; if the comparison result is not equal, execute: The system checks if there are any subsequent differential resource tables. If no subsequent differential resource tables exist, it means the end of the differential resource table chain has been reached without a match, triggering an assertion error and terminating chip startup. Otherwise, it continues traversing the differential resource tables. During iterative traversal of the differential resource tables, a counter is incremented by 1, and the traversal pointer is moved to the head of the next differential resource table (the offset is the current head's starting offset plus the head's length of 16 bytes plus the current head's length field value), and then the loop continues with comparisons.

[0028] S102. Determine the type of the matching table. When the type of the matching table is a differential resource table, traverse the differential data buffer and record the offset position of each differential resource table in the differential data buffer to obtain the offset array. When the type of the matching table is a differential chain baseline table, directly copy the differential chain baseline table to the configuration buffer to obtain the chip configuration table.

[0029] Specifically, when determining the type of the matching table, after a successful match, the value of the resource table counter is used to determine the type: if the counter is equal to 1, it means that the matching table is the differential chain baseline table itself (i.e., the current hardware version is equal to the baseline version). In this case, the differential chain baseline table is directly copied to the memory configuration buffer to generate the chip configuration table and CRC check is performed. If the resource table counter is greater than or equal to 2, it means that the matching table is a differential resource table and the subsequent stages need to be executed.

[0030] When the matching table type is a differential resource table, during the construction of the offset array, before the board-level configuration load function is executed, all differential table data from the end of the chip-level configuration structure to the end of the chain in the flash OEM partition is copied to the differential data buffer in RAM. B1. Construct and initialize the offset array, specifically keeping the 0th item of the offset array unused (the 0th item corresponds to the differential chain baseline table and is not in the differential data buffer).

[0031] B2. Iterate through the differential resource tables preceding the position in the matching table, using the index of each differential resource table as the element index in the offset array; for each differential resource table, execute: Obtain the differential resource table body length parameter and differential resource table header size. Sum the differential resource table body length parameter, differential resource table header size, and the cumulative offset of the previous differential resource table to obtain the cumulative offset of the current differential resource table and save it to the offset array. This pointer points to the starting offset of the next differential table in the buffer.

[0032] After the traversal is complete, the offset array stores the precise offset of each differential resource table header in the differential data buffer, enabling subsequent stages to directly locate the header of any differential resource table through the offset array.

[0033] S103. Obtain the hardware version number of the differential parent table of the matching table. Based on the hardware version number of the differential parent table, search in the offset array to obtain the differential application index array from the matching table to the baseline table. Specifically, starting from the matching table, use the hardware version number of the differential parent table to search for the parent table in reverse (towards the direction of decreasing index) in the offset array, and trace back along the parent chain to the baseline table, recording the differential table indexes on the path into the differential application index array, thereby determining the correct differential application order. The hardware version number of the differential parent table is obtained by retrieving the hardware version number of the differential parent table from the header of the differential resource table corresponding to the matching table.

[0034] As attached Figure 3 As shown, the steps for obtaining the differential application index array from the matching table to the baseline table by searching the offset array based on the hardware version number of the differential parent table include: C1. Store the index of the matching table into a temporary variable, construct and initialize the differential application index array; when initializing the differential application index array, set the first element of the differential application index array to the index of the matching table, and initialize the differential depth counter to 1.

[0035] C2. Use the hardware version number of the differential parent table of the matching table as the hardware version number of the differential parent table to be searched. C3. Traverse the offset array in reverse order, where the reverse traversal direction is from the element at the end of the offset array to the element at the beginning of the offset array.

[0036] For each differential resource table corresponding to the obtained offset array, the following steps are performed: obtain the corresponding hardware version number of the differential resource table, which is directly obtained from the header field of the differential resource table; when the obtained hardware version number is equal to the hardware version number of the differential parent table to be searched, append the index of the current differential resource table to the differential application index array, initialize the differential depth counter by 1, and set the current differential resource table as the parent table.

[0037] C4. Obtain the mode of the parent table. The mode is obtained based on the mode flag in the header of the corresponding differential resource table. The mode flag is directly obtained from the mode field in the header of the differential resource table. When the mode of the parent table is a complete table, that is, the entire differential application index array reaches its root node baseline table, the parent table is copied to the memory configuration buffer and the traversal ends. Otherwise, it means that the parent table is a differential resource table. Obtain the hardware version number of the differential parent table of the current parent table and use it as the hardware version number of the new differential parent table to be searched. Continue to traverse in reverse in the offset array based on the new hardware version number of the differential parent table to be searched.

[0038] During the iterative traversal based on the hardware version number of the new differential parent table to be searched, each loop identifies the parent table of the current differential resource table and records it in the differential application index array. Then, the pattern flag of the parent table determines whether to continue tracing upwards or terminate. As the loop progresses, the differential application index array is filled sequentially from the matching table towards the baseline table, and the differential depth counter increments accordingly. The loop terminates when the pattern flag of the parent table is determined to be 0 in a certain loop iteration.

[0039] When the parent table found is the baseline table, the complete baseline table data is copied from the baseline table storage location in the chip-level configuration structure to the memory configuration buffer using a memory copy function. After the copy is complete, the buffer stores the most original complete configuration data, and subsequent steps will successively add changes to each difference table based on this data.

[0040] After traversal, the differential application index array stores a sequence of indices for all differential resource tables, starting from the matching table and ascending upwards to the last differential resource table before the baseline table. This sequence is stored in the direction of decreasing index values ​​from the matching table to the baseline table; the 0th item is always the matching table, and the last item is the differential resource table closest to the baseline table. The differential depth counter equals the total number of differential tables to be applied from the first differential table after the baseline table to the matching table.

[0041] S104. Reverse the order of the differential application index array and, based on the reverse traversal result, overwrite the corresponding positions in the configuration buffer with differential data to generate the chip configuration table. Since the differential application index array stores the reverse order from the matching table to the baseline table, and differential applications must evolve forward from the baseline table to the matching table, a reverse traversal is used, starting from the tail of the differential application index array (i.e., the differential table closest to the baseline table) and ending at the head of the differential application index array (i.e., the matching table). During the reverse traversal, the following steps are performed for each differential resource table: D1. Based on the index of the differential resource table, read the differential resource table from the differential data buffer and copy the CRC, hardware version number and other fields in the header of the differential resource table to the corresponding positions in the configuration buffer (for the header information of the final assembled table).

[0042] D2. Calculate the start and end positions of the differential resource table body based on the table body information. The start position of the table body is the differential start offset of the differential resource table plus the length of the differential resource table header. The differential start offset of the differential resource table can be obtained from the start offset of the differential resource table header in the differential data buffer. The length of the differential resource table header is the length of bytes occupied by the differential resource table header. Preferably, in this embodiment, the length of the differential resource table header is 16 bytes.

[0043] The end position of the table body is calculated by adding the data length of the differential block to the end position of the table body. The data length of the differential block can be obtained from the length field in the differential resource table body.

[0044] D3. Based on the start and end positions of the differential resource table body, parse each differential entry one by one, and overwrite the data of the differential entries into the corresponding positions in the memory configuration buffer. Specifically, read the offset, length, and data of each entry, and call the memory copy function to overwrite the data at the starting address of the memory configuration buffer plus the offset of the differential resource table. Repeat the processing of all differential entries until all entries of the differential table have been applied.

[0045] After performing steps D1-D3 on all differential resource tables in the differential application index array, the memory configuration buffer contains the complete configuration data after overlaying all differential changes from the baseline table.

[0046] After obtaining the chip configuration table in step S1, the process also includes performing a CRC32 check on the chip configuration table. Specifically, during the check, the CRC value is calculated from the 4th byte of the chip-level configuration structure (skipping the CRC field itself in the header) to the end of the entire structure. The calculated CRC value is compared with the CRC value stored in the header of the current assembly table. If they are equal, the configuration is valid and loading is successful; if they are not equal, an error is returned, indicating that data in a certain link of the differential chain is corrupted or there is an assembly error. The specific details of the CRC value calculation are existing technology and will not be elaborated here.

[0047] S2. Based on the chip configuration table, hardware resource initialization is performed to obtain the embedded chip board-level configuration. That is, the pin configuration and peripheral configuration information in the memory configuration buffer are read, and the GPIO (General Purpose Input / Output) matrix binding, peripheral controller initialization, DMA channel allocation, and multi-core spinlock initialization of the target chip are completed in sequence, so that the chip hardware resources are put into operation according to the target version configuration.

[0048] Specifically, first, the pin configuration array (62 entries) in the configuration buffer is traversed. For each entry, the GPIO number, core, pin function, input signal, output signal, and purpose fields are extracted. The GPIO matrix setting function is then called to bind the corresponding pin to the specified function and assign it to the specified CPU core. Next, the configuration arrays of various peripherals (UART, PWM, ADC, LEDC, SPI, I2C, spinlock, DMA, general-purpose timer, mailbox, watchdog) are traversed. For each peripheral entry, based on its core and purpose fields, the corresponding peripheral's initialization function is called to configure parameters such as clock, operating mode, and DMA channel mapping. Then, DMA channels are allocated to each peripheral according to the DMA configuration array, establishing data transmission paths. Finally, spinlocks are created or initialized for each CPU core according to the spinlock configuration array, ensuring mutual exclusion of resources in a multi-core environment. At this point, the chip's board-level resource configuration is fully effective, and subsequent applications can run normally under this initialization environment.

[0049] Compared to existing technologies, this solution, through its differential resource table chain storage structure, only requires storing one complete baseline table and several differential resource tables that record only the changed bytes. Specifically, the differential entries adopt a triple format of {offset, length, data}, and each differential resource table only records the actual changed bytes of this hardware version relative to the parent version. Taking a version that modifies only 2 bytes as an example, a differential resource table only requires about 10 bytes (including the table header and entry header), achieving a space saving rate of over 98% compared to storing a complete 642-byte configuration table.

[0050] Furthermore, this solution uses unions within the chip-level configuration structure to share the same storage space. The first-generation complete table format occupies all bytes (two chip configuration tables), while the differential table format occupies only the first 642 bytes (one differential chain baseline table), with the differential resource table stored after the chip-level configuration structure. The total size of the chip-level configuration structure is identical in both formats. Therefore, upgrading from the first-generation complete table format to the differential table format only requires changing the board-level configuration format version number from the value corresponding to the first-generation complete table format to the value corresponding to the differential table format, and appending the differential resource table after the chip-level configuration structure. No changes to the overall physical layout of the OEM partition are necessary.

[0051] In this scheme, the differential resource table header includes a hardware version number field for the differential parent table. This field allows each differential resource table to freely specify any previous version as its differential parent table, rather than being limited to adjacent versions. Therefore, when different versions for multiple product lines derive from the same baseline version, each product line's differential resource table can point its differential parent table's hardware version number to this common baseline version, forming a tree-like inheritance structure. Version branches of different product lines evolve independently without interfering with each other.

[0052] This solution employs a three-stage loading mechanism—offset array generation, differential application index array construction, and reverse application—to decouple the physical storage order of differential resource tables in flash memory from their logical dependencies. Specifically, during loading, the storage location of each differential resource table is first recorded using the offset array. Then, based on the hardware version number of the differential parent table in the header of each differential resource table, the algorithm traces backward from the matching table along the parent chain to the baseline table, constructing the differential application index array. This array accurately records the correct application order from the baseline table to the matching table, and finally, each differential entry is applied in the forward order according to this sequence. Therefore, even if the write order of the differential resource tables in flash memory is inconsistent with the version evolution order, the loading algorithm can still automatically reconstruct the correct application order, reducing the timing constraints on the programming tool.

[0053] The method in this solution only requires a single loading operation during chip startup. This involves traversing the differential resource table chain for version matching (the number of traversals equals the number of differential resource tables), recording offsets (the number of traversals equals the number of differential resource tables preceding the matching table), reverse chain building (the number of traversals equals the differential depth), and forward application of differential entries (the number of traversals equals the total number of differential entries). The computational complexity of each of these steps is linear. Furthermore, in practical applications, the number of differential resource tables is typically less than 10, the total number of differential entries is typically less than 50, and the total loading time is in the microsecond range, significantly improving the configuration loading time during chip startup.

[0054] This invention also aims to provide an embedded chip board-level configuration management system for implementing the embedded chip board-level configuration management method described above, including: The differential resource list module is used to store differential resource list chains, including chip-level configuration structures and multiple differential resource tables. Chip hardware information acquisition module, used to acquire target chip hardware information; The matching table generation module is used to obtain a matching table by performing hardware version matching in the differential resource list chain based on the target chip hardware information. The chip configuration table generation module is used to generate a chip configuration table based on a matching table; the chip configuration table generation module includes: The matching table type determination unit is used to determine whether the matching table is a differential resource table or a differential chain baseline table. The offset array generation unit is used to obtain an offset array based on the offset position of the differential resource table in the differential data buffer when the matching table is of the differential resource table type. The differential application index array generation unit is used to generate a differential application index array based on the offset array and the differential resource list chain; When the matching table is of type differential resource table, the chip configuration table generation module generates the chip configuration table based on the differential application index array; when the matching table is of type differential chain baseline table, the chip configuration table generation module generates the chip configuration table based on the differential chain baseline table.

[0055] The embedded chip board-level configuration generation module is used to perform hardware resource initialization based on the chip configuration table to obtain the embedded chip board-level configuration.

[0056] The present invention also aims to provide an embedded chip, including a memory, a processor, and a computer program stored in the memory, characterized in that the processor executes the computer program to implement the steps of the above-described embedded chip board-level configuration management method.

[0057] The present invention also aims to provide a computer-readable storage medium containing a computer program, wherein the computer program is stored thereon, characterized in that, when the computer program is executed by one or more processors, it implements the steps of the above-described embedded chip board-level configuration management method.

[0058] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the scope of the present invention should be included within the protection scope of the present invention.

Claims

1. An embedded chip board-level configuration management method, characterized in that, Includes the following steps: Obtain the target chip hardware information, and perform hardware version matching based on the target chip hardware information and the pre-built differential resource table chain to obtain a matching table, wherein the matching table is a differential chain baseline table or a differential resource table; Determine the type of the matching table. When the type of the matching table is a differential resource table, obtain the offset array based on the offset position of the differential resource table in the differential data buffer. Generate a differential application index array based on the offset array and the differential resource table chain. Traverse the differential application index array in reverse order and overwrite it with the configuration buffer to generate a chip configuration table. When the matching table is of type differential chain baseline table, a chip configuration table is generated based on the differential chain baseline table; Hardware resource initialization is performed based on the chip configuration table to obtain the embedded chip board-level configuration.

2. The embedded chip board-level configuration management method according to claim 1, characterized in that, The differential resource list chain includes a chip-level configuration structure and multiple differential resource tables. The chip-level configuration structure includes at least one of the following: basic and miscellaneous configuration information, board identification ID, board-level configuration format version number, core union, and subsequent configuration information. When the board-level configuration format version number is the first-generation complete table format, the core consortium stores the complete configuration table; when the board-level configuration format version number is the differential table format, the core consortium stores a differential chain baseline table.

3. The embedded chip board-level configuration management method according to claim 1 or 2, characterized in that, The step of obtaining the matching table by matching hardware versions based on the target chip hardware information and the pre-built differential resource list includes: Obtain the actual hardware version number based on the target chip's hardware information; Traverse the differential chain baseline table within the chip-level configuration structure, obtain the hardware version number of the differential chain baseline table, and compare the hardware version number of the differential chain baseline table with the actual hardware version number. If the comparison result is equal, use the current differential chain baseline table as the matching table; if the comparison result is not equal, then execute: Determine if there are any subsequent differential resource tables. If there are no subsequent differential resource tables, trigger an assertion error and terminate the chip startup. Otherwise, continue to traverse the differential resource tables, obtain the hardware version number of the differential resource table, and compare the hardware version number of the differential resource table with the actual hardware version number. If the comparison result is equal, use the current differential resource table as the matching table.

4. The embedded chip board-level configuration management method according to claim 1 or 2, characterized in that, The step of obtaining the offset array based on the offset position of the differential resource table in the differential data buffer includes: Construct and initialize the offset array; Iterate through the differential resource tables preceding the position in the matching table, using the index of each differential resource table as the element index in the offset array; for each differential resource table, execute: Obtain the differential resource table body length parameter and differential resource table header size. Sum the differential resource table body length parameter, differential resource table header size and the cumulative offset of the previous differential resource table to obtain the cumulative offset of the current differential resource table and save it to the offset array.

5. The embedded chip board-level configuration management method according to claim 1 or 2, characterized in that, The step of generating a differential application index array based on the offset array and the differential resource list chain includes: Construct and initialize the differential application index array; Get the hardware version number of the differential parent table of the matching table, and use the hardware version number of the differential parent table of the matching table as the hardware version number of the differential parent table to be searched. Iterate through the offset array in reverse order, and execute the following steps on the differential resource table corresponding to each offset array obtained from the iteration: Get the corresponding hardware version number of the differential resource table. When the obtained hardware version number is equal to the hardware version number of the differential parent table to be searched, append the index of the current differential resource table to the differential application index array and set the current differential resource table as the parent table. When the parent table's pattern is a complete table, the parent table is copied to the memory configuration buffer, and the traversal ends; otherwise, the hardware version number of the current parent table's differential parent table is obtained and used as the new hardware version number of the differential parent table to be searched, and the reverse traversal in the offset array is continued based on the new hardware version number of the differential parent table to be searched.

6. The embedded chip board-level configuration management method according to claim 1 or 2, characterized in that, When reversing the differential application index array and overwriting it with the configuration buffer to generate the chip configuration table, the following steps are performed for each differential resource table obtained through the traversal: Retrieve the differential resource table and copy it to the configuration buffer; Calculate the start and end positions of the differential resource table body based on the table body information; Based on the start and end positions of the differential resource table body, each differential entry is parsed and its data is overwritten into the corresponding position in the memory configuration buffer. After traversing all differential resource tables in the differential application index array, the complete configuration data is obtained.

7. An embedded chip board-level configuration management system, used to implement the embedded chip board-level configuration management method as described in any one of claims 1-6, characterized in that, include: The differential resource list module is used to store differential resource list chains, including chip-level configuration structures and multiple differential resource tables. Chip hardware information acquisition module, used to acquire target chip hardware information; The matching table generation module is used to obtain a matching table by performing hardware version matching in the differential resource list chain based on the target chip hardware information. The chip configuration table generation module is used to generate a chip configuration table based on the matching table; The embedded chip board-level configuration generation module is used to perform hardware resource initialization based on the chip configuration table to obtain the embedded chip board-level configuration.

8. The embedded chip board-level configuration management system according to claim 7, characterized in that, The chip configuration table generation module includes: The matching table type determination unit is used to determine whether the matching table is a differential resource table or a differential chain baseline table. The offset array generation unit is used to obtain an offset array based on the offset position of the differential resource table in the differential data buffer when the matching table is of the differential resource table type. The differential application index array generation unit is used to generate a differential application index array based on the offset array and the differential resource list chain; When the matching table is of type differential resource table, the chip configuration table generation module generates the chip configuration table based on the differential application index array; when the matching table is of type differential chain baseline table, the chip configuration table generation module generates the chip configuration table based on the differential chain baseline table.

9. An embedded chip, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the embedded chip board-level configuration management method as described in any one of claims 1-6.

10. A computer-readable storage medium containing a computer program, wherein the computer program is stored thereon, characterized in that, When the computer program is executed by one or more processors, it implements the steps of the embedded chip board-level configuration management method according to any one of claims 1-6.

Images