Firmware upgrading method, device, equipment and storage medium

Abstract

The application relates to the technical field of firmware upgrading, and discloses a firmware upgrading method, device, equipment and storage medium, the method comprising the following steps: querying a preset storage area, judging whether a stored segmentation index exists in the preset storage area, the segmentation index being an identifier on each segmentation result after the upgrading firmware package is segmented; if yes, acquiring a current segmentation index, the current segmentation index being the latest stored segmentation index in the preset storage area; in the case that a next segmentation index of the current segmentation index does not exist, determining that the firmware upgrading is completed; in the case that the next segmentation index of the current segmentation index exists, performing burning through a target segmentation result corresponding to the next segmentation index, storing the next segmentation index as a new current segmentation index in the preset storage area when the target segmentation result burning is completed, and returning to execute the step of acquiring the current segmentation index until it is determined that the firmware upgrading is completed.

Description

Technical Field

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

[0002] With the rapid development of the electric vehicle industry, charging stations, as critical infrastructure, are being deployed on a large scale in outdoor or semi-outdoor environments. Charging stations typically operate unattended and require remote batch firmware upgrades via OTA (Over-The-Air) to fix vulnerabilities, add features, or meet compliance requirements.

[0003] Current firmware upgrades typically involve downloading the entire firmware package and then flashing it all at once. This means first downloading the complete firmware package to the device's storage, then erasing and writing the target application area all at once. In the actual operating environment of charging stations, unstable power supply is a significant issue, with power outages and voltage fluctuations frequently occurring during peak charging periods or in inclement weather. Because current technology uses a one-time flashing method, if a power outage occurs during the flashing process, the device cannot know the progress of the upgrade after restarting, and must start downloading and flashing the entire firmware package again from scratch. This results in a low firmware upgrade success rate in power outage scenarios. Summary of the Invention

[0004] The main purpose of this application is to provide a firmware upgrade method, which aims to solve the technical problem of how to improve the success rate of firmware upgrades.

[0005] To achieve the above objectives, this application proposes a firmware upgrade method, the method comprising: The preset storage area is queried to determine whether there is a stored segment index in the preset storage area. The segment index is the identifier on each segment result after the upgrade firmware package is segmented. If so, obtain the current segment index, where the current segment index is the latest stored segment index within the preset storage area; If the next segment index of the current segment index does not exist, the firmware upgrade is determined to be complete. If a next segment index exists for the current segment index, the target segment result corresponding to the next segment index is used for burning. When the target segment result is burned, the next segment index is stored as the new current segment index in the preset storage area, and the process of obtaining the current segment index is returned until the firmware upgrade is determined to be complete.

[0006] In one embodiment, before the step of querying a preset storage area to determine whether a segmented index exists in the preset storage area, the method further includes: Obtain the upgrade firmware package, the corresponding firmware length, and the preset segment length; The upgrade firmware package is divided into several segments according to the preset segment length; The current number of segments is determined based on the firmware length and the preset segment length, and a segment index, which serves as a unique identifier, is assigned to each segment result sequentially from front to back based on the current number of segments.

[0007] In one embodiment, before the step of obtaining the current segment index, the method further includes: Obtain the upgrade firmware package and the corresponding metadata description file of the upgrade firmware package; Based on the metadata description file, perform secure signature verification and rollback prevention verification to obtain the security verification result; When the security verification result is that the security verification is passed, the step of obtaining the current segment index is executed.

[0008] In one embodiment, the preset storage area includes several parameter slots, and the step of obtaining the current segment index includes: The validity of each parameter slot is verified, and the validity verification results are obtained. Based on the validity verification results, target parameter slots are selected from each of the parameter slots; The upgrade progress information is extracted from the target parameter slot, and the latest segment index stored in the upgrade progress information is used as the current segment index.

[0009] In one embodiment, the step of selecting the target parameter slot from each of the parameter slots based on the validity verification result includes: Determine the validity verification result corresponding to each parameter slot, and take the parameter slot with the validity verification result being valid as the valid parameter slot; If one of the effective parameter slots exists, the effective parameter slot is used as the target parameter slot; If there are at least two valid parameter slots, obtain the sequence number value corresponding to each valid parameter slot, and take the valid parameter slot with the largest sequence number value as the target parameter slot. If no valid parameter slot exists, a preset parameter slot is obtained and used as the target parameter slot.

[0010] In one embodiment, the target segment hash value corresponding to the target segment result is obtained, and a hash calculation is performed on the target segment result to obtain the actual segment hash value; If the actual segment hash value matches the target segment hash value, the target segment result is burned into the program. If the actual segment hash value is inconsistent with the target segment hash value, determine whether the number of returns has reached a preset threshold. If the number of returns does not reach the preset threshold, update the number of returns and return to the step of obtaining the target segment hash value corresponding to the target segment result, until the number of returns reaches the preset threshold or the actual segment hash value is consistent with the target segment hash value; If the number of returns reaches the preset threshold, the target segment result is marked as a failed segment and recorded in the failed segment bitmap of the preset storage area. The next segment index is stored as the new current segment index in the preset storage area, and the step of obtaining the current segment index is returned until the firmware upgrade is determined to be complete.

[0011] In one embodiment, after the step of determining that the firmware upgrade is complete, the method further includes: Read the failure segment bitmap from the preset storage area; Determine whether the failed segment exists in the failed segment bitmap; When the failure segment exists in the failure segment bitmap, fault reporting information is generated based on the segment index corresponding to each failure segment recorded in the failure segment bitmap, and a fault alarm is triggered based on the fault reporting information.

[0012] Furthermore, to achieve the above objectives, this application also proposes a firmware upgrade device, the device comprising: The query module is used to query a preset storage area to determine whether there is a stored segment index in the preset storage area. The segment index is the identifier on each segment result after the upgrade firmware package is segmented. The acquisition module is used to acquire the current segment index, which is the latest segment index stored in the preset storage area. The segment index is a unique identifier generated on each segment result after the upgrade firmware package is segmented. The upgrade module is used to determine that the firmware upgrade is complete if the next segment index of the current segment index does not exist; The burning module is used to burn the target segment result corresponding to the next segment index when the next segment index of the current segment index exists. When the burning of the target segment result is completed, the next segment index is stored as the new current segment index in the preset storage area, and the step of obtaining the current segment index is returned to be executed until the firmware upgrade is determined to be complete.

[0013] In addition, to achieve the above objectives, this application also proposes a firmware upgrade device, the device having a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the firmware upgrade method as described above when executed by the processor.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium that is a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements the steps of the firmware upgrade method described above.

