A flash partition identification multi-hardware automatic adaptation method and system

Abstract

The application discloses a flash memory partition identification multi-hardware automatic adaptation method and system, relates to the technical field of embedded system starting, and steps are as follows: presetting hardware type information identification and data check information at the device end, and writing the information into a predefined partition according to a preset format; storing a device tree binary file into a resource image according to a uniform rule; after power-on of the device, a bootloader mounts the predefined partition, automatically matches and extracts the hardware type information identification and check information and checks; if the check is passed, corresponding device trees are parsed, matched and loaded, if the check is not passed or there is no matching file, a preset default device tree is loaded; and the device trees are transmitted to an operating system kernel to complete initialization. The application solves the problems of device tree dynamic selection difficulty, many firmwares in traditional schemes and high operation and maintenance costs in the scene without physical hardware identification signals. The application achieves the goal of no additional hardware and one set of firmware compatible with multiple hardware versions, improves reliability and expandability, and reduces production and operation and maintenance costs.

Description

Technical Field

[0001] This invention relates to the field of embedded system boot technology, and in particular to a flash memory partition recognition method and system for automatic adaptation of multiple hardware components. Background Technology

[0002] In embedded product development, supporting multiple hardware versions on the same SoC platform is a common industry requirement. Different hardware versions often have different specifications of camera modules, sensors, or interface layouts to adapt to differentiated market scenarios. Traditional solutions maintain a separate firmware image for each hardware version. This directly leads to a surge in the number of firmware files, increasing testing and R&D costs, making the production burning process cumbersome, the OTA upgrade process complex, and increasing the difficulty of maintenance. Existing improved solutions for multi-hardware version adaptation have limitations: one type of solution relies on physical hardware identifiers such as DIP switches, EEPROM, or OTP fuses to store version information for the bootloader to read and identify. However, cost-sensitive products usually do not reserve such additional hardware resources, making this solution difficult to apply in practice. Another type of solution achieves adaptation by detecting peripheral differences through drivers after kernel startup, but it has multiple drawbacks: if the device tree does not match at the initial startup, the system may fail to initialize normally; the driver layer needs to maintain a large amount of conditional branch code, reducing code maintainability; at the same time, it cannot complete necessary hardware initialization operations such as DDR and display backlight during the bootloader stage, affecting system startup stability and adaptation reliability.

[0003] Therefore, there is an urgent need in this field for an automatic hardware adaptation technology that can accurately match the device tree at the bootloader stage without additional hardware resources, be compatible with multiple hardware versions, simplify firmware maintenance and OTA upgrade processes, and improve system reliability. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a flash partition identification method and system for automatic adaptation of multiple hardware, so as to solve the problems of difficulty in dynamic selection of device tree in scenarios without physical hardware identification signals, high firmware maintenance costs, initialization anomalies and low code maintainability caused by kernel boot adaptation in the prior art, thereby realizing one firmware is compatible with multiple hardware versions, improving system boot stability, adaptation reliability and scalability, and meeting the needs of low-cost development, simplified production and OTA upgrade.

[0005] The specific plan is as follows:

[0006] In a first aspect, this application provides a method for automatic adaptation of multiple hardware components for flash memory partition recognition, the method mainly including the following steps:

[0007] S10: The hardware type information identifier is pre-set on the device side, and the data verification information is added and written to the predefined partition in a preset format;

[0008] S20, Name the device tree binary files of each hardware version according to the unified rules of the hardware type information identifier, and store them in the resource image;

[0009] S30, the device powers on and starts up. The bootloader mounts the predefined partition, extracts the hardware type information identifier and the data verification information, and performs verification. If the verification passes, the bootloader parses the hardware type information identifier to obtain the target device type code and the target hardware version code. It then traverses the resource image, automatically matches and extracts the corresponding identifier field from the device tree binary file name, and loads the file that matches the target device type code and the target hardware version code. If the verification fails or there is no matching file, the bootloader loads a preset default device tree binary file.

[0010] S40: The bootloader passes the loaded device tree binary file to the operating system kernel to complete system initialization.

