Embedded device adaptive firmware burning method based on automatic recognition of device model

Abstract

The application provides an embedded device adaptive firmware programming method based on automatic identification of device models. The method automatically captures hardware models through serial port logs, and realizes accurate classification of programming models by combining three-stage progressive mapping rules. In combination with a two-stage dynamic password authentication mechanism, the method effectively solves the problems of multiple manual interventions and poor adaptability in programming of multiple models. Through a differentiated instruction mapping table, the method realizes automatic matching of programming parameters, and introduces an operation counter fuse mechanism to prevent hardware damage caused by repeated erasing and writing, thereby improving the compatibility of embedded device firmware programming.

Description

Technical Field

[0001] This application relates to the field of embedded device technology, and in particular to an adaptive firmware burning method for embedded devices based on automatic device model identification. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) and embedded technology, smart terminal devices are becoming increasingly diverse and widely used in various fields such as industrial control, smart homes, and consumer electronics. Firmware burning is a crucial and indispensable step in the manufacturing, firmware upgrade, and after-sales maintenance of embedded devices. Traditional firmware burning methods typically rely on dedicated programmers or specific debugging interfaces, using host computer software to write the compiled binary firmware file into the device's non-volatile memory.

[0003] Existing firmware flashing technologies have significant limitations when dealing with production scenarios involving multiple device models and batches. Firstly, different device models often employ different hardware architectures, Flash memory chips, and pin definitions, resulting in differences in parameters such as flashing instructions, memory load addresses, and erase ranges. Current technologies typically require configuring a separate flashing project or configuration file for each device model. Operators must manually select the corresponding configuration file or flashing program when switching production. This reliance on manual intervention is not only inefficient but also highly susceptible to human error leading to incorrect configuration selection, potentially causing flashing failures or even hardware damage (such as bricking the device).

[0004] Secondly, to ensure compatibility with different device models, existing programming tools often adopt a "generalized" or "greatest common denominator" strategy, meaning they use relatively conservative programming parameters to adapt to various devices. While this approach improves compatibility, it often sacrifices programming efficiency and optimal device performance. For example, it cannot perform optimal erase / write operations for the Flash characteristics of a specific device, or it cannot utilize the debugging interface during specific operating phases of the device for high-speed programming.

[0005] Therefore, how to automatically identify device models, dynamically adapt and program burning parameters, and improve the firmware burning compatibility of embedded devices has become an urgent technical problem to be solved. Summary of the Invention

[0006] This application provides an adaptive firmware burning method for embedded devices based on automatic device model identification, so as to improve the firmware burning compatibility of embedded devices.

[0007] In a first aspect, this application provides an embedded device adaptive firmware burning method based on automatic device model identification, the method comprising: By monitoring the startup log output after the device is powered on via serial port, the hardware model string of the device is captured using regular expressions, and the hardware model string is classified as an internal programming model identifier according to a preset three-level progressive mapping rule. The system timestamps of the first and second running stages are captured from the startup log output, and the first authentication password corresponding to the first running stage and the second authentication password corresponding to the second running stage are generated by combining them with the hardware model string. After successfully authenticating the first authentication password and the second authentication password through the state machine, the internal programming model identifier is used as the index key to match the target programming instruction sequence from the predefined differentiated programming instruction mapping table; The programming process is executed according to the target programming instruction sequence, and the programming process is terminated when the erase operation counter and / or write operation counter reach the preset upper limit.

[0008] Secondly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the above-described method for automatically identifying embedded device model and adaptive firmware burning.

[0009] This application discloses an adaptive firmware burning method for embedded devices based on automatic device model identification. The method includes: monitoring the startup log output after the device is powered on via a serial port; capturing the device's hardware model string using regular expressions and classifying the hardware model string as an internal burning model identifier according to a preset three-level progressive mapping rule; capturing the system timestamps of the first and second running stages from the startup log output, and generating a first authentication password corresponding to the first running stage and a second authentication password corresponding to the second running stage, respectively, in combination with the hardware model string; after successful authentication of the first and second authentication passwords through a state machine, using the internal burning model identifier as an index key to match a target burning instruction sequence from a predefined differentiated burning instruction mapping table; executing the burning process according to the target burning instruction sequence, and terminating the burning process when the erase operation counter and / or write operation counter reach a preset upper limit. Through the above methods, this application automatically captures the hardware model through serial port logs and achieves accurate classification of the burning model by combining a three-level progressive mapping rule. With the help of a two-stage dynamic password authentication mechanism, it effectively solves the problems of excessive manual intervention and poor adaptability in the burning of multiple device models. It achieves automatic matching of burning parameters through a differentiated instruction mapping table and introduces an operation counter fuse mechanism to prevent repeated erasure and writing from causing hardware damage, thereby improving the firmware burning compatibility of embedded devices. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic flowchart of an embedded device adaptive firmware burning method based on device model automatic identification provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0014] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0015] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] This application provides an embedded device adaptive firmware burning method based on automatic device model identification. This method can be applied to servers, automatically capturing hardware models through serial port logs and accurately classifying burning models using a three-level progressive mapping rule. Combined with a two-stage dynamic password authentication mechanism, it effectively solves the problems of excessive manual intervention and poor adaptability in burning multiple device models. Furthermore, it achieves automatic matching of burning parameters through a differentiated instruction mapping table and introduces an operation counter fuse mechanism to prevent hardware damage caused by repeated erasure and rewriting, thus improving the compatibility of embedded device firmware burning.