[0015] This application proposes a firmware upgrade method, apparatus, device, and storage medium. The method includes: querying a preset storage area to determine whether a stored segment index exists in the preset storage area, wherein the segment index is an identifier on each segment result after segmenting the upgrade firmware package; if so, obtaining the current segment index, wherein the current segment index is the latest stored segment index in the preset storage area; if the next segment index of the current segment index does not exist, determining that the firmware upgrade is complete; if the next segment index of the current segment index exists, burning the target segment result corresponding to the next segment index; when the target segment result is burned, storing the next segment index as a new current segment index in the preset storage area, and returning to execute the step of obtaining the current segment index, until the firmware upgrade is determined to be complete.

[0016] This application's firmware upgrade method and device can be configured with a breakpoint resume burning mechanism based on segmented indexes. By querying a preset storage area, it determines whether a stored segmented index (i.e., a unique identifier for each segment after segmenting the upgrade firmware package) exists. If it exists, the latest stored current segmented index is retrieved. During the actual upgrade process, the system checks whether the next segmented index exists. If not, the upgrade is considered complete; if it exists, the next segmented index is used for burning. After burning, this next segmented index is stored as the new current segmented index, and the process is repeated until the upgrade is complete. Compared to existing firmware upgrade schemes that require re-downloading and burning after an upgrade interruption, leading to repetitive work and low upgrade efficiency, this application, by introducing persistent storage of segmented indexes and a breakpoint resume burning mechanism, can resume execution from the last completed burning position after an upgrade interruption, avoiding repeated burning of completed firmware segments. This improves the fault tolerance and efficiency of the upgrade process, thereby increasing the firmware upgrade success rate. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0019] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a flowchart of the first embodiment of the firmware upgrade method proposed in this application; Figure 3 This is a flowchart of a second embodiment of the firmware upgrade method proposed in this application; Figure 4 This is a flowchart of the third embodiment of the firmware upgrade method proposed in this application; Figure 5 A diagram of a firmware upgrade device provided in an embodiment of this application.

[0020] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0022] Reference Figure 1 , Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application.

[0023] like Figure 1As shown, the device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may be connected to a display screen; optionally, the user interface 1003 may include a standard wired interface or a wireless interface. In this application, the wired interface of the user interface 1003 may be a USB interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0024] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0025] like Figure 1 As shown, the memory 1005, which is identified as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a firmware upgrade program.

[0026] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the user equipment; the device calls the firmware upgrade program stored in the memory 1005 through the processor 1001 and executes the steps of the firmware upgrade method provided in the embodiments of this application.

[0027] Understandably, with the rapid development of the electric vehicle industry, charging stations, as critical infrastructure, are being deployed on a large scale in outdoor or semi-outdoor environments. Charging stations typically operate unattended and require remote batch firmware upgrades via OTA (Over-The-Air) to fix vulnerabilities, add features, or meet compliance requirements.

[0028] Current firmware upgrades typically involve downloading the entire firmware package and then flashing it all at once. This means first downloading the complete firmware package to the device's storage, then erasing and writing the target application area all at once. In the actual operating environment of charging stations, unstable power supply is a significant issue, with power outages and voltage fluctuations frequently occurring during peak charging periods or in inclement weather. Because current technology uses a one-time flashing method, if a power outage occurs during the flashing process, the device cannot know the progress of the upgrade after restarting, and must start downloading and flashing the entire firmware package again from scratch. This results in a low firmware upgrade success rate in power outage scenarios.

[0029] Therefore, to solve the above-mentioned technical problems, this embodiment proposes a firmware upgrade method, which includes: querying a preset storage area to determine whether a segment index exists in the preset storage area, where the segment index is the identifier on each segment result after segmenting the upgrade firmware package; if so, obtaining the current segment index, which is the latest stored segment index in the preset storage area; if the next segment index of the current segment index does not exist, determining that the firmware upgrade is complete; if the next segment index of the current segment index exists, burning the target segment result corresponding to the next segment index; when the target segment result is burned, storing the next segment index as the new current segment index in the preset storage area, and returning to execute the step of obtaining the current segment index, until the firmware upgrade is determined to be complete.

[0030] This embodiment of the firmware upgrade method and device can be equipped with a breakpoint resume burning mechanism based on segmented indexes. By querying a preset storage area, it determines whether a stored segmented index (i.e., a unique identifier for each segment after segmenting the upgrade firmware package) exists. If it exists, the latest stored current segmented index is obtained. Then, during the actual upgrade process, the system determines whether the next segmented index exists. If it does not exist, the upgrade is considered complete; if it exists, the next segmented index is used to burn the firmware. After burning, the next segmented index is stored as the new current segmented index, and this process is repeated until the upgrade is complete. Compared to existing firmware upgrade schemes that require re-downloading and burning after an upgrade is interrupted, leading to repetitive work and low upgrade efficiency, this embodiment, by introducing persistent storage of segmented indexes and a breakpoint resume burning mechanism, can continue execution from the last completed burning position after an upgrade is interrupted. This avoids repeatedly burning completed firmware segments, thereby improving the fault tolerance and efficiency of the upgrade process and increasing the firmware upgrade success rate.

[0031] For ease of understanding, the following is combined with Figures 2 to 4 The firmware upgrade method provided in the embodiments of this application, as well as the firmware upgrade method, apparatus, device and storage medium provided in the following embodiments, will be described in detail.

[0032] This application provides a firmware upgrade method. (Refer to...) Figure 2 , Figure 2 This is a flowchart of the first embodiment of the firmware upgrade method proposed in this application.

[0033] like Figure 2 As shown, the method includes: Step S10: Query the preset storage area to determine whether there is a stored segment index in the preset storage area. The segment index is the identifier on each segment result after the upgrade firmware package is segmented.

[0034] It should be noted that the executing entity in this embodiment can be a multi-functional machine device with firmware upgrade capabilities, such as a firmware upgrade device, or a device capable of performing the aforementioned functions. This embodiment uses a firmware upgrade device (hereinafter referred to as the device) for illustration.

[0035] Furthermore, it should be noted that the aforementioned preset storage area may refer to a dedicated storage space pre-allocated within the device's internal non-volatile memory, such as a specific address range in the internal Flash memory. This area is used to persistently store state information during the firmware upgrade process. The aforementioned segment index may refer to a unique identifier assigned to each segment result after logically dividing the upgrade firmware package, such as a consecutive integer number starting from 0. The aforementioned segment result may refer to each independent binary data block obtained by cutting the complete upgrade firmware package into fixed sizes (e.g., 4 kilobytes). The aforementioned unique identifier may refer to numbering information that can distinguish different segment results, such as a segment sequence number.

