Firmware upgrading method capable of returning version

Abstract

The invention discloses a firmware upgrading method capable of backspacing versions, which relates to the technical field of data processing, and comprises the following steps: transmitting a firmware file 2 to target equipment according to a network protocol; carrying out storage space recombination on the target equipment, receiving the firmware file 2 and carrying out firmware content integrity verification; if verification succeeds, the firmware file 2 is stored to the boot.b partition, data integrity verification is carried out, and firmware upgrade driving is carried out according to the firmware file 2; wherein the firmware upgrade management is carried out through the cooperation of the boot.a partition and the boot.b partition, and the boot.a partition executes the firmware rollback drive under the loading failure state of the boot.b partition. According to the method and the device, the technical problem that the firmware cannot be quickly recovered after the firmware upgrading fails in the prior art is solved, and the technical effect of enhancing the firmware upgrading fault-tolerant capability is achieved through a double-partition management mechanism and firmware content integrity verification.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to a firmware upgrade method capable of rolling back versions. Background Art

[0002] With the rapid development of the Internet of Things and smart devices, firmware upgrade technology has been widely used in modern electronic devices. However, with the increasing complexity of device functions and the diversification of network environments, the firmware upgrade process is also facing increasing challenges. When upgrading, if there is an abnormality in the upgraded firmware, the device will become unusable and the old version cannot be quickly restored. There is also a problem that the firmware cannot be quickly restored after the upgrade fails. Summary of the invention

[0003] The present application provides a method for firmware upgrade that can roll back versions, which is used to solve the technical problem in the prior art that a firmware upgrade cannot be quickly restored after a failure.

[0004] In view of the above problems, the present application provides a method for upgrading firmware that can roll back versions.

[0005] The present application provides a method for upgrading a firmware that can roll back a version, the method comprising: According to the network protocol, the firmware file 2 is transmitted to the target device, wherein the firmware file 2 is the file to be upgraded; the storage space of the target device is reorganized, the firmware file 2 is received and the firmware content integrity check is performed, wherein the storage space includes at least two boot partitions, and the boot.a partition is used to store the firmware file 1, and the firmware file 1 is the original firmware file; if the check is successful, the firmware file 2 is stored in the boot.b partition and the data integrity check is performed, and the firmware upgrade drive is performed according to the firmware file 2; wherein the firmware upgrade management is performed in collaboration with the boot.a partition and the boot.b partition, and the boot.a partition executes the firmware fallback drive when the boot.b partition fails to load.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages: The present application transmits the firmware file 2 to the target device according to the network protocol, wherein the firmware file 2 is the file to be upgraded; reorganizes the storage space of the target device, receives the firmware file 2 and performs a firmware content integrity check, wherein the storage space includes at least two boot partitions, and the boot.a partition is used to store the firmware file 1, and the firmware file 1 is the original firmware file; if the check is successful, the firmware file 2 is stored in the boot.b partition and a data integrity check is performed, and the firmware upgrade drive is performed according to the firmware file 2; wherein the firmware upgrade management is performed in collaboration with the boot.a partition and the boot.b partition, and the boot.a partition executes the firmware fallback drive in the state where the boot.b partition fails to load. The present invention solves the technical problem in the prior art that the firmware upgrade cannot be quickly recovered after the failure, and achieves the technical effect of enhancing the fault tolerance of the firmware upgrade through the dual partition management mechanism and the firmware content integrity check. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0008] Figure 1 A flowchart of a method for firmware upgrade that can roll back versions provided in an embodiment of the present application; Figure 2 A flowchart of reorganizing the storage space of a target device in a firmware upgrade method capable of rolling back a version provided in an embodiment of the present application. DETAILED DESCRIPTION

[0009] The present application provides a method for firmware upgrade that can roll back versions, which is used to solve the technical problem in the prior art that firmware cannot be quickly recovered after a failed upgrade. Through a dual partition management mechanism and firmware content integrity verification, the technical effect of enhancing the fault tolerance capability of firmware upgrades is achieved.

[0010] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0011] It should be noted that any variations of the terms "include" and "have" are intended to cover non-exclusive inclusions. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules that are not explicitly listed or inherent to these processes, methods, products or devices.