[0017] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0018] Please see Figure 1 , Figure 1 This is a schematic flowchart illustrating an embedded device adaptive firmware burning method based on device model automatic identification, provided in an embodiment of this application. This embedded device adaptive firmware burning method based on device model automatic identification can be applied to servers to improve the compatibility of embedded device firmware burning.

[0019] like Figure 1 As shown, the embedded device adaptive firmware burning method based on device model automatic identification specifically includes steps S10 to S40.

[0020] Step S10: Listen to the startup log output after the device is powered on via serial port, capture the hardware model string of the device using regular expressions, and classify the hardware model string as the internal burning model identifier according to the preset three-level progressive mapping rules. Specifically, after the device is powered on, the serial port monitoring thread of the host computer tool continuously reads the startup log output by the device through the serial port. In the log text stream, a regular expression matcher scans in real time for the existence of hardware model strings prefixed with "JA-", such as JA-B14, JA-A10, or JA-K22J. Once a string matching the condition is captured, it is sent to a three-level progressive classification engine for processing. The first level checks by prefix prediction; if the model starts with "JA-A", it is directly classified as an A-series burning model, and Flash capacity testing is required later. The second level matches non-A-series models using a precise mapping dictionary. The dictionary predefines the mapping relationship between models such as JA-B14, JA-B1E, JA-B1H, JA-K12, JA-K2L, JA-B15, JA-K22, JA-K22J, and JA-K3L and their corresponding internal identifiers. The third level is a fallback rule. If the first two levels fail, the model number preset by the user in the GUI interface is used as the final identifier to ensure that the flashing process can continue in case of abnormalities. After three levels of progressive classification, the original model number string is uniformly converted into an internal flashing model identifier, which serves as the index key for all subsequent differentiated processing.

[0021] Step S20: Capture the system timestamps of the first running stage and the second running stage from the startup log output, and generate a first authentication password corresponding to the first running stage and a second authentication password corresponding to the second running stage by combining the hardware model string. Specifically, while the host computer tool completes model capture, the serial port monitoring thread continues to capture system timestamps from the device output in real time for two key stages. The first stage is the Linux system startup stage, during which the device is in the operating system environment, and the host computer tool captures the system timestamp string output by the Linux kernel. The second stage is the U-Boot bootloader stage after the device restarts, during which the host computer tool captures the timestamp string output by U-Boot.

[0022] For the Linux stage, the host computer tool generates a 20-digit hexadecimal string as the first authentication password based on the captured timestamp and the model string obtained in step S10, using a specific key material construction method and SHA256 hash operation.

[0023] For the U-Boot phase, the host computer tool employs a separate, custom bitwise transformation algorithm to perform a series of transformations on the timestamp data, including adjacent character bitwise combination, nonlinear scattering padding, and hexadecimal conversion, generating a 32-bit string as the second authentication password. The entire password authentication process is managed by a strict state machine, which sequentially goes through an idle state, a Linux password waiting state, a U-Boot reboot state, a U-Boot password input waiting state, and a U-Boot login success state. This ensures that each password is submitted only in its corresponding session phase, preventing authentication failure due to phase misalignment.

[0024] Step S30: After successfully authenticating the first authentication password and the second authentication password through the state machine, the internal programming model identifier is used as the index key to match the target programming instruction sequence from the predefined differentiated programming instruction mapping table; Specifically, after the state machine confirms that both the first and second authentication passwords have successfully passed device verification, the host computer tool uses the internal programming model identifier finally determined in step S10 as the index key to perform a lookup operation from the predefined differentiated programming instruction mapping table. This mapping table is a dictionary structure with the model identifier as the key and the instruction sequence as the value, which contains complete difference information for all models in four dimensions: memory load address, Flash command type, erase range, write length, and SD card device number. For example, the instruction sequence corresponding to the A series 8MB model includes parameters such as memory initialization range of 0x800000, using sf series commands for erasure and writing, and SD card device number of mmc0; the instruction sequence corresponding to the B15 model uses nand series commands, erase range of 0x8000000, and SD card device number of mmc1. The host computer tool quickly obtains the target programming instruction sequence that perfectly matches the current device model through a lookup operation with O(1) time complexity. If the current device is an A series and the Flash capacity test has not yet been completed, the capacity test step will be performed first. Based on the test results, the instruction subset corresponding to A series 8MB or A series_16MB will be selected before matching.

[0025] The differences between all models across four dimensions (memory load address, Flash command type, erase / write range, and SD card device number) are encapsulated in a dictionary structure (burn_commands_map) with the model identifier as the key and the instruction sequence as the value. At runtime, the complete instruction sequence is retrieved by looking up the table using the classification result as the key in time complexity. Adding a new model only requires adding a dictionary entry, requiring zero modification to the core scheduling engine.

[0026] As shown in Table 1, Table 1 is a comparison table of all model differentiation instructions.

[0027] Table 1 Step S40: Execute the burning process according to the target burning instruction sequence, and terminate the burning process when the erase operation counter and / or write operation counter reach the preset upper limit.

