A firmware download method, device and storage medium

Abstract

A firmware download method applied to a first computing device, comprising receiving target firmware upgrade compressed data packets and target firmware extension instruction compressed data packets issued by a second computing device; wherein the target firmware upgrade compressed data packets are compressed by using a preset first compression algorithm, the target firmware extension instruction compressed data packets are built-in with decompression codes of a first decompression algorithm matched with the first compression algorithm; the first compression algorithm is generated based on the target firmware and chip parameter configuration information carried by the first computing device. The target firmware extension instruction compressed data packets are decompressed, and the first decompression algorithm obtained after decompression is loaded into RAM for running; the target firmware upgrade compressed data packets are decompressed based on the first decompression algorithm, and the target firmware upgrade data obtained after decompression is stored into a non-volatile memory. In this way, the compression efficiency and decompression performance of the target firmware can be improved, and the target firmware download speed can be effectively accelerated.

Description

Technical Field

[0001] This article relates to the field of firmware upgrade technology, and in particular to a firmware download method, device and storage medium. Background Technology

[0002] The existing bootloader (Boot) adopts a fully functional solidified implementation scheme, in which all business logic and instruction code of the target device are directly compiled and integrated into the Boot. The corresponding Boot firmware upgrade method is the original full direct transmission mode: the host computer transmits complete uncompressed firmware data through the communication interface and writes it directly into the non-volatile memory (such as Flash chip) of the target device.

[0003] In the original full-data transfer mode, the overall firmware download time consists of two parts: the time spent on original firmware data transmission and the time spent writing to memory. Due to the large size of the original firmware, this mode consumes a significant amount of the device's Flash storage space, thus extending the firmware upgrade download time. In embedded terminal scenarios with limited storage resources and communication bandwidth, how to reduce firmware storage space consumption and shorten firmware upgrade download time is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a firmware download method, device, and storage medium that can reduce the storage space occupied by firmware and shorten the firmware download time.

[0005] In a first aspect, embodiments of this application provide a firmware download method applied to a first computing device, wherein the first computing device includes a non-volatile memory and a random access memory (RAM), and a bootloader program (Boot) is pre-stored in the non-volatile memory. The method includes: receiving a target firmware upgrade instruction sent by a second computing device, and in response to the target firmware upgrade instruction, receiving a target firmware upgrade compressed data packet and a target firmware extension instruction compressed data packet issued by the second computing device; wherein the target firmware upgrade compressed data packet is generated using a preset first compression algorithm, and the target firmware extension instruction compressed data packet contains decompression code for a first decompression algorithm compatible with the first compression algorithm; the first compression algorithm is generated based on the target firmware and chip parameter configuration information mounted on the first computing device. Next, the target firmware extension instruction compressed data packet is decompressed, and the decompressed first decompression algorithm is loaded into RAM for execution; the target firmware upgrade compressed data packet is decompressed based on the first decompression algorithm, and the decompressed target firmware upgrade data is stored in the non-volatile memory.

[0006] In this way, when downloading the target firmware, by combining the data characteristics of the target firmware itself with the configuration information of the first computing device chip of the firmware to be downloaded, a compression algorithm adapted to the target firmware is generated and the target firmware is compressed. This improves the compression efficiency and decompression performance of the target firmware, effectively speeding up the download speed. Simultaneously, the decompression code corresponding to the decompression algorithm for decompressing the target firmware is loaded into RAM as extended instructions for the boot program, reducing the size of the boot program's own code and decreasing the storage space occupied by non-volatile memory.

[0007] It is understood that the non-volatile memory in the embodiments of this application can refer to the Flash memory unit integrated on the microcontroller unit (MCU). The non-volatile memory can also be the read-only memory (ROM) integrated on the MCU.

[0008] Secondly, embodiments of this application provide a firmware download method applied to a second computing device. The method includes: acquiring target firmware and chip parameter configuration information of a first computing device; then, generating a first encoding / decoding algorithm based on the target firmware and chip parameter configuration information; then, compressing the target firmware using a first compression algorithm in the first encoding / decoding algorithm to obtain a target firmware compressed upgrade package; then, compressing the first decompression algorithm using a second compression algorithm to obtain a target firmware extended instruction compressed data package; and finally, sending a target firmware upgrade instruction to the first computing device, wherein the target firmware upgrade instruction is used to trigger the Boot program in the non-volatile memory within the first computing device to start the firmware download process.

[0009] In this way, by generating a compression algorithm adapted to the target firmware based on the chip configuration information of the first computing device that needs to download the target firmware, and compressing the target firmware, the compression efficiency and decompression performance of the target firmware can be improved, thereby improving the download efficiency of the target firmware.

[0010] Thirdly, embodiments of this application provide a computing device, including a processor and a memory; Memory, used to store instructions; A processor is configured to execute instructions stored in memory to cause the energy storage device to perform the methods described in the first or second aspect above.

[0011] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program is used to implement the method described in the first or second aspect above.

[0012] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0013] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0014] Figure 1 This is a schematic diagram illustrating how a startup loader is implemented in a computing device. Figure 2 A diagram illustrating the decompression method for firmware compressed data packets; Figure 3 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 4 A schematic diagram illustrating the process of generating a target firmware compressed upgrade data package and a target firmware extended instruction compressed data package, provided in an embodiment of this application; Figure 5 This application provides a schematic diagram illustrating a process for compressing and encoding target firmware in an embodiment. Figure 6 This application provides a schematic diagram illustrating the process of decoding a target firmware compressed data packet in an embodiment. Figure 7 This application provides a schematic diagram illustrating a process for decompressing data at a specified offset address from compressed data, as provided in an embodiment of the present application. Figure 8 A schematic diagram illustrating another process for decompressing data at a specified offset address in compressed data, provided in an embodiment of this application; Figure 9 A schematic diagram illustrating the process of a Boot program decompressing a target firmware extended instruction compressed data packet, provided in an embodiment of this application; Figure 10 A schematic diagram illustrating the download process of a target firmware upgrade compressed data package provided in this application embodiment; Figure 11 This application provides a schematic diagram of a process for decompressing a target firmware upgrade compressed data package. Figure 12 A schematic flowchart illustrating a firmware download method provided in an embodiment of this application; Figure 13 A flowchart illustrating another firmware download method provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0015] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0016] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0017] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0018] The following sections will introduce the relevant solutions of this application from different aspects.

[0019] The computing device has a pre-installed boot program. When the computing device receives a firmware upgrade command, the boot program responds to the received firmware upgrade command and initiates the firmware download process. In current computing devices, the boot process is implemented as follows: Figure 1 As shown, all of Boot's functions are integrated into the Boot code, which leads to an increase in the Flash space occupied by the Boot code.