[0012] Examples, such as Figure 1 As shown, the present application provides a method for upgrading a firmware that can roll back a version, the method comprising: Step S100: According to the network protocol, the firmware file 2 is transmitted to the target device, wherein the firmware file 2 is a file to be upgraded.

[0013] In the embodiment of the present application, during the firmware upgrade process, the firmware file 2 is first transmitted to the target device through a network protocol. The network protocol includes but is not limited to communication methods such as HTTP, FTP, UDP, and SSH, and the specific selection depends on the hardware capabilities and application scenarios of the target device. For example, HTTP is suitable for the Internet environment, while SSH is more suitable for scenarios with higher security requirements.

[0014] At the beginning of the transmission, the firmware file 2 is divided into multiple data packets and sent to the target device packet by packet through the network protocol. After the target device receives the data packets, it will reassemble the data packets to ensure the integrity of the firmware file 2. If the data packets are lost or damaged, the target device will request the sender to resend the relevant data packets through the retransmission mechanism until the firmware file 2 is completely received.

[0015] After receiving, the target device temporarily stores the firmware file 2 in a memory (such as RAM) for subsequent processing. The purpose of this step is to avoid unexpected interruptions or data corruption that may occur when writing directly to a storage medium (such as Flash).

[0016] Through the above steps, the firmware file 2 is safely and completely transmitted to the target device. Among them, the transmitted firmware file 2 is the file to be upgraded.

[0017] Step S200: reorganize the storage space of the target device, receive the firmware file 2 and perform a firmware content integrity check, wherein the storage space includes at least two boot partitions, and the boot.a partition is used to store the firmware file 1, and the firmware file 1 is the original firmware file.

[0018] In an embodiment of the present application, during the firmware upgrade process, the target device first reorganizes the storage space to ensure that the firmware file 2 can be successfully received and stored, wherein the storage space includes at least two boot partitions, the boot.a partition is used to store the currently running firmware file 1 (i.e., the original firmware file), and the boot.b partition is used to store the firmware file 2 to be upgraded. The target device checks the partition structure, cleans up the boot.b partition, and prepares for partition switching to ensure that it can roll back to the original firmware when the upgrade fails. Subsequently, the target device receives the firmware file 2 through the network protocol, divides it into multiple data packets and transmits them packet by packet. After receiving the firmware file 2, it is temporarily stored in the memory for firmware content integrity verification, and the CRC or hash value verification is used to ensure that the file is not damaged. Finally, the verified firmware file 2 is written to the boot.b partition to complete the upgrade preparation work in the storage stage.

[0019] Further, such as Figure 2 As shown, in the method provided in the embodiment of the application, the storage space of the target device is reorganized, and further includes: Obtain the second file capacity of the firmware file 2 and the first file capacity of the firmware file 1, wherein the first file capacity and the second file capacity are fuzzy values; calculate the fuzzy ratio of the first file capacity and the second file capacity to determine a reorganization standard; and reorganize the storage space of the target device according to the reorganization standard.

[0020] In an embodiment of the present application, during the firmware upgrade process, the target device first obtains the second file capacity of firmware file 2 and the first file capacity of firmware file 1. Both capacities are fuzzy values, that is, they do not need to be accurately calculated, and only approximate values ​​need to be obtained to meet the needs of fast processing. The target device reads the approximate size information of the file from the file metadata by calling the file system interface or the firmware management module (such as the stat system call). For example, the first file capacity of firmware file 1 may be 100MB, while the second file capacity of firmware file 2 may be 120MB. This step reduces the computational overhead and improves processing efficiency by simplifying the capacity acquisition process.

[0021] Next, the target device calculates the fuzzy ratio of the first file capacity and the second file capacity through simple mathematical operations, that is, fuzzy ratio = second file capacity / first file capacity. For example, if the first file capacity is 100MB and the second file capacity is 120MB, the fuzzy ratio is 1.2. This step uses fuzzy values ​​for fast calculations, avoiding complex and precise calculations, and further speeding up the processing speed.

[0022] Based on the calculated fuzzy ratio, the target device determines the reorganization standard. For example, when the fuzzy ratio is 1.2, the reorganization standard of the storage space is 1 for the first file and 1.2 for the second file. This standard clarifies the allocation ratio of the storage space, ensuring that both firmware file 1 and firmware file 2 can obtain sufficient storage space.