[0028] Specifically, the host computer tool sends the burning commands to the device's serial port one by one according to the target burning command sequence and waits for the execution results. The command execution engine maintains two independent counters, one for recording the number of erase operations and the other for recording the number of write operations, both with a preset upper limit of one. Before each command is sent, it first checks whether it is an erase or write command. If so, the corresponding counter is incremented by 1, and it is checked whether the upper limit has been exceeded. If the upper limit has been reached, the command is immediately rejected, an error log is recorded, and the entire burning process is terminated. Simultaneously, before executing each command, the host computer tool also checks the serial port connection status. If an abnormal serial port closure is detected (such as a loose USB connection or device power failure), all subsequent operations are immediately terminated and resources are released. Before the formal start of the burning process, the host computer tool has already calculated the MD5 value of the BIN file to be burned on the device's Linux side and compared it with the MD5 value calculated locally on the host computer. Only after ensuring the file integrity is correct is the command execution phase allowed. During instruction execution, the filename placeholder in each instruction is replaced with the target filename that has undergone 8.3 format conversion (i.e., main filename ≤ 8 characters, extension ≤ 3 characters) before step S30, ensuring that U-Boot's FAT file system can be correctly recognized. After all instructions have been executed, the device automatically executes a reset command to complete the burning process.

[0029] This embodiment discloses an adaptive firmware burning method for embedded devices based on automatic device model identification. The method includes: monitoring the startup log output after the device is powered on via a serial port; capturing the device's hardware model string using regular expressions and classifying the hardware model string as an internal burning model identifier according to a preset three-level progressive mapping rule; capturing the system timestamps of the first and second running stages from the startup log output, and generating a first authentication password corresponding to the first running stage and a second authentication password corresponding to the second running stage, respectively, in combination with the hardware model string; after successful authentication of the first and second authentication passwords through a state machine, using the internal burning model identifier as an index key to match a target burning instruction sequence from a predefined differentiated burning instruction mapping table; executing the burning process according to the target burning instruction sequence, and terminating the burning process when the erase operation counter and / or write operation counter reach a preset upper limit. Through the above methods, this application automatically captures the hardware model through serial port logs and achieves accurate classification of the burning model by combining a three-level progressive mapping rule. With the help of a two-stage dynamic password authentication mechanism, it effectively solves the problems of excessive manual intervention and poor adaptability in the burning of multiple device models. It achieves automatic matching of burning parameters through a differentiated instruction mapping table and introduces an operation counter fuse mechanism to prevent repeated erasure and writing from causing hardware damage, thereby improving the firmware burning compatibility of embedded devices.

[0030] based on Figure 1 In the illustrated embodiment, step S10 includes: Determine whether the hardware model string begins with a preset prefix; Specifically, after capturing the hardware model string of the device using regular expressions, the host computer tool first performs a first-level prefix prediction operation. The preset prefix is ​​"JA-A", which corresponds to the A-series devices in the company's product line. The tool compares the captured original model string (e.g., JA-A10, JA-B14, etc.) with the preset prefix to check if it starts with "JA-A". The purpose of this judgment is to preferentially separate A-series devices from the many models, because A-series devices have the special case of different Flash capacities despite having the same appearance, requiring additional capacity detection in subsequent processes.

[0031] If the hardware model string begins with the preset prefix, then the hardware model string is classified as the first series device identifier of the capacity to be tested; Specifically, when the hardware model string is confirmed to begin with "JA-A", the tool directly classifies the device as a first-series device identifier, i.e., "A-series flashing". This identifier is a temporary classification result, and it will need to be further subdivided into 8MB or 16MB versions based on the actual size of the firmware file to select the corresponding subset of flashing instructions. At this point, the tool will not attempt to perform more refined sub-model matching on the model string, but will instead redirect it to a dedicated capacity detection process.

[0032] If the hardware model string does not begin with the preset prefix, then by querying the preset precise mapping dictionary, the hardware model string is classified as the second series device identifier corresponding to the dictionary key value; Specifically, if the hardware model string does not begin with "JA-A", the tool proceeds to the second level of precise mapping. The tool has a pre-built precise mapping dictionary. This dictionary uses the complete original model string (such as "JA-B14", "JA-B1E", "JA-K12", "JA-K22J", etc.) as keys and the corresponding internal programming model identifier (such as "B14", "B1E", "K12", "K22", etc.) as values. The tool searches the dictionary using the captured original model string as the key. If the search matches, it directly returns the corresponding internal programming model identifier, completing the classification. For example, capturing "JA-B14" will classify it as "B14", and capturing "JA-K22J" will classify it as "K22".

[0033] If the hardware model string is not matched in the exact mapping dictionary, then the hardware model string is classified as the preset fallback model identifier.

[0034] Specifically, if classification fails in the first two stages—meaning the model string neither begins with "JA-A" nor finds a match in the exact mapping dictionary—then the third-level fallback rule is invoked. At this point, the host computer tool uses the model manually preset by the operator in the GUI interface as the final classification result. This preset model is a backup model selected by the user via a dropdown menu before starting the flashing process, used to handle extreme anomalies, such as incomplete device startup log output or the new model not yet being added to the mapping dictionary. The tool classifies the device as this preset fallback model identifier and uses it as the basis for subsequent password authentication and command scheduling processes, ensuring the flashing process is not completely interrupted due to model recognition failure.