[0020] In the current boot firmware download process, firmware data is directly transmitted via the interface and then written to the device's Flash storage. The firmware download time equals the firmware data transmission time plus the time spent writing to the Flash storage. To reduce firmware download time, the industry commonly uses pre-compressed firmware to reduce the size of the transmission packet. For example... Figure 2 As shown, after compressing the firmware based on the existing compression scheme, if it is necessary to read the target compressed data in the compressed firmware, it is necessary to completely decompress it from the beginning and retain all the decompressed content. However, the decompression operation relies on RAM cache data throughout, which will result in a large peak memory usage during the decompression process.

[0021] In view of this, this application provides a firmware download method. Based on the target firmware to be downloaded and the chip parameter configuration information of the computing device downloading the target firmware, an encoding / decoding algorithm adapted to the target firmware is generated in advance. Then, the compression algorithm in the encoding / decoding algorithm is used to compress the target firmware into blocks, and the compressed firmware data packets are transmitted through a communication interface. This effectively reduces the amount of data transmitted and shortens the firmware download time. Furthermore, when decompressing the compressed firmware, it is not necessary to completely decompress the entire compressed data packet; the target compressed block can be directly located and decompressed, allowing the decompressed data to be randomly read from a specified address. For example, as shown in Figure 2, if it is necessary to read a target data segment within the compressed firmware, only the corresponding target compressed block needs to be decompressed to obtain the corresponding original data.

[0022] In this embodiment of the application, some functions of the boot program can also be externalized to RAM as extended functions. For example, as shown... Figure 1 As shown, the Boot program instructions are divided into standard Boot instructions and extended Boot instructions, with the extended Boot instructions externalized to RAM to implement extended functions. Standard Boot instructions are basic instructions common to the firmware download process, while extended Boot instructions are specific instructions adapted to the target firmware. This approach effectively reduces the storage space occupied by the Boot program in flash memory. For example, a complete Boot program requires 16KB of flash memory space; by externalizing 4KB of the corresponding functions as extended instructions to RAM, the Boot program only occupies 12KB of flash memory space, requiring an additional 4KB of RAM.

[0023] Next, the firmware download method provided in the embodiments of this application will be described in detail. For example, Figure 3 This illustration shows an application scenario diagram of a firmware download method provided in an embodiment of this application. For example... Figure 3As shown, this scenario may include a first computing device 110, a server 120, and a third computing device 130. The first computing device 110 can act as a client to receive firmware upgrade commands and target firmware upgrade compressed data packets sent by a host computer. The server 120 can act as a host computer to send firmware upgrade commands and target firmware upgrade compressed data packets to the client.

[0024] Server 120 can also receive target firmware and chip parameter configuration information of the first computing device 110 sent by users or maintenance personnel through the third computing device 130. Server 120 can generate a target encoding / decoding algorithm adapted to the target firmware based on the received target firmware and chip parameter configuration information of the first computing device 110. Then, server 120 can compress the target firmware based on the target compression algorithm in the target encoding / decoding algorithm to obtain a target firmware upgrade compressed data packet. Next, server 120 can also compress the target decompression algorithm in the target encoding / decoding algorithm based on a compression algorithm corresponding to the pre-set decompression algorithm in the boot program of the first computing device 110 to obtain a target firmware extension instruction compressed data packet. After generating the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet, server 120 can send a firmware upgrade instruction to the first computing device.

[0025] The first computing device 110 receives a target firmware compressed data packet and a target firmware instruction compressed data packet sent by the server 120. Upon receiving the target firmware instruction compressed data packet, the Boot program in the first computing device 110 decompresses the target firmware extended instruction compressed data packet based on a pre-stored decompression algorithm, and loads the decompressed instruction program containing the target decompression algorithm into RAM for execution. Next, the Boot program decompresses the target firmware upgrade compressed data packet based on the instruction program running in RAM to obtain the target firmware upgrade data, thus completing the download of the target firmware.

[0026] Understandably, in Figure 3 In the application scenario shown, the first computing device 110 and the third computing device 130 can be the same computing device.

[0027] Next, continue with Figure 3 The first computing device 110 and server 120 in the illustrated application scenario are described in detail. For example, Figure 4 The process of server 120 generating target firmware upgrade compressed data packets and target firmware extension instruction compressed data packets is illustrated.

[0028] like Figure 4As shown, firstly, server 120 obtains the target firmware and chip parameter configuration information of the first computing device 110. The target firmware can refer to a target firmware bin file, which is the original firmware binary image file to be upgraded. It stores the complete program code and configuration data required for device operation and is the original data source for generating the target firmware upgrade compressed data package.

[0029] In one possible example, the chip parameter configuration information of the first computing device 110 may include at least one of the following: available code information of the read-only memory ROM, space partitioning configuration of RAM, speed of the communication interface, read and write performance indicators of the Flash storage unit, and hardware arithmetic operators built into the chip.

[0030] Server 120 generates a target encoding / decoding algorithm based on the target firmware and the chip parameter configuration information of the first computing device 110. For example, server 120 can input the target firmware and the chip parameter configuration information of the first computing device 110 into a pre-trained neural network model. The neural network model can analyze the data features of the target firmware and, combined with the chip parameter configuration information, output multiple encoding / decoding algorithms. Server 120 can use the compression algorithm among the multiple encoding / decoding algorithms output by the neural network model to compress the target firmware, obtaining multiple compressed data packets corresponding to the target firmware. Then, server 120 inputs the multiple compressed data packets corresponding to the target firmware into a pre-configured simulator for simulation, obtaining a set of performance data corresponding to each compressed data packet. The simulator is configured according to the chip parameter information of the first computing device 110.

[0031] In one possible example, the performance data corresponding to a single compressed data packet includes at least one of the following: compressed packet download time, total firmware decompression time, peak RAM usage during decompression, compression ratio, Flash write time, and device power consumption.

[0032] Based on the performance data corresponding to each compressed data packet, server 120 selects the compressed data packet with the best performance data from multiple compressed data packets, and uses the encoding and decoding algorithm corresponding to the compressed data packet with the best performance data as the target encoding and decoding algorithm for the target firmware. Next, server 120 compresses the target firmware (i.e., the target firmware bin file) based on the target compression algorithm in the target encoding and decoding algorithm to generate a target firmware upgrade compressed data packet (also known as the download instruction corresponding to the encoded target firmware). Finally, server 120 compresses the decompression code of the target decompression algorithm in the target encoding and decoding algorithm based on the compression algorithm corresponding to the decompression algorithm preset in the Boot program of the first computing device 110 to obtain the target firmware extension instruction compressed data packet.

[0033] In one possible example, server 120 determines the target compression algorithm corresponding to the target firmware data based on the ROM space size, RAM space size, and target firmware data in the first computing device 110. The target firmware upgrade data packet, compressed by the target compression algorithm, consists of multiple data blocks, each containing one header and eight tokens. Each header is one byte long, where bits 0-7 correspond to tokens 0-7, where 0 indicates unencoded data and 1 indicates encoded data. The header of each data packet defines the bit length of the token's type 0-3 encoding, the original data length, and a checksum.