[0023] Finally, according to the reorganization standard, the target device reallocates the storage space. The device divides the existing storage space into two parts according to the fuzzy ratio, one for storing firmware file 1 and the other for storing firmware file 2. Through this process, the storage space of the target device is reorganized quickly.

[0024] Furthermore, in the method provided in the embodiment of the application, after obtaining the second file capacity of the firmware file 2 and the first file capacity of the firmware file 1, the method further includes: Obtain the storage space capacity, sum the capacity of the first file and the second file, and determine whether the storage space capacity meets the capacity sum; if so, perform the storage space reorganization operation of the target device; if not, the storage of the firmware file 2 fails, with insufficient capacity as the cause and storage failure as the result, and generate a warning pop-up window.

[0025] In an embodiment of the present application, the target device first checks the overall capacity of the current storage space through the system's built-in storage management function. Specifically, the device reads the mount point information of the file system to obtain the total size of the available storage space, that is, the storage space capacity. Next, the device reads the first file capacity of firmware file 1 and the second file capacity of firmware file 2 from the file metadata. These two capacity values ​​are fuzzy values, that is, the device only needs to obtain the approximate size of the file without precise calculation. For example, the device reads the basic information of the file through the file system interface and obtains the first file capacity of 100MB and the second file capacity of 120MB.

[0026] After obtaining the first file capacity and the second file capacity, the sum of the two capacities is calculated by simple addition operation. For example, if the first file capacity is 100 MB and the second file capacity is 120 MB, the sum of the capacities is 220 MB.

[0027] The capacity sum is then compared with the current storage space capacity to determine whether the storage space meets the requirements. If the total capacity of the current storage space is greater than or equal to the capacity sum, it indicates that the storage space is sufficient, and the device will perform a storage space reorganization operation; if the total capacity of the current storage space is less than the capacity sum, it indicates that the storage space is insufficient, and the device will determine that the storage of firmware file 2 has failed.

[0028] If the storage space meets the requirement, the storage space reorganization operation is performed. Specifically, the device adjusts the partition size, allocates the unallocated space to the firmware partition, or expands the file system capacity to accommodate firmware file 2. If the storage space is insufficient, it is determined that the storage of firmware file 2 has failed, and a warning pop-up window is generated with insufficient capacity as the reason. Specifically, the device generates a pop-up window through a graphical interface to prompt the user with a warning message of insufficient storage space.

[0029] Furthermore, in the method provided in the embodiment of the application, the firmware content integrity check is performed, and further includes: Determine a first pre-verification target, wherein the first pre-verification target is the integrity of the firmware content; take the firmware file 2 as the target data, perform redundancy identification on the target data, and determine the valid target data, wherein the valid firmware code and configuration parameters for measuring the firmware content are used as the valid target data; initialize the sha256 computing environment, process the valid target data, and output a target hash value, wherein the target hash value is used to characterize the content characteristics of the firmware file 2; verify the target hash value according to the standard hash value, and generate a content verification result based on the first pre-verification target, wherein the verification success or verification failure is included.

[0030] In the embodiment of the present application, the first pre-verification target is determined to be the integrity of the firmware content by reading the firmware upgrade protocol or configuration file. This step usually relies on the built-in firmware management module of the device, which parses the verification rules in the upgrade protocol or configuration file and determines that the core task of the verification is to verify whether the firmware content is complete and has not been tampered with.

[0031] Next, firmware file 2 is used as the target data, and a file parsing tool is used to remove redundant identifiers and extract valid target data. This step is achieved with the help of a file parsing library or tool. The device reads the binary data of the firmware file, removes blank areas, filler data, or invalid codes, and only retains the valid firmware code and configuration parameters actually used.

[0032] The target device then calls the SHA256 calculation module provided by the system or hardware to initialize the hash calculation environment. This step relies on the encryption library provided by the operating system or hardware (such as OpenSSL or hardware encryption engine) to be implemented. The target device will initialize the context required for SHA256 calculation, including setting the parameters of the hash algorithm and allocating necessary memory resources.

[0033] After that, the valid target data is input into the SHA256 calculation module, processed in blocks and a fixed-length target hash value is generated. This step is achieved by calling the hash calculation function of the encryption library. The device inputs the valid target data into the hash calculation module in blocks, and gradually calculates and generates a 256-bit hash value.