[0036] In its implementation, after initiating the firmware upgrade process or recovering from a power outage, the device first accesses a pre-defined storage area in the non-volatile memory. The device reads this pre-defined storage area to check if a segment index is already stored there. The segment index is identification information written to the pre-defined storage area after each successful segment burning during the previous upgrade process, used to record the current upgrade progress. By determining whether the segment index exists in the pre-defined storage area, the device determines whether there are any incomplete upgrade tasks.

[0037] Step S20: If yes, then obtain the current segment index, where the current segment index is the latest segment index stored in the preset storage area.

[0038] It should be explained that the aforementioned current segment index can refer to the segment identifier value, representing the latest upgrade progress, read by the device from the preset storage area. The aforementioned latest stored segment index can refer to the segment index value last written to the preset storage area during the previous upgrade process; this index value corresponds to the last successfully burned segment result.

[0039] In its implementation, after determining that a segment index already exists in the preset storage area, the device further reads the segment index information from the preset storage area. The preset storage area may store multiple segment index values, or it may store the segment index value of the last updated record. The device obtains the most recently stored segment index in the preset storage area as the current segment index. Since the current segment index represents the number corresponding to the last successfully burned segment result when the last upgrade was interrupted, the device uses this current segment index as the starting point for resuming the upgrade.

[0040] In another example, when determining whether a stored segment index exists in the preset storage area, if the result is negative, the system checks whether the complete upgrade firmware package data has been stored in the device storage area. This includes checking the firmware package identifier magic number at the beginning of the device storage area, the firmware package length field, and the integrity check value. If the upgrade firmware package exists in the device storage area, it indicates that the device has already downloaded or received the upgrade firmware package, and only the flashing step needs to be performed. Therefore, the segment index of the upgrade firmware package is obtained, and the first segment index is determined. Flashing is then performed based on the first segment result corresponding to the first segment index. After flashing, the first segment index is used as the current segment index and stored in the preset storage area. The system then returns to the step of determining whether a stored segment index exists in the preset storage area. If the upgrade firmware package does not exist in the preset storage area, it is first obtained from a remote source.

[0041] It is understood that the aforementioned device storage area can refer to a dedicated storage space in the device's internal or external non-volatile memory used to temporarily store the complete upgrade firmware package, such as a specific address range of external SPI Flash or a reserved partition of internal Flash. The aforementioned firmware package identifier magic number can refer to a fixed constant value stored at the beginning of the device storage area, used to identify whether the area contains valid firmware package data, such as the preset 4-byte hexadecimal value 0x47494D46. The aforementioned firmware package length field can refer to a field recording the total number of bytes in the upgrade firmware package, usually stored immediately after the firmware package identifier magic number, used to verify the integrity boundaries of the firmware package data. The aforementioned integrity check value can refer to the check result obtained after performing cyclic redundancy check or hash operation on the entire upgrade firmware package data, used to confirm that the firmware package data has not been corrupted during transmission or storage. The aforementioned first segment index can refer to a unique identifier assigned to the first segment result, usually a value of 0. The aforementioned first segment result can refer to the first data block obtained after the upgrade firmware package is segmented, corresponding to segment index 0. The aforementioned remote end can refer to a remote server or cloud platform connected to the device via a network, used to provide firmware package download services.

[0042] Step S30: If the next segment index of the current segment index does not exist, determine that the firmware upgrade is complete.

[0043] It should be explained that the "next segment index" mentioned above can refer to the segment identifier value immediately following the current segment index. For example, if the current segment index is 9, then the next segment index is 10. "None" can mean that there is no segment result corresponding to the next segment index in the segment result set of the upgrade firmware package. For example, when the current segment index is equal to the index of the last segment result, its next segment index will be out of the valid range, i.e., it is considered non-existent.

[0044] In its implementation, after obtaining the current segment index, the device calculates the next segment index based on it. Specifically, the device increments the value of the current segment index by 1 to obtain the value of the next segment index. Then, the device determines whether this next segment index exists in the set of segment results defined by the upgrade firmware package. If the value of the next segment index is greater than or equal to the total number of segments in the upgrade firmware package, it indicates that there is no segment result corresponding to this next segment index, meaning that all segment results have been successfully burned. In this case, the device determines that the firmware upgrade process is complete and no further burning operations are performed.

[0045] Step S40: If the next segment index of the current segment index exists, the target segment result corresponding to the next segment index is burned. When the target segment result is burned, the next segment index is stored as the new current segment index in the preset storage area, and the process of obtaining the current segment index is returned until the firmware upgrade is determined to be complete.

[0046] It should be explained that the aforementioned target segmentation result can refer to the segment data block in the upgrade firmware package corresponding to the next segment index. The aforementioned burning process can refer to the process of writing the segmentation result data into the device's internal non-volatile memory (such as the main application area Flash), typically including operations such as erasing the target address region, writing data, and readback verification. The aforementioned new current segment index can refer to using the value of the next segment index as an updated progress indicator, replacing the original current segment index stored in a preset storage area.

[0047] In its implementation, the device, upon determining that the next segment index exists, locates the corresponding target segment result from the upgrade firmware package based on the next segment index. The device obtains the binary data of the target segment result and burns this data to the corresponding address in the main application area. After the burning operation is complete, the device uses the next segment index as the new current segment index and writes it to a preset storage area. After storing the next segment index in the preset storage area, the device uses the stored index as the new current segment index and returns to execute the step of obtaining the current segment index. The device repeats the above process, burning each subsequent segment result sequentially, updating the segment index in the preset storage area after each burning, until it is determined in a certain loop that the next segment index does not exist, at which point the loop ends and the firmware upgrade is considered complete.

[0048] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, assume the current segment index is 9, the next segment index is 10, and the upgrade firmware package contains 25 segment results. The device determines that the next segment index 10 exists, retrieves the target segment result corresponding to segment index 10 from the upgrade firmware package, and burns this segment result to the main application area. After burning, the device stores segment index 10 as the new current segment index in a preset storage area. Subsequently, the device returns to the step of retrieving the current segment index. At this time, the retrieved current segment index is 10, and the next segment index is 11. The device continues to burn the segment result corresponding to segment index 11. The device repeats the above process, burning the segment results corresponding to segment indices 10 to 24 in sequence. When the device completes the burning of segment index 24 and stores segment index 24 in the preset storage area, it returns to the step of retrieving the current segment index again. At this time, the current segment index is 24, and the next segment index is 25. Since the segmentation result corresponding to segmentation index 25 is not found in the upgrade firmware package, the device determines that the next segmentation index does not exist, and thus determines that the firmware upgrade is complete.

[0049] Furthermore, before the step of querying the preset storage area to determine whether a segmented index already exists in the preset storage area, the method further includes: Step S01: Obtain the upgrade firmware package, the firmware length corresponding to the upgrade firmware package, and the preset segment length; Step S02: Divide the upgrade firmware package into several segments according to the preset segment length; Step S03: Determine the current number of segments based on the firmware length and the preset segment length, and assign a segment index as a unique identifier to each segment result from front to back based on the current number of segments.