[0034] For example, the compressed data format corresponding to the target firmware upgrade data package is shown in Table 1.

[0035] Table 1 For example, the header encoding of the target firmware upgrade data packet is: 01 68 00 B4 54 CA78 A3. Here, 0x016800 indicates that the length of the decompressed data is 92160 bytes; 0xB454CA indicates the encoding format of the token in the target firmware upgrade data packet; and 0x78A3 indicates the decompressed data verification value.

[0036] The encoding format 0xB454CA indicates that the minimum length of data matching in the target compression algorithm is 3 bytes. The number of bits corresponding to 3 bytes is used as the minimum bit base, and the actual bit length of a single token is the sum of the bit length field value and the minimum bit base. Each token in the target firmware upgrade data packet is encoded according to the Token encoding format shown in Table 2.

[0037] Table 2 In the target compression algorithm, the target firmware is encoded. In addition to encoding according to the Token encoding format in Table 2, the encoding process also includes the following rules: Rule 1: The minimum length of unencoded data is 8 bytes, that is, when the length of unencoded data is 0, it means that there are 8 bytes of unencoded data; Rule 2: Actual matching byte length = matching length + minimum matching data length, that is, when the matching length is 0, it means there are 3 bytes of matching data; Rule 3: When the data to be encoded is applicable to both Type 1 and Type 2, Type 2 encoding is only used when the buffer distance exceeds the maximum distance of Type 1 (i.e., 0x3FF); otherwise, Type 1 encoding is preferred. Rule 4: When the matching byte length of encoding type Type1~3 is greater than or equal to the current maximum value, an additional 1 byte is needed to extend the length. For example, if the ROM address offset of the data to be encoded in Type3 is 0x000000 and the matching byte length is 0x80, the maximum value that the native length field of Type3 can hold when fully filled is 0x3F. Since the matching length of 0x80 exceeds the maximum capacity of the native length field of Type3, it cannot be directly written into the native field. Therefore, an additional byte is needed to store the offset value of the excess portion. The value to be written in the additional byte is 0x3E (0x80 - 0x3F - 3 = 0x3E). Concatenating the Type3 type identifier, ROM offset, native length field, and extended length byte in byte order yields the complete Type3 token: C0003F3E.

[0038] For example, a specific example will be used to introduce the target encoding and decoding algorithm described above.

[0039] The data to be encoded is: 00112233445566778899334455667701020304AABBCCDDEE, which is a data block (Block 1) in the target firmware. The ROM data is: 0102030405060708; After encoding according to the encoding rules corresponding to the above target encoding / decoding algorithm, the obtained data is: 0702001122334455667788994072C00001AABBCCDDEE.

[0040] The encoding process based on the encoding rules corresponding to the above target encoding / decoding algorithm can be described as follows: Figure 5 As shown. (Refer to...) Figure 5 It is known that data segment 1 (original byte sequence 00 11 22 33 44 55 66 77 8899) in the data to be encoded does not contain any content that can be matched with a dictionary, and the data length is greater than 8 bytes. Therefore, Type 0 is used to encode data segment 1. The Type 0 header byte is divided into the following fields: the high 2 bits are 00, used to identify the current encoding type as Type 0; according to the established encoding rules, the low 6 bits store the converted actual length value 2 (conversion logic: 10-8=2), corresponding to the binary bit string 000010, which is integrated to obtain the complete header byte binary 00000010, which is 0x02 in hexadecimal. The Type 0 header byte is concatenated with the original data segment 1 byte content, and finally the encoded Token0 corresponding to data segment 1 is generated as 02 00 11 22 33 44 55 66 7788 99.

[0041] Data segment 2 (original byte sequence 33 44 55 66 77) in the data to be encoded can match the data in data segment 1. The matching length is 5 bytes, which is greater than the minimum data matching length of 3 bytes in the target encoding / decoding algorithm. The buffer distance is 7, which is less than or equal to the maximum distance of Type 1, 0x3FF. Therefore, Type 1 is used to encode data segment 2. The header of Type 1 contains 2 bytes. Among them, the high 2 bits of byte 0 are 01, which is used to identify the current encoding type as Type 1. The remaining 6 bits of byte 0 and the high 4 bits of byte 2 are used to identify the buffer distance (buffer distance 7, i.e., 0000000111b). The remaining 4 bits of byte 2 are used to identify the matching length value (according to the above rule 2, matching length value = actual matching length - minimum matching length = 5 - 3 = 2, i.e., 0010b). Therefore, byte 0 of Type1 is 01 000000 = 0x40, and byte 2 is 01110010 = 0x72. By concatenating byte 0 and byte 1 of Type1, we can obtain the encoding Token1 corresponding to data segment 2 as 4072.

[0042] Data segment 3 (original byte sequence 01 02 03 04) in the data to be encoded matches the data in the ROM with an offset of 0 bytes (i.e., 0x0000). The matching length is 4 words, which is greater than the minimum data matching length of 3 bytes in the target encoding / decoding algorithm. Therefore, Type 3 is used to encode data segment 2. The header of Type 3 contains 3 bytes. The high 2 bits of byte 0 are set to 10 to identify the current encoding type as Type 3. The low 6 bits of byte 0 and byte 1 are used to identify the offset byte, and byte 2 is used to identify the offset length value. Therefore, in Type 3, byte 0 is 11000000b, i.e., 0xC0, byte 1 is 0x00, and byte 2 is 00000001, i.e., 0x01. Concatenating byte 0, byte 2, and byte 2 of Type 3, we can obtain the encoded Token2 corresponding to data segment 3 as C00001.

[0043] Continue encoding the remaining data (original byte sequence AA BB CC DD EE). Since there are no matching data for the remaining data, and the data length is less than or equal to 8 bytes, using Type 0 encoding would actually increase the overhead of the encoded data. Therefore, the remaining data can be encoded and stored directly byte by byte. That is, Token3 is AA, Token4 is BB, Token5 is CC, Token6 is DD, and Token7 is EE.

[0044] Since Token0 to Token2 are encoded data and Token3 to Token7 are unencoded data, the header of the data packet corresponding to Block1 is 11100000b, i.e., 0x07.

[0045] The encoding process for other blocks in the target firmware can refer to the encoding process for Block 1, and will not be repeated here.

[0046] For example, Figure 6 The diagram illustrates the process of decoding the encoded data (0702 001122334455667788994072C00001AABBCCDDEE) corresponding to Block 1 based on the target encoding / decoding algorithm. It can be understood that the decoding process for the encoded data corresponding to Block 1 is performed in the first computing device 110.

[0047] like Figure 6 As shown, initially, the Flash storage unit's buffer is empty. The Boot program reads the header of the data packet corresponding to Block1, which is 0x07, or 11100000b, and determines that Token0 to Token2 in the data compressed packet corresponding to Block1 are compressed encoded data, while Token3 to Token7 are uncompressed encoded data.