[0034] Finally, the device verifies the target hash value based on the standard hash value obtained from the firmware release package or the security server. This step is implemented through a string or binary comparison function. The target hash value is compared bit by bit with the standard hash value to determine whether the two are consistent. If the two are consistent, a verification success result is generated; if they are inconsistent, a verification failure result is generated, indicating that the firmware file 2 may be tampered with or damaged.

[0035] Finally, the content verification result is output through log records or pop-up window prompts. If the verification is successful, the device will record the log and continue the firmware upgrade process; if the verification fails, the device will prompt the user through a pop-up window or log and terminate the upgrade operation.

[0036] Furthermore, in the method provided in the embodiment of the application, after the storage space of the target device is reorganized, the method further includes: The bootarg parameter is introduced, wherein the bootarg parameter is used to distinguish boot partitions; wherein the bootarg parameter of the boot.a partition is a, and the bootarg parameter of the boot.b partition is b.

[0037] In an embodiment of the present application, the bootarg parameter is introduced to clearly distinguish different boot partitions. Specifically, the bootarg parameter of the boot.a partition is set to a, and the bootarg parameter of the boot.b partition is set to b. The core function of this mechanism is to identify the currently started partition by the parameter value, thereby providing clear context information for subsequent operations. When the device starts, the boot program reads the value of the bootarg parameter and determines whether it is currently booting from the boot.a partition or the boot.b partition based on the value. For example, if the bootarg parameter is detected to be a, the device will recognize that the currently started partition is the boot.a partition; if the bootarg parameter is detected to be b, it will recognize that the currently started partition is the boot.b partition.

[0038] Furthermore, the method provided in the application embodiment also includes: By identifying the bootarg parameter, the partition firmware version is read and written. If the verification is successful, the bootarg parameter b is identified to perform partition read and write driving. If the verification fails, the bootarg parameter is modified to a to perform partition read and write driving. The driver bug in firmware file 2 is used as a compensation condition for verification failure.

[0039] In an embodiment of the present application, the corresponding partition firmware version is dynamically selected and driven by identifying the value of the bootarg parameter. The bootarg parameter is a key identifier passed at startup, which is used to distinguish different boot partitions, for example, the bootarg parameter of the boot.a partition is a, and the bootarg parameter of the boot.b partition is b. When the system starts, the value of the bootarg parameter is first read. If the parameter is detected to be b, it is identified that the boot.b partition is currently started; if the parameter is detected to be a, it is identified that the boot.a partition is currently started. Subsequently, the integrity check is performed on the firmware file 2 in the current partition. If the check is successful, continue to use the current bootarg parameter (i.e., b) for partition read and write drive to ensure the normal operation of the device. If the check fails, further determine whether there is a driver bug of firmware file 2 as a compensation condition. If it is confirmed that there is a driver bug, modify the bootarg parameter to a, and switch to the boot.a partition for read and write drive. After modifying the bootarg parameter to a, restart and load firmware file 2 from the boot.a partition to ensure that the device can still run stably under firmware abnormalities.

[0040] Step S300: If the verification is successful, store the firmware file 2 to the boot.b partition and perform a data integrity check, and perform a firmware upgrade drive based on the firmware file 2.

[0041] In the embodiment of the present application, if the verification is successful, the firmware file 2 is stored in the boot.b partition, and a data integrity check is further performed. The data integrity check calculates the hash value of the firmware file and compares it with the pre-stored standard hash value to ensure that no errors or loss occur in the data during the storage process. If the data integrity check passes, the firmware upgrade driver is executed according to the content of the firmware file 2 to complete the firmware version update.

[0042] Furthermore, in the method provided in the embodiment of the application, data integrity verification is performed, and further includes: Determine a second pre-verification target, wherein the second pre-verification target is data integrity; determine a first-order verification result by rechecking the target hash value; identify a verification byte according to the firmware file 2; perform sha256 calculation and hash verification on the verification byte to determine a second-order verification result; determine a verification result based on the second pre-verification target according to the first-order verification result and the second-order verification result.