[0050] It should be explained that the aforementioned firmware length can refer to the total number of bytes of binary data contained in the upgrade firmware package. The aforementioned preset segment length can refer to the number of bytes contained in each pre-defined segment, such as 4 kilobytes (4096 bytes), a value that can be configured according to the Flash page size or transmission efficiency of the embedded system. The aforementioned segment result can refer to each independent data block obtained after cutting the complete upgrade firmware package according to the preset segment length; except for the last data block, which may be smaller than the preset segment length, the size of each data block is equal to the preset segment length. The aforementioned current segment count can refer to the total number of segment results obtained after completely dividing the upgrade firmware package. The aforementioned unique identifier can refer to the unique number assigned to each segment result, which is distinct within the entire segment set. The aforementioned sequential allocation from front to back can refer to allocating segment indices sequentially, starting from 0 and increasing incrementally, according to the arrangement order of the segment results in the original firmware package.

[0051] In its implementation, before performing a firmware upgrade, the device first retrieves the firmware package to be upgraded from a cloud server or local storage medium. Simultaneously, the device obtains the firmware length corresponding to the upgrade firmware package and the preset segment length pre-configured by the system. The device then segments the upgrade firmware package according to the preset segment length. Specifically, starting from the beginning of the upgrade firmware package, the device reads data sequentially according to the preset segment length, treating each read segment as a segment result. When the remaining data is less than the preset segment length, all remaining data is used as the last segment result. After segmentation, the device calculates the current number of segments based on the firmware length and the preset segment length. The device divides the firmware length by the preset segment length; if the division is even, the current number of segments equals the quotient; otherwise, the current number of segments equals the quotient plus 1. Subsequently, the aforementioned device assigns a segment index to each segmented result starting from 0. The first segmented result corresponds to segment index 0, the second segmented result corresponds to segment index 1, and so on, until the last segmented result corresponds to a segment index equal to the current number of segments minus 1.

[0052] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, suppose the device obtains an upgrade firmware package with a firmware length of 100 kilobytes (102400 bytes). The device obtains a preset segment length of 4 kilobytes (4096 bytes). The device divides 102400 by 4096, obtaining a quotient of 25, which is divisible, therefore the current number of segments is 25. The device divides the upgrade firmware package into 25 segments, each segment consisting of 4096 bytes. Starting with the first segment, the device assigns it a segment index of 0; the second segment assigns a segment index of 1; and so on, assigning a segment index of 24 to the 25th segment. Thus, the device obtains 25 segments with unique segment indices.

[0053] Furthermore, to ensure the security of the upgrade firmware package, the step of obtaining the current segment index is preceded by: Step S04: Obtain the upgrade firmware package and the metadata description file corresponding to the upgrade firmware package; Step S05: Perform security signature verification and rollback prevention verification based on the metadata description file to obtain the security verification result; Step S06: When the security verification result is that the security verification is passed, execute the step of obtaining the current segment index.

[0054] It should be explained that the aforementioned metadata description file can refer to a structured data file distributed along with the upgrade firmware package, used to describe the attribute information of the firmware package. This metadata description file may contain information such as firmware version number, firmware length, segment size, segment hash value list, rollback prevention counter, target device identifier, and digital signature. The aforementioned secure signature verification can refer to the process of using cryptographic algorithms to verify the validity of the digital signature of the metadata description file, used to confirm that the source of the metadata description file is trustworthy and has not been tampered with during transmission. The aforementioned rollback prevention verification can refer to the process of comparing the rollback prevention counter in the metadata description file with the minimum allowed version value stored internally by the device, used to prevent attackers from downgrading the device firmware to an older version with security vulnerabilities. The aforementioned security verification result can refer to the combined judgment result after the secure signature verification and rollback prevention verification pass, including two states: security verification passed or security verification failed.

[0055] In its implementation, before initiating the firmware upgrade process, the device obtains the upgrade firmware package and the corresponding metadata description file. The device can download both the upgrade firmware package and the metadata description file simultaneously from a cloud server, or read both files from local storage. After obtaining the metadata description file, the device performs a security signature verification. The device extracts the digital signature field and the data field to be signed from the metadata description file, and uses a pre-stored public key to perform a signature verification operation on the data to be signed, determining whether the digital signature is valid. If the signature is invalid, the device determines that the security verification result has failed and terminates the upgrade process. If the signature is valid, the device continues to perform anti-rollback verification. The device reads the anti-rollback counter from the metadata description file and compares this counter with the current anti-rollback version number stored in the device's internal non-volatile memory. If the anti-rollback counter in the metadata description file is less than the anti-rollback version number stored internally, it indicates a downgrade attack attempt, and the device determines that the security verification result has failed and terminates the upgrade process. If the rollback prevention counter in the metadata description file is greater than or equal to the rollback prevention version number stored internally by the device, the device determines that the security verification result is passed, and optionally updates the rollback prevention version number stored internally by the device to the rollback prevention counter in the metadata description file. When the security verification result is passed, the device performs the step of obtaining the current segment index and begins the firmware upgrade.

[0056] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, assume the device obtains an upgrade firmware package and its corresponding metadata description file from a cloud server. The metadata description file contains the firmware version number "2.0.0", the rollback prevention counter "5", the target device identifier "charging pile-001", and a digital signature generated using a private key. The device first uses a pre-stored public key to verify the signature of the metadata description file, calculating that the signature is valid and confirming the file source is trustworthy. Next, the device reads the currently stored rollback prevention version number from a dedicated area of ​​its internal Flash memory, finding a value of "4". The device compares the rollback prevention counter "5" in the metadata description file with the version number "4" stored internally. Since 5 is greater than 4, the rollback prevention verification passes. The device updates the internally stored rollback prevention version number to "5" and sets the security verification result to pass. Subsequently, the device begins the step of obtaining the current segment index and performs a segmented flash upgrade.

[0057] This embodiment introduces persistent storage of segmented indexes and a breakpoint resume mechanism, which can resume execution from the last completed burning position after the upgrade is interrupted, avoiding repeated burning of completed firmware segments. This improves the fault tolerance and efficiency of the upgrade process when users upgrade firmware, thereby increasing the success rate of firmware upgrades.

[0058] Based on the first embodiment, in the second embodiment, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart of a second embodiment of the firmware upgrade method proposed in this application. Further, the preset storage area includes several parameter slots, and the step of obtaining the current segment index includes: Step S21: Verify the validity of each parameter slot and obtain the validity verification result.