[0048] When Boot reads data from the compressed data packet, it reads "0x02", indicating that Token0 is encoded using Type0 and has a data length of 10 bytes. Therefore, the original data corresponding to Token0 is: 00112233445566778899. The original data corresponding to Token0 is then stored in the buffer of the Flash storage unit.

[0049] Boot continues reading the data "0x4072" from the compressed data packet, indicating that Token1 is encoded using Type1, with a buffer distance of 7 bytes and a length of 5 bytes. Therefore, the Boot program shifts 7 bytes forward from the current position in the Flash storage unit's buffer and begins reading 5 bytes of data (i.e., 3344556677) as the original data of Token1, storing it in the Flash storage unit's buffer.

[0050] Boot continues reading the data "C00001" from the compressed data packet, indicating that Token2 is encoded using Type3, with an offset of 0 in ROM and a length of 4 bytes. Therefore, the Boot program reads 4 bytes of data (i.e., 01020304) from ROM starting at position 0 as the raw data of Token2 and stores it in the buffer of the Flash memory unit.

[0051] Since Tokens 3 through 7 are uncompressed data, the Boot program directly reads the remaining data from the compressed data packet and stores it in the Flash memory buffer. Finally, the data stored in the Flash memory buffer is the data obtained after decompressing the Block 1 compressed data packet.

[0052] In some embodiments, compressed data packets can be directly used as user data storage. When it is necessary to read the original data corresponding to a specified address within the compressed data packet, it is not necessary to completely decompress the entire block. Based on this use case, when performing compression encoding on the original data, token encoding can be completed using only Type 0 and Type 3 encoding formats. The specific implementation process for completing token encoding using Type 0 and Type 3 encoding formats can be found in [reference needed]. Figure 5 This will not be elaborated upon here. When reading the original data corresponding to a specified address within the compressed data packet, the original data can be read at a random address offset using the compressed data. The specific implementation process can be carried out according to the following steps: Step 1: Read the first byte in the compressed data packet. This byte is the head data of the Block. Step 2: Determine whether Token0 to Token7 are encoded based on the values ​​corresponding to each bit in the head data; Step 3: While traversing and parsing the tokens within the compressed data packet, synchronously update the original data offset pointer: If the current token is an unencoded data type, increment the original data offset address byte by byte according to the number of original bytes carried by the token; if the current token is a matching encoded type, read the matching length field recorded inside the token and update the original data offset address using that byte length as the increment. During the process of updating the offset address, if the original address range corresponding to the current token coincides with the target address range to be read, extract the original data corresponding to the target address from the token.

[0053] Next, we will use two specific examples to introduce the data decompression process of Block.

[0054] In Example 1, the original data block (Block 2) to be encoded is: 001122334455667788993344556677010203040405060708; The ROM data is: 0102030405060708; The encoded compressed data is: 8302001122334455667788993344556677C00001C000C2.

[0055] Figure 7 This illustrates the process of reading data from a specified offset address within the compressed data corresponding to Block 2. For example... Figure 7 As shown, the original data offset address of the target data being read is 0x06, and the length is 3 bytes. Initially, the buffer of the Flash storage unit in the first computing device 110 is empty.

[0056] The Boot program initializes the raw data offset pointer to 0x00 and iterates through the Token sequence within the compressed data packet. The Boot program iterates through Token0 in the compressed data packet, determining that Token0 uses Type0 encoding and covers the raw offset range of 0x00~0x0A; the target raw offsets 0x06, 0x07, and 0x08 to be read fall within this range. Subsequently, the Boot program calculates the relative offset of the target data within the raw data segment corresponding to Token1 as 0x06, reads three consecutive bytes starting from offset 0x06 from this raw data segment, obtaining the target data 66 77 88, and stores it in the buffer of the Flash storage unit.

[0057] In Example 2, the original data to be encoded is: 001122334455667788993344556677010203040405060708; The ROM data is: 0102030405060708; The encoded compressed data is: 8302001122334455667788993344556677C00001C000C2; Figure 8 This illustrates the process of reading data at a specified offset address from the compressed data corresponding to Block 2. For example... Figure 8 As shown, the original data offset address corresponding to the target data to be read is 0x0C, and the data length is 4 bytes. In the initial state, the buffer of the built-in Flash storage unit of the first computing device 110 is empty.

[0058] The Boot program initializes the original data offset pointer to 0x00 and iterates through the Token sequence in the compressed data packet. The Boot program iterates through Token0 in the compressed data packet, determines that Token0 uses Type0 encoding, and Token0 covers the original offset range of 0x00~0x09. The original offsets of the target to be read, 0x0C, 0x0D, 0x0E, and 0x0F, do not fall within this range.

[0059] The Boot program updates the original data offset pointer to 0x0A, traverses Token1 and Token2 in the compressed data packet, and determines that Token1 and Token2 are both unencoded data with a total length of 2 bytes. Token1 and Token2 cover the original offset range of 0x0A to 0x0B. The original offsets of the target to be read, 0x0C, 0x0D, 0x0E, and 0x0F, do not fall within this range.

[0060] The Boot program updates the original data offset pointer to 0x0C, traverses Token3 to Token5 in the compressed data packet, and determines that Token3 to Token5 are all unencoded data, with a total data length of 3 bytes. Token3 to Token5 cover the original offset range of 0x0C to 0x0E. The 0x0C, 0x0D, and 0x0E of the original offsets 0x0C, 0x0D, 0x0E, and 0x0F of the target data to be read fall within this range. Subsequently, the Boot program calculates the relative offset of the target data in the original data corresponding to Token3 to Token5 as 0x00, reads 3 consecutive bytes starting from the relative offset 0x01 from this segment of original data, obtains the target data 55 66 77, and stores it in the buffer of the Flash storage unit.

[0061] The Boot program updates the original data offset pointer to 0x0F, iterates through Token6 in the compressed data packet, determines that Token6 uses Type3 encoding, has a data length of 4 bytes, and Token5 covers the original offset range of 0x0F~0x12. The target original offset of 0x0C, 0x0D, 0x0E, and 0x0F to be read falls within this range. Subsequently, the Boot program calculates the relative offset of the target data within the original data segment corresponding to Token6 as 0x00, reads the data 88 corresponding to 0x00 from this segment of original data, and stores it in the buffer of the Flash storage unit.

[0062] Next, continue with Figure 3 The application scenario shown will be described using server 120.

[0063] After generating the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet, server 120 first sends a firmware upgrade instruction to the first computing device 110. Then, after server 120 receives the response instruction from the first computing device 110 and confirms that the device is ready, it sends the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet to the first computing device 110.

[0064] In one possible example, server 120 first sends a target firmware extension instruction compressed data packet to first computing device 110, and then transmits a target firmware upgrade compressed data packet.