[0035] based on Figure 1 In the illustrated embodiment, step S20 includes: Capture the system timestamp of the first running stage from the startup log output, and perform a modulo operation on the preset ASCII value of the system timestamp to obtain the offset; Specifically, the host computer tool captures the timestamp string from the boot log output by the device's serial port during the Linux system boot process in real time. This timestamp string typically contains date and time information, in a format such as "Thu Jan 1 12:34:56UTC 2026". The tool locates the position of the last colon in this string and then extracts the second character after the colon. It subtracts 48 from the ASCII value of this character, takes the result modulo 10, and calculates an integer between 0 and 9, which serves as the offset needed for subsequent key material construction. For example, if the second character after the last colon is the number "5", its ASCII value is 53. Subtracting 48 gives 5, and taking the modulo 10 also gives 5, so the offset is 5.

[0036] The key material is constructed by sequentially concatenating the offset, the hardware model string, the preset salt value, and the remaining part of the system timestamp. Specifically, the host computer tool segments the original timestamp string based on the offset. The first offset characters of the timestamp string are taken as the first part, and the remaining portion from the offset position to the end of the timestamp string is taken as the second part. The tool concatenates the following four parts in a fixed order into a complete string as the key material: the first part is the first offset characters of the timestamp; the second part is a colon followed by the hardware model string captured in step S10; the third part is the preset fixed salt value string "JooanV2" followed by a colon; and the fourth part is the remaining portion of the timestamp. After concatenation, a composite string containing timestamp segment information, device model information, and the fixed salt value is obtained.

[0037] Perform a SHA256 hash operation on the key material, and take the first preset number of hexadecimal characters as the first authentication password.

[0038] Specifically, the host computer tool takes the key material as input and performs a standard SHA256 hash operation to obtain a 64-bit hexadecimal hash value string. The first 20 hexadecimal characters are extracted from this hash value string and used as the final initial authentication password. This password is unique and time-sensitive because its generation relies on the system timestamp output in real-time each time the device boots up and a unique device model string; therefore, each burning operation generates a different password. Subsequently, the host computer tool, controlled by a state machine, automatically submits this password to the device when the Linux system login prompt appears, completing the first stage of authentication.

[0039] based on Figure 1 In the illustrated embodiment, step S20 further includes: Capture the system timestamp of the second running phase from the startup log output; Specifically, after the device completes Linux stage authentication, the host computer tool controls the device to reboot into the U-Boot bootloader stage. During the device power-on process, U-Boot outputs its unique boot log via serial port, which includes the system timestamp for the U-Boot stage. The host computer tool's serial port listening thread continuously monitors the output stream, and when it detects log content before the U-Boot prompt appears, it captures the timestamp string for that stage. This timestamp has a different format than the Linux stage, typically being a value output by U-Boot's internal timer or formatted time information.

[0040] The adjacent characters of the system timestamp in the second running phase are combined bit by bit into bytes, and the initial key is generated by nonlinear scattering filling. Specifically, the host computer tool treats the captured U-Boot timestamp string as a continuous character sequence. It performs a bitwise combination operation on this sequence: taking every two adjacent characters and concatenating their binary bits according to a specific rule to form an 8-bit byte. After traversing the entire timestamp string, a byte sequence is obtained. The first 16 bytes of this byte sequence are used as the base of the initial key. For the remaining bytes, the tool uses their lower 4 bits as an index to look up the corresponding padding value in a predefined nonlinear scattering map table, and adds these padding values ​​sequentially to the end of the initial key until the key length is extended to 16 bytes. This nonlinear scattering map table uses predefined permutation rules, ensuring that even slight changes in the timestamp will result in significant differences in the generated key.

[0041] The initial key is converted into a hexadecimal string and used as the second authentication password.

[0042] Specifically, the host computer tool converts the 16-byte initial key byte by byte into a two-digit hexadecimal character representation, ultimately concatenating them into a 32-bit hexadecimal string. This string is the second authentication password. Unlike the Linux stage, the password generation in the U-Boot stage does not rely on the device model string, but is derived from the timestamp itself through complex bit-level transformations, and includes a fixed salt value. Subsequently, the host computer tool, controlled by a state machine, automatically submits this 32-bit password to the device when the U-Boot login prompt appears, completing the authentication for the second operational stage. This password is also unique and time-sensitive; each burning operation generates a different password.

[0043] based on Figure 1 In the illustrated embodiment, the steps preceding step S30 include: In the Linux environment of the device, execute the file size query command to obtain the disk usage of the firmware file to be burned; Specifically, after successfully completing password authentication and logging into the device during the Linux phase, the host computer tool sends a file size query command to the device via serial port. This command specifies that the object of the query is the BIN firmware file to be burned, which has been converted to 8.3 format and copied to the SD card. Upon receiving the command, the device performs a disk usage query operation in the Linux environment, returning the disk space occupied by the file in kilobytes. Due to the potential instability of serial communication, the host computer tool will retry up to three times until a valid file size value is successfully obtained. If the file size is still not obtained after three retries, it is considered a timeout and the entire burning process is terminated.