[0011] Furthermore, in step S10, the hardware type information identifier includes at least the target device type code and the target hardware version code; the data verification information is a check code obtained by performing a cyclic redundancy check on the hardware type information identifier.

[0012] Furthermore, in step S10, the predefined partition is located in the flash memory storage unit and is used to separately store the hardware type information identifier and the data verification information; the flash memory storage unit also includes a kernel image partition and a resource image partition.

[0013] Furthermore, in step S20, the format of the unified rule naming includes a device association identifier, a first type of preset separator, and an encoding field. The encoding field is split into two types of encoding subfields by a second type of preset separator, which correspond to the two types of encoding in the hardware type information identifier.

[0014] Further, in step S30, the specific process of performing the verification is as follows: re-execute the cyclic redundancy check calculation on the extracted hardware type information identifier, compare the calculation result with the extracted data verification information, and if the comparison is consistent, the verification passes; otherwise, the verification fails.

[0015] Further, in step S30, automatically matching and extracting files from the resource image includes: filtering a set of candidate files according to the target device type code, and then filtering out the target device tree binary file from the set of candidate files according to the target hardware version code.

[0016] Furthermore, in step S30, if the verification fails, the bootloader outputs verification error information to the debug interface before loading the preset default device tree binary file.

[0017] Furthermore, in step S30, when traversing the resource image, files whose filenames contain the first type of preset delimiter are first filtered out, and then the corresponding identifier field is automatically matched and extracted from the filtered files to exclude invalid files that do not conform to the unified naming rules.

[0018] Furthermore, in step S40, the operating system kernel, based on the received device tree binary file, sequentially completes power management configuration, clock parameter configuration, double data rate memory initialization, and peripheral driver adaptation operations, thereby completing system initialization.

[0019] Secondly, this application provides a flash partition identification multi-hardware automatic adaptation system for implementing the aforementioned flash partition identification multi-hardware automatic adaptation method. The system includes a hardware identification configuration module, a resource image construction module, a boot loading and adaptation module, and a system initialization module.

[0020] The hardware identification configuration module is used to pre-configure hardware type information identifiers on the device side, attach data verification information, and write it into a predefined partition according to a preset format.

[0021] The resource image building module is used to name the device tree binary files of each hardware version according to the unified rules of the hardware type information identifier, and store them in the resource image;

[0022] The bootloader and adaptation module is used to mount the predefined partition, extract the hardware type information identifier and data verification information and perform verification when the device is powered on and started; if the verification passes, it parses the hardware type information identifier to obtain the target device type code and the target hardware version code, traverses the resource image, automatically matches and extracts the corresponding identifier field in the device tree binary file name, and loads the matching device tree binary file; if the verification fails or there is no matching file, it loads the preset default device tree binary file.

[0023] The system initialization module is used to receive the device tree binary file transmitted by the bootloader and adapter module and complete the initialization of the operating system kernel.

[0024] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0025] (1) Hardware identification is achieved by storing logical identifiers in flash memory partitions, which does not require additional hardware resources, is compatible with low-cost platforms, and completes device tree matching during the bootloader stage, effectively avoiding startup anomalies and improving system startup reliability.

[0026] (2) By using the verification mechanism and fault-tolerant design, the system can prevent misreading of the identifier and ensure basic startup capability, improve system stability, and facilitate quick troubleshooting of compatibility issues.

[0027] (3) Adding a new hardware version does not require modifying the core logic; only the corresponding device tree binary file needs to be added. The adaptation cost is low and the cycle is short, which improves the convenience of expansion.

[0028] (4) A single firmware is compatible with multiple hardware variants, simplifying the production burning and OTA upgrade process, reducing firmware maintenance and upgrade costs, and meeting the needs of embedded product differentiation adaptation and efficient operation and maintenance. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0030] Figure 1 A flowchart of a flash memory partition identification method for automatic adaptation of multiple hardware is provided in an embodiment of the present invention;