[0065] After receiving the target firmware upgrade command sent by the server 120, the Boot program in the first computing device 110 switches to the upgrade-ready state and sends a response command to the server. The response command informs the server 120 that the first computing device 110 is ready for upgrade and can receive the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet. Upon receiving the target firmware extension instruction compressed data packet, the first computing device 110 decompresses the target firmware extension instruction compressed data packet using the Boot program to obtain an instruction program containing a first decompression algorithm. The target firmware extension instruction compressed data packet is obtained by compressing it using a second compression algorithm, and the Boot program pre-stores a second decompression algorithm compatible with the second compression algorithm. Next, the Boot program loads the instruction program containing the first decompression algorithm into RAM, and if the instruction program is verified, runs the first decompression algorithm to decompress the target firmware upgrade compressed data packet.

[0066] During the Boot program compilation phase, a segment of RAM space is pre-allocated in the first computing device 110 as the runtime storage area for Boot extension instructions. Furthermore, to ensure the integrity and unaltered nature of the loaded extension instructions, instruction data verification must be performed before scheduling and executing them in RAM. Therefore, based on this design, when the Boot program decompresses the target firmware extension instruction compressed data packet, it stores the decompression result in a preset RAM address and then compares the decompressed target firmware extension instructions with the corresponding verification data. If the verification results match, subsequent execution of the extension instruction code is allowed; if the verification does not match, execution of the extension instruction is prohibited.

[0067] For example, Figure 9 The process of the Boot program decompressing the target firmware extended instruction compressed data packet is illustrated. It can be understood that the target firmware extended instruction compressed data packet sent by server 120 can include two types: a loaded extended instruction compressed data packet and an extended instruction compressed data packet. The loaded extended instruction compressed data packet includes decompression code for decompressing the target firmware upgrade compressed data packet, i.e., the instruction program corresponding to the aforementioned target decompression algorithm. Based on the loaded extended instruction identifier in the header of the loaded extended instruction compressed data packet, the Boot program can be instructed to write the decompression code to a specified RAM address and verify the cache. The extended instruction compressed data packet contains several extended instructions, each with decompression control parameters. After the decompression code is preloaded, the code in RAM is called to decompress the target firmware. For example... Figure 9As shown, the processing flow includes steps 9010 to 9200.

[0068] In step 9010, the Boot program receives the target firmware extension instruction compressed data packet sent by the server 120.

[0069] In step 9020, the Boot program determines whether the received target firmware extended instruction compressed data packet is an extended instruction compressed data packet. If it is an extended instruction compressed data packet, step 9030 is executed; otherwise, step 9060 is executed.

[0070] In step 9030, the Boot program checks whether the code for the corresponding extended instructions has been pre-loaded in RAM (i.e., whether the extended instructions have been loaded). If they have been loaded, step 9040 is executed; otherwise, step 9050 is executed.

[0071] In step 9040, the Boot program runs the business logic corresponding to the extended instruction, returns the corresponding status code after processing, and the process returns to step 9010 to wait for the next instruction data.

[0072] In step 9050, the Boot program returns an error status code and continues to execute step 9010 to wait for the next instruction data.

[0073] In step 9060, the Boot program determines whether the received target firmware extension instruction compressed data packet is a load extension instruction compressed data packet. If so, proceed to step 9070; otherwise, proceed to step 9200.

[0074] In step 9070, the Boot program decompresses the instruction code data in the data packet and writes the code into the pre-allocated RAM storage space.

[0075] In step 9080, the Boot program compares the decompressed extended instruction code with the corresponding verification data. If they match, step 9090 is executed; otherwise, step 9100 is executed.

[0076] In step 9090, the Boot program returns a response indicating that the extended instruction has been successfully loaded, and continues to execute step 9010 to wait for the next instruction data.

[0077] In step 9100, the Boot program discards the code data stored in RAM, returns an error status code to the server, and continues to execute step 9010 to wait for the next instruction data.

[0078] In step 9200, the Boot program executes ordinary instructions according to general logic, returns the corresponding status code after completion, and continues to execute step 9010 to wait for the next instruction data.

[0079] After the first computing device 110 completes the processing of all target firmware extension instruction compressed data packets through its built-in boot program, it can call the decompression code pre-stored in RAM to execute the download operation of the target firmware upgrade compressed data packet. It can be understood that the process of the first computing device 110 downloading the target firmware upgrade compressed data packet includes the decompression processing of the downloaded compressed data packet.

[0080] For example, Figure 10 This diagram illustrates the download process for a compressed data package to upgrade the target firmware. Figure 10 As shown, it includes steps 1010 to 1080.

[0081] In step 1010, the Boot program initializes the decompression function data interface, sets the number of bits occupied by the distance, offset, and length fields corresponding to the decompressed data block, and sets the total length of the data to be decompressed.

[0082] In step 1020, the Boot program receives the target firmware upgrade compressed data packet sent by the server 120.

[0083] In step 1030, the Boot program determines whether the received target firmware upgrade compressed data packet has been completely decompressed. If the received target firmware upgrade compressed data packet has been completely decompressed, it can continue to execute step 1020 to receive the next target firmware upgrade compressed data packet, or end the download process of the target firmware upgrade compressed data packet. If the received target firmware upgrade compressed data packet has not been completely decompressed, it can execute step 1040.

[0084] It is understandable that when server 120 compresses the target firmware, it can divide the target firmware into multiple blocks and compress each block separately based on the generated target decompression algorithm.

[0085] In one possible example, when the server 120 sends the target firmware upgrade compressed data packet, it can send the Block compressed fragments one by one. After the boot program in the first computing device 110 receives a single Block compressed fragment (hereinafter also referred to as the target firmware upgrade compressed data packet), it decodes the Block compressed fragment, and then receives the next Block compressed fragment after the decoding is completed.

[0086] In another possible example, when server 120 sends the target firmware upgrade compressed data package, it sends all blocks as a complete target firmware upgrade compressed data package. After receiving the firmware upgrade compressed package, the boot program in the first computing device 110 stores the complete target firmware upgrade compressed package in a temporary area of ​​the Flash storage unit. During the decoding phase, the boot program sequentially reads the individual block compressed fragments from the Flash storage unit into RAM for decoding.

[0087] In step 1040, the Boot program decompresses the received target firmware upgrade compressed data packet and stores the decompressed data in the RAM buffer.

[0088] In step 1050, the Boot program determines whether the total length of the data in the RAM buffer meets the minimum write length of the Flash page. If it does, proceed to step 1060; otherwise, proceed to step 1030.

[0089] In step 1060, the Boot program writes the data in the RAM buffer to the Flash memory.

[0090] In step 1070, the Boot program determines whether the data written to the Flash storage unit is greater than the total length of the decompressed data. If it is greater, proceed to step 1080; otherwise, proceed to step 1030.

[0091] In step 1080, the Boot program verifies the decompressed data written to the Flash storage unit. If the verification passes, the firmware download is completed.

[0092] In some embodiments, for step 1040, such as Figure 11 As shown, it may include steps 10401 to 10413.