[0044] The disk usage size is compared with a preset first capacity threshold range and a preset second capacity threshold range, respectively; Specifically, the host computer tool converts the file disk usage size from kilobytes to megabytes, and then compares this value with two preset capacity threshold ranges. The first capacity threshold range is 7.5 megabytes to 8.5 megabytes, corresponding to an 8-megabyte Flash capacity version; the second capacity threshold range is 15.5 megabytes to 16.5 megabytes, corresponding to a 16-megabyte Flash capacity version. There is at least a 7-megabyte gap between these two ranges, with no overlap, ensuring absolute reliability of the judgment. A 0.5-megabyte margin is left at both ends of the range to cover reasonable size fluctuations between different firmware versions.

[0045] If the disk size falls within the first capacity threshold range, the burning model identifier is updated to the first capacity sub-identifier; Specifically, when the file size falls within the range of 7.5 MB to 8.5 MB, the host computer tool determines that the current device's Flash capacity is 8 MB. At this time, the tool updates the internal programming model identifier initially classified as "A-series programming" in step S10 to the specific capacity sub-identifier "A-series_8MB". This sub-identifier will serve as the index key for subsequent instruction scheduling, used to match the corresponding instruction subset from the differentiated programming instruction mapping table. In the matched instruction subset, the memory initialization range, erase command range, and write length are all set to 0x800000, perfectly matching the 8 MB Flash capacity.

[0046] If the disk size falls within the second capacity threshold range, the burning model identifier is updated to the second capacity sub-identifier.

[0047] Specifically, when the file size falls within the range of 15.5 to 16.5 megabytes, the host computer tool determines that the current device's Flash capacity is 16 megabytes. At this time, the tool updates the internal programming model identifier to the specific capacity sub-identifier "A series_16MB". In the instruction subset corresponding to this sub-identifier, the memory initialization range, erase command range, and write length are all set to 0x1000000, perfectly matching the 16 megabyte Flash capacity. If the file size does not meet either of the above two threshold ranges, it is determined to be an abnormal file, and the host computer tool terminates the entire programming process and prompts the user to check if the firmware file is correct.

[0048] In a specific embodiment, the A-series devices have two SPI NOR Flash capacity versions: 8MB and 16MB. Their appearance and PCB board markings are completely identical, making them indistinguishable to production line personnel by visual inspection. However, the memory initialization range, erase range, and write length differ between the two versions: 8MB → 0x800000, 16MB → 0x1000000. Incorrect selection will result in firmware miswriting, preventing the device from booting.

[0049] The `du -k` command on the device's Linux side is used to obtain the disk space occupied by the BIN file on the SD card (KB). This space is then converted to MB and compared with two threshold ranges. An 8MB firmware size will always fall between 7.5-8.5MB, and a 16MB firmware size will always fall between 15.5-16.5MB. The difference between the two ranges is ≥7MB, with no possibility of overlap, resulting in 100% accuracy. A ±0.5MB margin covers reasonable size fluctuations between different firmware versions.

[0050] As shown in Table 2, Table 2 is a comparison table of capacity parameters for Series A.

[0051] Table 2 In a specific embodiment, step S30 includes: When the internal programming model is identified as the first capacity sub-identifier, the first programming instruction sequence containing the first memory load address, the first erase range, and the first write length is matched. Specifically, after the host computer tool updates the internal programming model identifier to "A series 8MB" through capacity detection, the tool uses this identifier as an index key to perform a lookup operation from a predefined differentiated programming instruction mapping table. The instruction sequence corresponding to "A series 8MB" in the mapping table contains the following key parameters: the memory load address is the first memory load address, i.e., 0x80600000; the memory initialization range is 0x800000, corresponding to 8 megabytes; the erase command range is 0x800000, i.e., erasing 8 megabytes of space starting from address 0x0; the write command length is also 0x800000, i.e., writing firmware data to an 8 megabyte Flash area. The complete instruction sequence includes, in sequence: listing SD card files, filling the memory initialization range with the specified address, loading firmware from the SD card to the specified memory address, probing the SPI Flash, erasing the specified Flash range, writing the firmware data in memory to the specified Flash range, and performing a device reset. The filename placeholder in each instruction is replaced with the target filename that has undergone 8.3 format conversion at runtime.

[0052] When the internal programming model is identified as the second capacity sub-identifier, the second programming instruction sequence containing the second memory load address, the second erase range, and the second write length is matched.

[0053] Specifically, after the host computer tool updates the internal burning model identifier to "A series 16MB" through capacity detection, the tool uses this identifier as an index key to look up the corresponding instruction sequence in the differentiated burning instruction mapping table. The instruction sequence corresponding to "A series 16MB" in the mapping table contains the following key parameters: the memory load address is the second memory load address, which is also 0x80600000 (the same as the 8MB version); the memory initialization range is 0x1000000, corresponding to 16 megabytes; the erase command range is 0x1000000, that is, erasing 16 megabytes of space starting from address 0x0; the write command length is also 0x1000000, that is, writing firmware data to a 16 megabyte Flash area. The complete instruction sequence structure is consistent with the 8MB version, but all parameters involving range or length are replaced with values ​​corresponding to 16 megabytes. The two instruction sequences are completely identical in architecture, differing only in the erase range, write length, and memory initialization range, reflecting the design concept of adapting different capacity versions of the same series through parameterized configuration.