[0031] Figure 2 This is a block diagram of a flash memory partition recognition multi-hardware automatic adaptation system provided in an embodiment of the present invention. Detailed Implementation

[0032] The present invention will be further described in detail below with reference to a specific application embodiment and accompanying drawings. This embodiment is implemented based on the technical solution of the present invention, and provides detailed implementation methods and specific operation processes, but the scope of protection of the present invention is not limited to the following embodiment.

[0033] Example 1

[0034] Please see Figure 1 This invention provides a technical solution: a method for automatic adaptation of flash memory partition recognition to multiple hardware components. Specifically, it includes the following steps:

[0035] S10: The hardware type information identifier is pre-set on the device side, and data verification information is added and written to the predefined partition in a preset format.

[0036] S101, Determine the hardware type information identifier format: Use a 4-digit fixed-length string in the format SSVV, where SS represents the SoC type code and VV represents the hardware version code. That is, the preset format consists of the SoC type code and the hardware version code. For example, the code for the RV1126 SoC platform is 00, and the code for the IPC hardware version is 01. The two are combined to form the logical identifier 0001.

[0037] S102, Generate preset format configuration and data verification information: Organize the hardware type information identifier into a configuration segment in INI format, and calculate the CRC32 checksum of this configuration segment and write it into the configuration to ensure data integrity. A configuration example is as follows:

[0038] [DEVICE]

[0039] DTB_ID=0001 # 00 represents the RV1126 SoC platform, 01 represents the IPC hardware version

[0040] CRC32=0xA1B2C3D4 # CRC32 checksum calculated for the [DEVICE] configuration section

[0041] S103, Write to predefined flash memory partition: During the equipment production testing phase, the INI configuration, which includes hardware type information identifier and CRC32 check value, is written to the pre-divided devinfo partition of the flash memory using a production line-specific tool such as rkdeveloptool, thus completing the production line programming process.

[0042] S20, name the device tree binary files of each hardware version according to the unified rules of the hardware type information identifier, and store them in the resource image.

[0043] S201, Device Tree File Naming: For device tree binary files (dtb) of different hardware versions, name them according to the unified rule of product name##SS=VV.dtb, where ## and = are fixed separators, and SS and VV correspond to the SoC type code and hardware version code, respectively. A naming example is as follows:

[0044] The file adapted for the RV1126 platform IPC is: ipc##00=01.dtb

[0045] File for adapting Panels on the same platform: panel##00=02.dtb

[0046] S202, Store to resource image: Package all device tree binary files named according to the rules into the resource image resource.img to ensure that the bootloader can directly traverse and access them.

[0047] S30, the device powers on and starts up. The bootloader mounts the predefined partition, extracts the hardware type information identifier and the data verification information, and performs verification. If the verification passes, the bootloader parses the hardware type information identifier to obtain the target device type code and the target hardware version code. It then traverses the resource image, automatically matches and extracts the corresponding identifier field from the device tree binary file name, and loads the file that matches the target device type code and the target hardware version code. If the verification fails or there is no matching file, the bootloader loads the preset default device tree binary file.

[0048] S301, Mounting a predefined partition: After the device is powered on, the bootloader starts first, mounts the devinfo partition in the flash memory, and obtains the INI configuration data stored in the partition.

[0049] S302, Extract and perform verification: The bootloader parses the INI configuration segment, extracts the hardware type information identifier DTB_ID and the corresponding CRC32 check value, then recalculates the CRC32 value of the extracted configuration data and compares it with the extracted check value to determine whether the data is complete and has not been tampered with.

[0050] S303, Parse the encoding information: If the verification passes, split the 4-bit hardware type information identifier into the target device type code SS_id (e.g., 00) and the target hardware version code VV_id (e.g., 01).

[0051] S304, Traverse the resource image and extract identifiers: The bootloader mounts the resource image resource.img, traverses all device tree binary files within it, filters out valid files whose filenames contain the fixed separator ##, splits the filenames according to naming rules, and extracts the device type code SS_file and hardware version code VV_file from each file. The key bootloader code logic for this process is as follows:

[0052] / / Target hardware identifier (DTB_ID extracted from the devinfo partition, SS=00, VV=01)

[0053] char dtb_id[5] = "0001";

[0054] / / Traverse all device tree files in the resource image

[0055] for (each dtb in list) {

[0056] / / Filter valid device tree files containing the fixed delimiter "##" (conforming to naming rules)

[0057] if (strstr(dtb.name, "##")) {

[0058] / / Parse the SoC code (SS) and hardware version code (VV) in the filename.

[0059] parse_soc_ver(dtb.name,&soc,&ver);

[0060] / / Match the target encoding; if they match, load the device tree.

[0061] if (!strcmp(soc, "00")&&!strcmp(ver, "01")) {

[0062] fdt_load(dtb.data); / / Load the device tree into memory

[0063] break; / / Match successful, exit iteration.

[0064] }

[0065] }

[0066] }

[0067] S305, Matching and Loading: The extracted SS_file and VV_file are compared with SS_id and VV_id. If a completely identical match is found, the device tree binary file is loaded into memory. If the hardware identifier verification fails or no matching file is found after traversal, the bootloader automatically loads the preset default device tree binary file and records the error log for subsequent troubleshooting.

[0068] S40: The bootloader passes the loaded device tree binary file to the operating system kernel to complete system initialization.

[0069] S401, Passing Device Tree File: The bootloader passes the device tree binary file, either the matching file or the default file, that is loaded in memory to the Linux kernel.

[0070] S402, complete system initialization: Based on the received device tree, the Linux kernel sequentially completes early hardware initialization operations such as power management, clock configuration, DDR initialization, and peripheral driver adaptation, and then starts the complete system to achieve automatic adaptation and operation of multiple hardware versions.

[0071] Accordingly, see Figure 2As shown, this application also provides a flash partition identification multi-hardware automatic adaptation system for implementing the aforementioned flash partition identification multi-hardware automatic adaptation method. The system includes a hardware identification configuration module, a resource image construction module, a boot loading and adaptation module, and a system initialization module.

[0072] The hardware identification configuration module is used to pre-configure hardware type information identifiers on the device side, attach data verification information, and write it to a predefined partition in a preset format.

[0073] The resource image building module is used to name the device tree binary files of each hardware version according to the unified rules of the hardware type information identifier, and store them in the resource image;

[0074] The bootloader and adaptation module is used to mount the predefined partition, extract the hardware type information identifier and data verification information and perform verification when the device is powered on and started; if the verification passes, it parses the hardware type information identifier to obtain the target device type code and the target hardware version code, traverses the resource image, automatically matches and extracts the corresponding identifier field in the device tree binary file name, and loads the matching device tree binary file; if the verification fails or there is no matching file, it loads the preset default device tree binary file.

[0075] The system initialization module is used to receive the device tree binary file transmitted by the bootloader and adapter module and complete the initialization of the operating system kernel.

[0076] In summary, this invention achieves automatic adaptation of multiple hardware versions of embedded devices without additional hardware resources. It utilizes flash memory's devinfo partitioning to store logical identifiers and dynamically matches the device tree during the bootloader phase, enabling a single firmware version to be compatible with various hardware versions. This effectively solves the problems of escalating firmware quantity, high testing costs, and complex OTA upgrades in traditional solutions; the difficulty of dynamically selecting the device tree in scenarios without physical hardware identification signals; and the issues of system initialization failure, low code maintainability, and inability to complete necessary hardware initialization during the bootloader phase caused by driver detection and adaptation after kernel startup. Furthermore, it improves system reliability and scalability, reduces firmware maintenance, production flashing, and OTA upgrade costs, and enhances the versatility of the solution on low-cost embedded platforms.