[0093] In step 10401, the Boot program reads the first byte of the compressed data packet. The first byte of the compressed data packet is the header, which identifies whether each token in the compressed data packet is encoded data.

[0094] In step 10402, the Boot program reads one byte from the data packet excluding the header to determine whether the current Token is encoded data. If the current Token is encoded data, step 10404 is executed; otherwise, step 10403 is executed. Here, the current Token refers to the Token belonging to the currently read byte.

[0095] In step 10403, after the Boot program writes the currently read byte into the RAM buffer, it executes step 10411.

[0096] In step 10404, the Boot program determines whether the current Token's encoding type is Type0. If it is, proceed to step 10405; otherwise, proceed to step 10406.

[0097] In step 10405, after the Boot program reads the corresponding length of bytes according to the Type0 encoding and writes them into the RAM buffer, it executes step 10411.

[0098] In step 10406, the Boot program determines whether the current Token's encoding type is Type1. If yes, proceed to step 10407; otherwise, proceed to step 10408.

[0099] In step 10407, after the Boot program reads 1 byte of data, it writes the corresponding distance and length data from the decompressed data into the RAM buffer according to the Type1 encoding, and then executes step 10411.

[0100] In step 10408, the Boot program determines whether the current Token's encoding type is Type2. If yes, proceed to step 10409; otherwise, proceed to step 10410.

[0101] In step 10409, after the Boot program reads 2 bytes of data, it writes the corresponding distance and length data from the decompressed data into the RAM buffer according to the Type2 encoding, and then executes step 10411.

[0102] In step 10410, after the Boot program reads 2 bytes of data, it writes the data with the corresponding offset and length in the ROM into the RAM buffer according to the Type3 encoding, and then executes step 10411.

[0103] In step 10411, the Boot program determines whether the length of the currently decompressed data is greater than or equal to the preset data decompression length. If so, step 10412 is executed; otherwise, step 10413 is executed.

[0104] In step 10412, the Boot program stops decompression and processes the decompressed data. For example, the Boot program can write the decompressed data stored in the RAM buffer to the Flash memory.

[0105] In step 10413, the Boot program determines whether all Tokens in the current data packet have been decompressed. If so, it continues to obtain the data packet corresponding to the next block of the target firmware and executes step 10401. If not, the Boot program continues to execute step 10402.

[0106] Next, based on the above description, a firmware download method provided by an embodiment of this application will be introduced. It is understood that this method can be executed by any device, equipment, or platform with computing and processing capabilities. For example, this method can be performed by… Figure 3 The first computing device 110 executes the command, wherein the first computing device 110 includes non-volatile memory and RAM, and the non-volatile memory pre-stores a boot program. For ease of description, the first computing device 110 will be used as the execution entity in the following description. Figure 12 As shown, the firmware download method includes steps 1201 to 1204.

[0107] Step 1201: Receive the target firmware upgrade command sent by the second computing device.

[0108] In this step, after the first computing device 110 is powered on, it starts the Boot program, which receives the firmware upgrade command issued by the second computing device. The second computing device can be... Figure 3 Server 120 is shown in the image.

[0109] Step 1202: In response to the target firmware upgrade command, receive the target firmware upgrade compressed data packet and the target firmware extension command compressed data packet sent by the second computing device; wherein, the target firmware upgrade compressed data packet is generated by a preset first compression algorithm, and the target firmware extension command compressed data packet contains decompression code of a first decompression algorithm that is compatible with the first compression algorithm; the first compression algorithm is generated based on the target firmware and the chip parameter configuration information carried by the first computing device.

[0110] In this step, after receiving the target firmware upgrade instruction from the second computing device, the Boot program switches to the upgrade-ready state and sends a response instruction to the second computing device. The response instruction informs the second computing device that the first computing device 110 has completed upgrade preparation and can receive the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet.

[0111] In one possible example, the target chip's parameter configuration information includes one or more of the following: available code information of the read-only memory (ROM), space partitioning configuration of RAM, communication interface speed, read / write performance indicators of the Flash memory unit, and hardware arithmetic operators built into the chip.

[0112] In one possible example, the second computing device can generate a first encoding / decoding algorithm adapted to the target firmware based on the target firmware and the chip parameter configuration information on the first computing device 110. This first encoding / decoding algorithm includes a first compression algorithm and a first decompression algorithm. For example, the second computing device can generate N sets of third encoding / decoding algorithms based on the data structure information of the target firmware and the chip parameter configuration information on the first computing device, where N is a natural number greater than or equal to 1. Next, the second computing device uses the N sets of third encoding / decoding algorithms to compress the target firmware, obtaining N pre-compressed target firmware upgrade data packets. These N pre-compressed target firmware upgrade data packets are then input into a simulator to obtain N sets of performance data. The simulator is configured based on the chip parameter configuration information on the first computing device. Then, based on the N sets of performance data, the second computing device selects a first pre-compressed target firmware upgrade data packet from the N pre-compressed target firmware upgrade data packets. The first performance data corresponding to the first pre-compressed target firmware upgrade data packet is superior to the other performance data in the N sets of performance data. Subsequently, the second computing device uses the encoding and decoding algorithm corresponding to the first pre-compressed target firmware upgrade data packet as the first encoding and decoding algorithm, which includes a first compression algorithm and a first decoding algorithm.

[0113] In one possible example, the second computing device can input the target firmware and the chip parameter configuration information of the first computing device 110 into the pre-trained first neural network model to obtain N sets of third encoding and decoding algorithms.

[0114] Step 1203: Decompress the target firmware extension instruction compressed data packet and load the first decompression algorithm obtained after decompression into RAM for execution.

[0115] In this step, the Boot program decompresses the target firmware extended instruction compressed data packet to obtain an instruction program containing a first decompression algorithm. The target firmware extended instruction compressed data packet is obtained by compressing it using a second compression algorithm, and the Boot program pre-stores a second decompression algorithm compatible with the second compression algorithm. Next, the Boot program loads the instruction program containing the first decompression algorithm into RAM, and runs the first decompression algorithm if the instruction program is verified successfully. The specific implementation process of the Boot program decompressing the target firmware extended instruction compressed data packet can be referred to in the above embodiment. Figure 9 The description.

[0116] Step 1204: Decompress the target firmware upgrade compressed data packet based on the first decompression algorithm, and store the decompressed target firmware upgrade data in non-volatile memory.

[0117] In this step, the non-volatile memory can be the flash memory integrated on the microcontroller. The target firmware upgrade compressed data package contains multiple independent compressed data blocks, each of which is an independent decoding unit.

[0118] The Boot program loads the received single compressed data block into RAM and decodes it based on an instruction program containing a first decompression algorithm running within RAM, obtaining the target firmware upgrade data. Next, the Boot program writes the target firmware upgrade data into the RAM buffer. If the data length in the RAM buffer meets the minimum write length of a Flash page, the program writes the data in the RAM buffer, equal to the minimum write length of a Flash page, to the target firmware partition in the Flash storage unit.