[0054] based on Figure 1 In the illustrated embodiment, the steps preceding step S30 include: After authentication via the first authentication password, the version number identifier is extracted from the original firmware file name; Specifically, after successfully authenticating with the Linux stage password and logging into the device, the host computer tool obtains the original firmware filename selected by the user. The original firmware filename is typically in a long format, such as "JOOAN_A10_V05.02.31.45.bin", containing multiple segments of information including the product name and version number. The tool first attempts to match a four-segment version number format, i.e., a pattern like "number.number.number.number", and extracts the last segment as the version number identifier. If the original filename contains a four-segment version number, it extracts the last segment and adds an underscore prefix; for example, extracting "45" yields the version number identifier "_45". If the filename does not contain a four-segment version number, it backtracks by matching the last 1 to 3 consecutive digits of the filename, also adding an underscore prefix as the version number identifier. After extraction, the tool removes the version number pattern from the main name portion of the filename for subsequent cleaning processing.

[0055] The main name portion of the original firmware file name is cleaned and truncated. Specifically, the filename's main name portion, after removing the version number, undergoes a cleaning operation. The cleaning rules include: removing all non-alphanumeric characters, such as underscores, hyphens, and decimal points; and converting all remaining uppercase letters to lowercase. After cleaning, a clean string containing only lowercase letters and numbers is obtained. For example, the original main name "JOOAN_A10_V050231" becomes "jooana10v050231" after cleaning. The tool calculates the maximum length of this string that can be used for concatenation. The formula is: 8 minus the preset prefix length of 1, then minus the length of the version number identifier. Taking the version number identifier "_45" as an example, its length is 3, so the usable length is 8 minus 1 minus 3 equals 4. The tool extracts the first 4 characters from the cleaned string to obtain the truncated main name portion "jooa".

[0056] The preset prefix, the truncated main name portion, and the version number identifier are concatenated to generate a target format file name; Specifically, the tool concatenates the three parts into a complete 8-character main filename in a fixed order. The first part is a preset prefix, fixed as the single character "a", used to identify the source of the file; the second part is the truncated main name from step two, for example, "jooa"; the third part is the version number identifier extracted in step one, for example, "_45". The concatenation of these three parts results in the 8-character main filename "ajooa_45". The tool then adds the file extension ".bin" to this, ultimately generating the target format filename "ajooa_45.bin". This filename strictly adheres to the 8.3 short filename specification, with the main filename not exceeding 8 characters and the extension being 3 characters, while retaining the crucial version number information for easy identification by production line personnel.

[0057] Copy the original firmware file to a file corresponding to the target format filename.

[0058] Specifically, the tool sends a file copy command to the logged-in device's Linux environment via serial port, copying the original long-filename firmware file on the SD card to a new file corresponding to the target format filename generated in step three. Before sending the copy command, the tool first checks if the original file exists using a file list command. If the SD card is not properly mounted (common when the device is first powered on), it automatically executes the mount command and retryes. After the copy command executes successfully, the tool again verifies whether the new file has been successfully created using a file list command. After successful verification, the tool updates the internally referenced filename to the target format filename, and all placeholders for filenames in subsequent burning commands are replaced with this target format filename to ensure that the U-Boot FAT file system can correctly recognize and access the file.

[0059] In a specific embodiment, as shown in Table 3, Table 3 is a file name conversion comparison table for 8.3.

[0060] Table 3 based on Figure 1 In the illustrated embodiment, step S40 includes: Before each erase command is executed, the value of the erase operation counter is checked; Specifically, during the execution of the target programming instruction sequence, the host computer tool pauses the transmission process before sending an erase instruction and checks the current value of the internally maintained erase operation counter. This counter, initialized to 0 at the start of the programming process, is specifically used to record the number of times an erase instruction has been executed during this programming process. The tool identifies the instruction content to determine whether the instruction to be sent is an erase command, such as instructions starting with "sf erase" or "nand erase". If it is confirmed to be an erase instruction, the tool reads the value of the erase operation counter and performs a check before executing the transmission operation.

[0061] If the value of the erase operation counter is greater than or equal to the preset erase upper limit value, the erase instruction is rejected and the burning process is terminated. Specifically, if the current value of the erase operation counter is greater than or equal to the preset erase limit of 1, it indicates that an erase operation has already been performed in this programming process. According to security rules, the erase operation of the Flash chip is only allowed to be performed once in the entire programming process. Repeated erasure may cause physical damage to the chip or data corruption. Therefore, the tool immediately refuses to execute the currently pending erase command, records an error message in the log window indicating that the erase operation has reached the execution limit, and immediately terminates the entire programming process, no longer executing any subsequent commands, while releasing system resources such as the serial port.

[0062] Before each write instruction is executed, the value of the write operation counter is checked; Specifically, similar to the processing logic of erase commands, the host computer tool pauses the sending process and checks the current value of the internally maintained write operation counter when it is about to send a write command. This counter is also initialized to 0 at the beginning of the burning process and is specifically used to record the number of times the write command has been executed during this burning process. The tool identifies whether the command to be sent is a write command by recognizing the command content, such as commands that begin with "sf write" or "nand write". If it is confirmed to be a write command, the tool reads the value of the write operation counter and makes a judgment before executing the sending operation.

[0063] If the value of the write operation counter is greater than or equal to the preset write upper limit, the write instruction is rejected and the burning process is terminated.