[0043] In an embodiment of the present application, the second pre-verification target, namely data integrity, is first determined. This is the core task of the verification, which aims to ensure that the firmware file is not damaged or lost during storage and transmission. To achieve this goal, based on existing firmware management technology, the target hash value is extracted from the pre-stored standard hash value as a benchmark for subsequent verification. Next, the firmware file 2 is hashed by re-verifying the target hash value, generating a new hash value, and comparing it with the pre-stored target hash value. This step uses the SHA256 hash algorithm. Through comparison, it is preliminarily determined whether the firmware file is consistent with expectations, thereby determining the first-order verification result. If the hash values ​​match, it indicates that no abnormalities occurred in the firmware file during the transfer process; if they do not match, it means that the file may be damaged and needs to be re-downloaded or repaired.

[0044] After completing the first-order verification, the verification bytes are further identified according to the firmware file 2, that is, specific data segments are extracted from the firmware file as the basis for verification. These verification bytes are usually the key part of the firmware file and can reflect the overall status of the file. In order to improve the verification efficiency, the method of random data byte extraction is adopted to randomly extract a certain number of bytes from the firmware file as the verification target. By using the SHA256 algorithm to perform hash calculation on these verification bytes, a new hash value is generated and compared with the pre-stored standard hash value. This step is called the second-order verification, and its purpose is to further verify the integrity of the firmware file to ensure that no data damage or loss occurs during storage and transmission. Through this step, the second-order verification result is determined, that is, whether the integrity of the firmware file at the byte level is guaranteed.

[0045] Finally, the final verification result based on the second pre-verification target is comprehensively judged by combining the first-order verification result and the second-order verification result. If both verification results pass, it means that the firmware file has not been damaged or lost during storage and transmission, and the data integrity is verified. If one of the verification results fails, the data is considered incomplete.

[0046] Furthermore, in the method provided in the embodiment of the application, according to the firmware file 2, the check byte is identified, and further includes: A preset byte interval is set, wherein the preset byte interval is a byte interval; taking the preset byte interval as a constraint, randomly sampling data bytes of the firmware file 2 to determine the sampled bytes; and using the sampled bytes as the check bytes.

[0047] In the embodiment of the present application, a preset byte interval is first set, which is a byte interval used to constrain the range of random sampling. The setting of the preset byte interval is based on the size of the firmware file and the verification requirements, ensuring that the sampling can cover all parts of the file while avoiding sampling that is too concentrated or sparse. For example, if the size of the firmware file is 1MB, the preset byte interval is set to one interval of every 100KB, thereby dividing the file into 10 intervals.

[0048] Next, the data bytes of firmware file 2 are randomly sampled with the preset byte interval as a constraint. Specifically, one or more bytes are randomly selected as sampling points in each preset byte interval. For example, in the first 100KB interval, the byte at the 50KB is randomly selected; in the second 100KB interval, the byte at the 120KB is selected, and so on. The sampling bytes are determined by random sampling.

[0049] Finally, the sampled bytes are used as check bytes for subsequent hash verification. Check bytes are key data segments of the firmware file and can reflect the overall status of the file. These check bytes are hashed using the SHA256 algorithm to generate a new hash value, which is then compared with the pre-stored standard hash value. This step is called the second-order check, and its purpose is to further verify the integrity of the firmware file to ensure that no data is damaged or lost during storage and transmission. Through this step, the second-order check result is determined.

[0050] Step S400: wherein the firmware upgrade management is performed in collaboration with the boot.a partition and the boot.b partition, and the boot.a partition executes the firmware rollback driver when the boot.b partition fails to load.

[0051] In an embodiment of the present application, the reliability and security of the firmware upgrade process are ensured by the collaborative work of the boot.a partition and the boot.b partition. Specifically, the boot.b partition is used to store the new version of the firmware file, and attempts to load the partition to start the device during the upgrade. If the boot.b partition fails to load, the firmware fallback driver is triggered. At this time, the boot.a partition, as the current running partition, will take over the startup process. The boot.a partition stores the last stable version of the firmware, which can ensure that the device can still operate normally after the upgrade fails. Through this dual-partition collaborative mechanism, when the boot.b partition fails to load, it quickly falls back to the boot.a partition to avoid the device from being unable to start due to upgrade problems, thereby ensuring the stability and availability of the device.

[0052] Furthermore, the method provided in the application embodiment also includes: Among them, the boot.b partition has a first loading priority based on read and write permissions, and the boot.a partition has a second loading priority based on read and write permissions; with the first loading priority and the second loading priority as constraints, the boot.b partition is loaded, the firmware upgrade driver is executed, and the firmware version upgrade based on firmware file 2 is completed.