[0119] In one possible example, the boot program could store all compressed data blocks corresponding to the target firmware upgrade compressed data package in a temporary area of ​​the Flash memory unit, then sequentially read individual compressed data blocks from the temporary Flash memory unit into RAM, and decode the compressed data blocks based on the instruction program containing the first decompression algorithm running in RAM to obtain the target firmware upgrade data. Next, the boot program writes the target firmware upgrade data into the RAM buffer, and if the data length in the RAM buffer meets the minimum write length of a Flash page, writes the data in the RAM buffer, which is the minimum write length of a Flash page, into the target firmware partition of the Flash memory unit.

[0120] In one possible example, the MCU can integrate both Flash memory and ROM. The Flash memory can be used to store the target firmware upgrade data package, while the ROM is used to store the boot program.

[0121] In this embodiment, when downloading the target firmware, a compression algorithm adapted to the target firmware is generated by combining the data characteristics of the target firmware itself with the configuration information of the first computing device chip of the firmware to be downloaded, and the target firmware is compressed. This improves the compression efficiency and decompression performance of the target firmware, effectively accelerating the download speed. Simultaneously, the decompression code corresponding to the decompression algorithm for decompressing the target firmware is loaded into RAM as extended instructions for the Boot program, reducing the size of the Boot program's own code and decreasing the space occupied by the Flash chip.

[0122] Next, based on the above description, another firmware download method provided by the embodiments of this application will be introduced. It is understood that this method can be executed by any device, equipment, or platform with computing and processing capabilities. For example, this method can be performed by a second computing device (i.e., Figure 3 The execution is performed on server 120. For ease of description, the following description uses the second computing device as the execution subject. Figure 13 As shown, the firmware download method includes steps 1301 to 1305.

[0123] Step 1301: Obtain the target firmware and chip parameter configuration information of the first computing device.

[0124] In this step, the second computing device can receive the target firmware and chip parameter configuration information of the first computing device sent by the user through a client. The client can be one of the aforementioned... Figure 3 The first computing device 110 or the third settlement device 130 in the process. The parameter configuration information of the target chip includes one or more of the following: available code information of the read-only memory ROM, space partitioning configuration of RAM, communication interface speed, read and write performance indicators of Flash storage unit, and hardware arithmetic operators built into the chip.

[0125] Step 1302: Generate a first encoding / decoding algorithm based on the target firmware and the chip parameter configuration information carried by the first computing device.

[0126] In this step, the second computing device generates N sets of third encoding / decoding algorithms based on the target firmware's data structure information and the chip parameter configuration information on the first computing device, where N is a natural number greater than or equal to 1. Next, the second computing device uses the N sets of third encoding / decoding algorithms to compress the target firmware, obtaining N pre-compressed target firmware upgrade data packets. These N pre-compressed target firmware upgrade data packets are then input into a simulator to obtain N sets of performance data. The simulator is configured based on the chip parameter configuration information on the first computing device. Next, based on the N sets of performance data, the second computing device selects a first pre-compressed target firmware upgrade data packet from the N pre-compressed target firmware upgrade data packets. The first performance data corresponding to the first pre-compressed target firmware upgrade data packet is superior to all other performance data in the N sets of performance data. Subsequently, the second computing device uses the encoding / decoding algorithm corresponding to the first pre-compressed target firmware upgrade data packet as the first encoding / decoding algorithm, which includes a first compression algorithm and a first decoding algorithm.

[0127] In one possible example, the second computing device can input the target firmware and the chip parameter configuration information of the first computing device 110 into the pre-trained first neural network model to obtain N sets of third encoding and decoding algorithms.

[0128] Step 1303: Compress the target firmware using the first compression algorithm in the first encoding / decoding algorithm to obtain the target firmware upgrade compressed data packet.

[0129] In this step, when the second computing device compresses the target firmware using the first compression algorithm corresponding to the first encoding and decoding algorithm, it performs block compression processing on the target firmware, that is, it divides the complete target firmware into several data blocks and compresses each block separately.

[0130] Step 1304: Compress the first decompression algorithm in the first decompression algorithm based on the second compression algorithm to obtain the target firmware extension instruction compressed data packet.

[0131] In this step, based on the chip configuration information of the first computing device, the second computing device can determine the second encoding / decoding algorithm stored in the ROM of the first computing device, including a second compression algorithm and a second decompression algorithm. The second computing device can compress the first decompression algorithm in the first decompression algorithm based on the second compression algorithm to obtain a target firmware extension instruction compressed data packet. Thus, after receiving the target firmware extension instruction compressed data packet, the first computing device 110 can decompress the target firmware extension instruction compressed data packet based on the second decompression algorithm stored in the ROM.

[0132] In one possible example, when the second computing device performs compression processing on the target firmware related extension instructions, it compresses the decompression code corresponding to the first decompression algorithm based on the second compression algorithm to generate a compressed data packet for loading extension instructions. At the same time, it compresses various extension instructions of the target firmware based on the second compression algorithm to generate compressed data packets for extension instructions.

[0133] Step 1305: Send a firmware upgrade command to the first computing device. The firmware upgrade command is used to trigger the Boot program in the non-volatile memory of the first computing device to start the firmware download process.

[0134] In this step, after the second computing device generates the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet, the second computing device can send the target firmware upgrade instruction to the first computing device, and after receiving the response instruction sent by the first computing device, send the target firmware upgrade compressed data packet and the target firmware extension instruction compressed data packet to the first computing device.

[0135] In this embodiment, by combining the data characteristics of the target firmware itself with the configuration information of the first computing device chip of the firmware to be downloaded, a compression algorithm adapted to the target firmware is generated and the target firmware is compressed, which can improve the compression efficiency and decompression performance of the target firmware and effectively speed up the download speed of the target firmware.

[0136] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In addition, the various embodiments described above can be combined according to actual conditions, and the combined solutions are still within the protection scope of this application.

[0137] Based on the methods in the above embodiments, this application also provides a computing device 1400. For example... Figure 14 As shown, the computing device 1400 includes a bus 1402, a processor 1404, a memory 1406, and a communication interface 1408. The processor 1404, the memory 1406, and the communication interface 1408 communicate with each other via the bus 1402. The computing device 1400 may be a server or an electronic device. It should be understood that this application does not limit the number of processors and memories in the computing device 1400.

[0138] Bus 1402 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 14 The bus 1402 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1402 may include a path for transmitting information between various components of the computing device 1400 (e.g., memory 1406, processor 1404, communication interface 1408).

[0139] Processor 1404 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0140] The memory 1406 may include volatile memory, such as random access memory (RAM). The processor 404 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0141] The memory 1406 stores executable program code, and the processor 1404 executes the executable program code to implement the firmware download method described in the above embodiments. That is, the memory 1606 stores instructions for executing the firmware download method described in the above embodiments.