[0064] Specifically, if the current value of the write operation counter is greater than or equal to the preset write limit of 1, it indicates that a write operation has already been performed in this programming process. According to security rules, a write operation on the Flash chip is also only allowed to be performed once during the entire programming process. Repeated writing may lead to firmware data corruption or even permanent physical damage to the Flash. Therefore, the tool immediately refuses to execute the currently pending write command, records an error message in the log window, indicates that the write operation has reached the execution limit, and immediately terminates the entire programming process. Through this hard counter fuse mechanism, combined with real-time monitoring of the serial port connection status and MD5 integrity verification before programming, a three-layer security protection system is formed, fundamentally eliminating the risk of repeated erasure and rewriting of the Flash chip due to program abnormalities, serial port interference, or operational errors.

[0065] based on Figure 1 The embodiment shown further includes: Calculate the MD5 value of the firmware file to be burned on the SD card of the device. Specifically, after successfully completing password authentication and logging into the device during the Linux phase, the host computer tool sends an MD5 calculation command to the device via serial port before actually executing the erase and write commands. The command specifies the calculation target as the firmware file on the SD card that has undergone 8.3 format conversion and is to be burned. Upon receiving the command, the device performs an MD5 hash operation on the firmware file to be burned in the Linux environment, generating a 32-bit hexadecimal string as the file's MD5 value. The host computer tool's serial port listening thread waits for the device to return the calculation result and extracts the MD5 value string from the output text. If the SD card is not correctly mounted, the tool will automatically execute the mount command and retry to ensure normal access to the firmware file to be burned.

[0066] The MD5 value of the firmware file to be burned is compared with the MD5 value of the local firmware file to be burned on the host computer. Specifically, when the user selects the firmware file to be burned, the host computer tool has already calculated and recorded the MD5 value of that file locally. The tool then compares the MD5 value obtained from the device in step one with the locally stored MD5 value character by character. These two values ​​should theoretically be completely identical, as they are the hash calculation results of the same firmware file. The purpose of this comparison is to confirm that the firmware file on the SD card has not been damaged or tampered with during transmission or storage, ensuring that the firmware data to be burned into the device's Flash memory is complete and correct.

[0067] If the MD5 value of the firmware file to be burned is inconsistent with the MD5 value of the local firmware file to be burned, the burning process will be refused and terminated.

[0068] Specifically, if the comparison results show that the two MD5 values ​​are inconsistent, it indicates that there is a difference between the firmware file on the SD card and the local file on the host computer, which may be due to reasons such as SD card file corruption, incomplete copying, or storage media failure. In this case, the host computer tool immediately determines that the file integrity verification has failed, refuses to perform subsequent erase and write operations, records detailed information about the MD5 verification failure in the log window, and terminates the entire flashing process. This verification, as the third layer in the three-layer security protection system, together with erase / write counter protection and serial port status monitoring, constitutes a complete protection mechanism, ensuring that only firmware files that have passed integrity verification can enter the actual Flash flashing stage, fundamentally preventing device flashing failure or startup abnormalities caused by file corruption.

[0069] In a specific embodiment, each memory cell of the Flash chip has a fixed erase / write lifespan. Repeated erasing / writing to the same area may cause firmware data corruption or even permanent physical damage. In a production environment, program malfunctions or operational errors may cause the same erase / write instruction to be executed multiple times. Therefore, this embodiment sets up a three-layer security protection system, specifically: The first layer, erase / write operation counters: The `execute_commands` method maintains `erase_count` and `write_count` counters, both with a maximum value of 1. Before each `sf erase` command is executed, `erase_count` is checked to ensure it is greater than 1; if so, execution is refused, an error is reported, and the entire process is terminated. The same applies to the `sf write` command. This ensures that flash erase / write operations are never repeated under any abnormal circumstances.

[0070] The second layer involves real-time monitoring of the serial port connection status: Before executing each command, check_serial_status() is called to check if the serial port is still open. If the USB port becomes loose or the device loses power, causing the serial port to close abnormally, all subsequent operations are immediately terminated and resources are released to prevent incomplete Flash commands from being sent to the device in a partially disconnected state.

[0071] The third layer, device-side MD5 integrity verification: Before burning, the MD5 value of the BIN file on the SD card is calculated on the device's Linux side and compared with the MD5 value calculated locally on the host computer. If they do not match, the burning process is rejected and terminated to prevent firmware incompleteness caused by SD card file corruption.

[0072] As shown in Table 4, Table 4 is a comparison table of security mechanism count protection.

[0073] Table 4 The embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, and the processor executing the program instructions to implement any of the embedded device adaptive firmware burning methods based on device model automatic identification provided in the embodiments of this application.

[0074] The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device.

[0075] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for adaptive firmware burning of embedded devices based on automatic device model identification, characterized in that, include: By monitoring the startup log output after the device is powered on via serial port, the hardware model string of the device is captured using regular expressions, and the hardware model string is classified as an internal programming model identifier according to a preset three-level progressive mapping rule. The system timestamps of the first and second running stages are captured from the startup log output, and the first authentication password corresponding to the first running stage and the second authentication password corresponding to the second running stage are generated by combining them with the hardware model string. After successfully authenticating the first authentication password and the second authentication password through the state machine, the internal programming model identifier is used as an index key to match the target programming instruction sequence from the predefined differentiated programming instruction mapping table; The programming process is executed according to the target programming instruction sequence, and the programming process is terminated when the erase operation counter and / or write operation counter reach the preset upper limit.