[0059] It should be explained that the aforementioned parameter slots can refer to two independent storage areas pre-allocated within the device's internal non-volatile memory for storing upgrade progress parameters, such as parameter slot A and parameter slot B. The aforementioned validity verification can refer to the process of performing integrity checks and consistency judgments on the data stored in the parameter slots, including checking whether the magic number matches, whether the tail magic number exists, and whether the cyclic redundancy check of the structure is correct. The aforementioned validity verification result can refer to the judgment conclusion obtained after integrity checks for each parameter slot, including two states: valid or invalid.

[0060] In its implementation, the device performs validity verification on each parameter slot before reading the upgrade progress parameters. The device sequentially reads the data structures stored in parameter slot A and parameter slot B. For each parameter slot, the device first checks if the magic number field at the beginning of the slot equals a preset magic number, and simultaneously checks if the tail magic number field at the end of the slot equals a preset tail magic number. If both the magic number and the tail magic number match, the device further calculates the cyclic redundancy check (CRUD) value of the data area in the parameter slot excluding the magic number, and compares the calculated CRUD value with the CRUD field of the structure stored in the parameter slot. If the calculated CRUD value matches the stored CRUD value, the device determines the parameter slot is valid; if any of the following occurs: magic number mismatch, tail magic number mismatch, or inconsistent CRUD, the device determines the parameter slot is invalid. After traversing all parameter slots, the device obtains the validity verification result for each parameter slot.

[0061] Step S22: Based on the validity verification results, select the target parameter slot from each of the parameter slots.

[0062] It should be explained that the aforementioned target parameter slot can refer to the single parameter slot selected from multiple parameter slots to provide valid upgrade progress data. When multiple parameter slots are valid, the target parameter slot is the one with the larger sequence number; when only one parameter slot is valid, the target parameter slot is that valid parameter slot.

[0063] Step S23: Extract upgrade progress information from the target parameter slot, and use the latest stored segment index in the upgrade progress information as the current segment index.

[0064] It should be explained that the aforementioned upgrade progress information refers to a structured data set stored in the target parameter slot, used to describe the status of the firmware upgrade process. This upgrade progress information may include fields such as the current upgrade stage, the index of the last successful segment, the number of returns, the total number of segments, the firmware version number, the firmware size, fault information, and flag bits. The most recently stored segment index may refer to the value indicated by the last successful segment index field in the upgrade progress information, which represents the segment identifier corresponding to the last successfully flashed segment result.

[0065] In its implementation, after selecting the target parameter slots, the device reads the upgrade progress information from them. The device parses the binary data in the target parameter slots according to a preset data structure, extracting the values ​​of each field. The device locates the last successful segment index field from the upgrade progress information and uses the value stored in that field as the current segment index. This current segment index represents the number of the last successfully burned segment when the last upgrade was interrupted; the device uses this as the basis to determine the starting position for subsequent re-burning.

[0066] Further, the step of selecting the target parameter slot from each of the parameter slots based on the validity verification result includes: Determine the validity verification result corresponding to each parameter slot, and take the parameter slot with the validity verification result being valid as the valid parameter slot; If one of the effective parameter slots exists, the effective parameter slot is used as the target parameter slot; If there are at least two valid parameter slots, obtain the sequence number value corresponding to each valid parameter slot, and take the valid parameter slot with the largest sequence number value as the target parameter slot. If no valid parameter slot exists, a preset parameter slot is obtained and used as the target parameter slot.

[0067] It should be explained that the aforementioned valid parameter slots refer to those that have been verified as valid. The aforementioned serial number value can be a monotonically increasing integer stored in the parameter slot; each time a parameter slot update operation is performed, the serial number value increments by 1, used to distinguish the age of the data stored in different parameter slots. The aforementioned preset parameter slots can refer to the default parameter slots pre-configured at the factory, or a parameter storage area containing default upgrade progress information, used to provide usable initial upgrade progress data when all parameter slots are invalid.

[0068] In its implementation, the device performs validity verification on each parameter slot and obtains the validity verification result for each slot. The device then identifies the parameter slots with valid validity verification results as valid parameter slots. Subsequently, the device counts the number of valid parameter slots. If one valid parameter slot exists, the device designates this unique valid parameter slot as the target parameter slot. If at least two valid parameter slots exist, the device reads the serial number value from each valid parameter slot, compares all read serial number values, determines the valid parameter slot corresponding to the maximum value, and designates this valid parameter slot as the target parameter slot. If no valid parameter slot exists, the device retrieves the preset parameter slot from the factory and designates this preset parameter slot as the target parameter slot to ensure that the upgrade process can obtain usable initial upgrade progress information.

[0069] To facilitate understanding, the following examples are provided for illustration, but they do not impose specific limitations on this embodiment. For example, suppose that after the device verifies the validity of parameter slot A and parameter slot B, parameter slot A is valid and parameter slot B is invalid. The device counts the number of valid parameter slots as 1 and uses parameter slot A as the target parameter slot. As another example, suppose that both parameter slot A and parameter slot B are valid, the device reads a serial number value of 8 from parameter slot A and a serial number value of 10 from parameter slot B, and uses parameter slot B corresponding to serial number value 10 as the target parameter slot. Yet another example, suppose that both parameter slot A and parameter slot B are invalid, the device obtains a preset parameter slot burned into the read-only area at the factory. This preset parameter slot contains an initial segment index value of 0 and an initial serial number value of 0. The device uses this preset parameter slot as the target parameter slot for initial firmware upgrades or emergency recovery scenarios.

[0070] Further, the step of storing the next segment index as the new current segment index in the preset storage area includes: The next segment index is used as the new current segment index, and the new current segment index is written to the target parameter slot in the order of writing data body, integrity verification data, tail magic number, and head magic number. The head magic number is written last as the atomic commit flag.

[0071] It should be noted that the aforementioned data body can refer to the core data portion of the upgrade progress information structure, excluding the head magic number, integrity verification data, and tail magic number. This includes fields such as serial number, upgrade status, last successful segment index, return count, total number of segments, and flag bits. The aforementioned integrity verification data can refer to the verification value obtained after performing cyclic redundancy check or hash operation on the data body, used to verify whether the data body remains intact and has not been tampered with after storage. The aforementioned tail magic number can refer to a fixed constant value located at the end of the parameter slot, used to detect whether an interruption occurred during the write process, such as the preset 4-byte hexadecimal value 0x47494D41. The aforementioned head magic number can refer to a fixed constant value located at the beginning of the parameter slot, used as an atomic commit flag, such as the preset 4-byte hexadecimal value 0x4D414749. The aforementioned atomic commit flag can refer to a mechanism identifier that ensures the data write operation is either completely successful or completely ineffective. As the last field written, the existence of the head magic number indicates that the data in the entire parameter slot has been completely written.