[0142] The communication interface 1608 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1400 and other devices or communication networks.

[0143] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program. When the computer program runs on a processor, it causes the processor to execute the battery thermal management and corrosion prevention collaborative control method in the above embodiments.

[0144] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0145] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A firmware download method, characterized in that, Applied to a first computing device, the first computing device including non-volatile memory and random access memory (RAM), wherein a boot loader program (Boot) is pre-stored in the non-volatile memory, the method comprising: Receive the target firmware upgrade command sent by the second computing device; In response to the target firmware upgrade instruction, the system receives a target firmware upgrade compressed data packet and a target firmware extension instruction compressed data packet sent by the second computing device. The target firmware upgrade compressed data packet is generated by compressing the target firmware using a preset first compression algorithm, and the target firmware extension instruction compressed data packet contains decompression code of a first decompression algorithm that is compatible with the first compression algorithm. The first compression algorithm is generated based on the target firmware and the chip parameter configuration information of the first computing device. The target firmware extension instruction compressed data packet is decompressed, and the first decompression algorithm obtained after decompression is loaded into the RAM for execution; The target firmware upgrade compressed data packet is decompressed based on the first decompression algorithm, and the decompressed target firmware upgrade data is stored in the non-volatile memory.

2. The method according to claim 1, characterized in that, The step of decompressing the target firmware extension instruction compressed data packet and loading the decompressed first decompression algorithm into the RAM for execution includes: The Boot program decompresses the target firmware extension instruction compressed data packet to obtain an instruction program containing a first decompression algorithm. The target firmware extension instruction compressed data packet is obtained by compressing it using a second compression algorithm. The Boot program pre-stores a second decompression algorithm that is compatible with the second compression algorithm. The instruction program containing the first decompression algorithm is loaded into the RAM, and the first decompression algorithm is run if the instruction program is verified.

3. The method according to claim 2, characterized in that, The non-volatile memory is a flash memory storage unit integrated on the microcontroller. The target firmware upgrade compressed data package contains multiple independent compressed data blocks, and each compressed data block is an independent decoding unit. The step of decompressing the target firmware upgrade compressed data packet based on the first decompression algorithm and storing the decompressed target firmware upgrade data in the non-volatile memory includes: The received single compressed data block is loaded into the RAM, and the compressed data block is decoded based on the instruction program containing the first decompression algorithm running in the RAM to obtain the target data firmware upgrade data; The target firmware upgrade data is written to the cache area of ​​the RAM, and if the data length in the RAM cache area meets the minimum write length of the Flash page, the data in the RAM cache area with a size equal to the minimum write length of the Flash page is written to the target firmware partition of the Flash storage unit.

4. The method according to claim 1, characterized in that, The first compression algorithm is generated in the following way: Obtain the target firmware and the chip parameter configuration information of the first computing device. The parameter configuration information includes one or more of the following: available code information of the read-only memory (ROM), space partitioning configuration of RAM, speed of the communication interface, read and write performance indicators of the Flash storage unit, and hardware arithmetic operators built into the chip. Based on the data structure information of the target firmware and the chip parameter configuration information, N sets of third encoding and decoding algorithms are generated, where N is a natural number greater than or equal to 1; The target firmware is compressed using N sets of third encoding and decoding algorithms to obtain N pre-compressed target firmware upgrade data packets; The N pre-compressed target firmware upgrade data packages are input into the simulator to obtain N sets of performance data, which are configured based on the chip parameter configuration information. Based on the N sets of performance data, a first pre-compressed target firmware upgrade data packet is selected from the N pre-compressed target firmware upgrade data packets. The first performance data corresponding to the first pre-compressed target firmware upgrade data packet is better than the other performance data in the N sets of performance data except for the first performance data. The encoding and decoding algorithm corresponding to the first pre-compressed target firmware upgrade data packet is used as the first encoding and decoding algorithm, which includes a first compression algorithm and a first decompression algorithm.

5. The method according to claim 4, characterized in that, The generation of N sets of third encoding / decoding algorithms based on the target firmware and the chip parameter configuration information mounted on the first computing device includes: The target firmware and the chip parameter configuration information of the first computing device are input into the pre-trained first neural network model, and N sets of third encoding and decoding algorithms are output.

6. A firmware download method, characterized in that, Applied to a second computing device, the method includes: Obtain the target firmware and the chip parameter configuration information of the first computing device. The parameter configuration information includes one or more of the following: available code information of the read-only memory ROM, space partitioning configuration of RAM, communication interface speed, read and write performance indicators of Flash storage unit, and hardware arithmetic operators built into the chip. Based on the target firmware and the chip parameter configuration information of the first computing device, a first encoding / decoding algorithm is generated; The target firmware is compressed using the first compression algorithm in the first encoding / decoding algorithm to obtain a target firmware upgrade compressed data packet; The first decompression algorithm in the first decompression algorithm is compressed based on the second compression algorithm to obtain the target firmware extension instruction compressed data packet; A target firmware upgrade command is sent to the first computing device. The firmware upgrade command is used to trigger the Boot program in the non-volatile memory of the first computing device to start the firmware download process.

7. The method according to claim 6, characterized in that, The step of generating a first encoding / decoding algorithm based on the target firmware and the chip parameter configuration information mounted on the first computing device includes: Based on the data structure information of the target firmware and the chip parameter configuration information of the first computing device, N sets of third encoding and decoding algorithms are generated, where N is a natural number greater than or equal to 1; The target firmware is compressed using N sets of third encoding and decoding algorithms to obtain N pre-compressed target firmware upgrade data packets; The N pre-compressed target firmware upgrade data packages are input into the simulator to obtain N sets of performance data, which are configured based on the chip parameter configuration information. Based on the N sets of performance data, a first pre-compressed target firmware upgrade data packet is selected from the N pre-compressed target firmware upgrade data packets. The first performance data corresponding to the first pre-compressed target firmware upgrade data packet is better than the other performance data in the N sets of performance data except for the first performance data. The encoding and decoding algorithm corresponding to the first pre-compressed target firmware upgrade data packet is used as the first encoding and decoding algorithm, which includes a first compression algorithm and a first decompression algorithm.

8. The method according to claim 7, characterized in that, The generation of N sets of third encoding / decoding algorithms based on the target firmware and the chip parameter configuration information mounted on the first computing device includes: The target firmware and the chip parameter configuration information mounted on the first computing device are input into the pre-trained first neural network model, and N sets of third encoding and decoding algorithms are output.

9. A computing device, characterized in that, Including processor and memory; The memory is used to store instructions; The processor is configured to execute instructions stored in the memory to cause the energy storage device to perform the method as claimed in claims 1 to 5 or as claimed in any one of claims 6 to 8.

10. A computer-readable storage medium, characterized in that, Used to store a computer program; wherein the computer program, when executed by a processor, implements the method as claimed in claims 1 to 5 or as claimed in any one of claims 6 to 8.

Images