[0053] In the embodiment of the present application, the efficiency and reliability of the upgrade process are ensured by the collaborative work of the boot.a partition and the boot.b partition, and based on the read and write permissions and loading priorities of the partitions. The boot.b partition has a first loading priority based on read and write permissions, which means that when the device starts, the firmware will be loaded from the boot.b partition first. The boot.a partition has a second loading priority based on read and write permissions, and as a backup partition, it takes over the startup process when the boot.b partition fails to load.

[0054] With the first loading priority and the second loading priority as constraints, the new firmware is first loaded from the boot.b partition, and the firmware upgrade driver is executed to complete the firmware version upgrade based on firmware file 2. If the boot.b partition is loaded successfully, the device will run normally and complete the version upgrade. However, if the boot.b partition fails to load, according to the second loading priority, it will automatically switch to the boot.a partition and load the old version of the firmware from this partition to ensure that the device can continue to operate normally. Through this dual-partition collaborative mechanism, while giving priority to loading the new firmware, reliable fault recovery capabilities are provided to ensure the smooth completion of the firmware upgrade.

[0055] Furthermore, the method provided in the application embodiment also includes: If the boot.b partition fails to load, switch the drive partition address and convert it to the boot.a partition; interrupt the loading of the boot.b partition, switch to the boot.a partition and load firmware file 1, and perform firmware version rollback.

[0056] In the embodiment of the present application, if the boot.b partition fails to load, the operation of switching the driver partition address is triggered, and the startup process is converted from the boot.b partition to the boot.a partition.

[0057] Specifically, when loading new firmware from the boot.b partition, if a loading failure is detected (for example, firmware file corruption or partition read error), the loading of the boot.b partition will be interrupted immediately. After the loading is interrupted, the operation of switching the driver partition address is performed to switch the boot target from the boot.b partition to the boot.a partition. The boot.a partition stores the last stable version of the firmware file (i.e., firmware file 1). As a backup partition, it can provide reliable recovery capabilities when the primary partition fails to load.

[0058] Next, load the firmware file 1 from the boot.a partition and boot the device. This step combines existing boot management technology to minimize device downtime by quickly switching partitions. After loading is complete, perform a firmware version rollback to restore the device to the last stable version to ensure that it can operate normally. At the same time, record the reason for the loading failure and generate a log file for subsequent analysis and repair.

[0059] Through the above steps, when the boot.b partition fails to load, it can quickly switch to the boot.a partition and complete the firmware version rollback.

[0060] In the embodiments of the present application, in summary, the embodiments of the present application have at least the following technical effects: The present application transmits the firmware file 2 to the target device according to the network protocol, wherein the firmware file 2 is the file to be upgraded; reorganizes the storage space of the target device, receives the firmware file 2 and performs a firmware content integrity check, wherein the storage space includes at least two boot partitions, and the boot.a partition is used to store the firmware file 1, and the firmware file 1 is the original firmware file; if the check is successful, the firmware file 2 is stored in the boot.b partition and a data integrity check is performed, and the firmware upgrade drive is performed according to the firmware file 2; wherein the firmware upgrade management is performed in collaboration with the boot.a partition and the boot.b partition, and the boot.a partition executes the firmware fallback drive in the state where the boot.b partition fails to load. The present invention solves the technical problem in the prior art that the firmware upgrade cannot be quickly recovered after the failure, and achieves the technical effect of enhancing the fault tolerance of the firmware upgrade through the dual partition management mechanism and the firmware content integrity check.

[0061] It should be noted that the above-mentioned sequence of the embodiments of the present application is only for description and does not represent the advantages and disadvantages of the embodiments. And the above-mentioned specific embodiments of this specification are described. The processes depicted in the accompanying drawings do not necessarily require the specific order and continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0062] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

[0063] This specification and drawings are merely exemplary illustrations of the present application and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, a person skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the present application and its equivalents, the present application intends to include these modifications and variations.

Claims