[0072] In its implementation, the device first writes the data body (including the new current segment index, updated serial number, upgrade status, etc.) into the target parameter slot, excluding the head magic number position. Then, the device calculates the cyclic redundancy check value of the data body and writes the calculated integrity check data into the corresponding check field position in the target parameter slot. Next, the device writes the preset tail magic number to the end of the target parameter slot. After all the above steps are completed, the device finally writes the head magic number to the beginning of the target parameter slot. The device uses the head magic number as an atomic commit flag, indicating that the data body, integrity check data, and tail magic number have all been successfully written. If a power outage occurs at any step during the writing process, the head magic number will not be written, and the target parameter slot will be deemed invalid during subsequent readings due to the lack of a valid head magic number, thus ensuring the atomicity of the data writing process.

[0073] Based on the first and second embodiments, in the third embodiment, the content that is the same as or similar to that in Embodiments 1 and 2 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart of the third embodiment of the firmware upgrade method proposed in this application. Further, the step of obtaining the target segment result corresponding to the next segment index and burning it includes: Step S41: Obtain the target segment hash value corresponding to the target segment result, and perform hash calculation on the target segment result to obtain the actual segment hash value; Step S42: If the actual segment hash value is consistent with the target segment hash value, burn the target segment result.

[0074] It should be explained that the aforementioned target segment hash value can refer to the hash value pre-stored in the metadata description file (Manifest) corresponding to the target segment result. This hash value serves as the expected standard value for the segment result in subsequent comparison and verification. The aforementioned hash calculation can refer to a one-way hash operation performed on the binary data of the target segment result using a cryptographic hash function (such as SHA-256), which converts input data of arbitrary length into a hash value output of fixed length. The aforementioned actual segment hash value can refer to the result value obtained by the device after performing a hash calculation on the target segment result, representing the true hash fingerprint of the segment result at the current moment.

[0075] In its implementation, after obtaining the target segment result, the device retrieves the target segment hash value corresponding to that result from the metadata description file. This target segment hash value is pre-calculated and stored in the Manifest during firmware package creation. Subsequently, the device performs a hash calculation on the target segment result, using hash algorithms such as SHA-256 to operate on the binary data of the target segment result, obtaining a fixed-length actual segment hash value. The device compares the actual segment hash value with the target segment hash value. If the actual segment hash value matches the target segment hash value, it indicates that the target segment result data is complete and has not been tampered with. The device then performs a burning operation on the target segment result, writing it to the corresponding address in the main application area. If the actual segment hash value does not match the target segment hash value, it indicates that the target segment result may be corrupted. The device terminates the burning of that segment result and triggers a retry or error handling process.

[0076] Step S43: If the actual segment hash value is inconsistent with the target segment hash value, determine whether the number of returns has reached a preset threshold; Step S44: If the number of returns does not reach the preset threshold, update the number of returns and return to the step of obtaining the target segment hash value corresponding to the target segment result, until the number of returns reaches the preset threshold or the actual segment hash value is consistent with the target segment hash value; Step S45: If the number of returns reaches the preset threshold, mark the target segmentation result as a failed segment and record it in the failed segment bitmap of the preset storage area. Store the next segment index as the new current segment index in the preset storage area and return to execute the step of obtaining the current segment index until the firmware upgrade is determined to be complete.

[0077] In its implementation, when the actual segment hash value differs from the target segment hash value, the device first determines whether the return count has reached a preset threshold. The device reads the return count variable stored in memory or non-volatile storage and compares its current value with the preset threshold. If the return count has not reached the preset threshold, the device updates the return count by incrementing the variable by 1 and writing the updated value back to storage. Subsequently, the device returns to the step of obtaining the target segment hash value corresponding to the target segment result. This involves rereading the target segment hash value from the metadata description file, recalculating the hash value to obtain a new actual segment hash value, and then comparing this new actual segment hash value with the newly obtained target segment hash value. The device repeats this process until the return count reaches the preset threshold or the actual segment hash value matches the target segment hash value in a particular comparison.

[0078] If the number of return attempts reaches a preset threshold, it indicates that the target segment result still fails the hash check after a preset number of repeated verifications. The device marks the target segment result as a failed segment and sets the corresponding binary bit to 1 in the failed segment bitmap of the preset storage area. The device stores the next segment index as the new current segment index in the preset storage area, skips the currently failed segment result, and continues processing subsequent segment results. The device returns to the step of obtaining the current segment index and performs the same burning process on the next segment result until all segment results have been processed, at which point the firmware upgrade is considered complete.

[0079] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, assume the preset threshold is 3 times, the current return count is initialized to 0, and the target segmentation result corresponds to segmentation index 10. During the first verification, the device finds that the actual segmentation hash value is inconsistent with the target segmentation hash value, determines that the return count of 0 has not reached the threshold of 3, updates the return count to 1, returns to re-acquire the target segmentation hash value, and recalculates the actual segmentation hash value. The second comparison is still inconsistent, the return count of 1 has not reached the threshold of 3, updates the return count to 2, and returns again. The third comparison is still inconsistent, the return count of 2 has not reached the threshold of 3, updates the return count to 3, and returns again. The fourth comparison is still inconsistent, this time the return count is 3, reaching the preset threshold of 3, and the device stops retrying. The device marks segmentation index 10 as a failed segment, setting bit 10 to 1 in the failed segment bitmap. The device stores the next segmentation index 11 as the new current segmentation index in the preset storage area. The device returns to execute the step of obtaining the current segmentation index and continues processing the segmentation result corresponding to segmentation index 11. If the actual segment hash value matches the target segment hash value in the second comparison, the device will directly perform the burning operation on the segment result and will not mark it as a failed segment.

[0080] Furthermore, after the step of determining that the firmware upgrade is complete, the method further includes: Read the failure segment bitmap from the preset storage area; Determine whether the failed segment exists in the failed segment bitmap; When the failure segment exists in the failure segment bitmap, fault reporting information is generated based on the segment index corresponding to each failure segment recorded in the failure segment bitmap, and a fault alarm is triggered based on the fault reporting information.

[0081] It should be explained that the aforementioned fault reporting information can refer to structured data generated by the device to describe the failure segments that occur during the firmware upgrade process. This fault reporting information may include the number of failed segments, a list of segment indices corresponding to each failed segment, a timestamp of the failure, and device identification information. The aforementioned fault alarm can refer to the device sending a fault notification to a remote server or maintenance terminal via its communication module, or the device displaying a fault status through a local display interface, indicator lights, or other means.