[0077] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0078] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for automatic adaptation of multiple hardware components to flash memory partition recognition, characterized in that, Includes the following steps: S10, a hardware type information identifier is pre-set on the device side, and data verification information is added and written to a predefined partition according to a preset format. The hardware type information identifier adopts a fixed-length string format and is composed of system-level chip type code and hardware version code. The preset format is a configuration segment organized according to the initialization file format. The data verification information is a cyclic redundancy check value calculated from the configuration segment. S20, Name the device tree binary files of each hardware version according to the unified rules of the hardware type information identifier, and store them in the resource image; S30, the device powers on and starts up. The bootloader mounts the predefined partition, extracts the hardware type information identifier and the data verification information, and performs verification. The verification specifically involves: recalculating the cyclic redundancy check on the extracted hardware type information identifier, comparing the calculation result with the extracted data verification information; if the verification passes, the bootloader parses the hardware type information identifier to obtain the target device type code and the target hardware version code, traverses the resource image, automatically matches and extracts the corresponding identifier field in the device tree binary file name, and loads the file that matches the target device type code and the target hardware version code. When traversing the resource image, valid files whose filenames contain fixed delimiters are filtered out, and the system-level chip type code and hardware version code of the valid files are parsed out and matched with the target device type code and the target hardware version code; If the verification fails or no matching file is found, the bootloader loads the preset default device tree binary file. S40, the bootloader passes the loaded device tree binary file to the operating system kernel to complete system initialization; the device tree binary file is a matching file or a default file.

2. The method for automatic adaptation of multiple hardware components for flash memory partition recognition according to claim 1, characterized in that, In step S10, the predefined partition is located in the flash memory storage unit and is used to separately store the hardware type information identifier and the data verification information.

3. The method for automatic adaptation of multiple hardware components for flash memory partition recognition according to claim 1, characterized in that, In step S20, the format of the unified rule naming includes a device association identifier, a first type of preset separator, and an encoding field. The encoding field is split into two types of encoding subfields by a second type of preset separator, which correspond to the two types of encoding in the hardware type information identifier.

4. The method for automatic adaptation of multiple hardware components for flash memory partition recognition according to claim 1, characterized in that, In step S30, automatically matching and extracting files from the resource image includes: filtering a set of candidate files according to the target device type encoding, and selecting binary files of the target device tree from the set of candidate files.

5. The method for automatic adaptation of multiple hardware components for flash memory partition recognition according to claim 1, characterized in that, In step S30, if the verification fails, the bootloader outputs verification error information to the debug interface before loading the preset default device tree binary file.

6. The method for automatic adaptation of multiple hardware components for flash memory partition recognition according to claim 1, characterized in that, In step S30, when traversing the resource image, files whose filenames contain the first type of preset delimiter are first filtered out, and then the corresponding identifier field is automatically matched and extracted from the filtered files to exclude invalid files that do not conform to the unified naming rules.

7. The method for automatic adaptation of multiple hardware components for flash memory partition recognition according to claim 1, characterized in that, In step S40, the operating system kernel, based on the received device tree binary file, sequentially completes power management configuration, clock parameter configuration, double data rate memory initialization, and peripheral driver adaptation operations, thereby completing system initialization.

8. A flash memory partition recognition multi-hardware automatic adaptation system, used to implement the method as described in any one of claims 1 to 7, characterized in that, The system includes a hardware identification configuration module, a resource image construction module, a boot loading and adaptation module, and a system initialization module; The hardware identification configuration module is used to pre-configure hardware type information identifiers on the device side, attach data verification information, and write it into a predefined partition according to a preset format. The resource image building module is used to name the device tree binary files of each hardware version according to the unified rules of the hardware type information identifier, and store them in the resource image; The boot loading and adaptation module is used to mount the predefined partition, extract the hardware type information identifier and data verification information and perform verification when the device is powered on and started; if the verification is successful, the hardware type information identifier is parsed to obtain the target device type code and the target hardware version code, the resource image is traversed, the corresponding identifier field in the device tree binary file name is automatically matched and extracted, and the matched device tree binary file is loaded. If the verification fails or no matching file is found, the preset default device tree binary file is loaded. The system initialization module is used to receive the device tree binary file transmitted by the bootloader and adapter module and complete the initialization of the operating system kernel.

Images