1. A method for upgrading a firmware that can roll back a version, characterized in that: The method comprises: According to the network protocol, the firmware file 2 is transmitted to the target device, wherein the firmware file 2 is the file to be upgraded; Reorganize the storage space of the target device, receive the firmware file 2 and perform a firmware content integrity check, wherein the storage space includes at least two boot partitions, and the boot.a partition is used to store the firmware file 1, and the firmware file 1 is the original firmware file; If the verification is successful, the firmware file 2 is stored in the boot.b partition and the data integrity is verified, and the firmware upgrade driver is performed according to the firmware file 2; The firmware upgrade management is performed in collaboration with the boot.a partition and the boot.b partition, and the boot.a partition executes the firmware rollback driver when the boot.b partition fails to load.

2. A method for firmware upgrade capable of rolling back versions as claimed in claim 1, characterized in that: in, The boot.b partition has the first loading priority based on read and write permissions, and the boot.a partition has the second loading priority based on read and write permissions; With the first loading priority and the second loading priority as constraints, the boot.b partition is loaded, the firmware upgrade driver is executed, and the firmware version upgrade based on firmware file 2 is completed.

3. A method for firmware upgrade capable of rolling back versions as claimed in claim 1, characterized in that: The method further comprises: If the boot.b partition fails to load, switch the driver partition address and convert it to the boot.a partition; Interrupt the loading of the boot.b partition, switch to the boot.a partition and load firmware file 1 to perform firmware version rollback.

4. A method for firmware upgrade capable of rolling back versions as claimed in claim 1, characterized in that: Reorganize the target device's storage space, including: Acquire a second file capacity of the firmware file 2 and a first file capacity of the firmware file 1, wherein the first file capacity and the second file capacity are fuzzy values; calculating a fuzzy ratio between the first file capacity and the second file capacity to determine a reorganization standard; The storage space of the target device is reorganized according to the reorganization standard.

5. A method for firmware upgrade capable of rolling back versions as claimed in claim 4, characterized in that: After obtaining the second file capacity of the firmware file 2 and the first file capacity of the firmware file 1, the method includes: Acquire storage space capacity, sum the capacity of the first file and the capacity of the second file, and determine whether the storage space capacity satisfies the capacity sum; If satisfied, executing a storage space reorganization operation of the target device; If not, the storage of the firmware file 2 fails, with insufficient capacity as the cause and storage failure as the result, and a warning pop-up window is generated.

6. A method for firmware upgrade capable of rolling back versions as claimed in claim 1, characterized in that: Perform firmware content integrity check, including: Determining a first pre-verification target, wherein the first pre-verification target is firmware content integrity; Taking the firmware file 2 as target data, de-redundantly marking the target data, and determining valid target data, wherein valid firmware codes and configuration parameters for measuring firmware content are taken as the valid target data; Initialize the sha256 computing environment, process the valid target data, and output a target hash value, wherein the target hash value is used to characterize the content characteristics of the firmware file 2; The target hash value is verified according to the standard hash value to generate a content verification result based on the first pre-verification target, which includes verification success or verification failure.

7. A method for firmware upgrade capable of rolling back versions as claimed in claim 6, characterized in that: Perform data integrity checks, including: Determining a second pre-verification target, wherein the second pre-verification target is data integrity; Determine the first-order verification result by rechecking the target hash value; According to the firmware file 2, identifying the check byte; Perform sha256 calculation and hash verification on the verification byte to determine the second-order verification result; A verification result based on a second pre-verification target is determined according to the first-order verification result and the second-order verification result.

8. A method for firmware upgrade capable of rolling back versions as claimed in claim 7, characterized in that: According to the firmware file 2, the check byte is identified, including: Setting a preset byte interval, wherein the preset byte interval is a byte interval; Taking the preset byte interval as a constraint, randomly sampling data bytes of the firmware file 2 to determine the sampled bytes; The sampled bytes are used as the check bytes.

9. A method for firmware upgrade capable of rolling back versions as claimed in claim 1, characterized in that: After the target device has been reorganized, it includes: Introducing the bootarg parameter, wherein the bootarg parameter is used to distinguish the boot partition; The bootarg parameter of the boot.a partition is a, and the bootarg parameter of the boot.b partition is b.

10. A method for firmware upgrade capable of rolling back versions as claimed in claim 9, characterized in that: include: By identifying the bootarg parameter, the partition firmware version is read and written to the driver; If the verification is successful, the bootarg parameter b is identified to perform partition read and write driving; if the verification fails, the bootarg parameter is modified to a to perform partition read and write driving; The existence of a driver bug in the firmware file 2 is used as a compensation condition for verification failure.

Images