[0082] In its implementation, after completing the firmware upgrade process, the device reads the failure segment bitmap stored in a preset storage area. This failure segment bitmap is a binary bit array, where each bit corresponds to a segment index. A value of 1 indicates a failed segment, and a value of 0 indicates a successful segment. The device iterates through each bit in the failure segment bitmap, checking if any bit is marked as 1. If at least one bit is 1, a failure segment is identified in the bitmap. When a failure segment is present, the device generates fault reporting information based on the segment indices recorded in the bitmap. The device extracts the segment index values ​​corresponding to all bits with a value of 1 from the failure segment bitmap, arranges these index values ​​in ascending order, and encapsulates them along with additional information such as the device identifier, firmware version number, upgrade timestamp, and hash value of the failed segment into fault reporting information. Subsequently, the aforementioned equipment will issue a fault alarm based on the fault reporting information. Specifically, the fault reporting information can be sent to the remote operation and maintenance server through the network interface, or the index list of failed segments can be displayed on the local display screen of the equipment, or the fault indicator light can be lit to alert the on-site maintenance personnel.

[0083] In addition, after the step of determining that the firmware upgrade is complete, the following steps are also included: Detect the reset source identifier during the device startup phase; When the reset source identifier is a watchdog reset identifier, increment the startup failure counter; When the startup failure counter reaches the preset failure threshold, the gold image stored in the backup application area is copied to the main application area to obtain the restored main application area firmware.

[0084] It should be explained that the aforementioned reset source identifier can refer to the identifier information read from the reset control register after the device is reset, used to indicate the reason for this device reset. The aforementioned watchdog reset identifier can refer to a specific type of reset source identifier, indicating a reset triggered by a watchdog timer timeout, typically indicating an abnormal situation such as an infinite loop, prolonged blocking, or crash during application execution. The aforementioned boot failure counter can refer to an integer value stored in non-volatile memory, used to accumulate the number of times the watchdog resets due to application abnormalities.

[0085] The aforementioned preset failure threshold can refer to a pre-set maximum number of allowed boot failures, such as 5 times. A recovery mechanism is triggered when the boot failure counter reaches this threshold. The aforementioned backup application area can refer to a dedicated storage area pre-allocated in the device's non-volatile memory, used to store the proven and usable firmware burned at the factory, i.e., the "golden image." The aforementioned golden image can refer to a firmware copy that has undergone thorough testing and verification to ensure normal boot and operation. The aforementioned main application area can refer to the fixed Flash address area where the firmware is executed during normal device operation; all applications always boot from this address. The aforementioned copying can refer to the process of copying the golden image data stored in the backup application area byte-by-byte or block-by-block to the main application area.

[0086] In its implementation, the device detects the reset source flag during the bootloader execution phase at each startup. It reads the flag bit in the reset control register to determine the trigger source for this reset. When the reset source flag is a watchdog reset flag, it indicates that a watchdog timeout occurred during the previous application execution, and the application may have crashed or entered an infinite loop. In this case, the device increments the startup failure counter, adding 1 to the value stored in non-volatile memory and writing the updated value back to non-volatile memory. The device then determines whether the startup failure counter has reached a preset failure threshold. If the startup failure counter is less than the preset failure threshold, the device attempts to boot the firmware in the main application area normally. If the startup failure counter reaches the preset failure threshold, indicating multiple consecutive startup failures, the device initiates a copy-based rollback mechanism, copying the gold image stored in the backup application area to the main application area. The device reads the gold image data from the starting address of the backup application area and writes the data to the main application area in a segmented copy manner. After each segment is written, a readback verification is performed to ensure the data copy is correct. After completing the copying of all data, the device obtains the restored firmware for the main application area. Subsequently, the device resets the boot failure counter to 0 and starts execution from the restored main application area.

[0087] This embodiment also provides a first embodiment of a firmware upgrade device; please refer to [link / reference]. Figure 5 , Figure 5 This is a diagram of a firmware upgrade device provided in an embodiment of this application. The firmware upgrade device includes: The query module is used to query a preset storage area to determine whether there is a stored segment index in the preset storage area. The segment index is the identifier on each segment result after the upgrade firmware package is segmented. The acquisition module is used to acquire the current segment index, which is the latest segment index stored in the preset storage area. The segment index is a unique identifier generated on each segment result after the upgrade firmware package is segmented. The upgrade module is used to determine that the firmware upgrade is complete if the next segment index of the current segment index does not exist; The burning module is used to burn the target segment result corresponding to the next segment index when the next segment index of the current segment index exists. When the burning of the target segment result is completed, the next segment index is stored as the new current segment index in the preset storage area, and the step of obtaining the current segment index is returned to be executed until the firmware upgrade is determined to be complete.

[0088] The acquisition module is further configured to acquire the upgrade firmware package, the firmware length corresponding to the upgrade firmware package, and the preset segment length; divide the upgrade firmware package into several segment results according to the preset segment length; determine the current number of segments based on the firmware length and the preset segment length, and assign a segment index as a unique identifier to each segment result sequentially from front to back based on the current number of segments.

[0089] The acquisition module is further configured to acquire the upgrade firmware package and the metadata description file corresponding to the upgrade firmware package; perform security signature verification and anti-rollback verification based on the metadata description file to obtain a security verification result; and when the security verification result is a successful security verification, execute the step of acquiring the current segment index.

[0090] Referring to the first embodiment of the firmware upgrade device, this embodiment also proposes a second embodiment of the firmware upgrade device. The contents that are the same as or similar to those in the first embodiment of the firmware upgrade device can be referred to the above description, and will not be repeated hereafter.

[0091] The acquisition module is further configured to perform validity verification on each parameter slot and obtain validity verification results; select target parameter slots from each parameter slot based on the validity verification results; extract upgrade progress information from the target parameter slots and use the latest stored segment index in the upgrade progress information as the current segment index.

[0092] The acquisition module is further configured to determine the validity verification result corresponding to each of the parameter slots, and to designate the parameter slots with valid validity verification results as valid parameter slots; if there is one valid parameter slot, designate the valid parameter slot as the target parameter slot; if there are at least two valid parameter slots, acquire the serial number value corresponding to each of the valid parameter slots, and designate the valid parameter slot with the largest serial number value as the target parameter slot; if there is no valid parameter slot, acquire a preset parameter slot, and designate the preset parameter slot as the target parameter slot.

[0093] Referring to the first and second embodiments of the firmware upgrade device, this embodiment also proposes a third embodiment of the firmware upgrade device. The contents that are the same as or similar to the first and second embodiments of the firmware upgrade device can be referred to the above description, and will not be repeated hereafter.