2. The embedded device adaptive firmware burning method based on device model automatic identification according to claim 1, characterized in that, The internal programming model identifier includes a first series device identifier, a second series device identifier, and a preset fallback model identifier. The process of classifying the hardware model string into internal programming model identifiers according to a preset three-level progressive mapping rule includes: Determine whether the hardware model string begins with a preset prefix; If the hardware model string begins with the preset prefix, then the hardware model string is classified as the first series device identifier of the capacity to be tested; If the hardware model string does not begin with the preset prefix, then by querying the preset precise mapping dictionary, the hardware model string is classified as the second series device identifier corresponding to the dictionary key value; If the hardware model string is not matched in the exact mapping dictionary, then the hardware model string is classified as the preset fallback model identifier.

3. The embedded device adaptive firmware burning method based on device model automatic identification according to claim 1, characterized in that, The step of capturing system timestamps for the first and second running phases from the boot log output, and generating a first authentication password corresponding to the first running phase and a second authentication password corresponding to the second running phase, respectively, by combining the hardware model string, includes: Capture the system timestamp of the first running stage from the startup log output, and perform a modulo operation on the preset ASCII value of the system timestamp to obtain the offset; The key material is constructed by sequentially concatenating the offset, the hardware model string, the preset salt value, and the remaining part of the system timestamp. Perform a SHA256 hash operation on the key material, and take the first preset number of hexadecimal characters as the first authentication password.

4. The embedded device adaptive firmware burning method based on automatic device model identification according to claim 1, characterized in that, The step of capturing system timestamps for the first and second running phases from the boot log output, and generating a first authentication password corresponding to the first running phase and a second authentication password corresponding to the second running phase, respectively, by combining the hardware model string, includes: Capture the system timestamp of the second running phase from the startup log output; The adjacent characters of the system timestamp in the second running phase are combined bit by bit into bytes, and the initial key is generated by nonlinear scattering filling. The initial key is converted into a hexadecimal string and used as the second authentication password.

5. The embedded device adaptive firmware burning method based on device model automatic identification according to claim 1, characterized in that, After successful authentication of the first and second authentication passwords via the state machine, before matching the target programming instruction sequence from the predefined differentiated programming instruction mapping table using the internal programming model identifier as the index key, the process includes: In the Linux environment of the device, execute the file size query command to obtain the disk usage of the firmware file to be burned; The disk usage size is compared with a preset first capacity threshold range and a preset second capacity threshold range, respectively; If the disk size falls within the first capacity threshold range, the burning model identifier is updated to the first capacity sub-identifier; If the disk size falls within the second capacity threshold range, the burning model identifier is updated to the second capacity sub-identifier.

6. The embedded device adaptive firmware burning method based on device model automatic identification according to claim 5, characterized in that, The target programming instruction sequence includes a first programming instruction sequence and a second programming instruction sequence. After successful authentication of the first and second authentication passwords via the state machine, the internal programming model identifier is used as an index key to match the target programming instruction sequence from a predefined differentiated programming instruction mapping table, including: When the internal programming model is identified as the first capacity sub-identifier, the first programming instruction sequence containing the first memory load address, the first erase range, and the first write length is matched. When the internal programming model is identified as the second capacity sub-identifier, the second programming instruction sequence containing the second memory load address, the second erase range, and the second write length is matched.

7. The embedded device adaptive firmware burning method based on automatic device model identification according to claim 1, characterized in that, After successful authentication of the first and second authentication passwords via the state machine, before matching the target programming instruction sequence from the predefined differentiated programming instruction mapping table using the internal programming model identifier as the index key, the process includes: After authentication via the first authentication password, the version number identifier is extracted from the original firmware file name; The main name portion of the original firmware file name is cleaned and truncated. The preset prefix, the truncated main name portion, and the version number identifier are concatenated to generate a target format file name; Copy the original firmware file to a file corresponding to the target format filename.

8. The embedded device adaptive firmware burning method based on device model automatic identification according to claim 1, characterized in that, The step of executing the programming process according to the target programming instruction sequence, and terminating the programming process when the erase operation counter and / or write operation counter reach a preset upper limit, includes: Before each erase command is executed, the value of the erase operation counter is checked; If the value of the erase operation counter is greater than or equal to the preset erase upper limit value, the erase instruction is rejected and the burning process is terminated. Before each write instruction is executed, the value of the write operation counter is checked; If the value of the write operation counter is greater than or equal to the preset write upper limit, the write instruction is rejected and the burning process is terminated.

9. The embedded device adaptive firmware burning method based on device model automatic identification according to claim 1, characterized in that, The method further includes: Calculate the MD5 value of the firmware file to be burned on the SD card of the device. The MD5 value of the firmware file to be burned is compared with the MD5 value of the local firmware file to be burned on the host computer. If the MD5 value of the firmware file to be burned is inconsistent with the MD5 value of the local firmware file to be burned, the burning process will be refused and terminated.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to implement the embedded device adaptive firmware burning method based on device model automatic identification as described in any one of claims 1 to 9.

Images