[0094] The programming module is further configured to obtain the target segment hash value corresponding to the target segment result, and perform hash calculation on the target segment result to obtain the actual segment hash value; if the actual segment hash value is consistent with the target segment hash value, the target segment result is programmed; if the actual segment hash value is inconsistent with the target segment hash value, the step of obtaining the target segment hash value corresponding to the target segment result is returned until the number of returns reaches a preset threshold or the actual segment hash value is consistent with the target segment hash value; when the number of returns reaches the preset threshold and the actual segment hash value is inconsistent with the target segment hash value, the target segment result is marked as a failed segment and recorded in the failed segment bitmap of the preset storage area, the next segment index is stored as the new current segment index in the preset storage area, and the step of obtaining the current segment index is returned until the firmware upgrade is determined to be complete.

[0095] The upgrade module is further configured to read the failure segment bitmap in the preset storage area; determine whether the failure segment exists in the failure segment bitmap; when the failure segment exists in the failure segment bitmap, generate fault reporting information based on the segment index corresponding to each failure segment recorded in the failure segment bitmap, and perform fault alarm based on the fault reporting information.

[0096] The firmware upgrade device provided in this embodiment, employing the firmware upgrade method described in the above embodiments, can solve the technical problem of how to improve the success rate of firmware upgrades. Compared with the prior art, the beneficial effects of the firmware upgrade device provided in this embodiment are the same as those of the firmware upgrade method described in the above embodiments, and other technical features in the firmware upgrade device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0097] This embodiment provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the firmware upgrade method in the above embodiment.

[0098] The computer-readable storage medium provided in this embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0099] The aforementioned computer-readable storage medium may be included in the firmware upgrade device; or it may exist independently and not be assembled into the firmware upgrade device.

[0100] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the firmware upgrade device, cause the firmware upgrade device to perform a firmware upgrade.

[0101] Computer program code for performing the operations of this embodiment can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0102] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of the system, method, and display according to various embodiments of this embodiment. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0103] The modules described in this embodiment can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0104] The readable storage medium provided in this embodiment is a computer-readable storage medium, which stores computer-readable program instructions (i.e., a computer program) for executing the above-described firmware upgrade method, and can solve the technical problem of how to improve the viewing experience of the display screen. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this embodiment are the same as the beneficial effects of the firmware upgrade method provided in the above embodiments, and will not be repeated here.

[0105] The above descriptions are only some embodiments and do not limit the patent scope of this embodiment. All equivalent structural transformations made based on the technical concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A firmware upgrade method, characterized in that, The method includes: The preset storage area is queried to determine whether there is a stored segment index in the preset storage area. The segment index is the identifier on each segment result after the upgrade firmware package is segmented. If so, then obtain the current segment index, which is the latest segment index stored in the preset storage area; If the next segment index of the current segment index does not exist, the firmware upgrade is determined to be complete. If a next segment index exists for the current segment index, the target segment result corresponding to the next segment index is used for burning. When the target segment result is burned, the next segment index is stored as the new current segment index in the preset storage area, and the process of obtaining the current segment index is returned until the firmware upgrade is determined to be complete.

2. The method as described in claim 1, characterized in that, Before the step of querying the preset storage area to determine whether a segmented index exists in the preset storage area, the method further includes: Obtain the upgrade firmware package, the corresponding firmware length, and the preset segment length; The upgrade firmware package is divided into several segments according to the preset segment length; The current number of segments is determined based on the firmware length and the preset segment length, and a segment index, which serves as a unique identifier, is assigned to each segment result sequentially from front to back based on the current number of segments.

3. The method as described in claim 1, characterized in that, Before the step of obtaining the current segment index, the method further includes: Obtain the upgrade firmware package and the corresponding metadata description file of the upgrade firmware package; Based on the metadata description file, perform secure signature verification and rollback prevention verification to obtain the security verification result; When the security verification result is that the security verification is passed, the step of obtaining the current segment index is executed.

4. The method as described in claim 1, characterized in that, The preset storage area includes several parameter slots, and the step of obtaining the current segment index includes: The validity of each parameter slot is verified, and the validity verification results are obtained. Based on the validity verification results, target parameter slots are selected from each of the parameter slots; The upgrade progress information is extracted from the target parameter slot, and the latest segment index stored in the upgrade progress information is used as the current segment index.

5. The method as described in claim 4, characterized in that, The step of selecting the target parameter slot from each parameter slot based on the validity verification result includes: Determine the validity verification result corresponding to each parameter slot, and take the parameter slot with the validity verification result being valid as the valid parameter slot; If one of the effective parameter slots exists, the effective parameter slot is used as the target parameter slot; If there are at least two valid parameter slots, obtain the sequence number value corresponding to each valid parameter slot, and take the valid parameter slot with the largest sequence number value as the target parameter slot. If no valid parameter slot exists, a preset parameter slot is obtained and used as the target parameter slot.

6. The method as described in claim 1, characterized in that, The step of obtaining the target segment result corresponding to the next segment index and burning it includes: Obtain the target segment hash value corresponding to the target segment result, and perform hash calculation on the target segment result to obtain the actual segment hash value; If the actual segment hash value matches the target segment hash value, the target segment result is burned into the program. If the actual segment hash value is inconsistent with the target segment hash value, determine whether the number of returns has reached a preset threshold. If the number of returns does not reach the preset threshold, update the number of returns and return to the step of obtaining the target segment hash value corresponding to the target segment result, until the number of returns reaches the preset threshold or the actual segment hash value is consistent with the target segment hash value; If the number of returns reaches the preset threshold, the target segment result is marked as a failed segment and recorded in the failed segment bitmap of the preset storage area. The next segment index is stored as the new current segment index in the preset storage area, and the step of obtaining the current segment index is returned until the firmware upgrade is determined to be complete.

7. The method as described in claim 6, characterized in that, After the step of determining that the firmware upgrade is complete, the following steps are also included: Read the failure segment bitmap from the preset storage area; Determine whether the failed segment exists in the failed segment bitmap; When the failure segment exists in the failure segment bitmap, fault reporting information is generated based on the segment index corresponding to each failure segment recorded in the failure segment bitmap, and a fault alarm is triggered based on the fault reporting information.

8. A firmware upgrade device, characterized in that, The device includes: The query module is used to query a preset storage area to determine whether there is a stored segment index in the preset storage area. The segment index is the identifier on each segment result after the upgrade firmware package is segmented. The acquisition module is used to acquire the current segment index, which is the latest segment index stored in the preset storage area. The segment index is a unique identifier generated on each segment result after the upgrade firmware package is segmented. The upgrade module is used to determine that the firmware upgrade is complete if the next segment index of the current segment index does not exist; The burning module is used to burn the target segment result corresponding to the next segment index when the next segment index of the current segment index exists. When the burning of the target segment result is completed, the next segment index is stored as the new current segment index in the preset storage area, and the step of obtaining the current segment index is returned to be executed until the firmware upgrade is determined to be complete.

9. A firmware upgrade device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the firmware upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the firmware upgrade method as described in any one of claims 1 to 7.

Images