Firmware upgrading method and device, equipment and medium

Abstract

The invention relates to a firmware upgrading method and device, equipment and a medium, and the method comprises the steps: responding to a firmware upgrading event, judging whether the current firmware version information of each chip in local equipment is consistent with the corresponding latest firmware version information in an upgrading server, and determining each target chip with inconsistent version information; obtaining a firmware upgrade package from the upgrade server, wherein the firmware upgrade package comprises upgrade metadata and firmware upgrade data corresponding to each target chip; and according to chip upgrading sequence information in the upgrading metadata, sending the firmware upgrading data to a corresponding target chip in sequence, and driving the target chip to execute firmware upgrading. According to the method and the device, the multi-chip firmware upgrading process is managed in a centralized manner, so that uniform acquisition and ordered upgrading of the firmware upgrading package are realized.

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 medium. Background Technology

[0002] In modern smart devices, firmware upgrades are a crucial step in ensuring device functionality optimization, security, and user experience. This is especially true for complex distributed systems, such as smart door lock systems. These systems typically contain multiple functionally independent microcontrollers, such as main control chips, Bluetooth chips, and Wi-Fi chips. Each chip performs different functions, and remote firmware updates for these chips are essential to fix security vulnerabilities, add new features, or improve performance.

[0003] However, existing firmware upgrade methods have several problems. First, the upgrade process typically requires separate version comparison and firmware download for each chip. This decentralized approach is not only cumbersome and prone to missing upgrades for certain chips, but also makes it difficult to ensure that all chips reach the preset, compatible version combination at the same time, leading to system compatibility issues and affecting the overall functionality and stability of the device. Furthermore, because this method requires multiple independent download and verification processes, it not only repeatedly consumes network bandwidth but also increases the device's computing resources and power consumption. In addition, in scenarios where multiple chips work together, the update order of different chips is crucial, but existing technologies lack centralized management and automated execution mechanisms for firmware update order, which can easily lead to update failures or operational anomalies. Summary of the Invention

[0004] The primary objective of this application is to provide a firmware upgrade method, apparatus, device, or medium that addresses at least one of the aforementioned problems.

[0005] To achieve the various objectives of this application, the following technical solution is adopted: A firmware upgrade method provided for one of the purposes of this application includes the following steps: In response to firmware upgrade events, determine whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identify the target chips whose version information is inconsistent. Obtain a firmware upgrade package from the upgrade server. The firmware upgrade package contains upgrade metadata and firmware upgrade data corresponding to each target chip. Based on the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip, driving the target chip to perform a firmware upgrade.

[0006] A firmware upgrade apparatus, proposed for one of the purposes of this application, includes: The firmware version detection module is configured to respond to firmware upgrade events, determine whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identify each target chip with inconsistent version information. The firmware upgrade package acquisition module is configured to acquire a firmware upgrade package from the upgrade server. The firmware upgrade package includes upgrade metadata and firmware upgrade data corresponding to each target chip. The firmware upgrade execution module is configured to send the firmware upgrade data sequentially to the corresponding target chip according to the chip upgrade order information in the upgrade metadata, and drive the target chip to perform firmware upgrade.

[0007] A computer device provided for one of the purposes of this application includes a central processing unit and a memory, wherein the central processing unit is configured to invoke and run a computer program stored in the memory to perform the steps of the firmware upgrade method described in this application.

[0008] On another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the described firmware upgrade method, which, when called by a computer, executes the steps included in the corresponding method.

[0009] Compared with existing technologies, the advantages of this application are as follows: First, the firmware upgrade method of this application significantly improves the reliability of firmware upgrades by centrally managing the firmware upgrade process. Specifically, by responding to firmware upgrade events, it determines whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identifies the target chips with inconsistent version information. This achieves unified management and upgrade of multiple chips, avoiding compatibility issues and operational cumbersomeness caused by upgrading each chip individually.

[0010] Secondly, by obtaining the firmware upgrade package containing upgrade metadata and firmware upgrade data, the firmware upgrade data for the current upgrade is packaged into a firmware upgrade package and sent to the local device to execute the upgrade process. This eliminates the need to send upgrade data multiple times, which not only reduces network bandwidth usage but also lowers the device's computing resources and power consumption.

[0011] Furthermore, after receiving the firmware upgrade data, the device sends the upgrade data sequentially to the corresponding target chips using the chip upgrade order information in the upgrade metadata, driving the target chips to perform the firmware upgrade. In scenarios where multiple chips work together, this ensures that each target chip can be updated in the correct order, thereby avoiding device instability or functional failure caused by improper update order, significantly improving the success rate of firmware upgrades and the overall performance of the device. Attached Figure Description

[0012] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is an exemplary network architecture for a smart door lock system in this application; Figure 2 This is a flowchart illustrating a typical embodiment of the firmware upgrade method of this application; Figure 3 This is a schematic diagram of the version information comparison process in an embodiment of this application; Figure 4 This is a schematic diagram of the process for handling firmware upgrade data as firmware image data in an embodiment of this application. Figure 5 This is a schematic diagram of the interface for reverse reconstructing firmware image data in an embodiment of this application; Figure 6 This is a schematic diagram of the process for handling firmware upgrade data as firmware differential data in an embodiment of this application. Figure 7 This is a schematic diagram of the process in this application embodiment for determining whether the firmware version of the chip to be upgraded depends on the preset compatibility conditions. Figure 8 This is a flowchart illustrating the abnormal rollback mechanism in the embodiments of this application; Figure 9 This is a schematic block diagram of the firmware upgrade device of this application; Figure 10 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0013] Please see Figure 1This application discloses an exemplary application scenario using a network architecture including an upgrade server 81, a smart lock device 82, and a user terminal 83. The upgrade server 81 interacts with the smart lock device 82 (i.e., the local device) via wired or wireless networks. These wireless networks include, but are not limited to, local area networks, cellular networks, or combinations thereof. The smart lock device 82, as a typical embedded system, contains multiple microcontroller units with different functions that work collaboratively. For example, in scenarios such as smart locks, smart home hubs, and industrial controllers, the smart lock device 82 can integrate multiple independent chips, such as a main control chip with complex main control logic, a Bluetooth chip responsible for near-field communication, and a Wi-Fi chip responsible for remote connection. Each chip carries firmware programs that implement its specific functions. The upgrade server 81, as a firmware version management and distribution center, stores the latest firmware upgrade packages suitable for different models of smart locks. User terminal 83 can receive upgrade notifications from upgrade server 81 or initiate upgrade commands by the user. These commands can be sent to upgrade server 81 via the Internet or directly or indirectly to smart lock device 82. The main control chip inside smart lock device 82 will execute the firmware upgrade process of this application in response to the aforementioned upgrade command or a firmware upgrade event triggered by itself.

[0014] In a typical embodiment of this application, the firmware upgrade event can be triggered periodically by the local device, remotely by an upgrade server, or by a user's local operation. In response to this firmware upgrade event, this application checks whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server. If they are inconsistent, the target chips with inconsistent version information are identified. Before obtaining the firmware upgrade package from the upgrade server, the upgrade server generates the firmware upgrade package. The firmware upgrade package includes upgrade metadata and firmware upgrade data corresponding to each target chip. The firmware upgrade data can be firmware image data or firmware differential data. Firmware image data is a complete firmware file used to fully replace the current firmware of the target chip, while firmware differential data only contains the changed parts compared to the current firmware version, used for incremental updates, thereby reducing data transmission volume and improving upgrade efficiency. After determining the firmware upgrade data, the upgrade server simultaneously generates corresponding upgrade metadata, which includes at least information such as chip identifier, firmware offset, firmware length, integrity check value, and chip upgrade order. The local device obtains the firmware upgrade package from the upgrade server and, based on the firmware upgrade order information in the upgrade metadata of the firmware upgrade package, sends the firmware upgrade data to the target chip in sequence, driving the target chip to perform the firmware upgrade.

[0015] The following section, in conjunction with the accompanying drawings, will provide a more detailed explanation of the implementation process of the firmware upgrade method described above and its collaborative relationship with hardware components, using flowcharts and module diagrams.

[0016] Please see Figure 2 The firmware upgrade method of this application, in its typical embodiment, includes the following steps: Step S3100: Respond to the firmware upgrade event, determine whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identify each target chip whose version information is inconsistent. Firmware upgrade events can be triggered in several ways. First, they can be triggered by setting a preset time interval. Specifically, the device can be configured with a timer, such as at 2 AM every day or at a specific time each week, to automatically start the firmware upgrade process. This timed triggering is suitable for scenarios where the device needs to periodically check for updates during daily use, ensuring that the device is always running the latest version.

[0017] Secondly, users can manually trigger firmware upgrade events through the local operating interface of their terminal devices. Specifically, users can select the "Check for updates" and "Confirm update" options in the corresponding user interface of the terminal device to trigger the upgrade.

[0018] In addition, firmware upgrade events can also be triggered based on the device's own operating status. For example, when the device detects sufficient power and a stable network connection, it will automatically trigger a firmware upgrade event. This ensures that the device performs a firmware upgrade under optimal conditions, thereby reducing potential unexpected situations during the upgrade process and increasing the success rate of the upgrade.

[0019] Finally, firmware upgrade events can also be triggered proactively by the upgrade server. Device manufacturers or maintenance personnel send firmware upgrade commands to the device via the upgrade server. This is suitable for scenarios requiring emergency repairs or feature updates to the device, ensuring that the device receives the latest firmware version as soon as possible.

[0020] In response to a firmware upgrade event triggered by any of the above methods, the system determines whether the current firmware version information of each chip in the local device is consistent with the corresponding latest firmware version information in the upgrade server. In one embodiment, the version information comparison process is performed by the upgrade server. Specifically, the local device sends a request data packet containing a device identifier and current firmware version information to the upgrade server. The device identifier is used to uniquely identify the device, ensuring that the upgrade server can provide the latest firmware version information matching the local device. The current firmware version information includes the firmware version number of each chip in the local device. After receiving the request, the upgrade server searches for the latest firmware version information matching the device based on the device identifier. The upgrade server stores a firmware version database for all devices, enabling it to quickly retrieve the latest firmware version number corresponding to each chip. The upgrade server compares this latest firmware version information with the current firmware version information sent by the local device. If the current version of a chip is inconsistent with the latest version, the upgrade server records the chip identifier of that chip and marks it as the target chip, indicating that the chip needs a firmware upgrade.

[0021] In another embodiment, the version information comparison process is performed by the local device. Specifically, the local device sends a request data packet containing a device identifier to the upgrade server. Upon receiving the request, the upgrade server finds the corresponding latest firmware version information based on the device identifier and sends this latest firmware version information along with a firmware upgrade list back to the local device. After receiving the firmware version list, the local device compares the latest firmware version information in the list with the current firmware version information of each chip in the local device. If the current version of a chip is inconsistent with the latest version, the chip identifier of that chip is recorded and marked as the target chip. Performing the version information comparison on the local device reduces the number of communications between the local device and the upgrade server, improving the upgrade response speed.

[0022] Step S3200: Obtain a firmware upgrade package from the upgrade server. The firmware upgrade package contains upgrade metadata and firmware upgrade data corresponding to each target chip. After identifying target chips with inconsistent version information based on version comparison results, the local device sends a request to the upgrade server to obtain a firmware upgrade package. The upgrade server responds to this request by generating or assembling the corresponding firmware upgrade package for the target chip. In one embodiment, the firmware upgrade package takes the form of firmware image data, i.e., a complete new version firmware binary file, used to completely replace the current firmware of the target chip. This is suitable for scenarios with large version differences or where the target chip does not support incremental upgrades. In this case, when generating the firmware upgrade package, the upgrade server packages the complete firmware image file and records detailed information about the firmware image data in the upgrade metadata, such as the target chip identifier, firmware offset, firmware length, integrity check value, and chip upgrade order information.

[0023] In another embodiment, the firmware upgrade data is in the form of firmware differential data. In this case, the firmware upgrade data only contains the changes compared to the current firmware version, and is used for incremental updates. This is more suitable for scenarios where the firmware version upgrade differences are small, significantly reducing data transmission volume and improving upgrade efficiency. For example, when a chip in a local device only needs to fix a known security vulnerability or make minor functional improvements, firmware differential data is used. In this case, when the upgrade server generates the firmware upgrade package, it calculates the difference between the current firmware version information and the latest firmware version information, packages the obtained difference data into firmware differential data, and records the detailed information of the firmware differential data in the upgrade metadata.

[0024] In another embodiment, the firmware upgrade package may contain a combination of firmware image data and firmware differential data. The upgrade server will generate a firmware upgrade package containing different types of firmware upgrade data according to the specific needs of the local device for this upgrade, and record in detail the parsing rules of each type of firmware upgrade data and the firmware upgrade order in the upgrade metadata.

[0025] The upgrade server sends the generated firmware upgrade package to the local device. In some embodiments, the firmware upgrade package employs encryption and verification mechanisms during transmission. The encryption algorithm can be symmetric encryption (such as AES) or asymmetric encryption (such as RSA), the specific choice depending on the security and performance requirements of the firmware upgrade. The verification mechanism includes calculating a checksum (such as CRC or SHA-256 hash) and comparing it with the checksum recorded in the upgrade metadata to ensure that the firmware upgrade data has not been tampered with or corrupted during transmission. After receiving the firmware upgrade package, the local device first decrypts and verifies the received data. Only if the data is complete and error-free will it continue with subsequent firmware upgrade operations.

[0026] Step S3300: According to the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip to drive the target chip to perform firmware upgrade.

[0027] In one embodiment, after the local device obtains the firmware upgrade package from the upgrade server, it decrypts and verifies the integrity of the received firmware upgrade package. Specifically, the local device uses a preset decryption key to decrypt the received firmware upgrade package, recovering the upgrade metadata and firmware upgrade data. After decryption, the local device calculates a checksum of the firmware upgrade data (such as a CRC or SHA-256 hash value) and compares it with the checksum recorded in the upgrade metadata to ensure that the firmware upgrade data has not been tampered with or damaged during transmission. If the checksum matches, it indicates that the firmware upgrade data is complete and error-free, and the local device will continue to perform subsequent upgrade operations. If the checksum does not match, the local device records error information and takes corresponding measures according to a preset strategy, such as re-obtaining the firmware upgrade package or terminating the upgrade operation.

[0028] The chip upgrade order information is pre-defined to ensure that dependent chips in a multi-chip system are updated in the correct order. After confirming the integrity of the firmware upgrade data, the local device will perform subsequent upgrade operations based on the chip upgrade order information according to the different forms of the firmware upgrade data. In one embodiment, if the firmware upgrade data is firmware image data, the local device will send the complete firmware image data to the target chip according to the firmware upgrade order information in the upgrade metadata. At this time, the local device will read the firmware image data one by one and write the corresponding firmware image data into the storage area of ​​the target chip according to the offset and length information in the upgrade metadata, completing the full replacement from the old version to the new version.

[0029] In another embodiment, if the firmware upgrade data is firmware differential data, the upgrade metadata is parsed to obtain the base version identifier of the chip to be upgraded. Based on the base version identifier, the corresponding source firmware image is obtained from the non-volatile memory of the target device. Finally, data reconstruction is performed according to the firmware differential data and the corresponding source firmware image to obtain the target firmware image. Based on the target firmware image, the firmware upgrade is performed according to the chip upgrade order information. For the specific steps of this embodiment, please refer to the subsequent specific implementation methods, which will not be repeated here.

[0030] After receiving the firmware upgrade data, the target chip's internal bootloader first verifies the integrity and correctness of the received firmware upgrade data and writes it to the chip's storage area. During the writing process, the bootloader employs various protection mechanisms, such as write protection and erase verification, to ensure the correct installation of the new firmware. Once the firmware upgrade data is written, the bootloader triggers the chip to perform the firmware upgrade operation, completing the switch from the old version to the new version.

[0031] As can be seen from the above embodiments and application examples, this application can achieve the following technical advantages through the above technical solutions, including but not limited to: First, the firmware upgrade method of this application significantly improves the reliability of firmware upgrades by centrally managing the firmware upgrade process. Specifically, by responding to firmware upgrade events, it determines whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identifies the target chips with inconsistent version information. This achieves unified management and upgrade of multiple chips, avoiding compatibility issues and operational cumbersomeness caused by upgrading each chip individually.

[0032] Secondly, by obtaining the firmware upgrade package containing upgrade metadata and firmware upgrade data, the firmware upgrade data for the current upgrade is packaged into a firmware upgrade package and sent to the local device to execute the upgrade process. This eliminates the need to send upgrade data multiple times, which not only reduces network bandwidth usage but also lowers the device's computing resources and power consumption.

[0033] Furthermore, after receiving the firmware upgrade data, the device sends the upgrade data sequentially to the corresponding target chips using the chip upgrade order information in the upgrade metadata, driving the target chips to perform the firmware upgrade. In scenarios where multiple chips work together, this ensures that each target chip can be updated in the correct order, thereby avoiding device instability or functional failure caused by improper update order, significantly improving the success rate of firmware upgrades and the overall performance of the device.

[0034] Based on any embodiment of the method in this application, please refer to Figure 3 In response to firmware upgrade events, it determines whether the current firmware version information of each chip in the local device is consistent with the corresponding latest firmware version information in the upgrade server, including: Step S3110: Respond to the version information comparison instruction and send a version comparison request to the upgrade server. The version comparison request includes the device identifier of the local device and the current firmware version information. When a firmware upgrade event is detected, a version information comparison command is triggered. The local device responds to this command by sending a version comparison request to the upgrade server. Before sending the version comparison request, the device reads the current firmware version information from its storage area, including the firmware version numbers of each chip in the device. It also obtains the device's unique identifier, which can be a device serial number or a device ID, used to uniquely identify the device on the upgrade server. This device identifier and the device's current firmware version information are encapsulated in a version comparison request data packet. This request data packet is encrypted before being sent to the upgrade server, and then sent to the upgrade server through the communication connection established between the local device and the upgrade server.

[0035] Step S3120: Receive the comparison result returned by the upgrade server. The comparison result is obtained by comparing the latest firmware version information queried by the upgrade server based on the device identifier with the current firmware version information.

[0036] After receiving the version comparison request, the upgrade server parses the request to obtain the device identifier and the current firmware version information. Then, based on the device identifier, it searches for the latest firmware version information that matches the device and compares this information with the current firmware version information sent by the local device chip by chip.

[0037] After the comparison is completed, the upgrade server will generate a response data packet containing the comparison results and send the response data packet to the local device as the comparison result. The local device will then perform subsequent firmware upgrade operations based on the comparison results. The response data packet details which chips need to have their firmware versions updated and their corresponding chip identifiers.

[0038] In this embodiment, the current firmware version information of each chip in the local device is compared with the latest firmware version information in the upgrade server to determine the target chip that needs to be updated. By accurately identifying the target chip with inconsistent versions, unnecessary upgrade operations can be avoided, reducing resource waste.

[0039] Based on any embodiment of the method in this application, please refer to Figure 4 After obtaining the firmware upgrade package from the upgrade server, the firmware upgrade package includes upgrade metadata and firmware upgrade data corresponding to each target chip. When the firmware upgrade data is firmware image data, it includes: Step S3210: Decrypt the firmware upgrade package using a preset decryption key to obtain the upgrade metadata and the firmware image data. The firmware image data is generated by the upgrade server performing cross-obfuscation on independent firmware images based on preset obfuscation rules. Firmware upgrade packages are encrypted during transmission to prevent data tampering or leakage. Encryption algorithms include symmetric or asymmetric encryption. The local device can use a pre-configured decryption key during decryption, which is pre-configured at the factory and matches the encryption key on the upgrade server.

[0040] After decryption, upgrade metadata and firmware image data are obtained. In one embodiment, the firmware image data is generated by the upgrade server performing cross-obfuscation on independent firmware images based on preset obfuscation rules. Cross-obfuscation increases the complexity of the firmware data, preventing it from being easily parsed or tampered with during transmission and storage. Obfuscation rules can include various methods such as data chunking and data rearrangement. For example, the upgrade server can divide the firmware data into multiple data blocks and then recombine the data blocks in a specific order. This cross-obfuscation technique not only improves the security of the firmware data but also increases the difficulty for attackers to crack the firmware.

[0041] Step S3220: Compare the hash value corresponding to the firmware image data with the standard hash value corresponding to the upgrade metadata to verify whether the firmware upgrade data is complete; A hash value is a fixed-length digital digest calculated using a specific algorithm (such as SHA-256 or MD5) that uniquely identifies data content. After decrypting the firmware image data, the hash value corresponding to that firmware image data is calculated and compared with the standard hash value in the upgrade metadata. The standard hash value in the upgrade metadata is generated on the upgrade server based on the firmware image data and then encapsulated within the upgrade metadata before being sent to the local device. By comparing the hash value of the decrypted firmware image data obtained on the local device with the standard hash value in the upgrade metadata, it can be determined whether the firmware image data has been tampered with or erroneous during transmission, such as data loss or data corruption.

[0042] In one embodiment, while comparing hash values, the received firmware image data is also digitally signed. The digital signature is generated by encrypting the firmware image data using the upgrade server's private key. After receiving the firmware image data, the local device decrypts the digital signature using the public key corresponding to the upgrade server, thereby verifying the source and integrity of the firmware image data. This dual verification mechanism not only ensures that the firmware image data has not been tampered with, but also verifies that the firmware image data indeed comes from a trusted upgrade server, thus effectively preventing man-in-the-middle attacks and data injection attacks.

[0043] After hash value comparison and digital signature verification are completed, if all verifications pass, the firmware image data is marked as verified and the subsequent firmware upgrade process is executed; if an error is detected during the verification process, the error is reported to the user and the upgrade process is terminated.

[0044] Step S3230: When the firmware upgrade data is complete, perform the corresponding deobfuscation operation on the firmware image data to restore it to the independent firmware image. This independent firmware image is used as firmware upgrade data for subsequent firmware upgrades based on the chip upgrade sequence information.

[0045] Deobfuscation is the reverse process of the cross-obfuscation used during the generation of firmware image data. In one embodiment, when verifying the integrity of firmware upgrade data, the obfuscation rules used in the firmware image data are first determined based on information in the upgrade metadata. The upgrade metadata contains identifiers for the obfuscation rules. Based on these identifiers, corresponding data restoration rules can be retrieved from the obfuscation rule library. These data restoration rules correspond to the obfuscation rules and guide the corresponding deobfuscation operations. For example, if the firmware image data was divided into multiple data blocks and reassembled according to preset obfuscation rules during generation, the deobfuscation operation restores the data blocks based on the retrieved data restoration rules to recover the original firmware image data.

[0046] In this embodiment, by combining encryption and cross-obfuscation techniques, not only is the confidentiality of firmware data protected during transmission, but the complexity of the data is also increased during storage and use, effectively preventing firmware from being tampered with or parsed. Through this dual mechanism, the security and reliability of the firmware upgrade process are significantly improved, and the risk of upgrade failure due to data leakage or tampering is reduced.

[0047] Based on any embodiment of the method in this application, please refer to Figure 5 When the firmware upgrade data is complete, perform a corresponding deobfuscation operation on the firmware image data to restore it to the independent firmware image, including: Step S3231: Determine the data restoration rule corresponding to the obfuscation rule based on the rule identifier in the upgrade metadata and the preset rule mapping table; The rule identifier in the upgrade metadata is a unique identifier for the rules followed during the obfuscation process of the firmware image data during generation. The pre-configured rule mapping table, pre-configured at the factory, stores the mapping relationship between various obfuscation rules and their corresponding data restoration rules. This rule mapping table is updated periodically. This step first extracts the rule identifier from the upgrade metadata. This rule identifier is a short string or number used to uniquely identify the obfuscation rule. Based on this rule identifier, the corresponding entry is looked up in the pre-configured rule mapping table. The rule mapping table is a data structure that maps rule identifiers to specific data restoration rules. These data restoration rules describe in detail how to deobfuscate the obfuscated firmware image data, including the data reassembly order.

[0048] In one embodiment, the rule mapping table is stored in the read-only memory (ROM) of the native device to ensure that it remains unchanged throughout the entire lifecycle of the native device and that the rule mapping table stored on the native device cannot be easily tampered with. In another embodiment, the rule mapping table is stored in the device's non-volatile memory (such as flash memory), in which case the native device can dynamically update the rule mapping table as needed through a secure update mechanism to support new obfuscation rules or fix known security vulnerabilities.

[0049] Step S3232: According to the data restoration rules, perform a reverse reconstruction operation on the firmware image data to restore it to the independent firmware image.

[0050] Based on the data restoration rules, the disordered data blocks in the cross-obfuscated firmware image data are recombined in the correct order to restore the firmware image data to the independent firmware image. Subsequently, the firmware upgrade is performed based on the independent firmware image and the chip upgrade order information.

[0051] In one embodiment, hardware acceleration technology can be used, which utilizes a dedicated hardware module (such as an encryption / decryption accelerator) in the local device to perform decryption and reconstruction operations. Hardware acceleration technology can not only significantly improve the speed of reverse reconstruction, but also reduce the CPU load of the device, thereby improving the efficiency of the entire firmware upgrade process.

[0052] In this embodiment, by combining rule identifiers and rule mapping tables, the local device can accurately identify and process complex obfuscation rules, ensuring the security and confidentiality of firmware data during transmission and storage. At the same time, the application of hardware acceleration technology further improves the efficiency of deobfuscation operations, reduces performance bottlenecks caused by complex operations, and makes the firmware upgrade process more efficient and reliable.

[0053] Based on any embodiment of the method in this application, please refer to Figure 6After obtaining the firmware upgrade package from the upgrade server, the firmware upgrade package includes upgrade metadata and firmware upgrade data corresponding to each target chip. When the firmware upgrade data is firmware differential data, it includes: Step S3240: Parse the upgrade metadata to determine the base version identifier of the chip to be upgraded; After the local device obtains the firmware upgrade package from the upgrade server and completes decryption and integrity verification, it parses the firmware upgrade package to obtain the base version identifier of the chip to be upgraded. In one embodiment, the base version identifier is directly set to the current firmware version number of the chip to be upgraded in the current firmware version information. This version number is used to subsequently match the corresponding source firmware image from the non-volatile memory; that is, the current firmware version number is the version number of the source firmware image.

[0054] In another embodiment, a string or number can be generated based on preset rules as a base version identifier, and the generated string or number serves as a unique identifier for matching the source firmware image.

[0055] Step S3250: Read the source firmware image corresponding to the base version identifier from the non-volatile memory of the target device; The target device's non-volatile memory (such as flash memory or EEPROM) is the physical medium for storing the source firmware image. This memory has the characteristic of retaining data even after power failure. When performing a source firmware image read operation, the corresponding firmware image location in the non-volatile memory can be directly located based on the base version identifier of the chip to be upgraded, thereby obtaining the corresponding source firmware image.

[0056] In some embodiments, before reading the source firmware image, the health status of the non-volatile memory is checked, including the degree of memory wear and the error correction code (ECC) status. If a health problem is found in the memory, error information is recorded, and corresponding measures are taken according to a preset strategy, such as terminating the upgrade process or attempting to repair the memory. After verifying that the non-volatile memory storing the source firmware image is in good condition, the corresponding source firmware image is read from the non-volatile memory based on the base version identifier determined in the aforementioned steps. The reading process includes accessing the physical address of the non-volatile memory and transferring the source firmware image to the memory of the local device.

[0057] Step S3260: Based on the firmware differential data, the source firmware image is reconstructed to generate a target firmware image. This target firmware image serves as firmware upgrade data for subsequent firmware upgrades based on the chip upgrade sequence information.

[0058] Once the firmware differential data and the source firmware image are obtained, the source firmware image is reconstructed based on the firmware differential data. The firmware differential data is stored in a specific format, such as a binary patch file or incremental update package, which contains specific instructions for modifying the source firmware image, such as adding, deleting, or modifying specific data blocks. Based on these instructions, the source firmware image is modified to generate the target firmware image.

[0059] In one embodiment, the firmware differential data includes multiple data blocks, each corresponding to a specific region in the source firmware image. Each data block is processed according to the instructions in the firmware differential data. For example, if the firmware differential data indicates that a new data block needs to be inserted at a certain location in the source firmware image, the location is first located, and then the corresponding data block is inserted; if the firmware differential data indicates that a data block needs to be deleted, the data block is located and deleted. Based on this, the source firmware image is progressively reconstructed into the target firmware image.

[0060] In some embodiments, the verification value (such as CRC or SHA-256 hash value) of the reconstructed target firmware image is calculated periodically and compared with the verification value provided in the firmware differential data. If the verification values ​​match, it indicates that the reconstruction process is error-free. If the verification values ​​do not match, the corresponding error information is recorded, and corresponding measures are taken based on the preset strategy, such as reapplying the firmware differential data or terminating the upgrade process.

[0061] In some embodiments, a multi-stage reconstruction strategy is employed. For example, all modification instructions in the firmware differential data are first categorized, and then these instructions are applied one by one according to the category, thereby reducing repetitive operations during the reconstruction process and improving efficiency. In addition, intermediate verification is performed after each stage to ensure that the reconstruction results of each stage are correct.

[0062] After data reconstruction is completed, the firmware upgrade module will generate a target firmware image. This target firmware image will be used as firmware upgrade data for subsequent firmware upgrades based on the upgrade order information in the upgrade metadata.

[0063] In this embodiment, incremental updates are performed using firmware differential data. Only the changed parts compared to the current firmware version need to be transmitted and processed, instead of the complete firmware image. This not only reduces network bandwidth usage but also lowers the storage and computing resource consumption of the device. At the same time, through precise base version identification and multi-stage reconstruction strategies, complex upgrade scenarios can be handled more flexibly, ensuring that the reconstruction results at each stage are correct, thereby improving the success rate of upgrades and the stability of the device.

[0064] Based on any embodiment of the method in this application, please refer to Figure 7According to the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip, driving the target chip to perform a firmware upgrade, including: Step S3310: Based on the chip dependency information in the upgrade metadata, check whether the firmware version of the associated chip that the chip to be upgraded depends on meets the preset compatibility conditions. The chip dependency information represents the firmware version dependency relationship between chips. When upgrading a target chip, it is essential to first ensure that the firmware versions of other related chips that the target chip depends on are compatible. In multi-chip systems, the functions of each chip are often interdependent. For example, the front-board main control chip may rely on the rear-board communication chip to perform specific functions. If the firmware versions of the communication chip are incompatible, even if the main control chip is successfully upgraded, the device will malfunction.

[0065] To address the aforementioned issues, this step obtains chip dependency information by parsing upgrade metadata. This chip dependency information details the dependencies between chips, including which chips depend on the chip to be upgraded and the corresponding compatibility conditions. For example, chip dependency information indicates that the main control chip requires the communication chip's firmware version to be at least a specific version to meet preset compatibility conditions. Specifically, based on the compatibility conditions corresponding to the chip dependency information, the firmware versions of associated chips are checked one by one to ensure they meet the requirements. In one embodiment, the preset compatibility conditions are implemented using a compatibility rule base. This rule base contains compatibility rules for various chip combinations, allowing for rapid determination of whether the firmware versions of associated chips meet the requirements. For example, the rule base may specify that for a specific model of main control chip, the firmware version of its dependent communication chip must be between 1.2.0 and 2.0.0. Based on these rules, the firmware versions of associated chips are checked one by one.

[0066] Step S3320: When the compatibility conditions are met, the corresponding firmware upgrade data is sent to the chip to be upgraded, driving the chip to perform a firmware upgrade. After completing the firmware version compatibility check of the associated chips, if the firmware versions of all associated chips of the chip to be upgraded meet the preset compatibility conditions, the chip is triggered to execute the firmware upgrade process. Specifically, the corresponding firmware upgrade data is sent to the chip to be upgraded, driving the chip to perform the firmware upgrade. For details of this firmware upgrade process, please refer to the specific implementation method described above for driving the target chip to perform firmware upgrade based on chip upgrade sequence information, which will not be repeated here.

[0067] Step S3330: When the compatibility conditions are not met, the current upgrade process is terminated and a firmware version rollback operation is performed.

[0068] When it is determined that the firmware version of the associated chip on which the chip to be upgraded depends does not meet the preset compatibility conditions, the current upgrade process is aborted, firmware upgrade data transmission to the target chip is stopped, and a firmware version rollback operation is performed. By performing the firmware version rollback operation, the device is restored to its stable state before the upgrade, ensuring that the device can continue to work normally. Specifically, before performing the firmware upgrade, the device backs up the source firmware image in non-volatile memory, which stores the firmware version currently running for each chip, so that it can be quickly obtained when needed. When the firmware version rollback operation is triggered, a reverse rewrite operation is performed on the upgraded chip based on the chip upgrade order information. That is, the source firmware image is re-burned into the upgraded chip in the reverse order of the chip upgrade order information. For specific rollback steps, please refer to the detailed implementation method below, which will not be repeated here.

[0069] In some embodiments, after the firmware version rollback operation is completed, a verification is required again to ensure that the firmware version of all chips has been correctly restored to the state before the upgrade. If the verification passes, the success information of the recovery operation is recorded, and the user is notified that the upgrade process has been stopped and successfully rolled back. If the verification fails, the error information is recorded, and corresponding measures are taken according to the preset strategy, such as retrying the recovery operation or reporting the error to the user.

[0070] In this embodiment, by parsing the chip dependency information in the upgrade metadata, the firmware versions of the associated chips that the chip to be upgraded depends on are checked one by one to see if they meet the preset compatibility conditions. The firmware upgrade process is only executed when the compatibility conditions are met. This ensures that in a multi-chip system where the functions of various chips are interdependent, the upgrade operation will not cause device instability or functional failure due to version incompatibility. In other words, by strictly checking compatibility conditions before the upgrade and quickly performing a rollback operation when an anomaly is detected, upgrade failures and device malfunctions caused by version incompatibility can be effectively avoided. This not only reduces maintenance costs and user inconvenience caused by upgrade failures but also improves the reliability and availability of the device during the upgrade process.

[0071] Based on any embodiment of the method in this application, please refer to Figure 8 According to the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip to drive the target chip to perform a firmware upgrade, and the method further includes: Step S3340: When any target chip upgrade failure or abnormal operation is detected, a firmware rollback command is sent to the upgraded chips in reverse order according to the chip upgrade sequence information. When the device performs a firmware upgrade, it continuously monitors the status of each target chip to ensure a smooth upgrade process. The monitoring mechanisms include, but are not limited to, detecting the chip's response status, verifying the upgraded firmware version, and monitoring the chip's operating parameters (such as temperature and voltage). If any target chip is detected to have failed to upgrade or malfunction during monitoring—for example, if the chip cannot correctly respond to the upgrade command, verification fails, or operating parameters exceed the normal range—pre-defined safety measures will be implemented to prevent device malfunction or uncontrollable device status. Specifically, when an anomaly is detected, the device identifies the chips that have already completed the firmware upgrade based on the chip upgrade sequence information and sends firmware rollback commands to the upgraded chips in reverse order. The firmware rollback command is a specific control signal used to trigger the chip's internal bootloader to perform a rollback operation.

[0072] Step S3350: In response to the firmware rollback command, the source firmware image that was backed up in the secure storage area is re-burned to the upgraded chip so that the target device is restored to the expected working state before the upgrade. After receiving the firmware rollback command, the upgraded chip responds by retrieving the backed-up source firmware image from the secure storage area. The secure storage area is a dedicated region for storing firmware backups, typically located in the device's non-volatile memory, such as flash memory or EEPROM. The backed-up source firmware image is created before the firmware upgrade and contains the currently running firmware version, ensuring a quick restoration to the pre-upgrade state when needed. This step re-programs the backed-up firmware image to the corresponding upgraded chip. In one embodiment, the programming process is performed block-by-block. Specifically, the firmware image is divided into multiple smaller data blocks, and these data blocks are written one by one to the corresponding chip's storage area. While writing each data block, an acknowledgment response from the chip is awaited to ensure correct data reception. If the chip does not return an acknowledgment response within a specified time, the data block is resent until all data blocks are written, restoring the target device to its expected pre-upgrade operating state.

[0073] During the programming process, the chip's status is continuously monitored to ensure the correctness of the programming operation. Specifically, status information sent by the chip, such as programming progress and error codes, can be received through an internal communication link. If any abnormality is detected during the programming process, operations such as pausing the programming operation, attempting to repair errors, or terminating the programming process can be performed.

[0074] Step S3360: Generate a corresponding upgrade exception report and send it to the upgrade server.

[0075] Collect detailed information related to this anomaly, including but not limited to the time of occurrence, the chip identifier involved, the current firmware version, the anomaly type, the error code, and the steps performed. Generate a detailed upgrade anomaly report based on the collected information. This report is formatted in a structured format to facilitate rapid parsing and processing by the upgrade server. The report may include a title briefly describing the anomaly; a detailed description detailing the specific circumstances of the anomaly; and an attachment containing relevant log files or data snapshots.

[0076] After generating an anomaly report, the device sends the report to the upgrade server through the communication connection established between the device and the upgrade server. When sending the report, the device's unique identifier (such as device serial number or device ID) is included so that the upgrade server can accurately identify the source of the report.

[0077] In some embodiments, the upgrade server analyzes received upgrade anomaly reports to identify potential patterns or trends. For example, if multiple devices report similar anomalies, the upgrade server triggers an automated troubleshooting process to determine if there are common problems.

[0078] In this embodiment, by combining the firmware rollback mechanism and the anomaly reporting mechanism, it is possible not only to quickly restore to a stable state when the upgrade fails, but also to provide maintenance personnel with detailed anomaly information, thereby accelerating the diagnosis and repair of problems.

[0079] Please see Figure 9 This invention provides a firmware upgrade device to meet one of the purposes of this application. It is a functional embodiment of the firmware upgrade method of this application. The device includes a firmware version detection module 3100, a firmware upgrade package acquisition module 3200, and a firmware upgrade execution module 3300. The firmware version detection module 3100 is configured to respond to a firmware upgrade event, determine whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identify target chips with inconsistent version information. The firmware upgrade package acquisition module 3200 is configured to acquire a firmware upgrade package from the upgrade server. The firmware upgrade package contains upgrade metadata and corresponding firmware upgrade data for each target chip. The firmware upgrade execution module 3300 is configured to send the firmware upgrade data sequentially to the corresponding target chips according to the chip upgrade order information in the upgrade metadata, driving the target chips to perform firmware upgrades.

[0080] Based on any embodiment of the device in this application, the firmware version detection module 3100 includes: a version comparison module, configured to respond to a version information comparison instruction and send a version comparison request to the upgrade server, wherein the version comparison request includes the device identifier of the local device and the current firmware version information; and a comparison result return module, configured to receive the comparison result returned by the upgrade server, wherein the comparison result is obtained by comparing the latest firmware version information queried by the upgrade server based on the device identifier with the current firmware version information.

[0081] Based on any embodiment of the device in this application, after the firmware upgrade package acquisition module 3200, when the firmware upgrade data is firmware image data, it includes: an upgrade package decryption module, configured to use a preset decryption key to decrypt the firmware upgrade package to obtain the upgrade metadata and the firmware image data, wherein the firmware image data is generated by the upgrade server performing cross-obfuscation on an independent firmware image based on a preset obfuscation rule; an integrity verification module, configured to compare the hash value corresponding to the firmware image data with the standard hash value corresponding to the upgrade metadata to verify whether the firmware upgrade data is complete; and a data restoration module, configured to perform a corresponding deobfuscation operation on the firmware image data when the firmware upgrade data is complete, restoring it to the independent firmware image, wherein the independent firmware image is used as firmware upgrade data for subsequent firmware upgrades based on the chip upgrade order information.

[0082] Based on any embodiment of the device in this application, the data restoration module is configured to include: a restoration rule determination module, configured to determine the data restoration rule corresponding to the obfuscation rule according to the rule identifier in the upgrade metadata and a preset rule mapping table; and a firmware image recovery module, configured to perform a reverse reconstruction operation on the firmware image data according to the data restoration rule to restore it to the independent firmware image.

[0083] Based on any embodiment of the device in this application, after the firmware upgrade package acquisition module 3200, when the firmware upgrade data is firmware differential data, it includes: a version identifier determination module, configured to parse the upgrade metadata to determine the base version identifier of the chip to be upgraded; a source firmware image determination module, configured to read the source firmware image corresponding to the base version identifier from the non-volatile memory of the target device; and a data reconstruction module, configured to reconstruct the source firmware image according to the firmware differential data to generate a target firmware image, which is used as firmware upgrade data for subsequent firmware upgrades based on the chip upgrade order information.

[0084] Based on any embodiment of the device in this application, the firmware upgrade execution module 3300 includes: a condition verification module, configured to verify whether the firmware version of the associated chip on which the current chip to be upgraded depends meets a preset compatibility condition based on the chip dependency information in the upgrade metadata, wherein the chip dependency information represents the firmware version dependency relationship between chips; a firmware upgrade module, configured to send the corresponding firmware upgrade data to the current chip to be upgraded when the compatibility condition is met, driving the current chip to be upgraded to perform a firmware upgrade; and a process termination module, configured to terminate the current upgrade process and perform a firmware version rollback operation when the compatibility condition is not met.

[0085] Based on any embodiment of the device in this application, the firmware upgrade execution module 3300 further includes: an upgrade exception module, configured to send a firmware rollback command to the upgraded chip in reverse order according to the chip upgrade order information when any target chip upgrade failure or malfunction is detected; a firmware rollback module, configured to re-burn the source firmware image pre-backed up in the secure storage area to the upgraded chip in response to the firmware rollback command, so as to restore the target device to the expected working state before the upgrade; and an exception report generation module, configured to generate a corresponding upgrade exception report and send it to the upgrade server.

[0086] To address the aforementioned technical problems, embodiments of this application also provide a computer device for implementing the escalator monitoring device of this application. For example... Figure 10 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, a network interface, and various communication components connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, they enable the processor to implement a firmware upgrade method. The processor of the computer device provides computing and control capabilities, supporting the operation of the entire computer device. The memory of the computer device may store computer-readable instructions, which, when executed by the processor, enable the processor to execute the firmware upgrade method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0087] In this embodiment, the processor is used to execute... Figure 9The system contains the specific functions of each module and its sub-modules, and the memory stores the program code and various data required to execute these modules or sub-modules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the firmware upgrade device of this application, and the server can call the server's program code and data to execute the functions of all sub-modules.

[0088] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the firmware upgrade method of any embodiment of this application.

[0089] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0090] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0091] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A firmware upgrade method, characterized in that, include: In response to firmware upgrade events, determine whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identify the target chips whose version information is inconsistent. Obtain a firmware upgrade package from the upgrade server. The firmware upgrade package contains upgrade metadata and firmware upgrade data corresponding to each target chip. Based on the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip, driving the target chip to perform a firmware upgrade.

2. The firmware upgrade method according to claim 1, characterized in that, In response to a firmware upgrade event, the system determines whether the current firmware version information of each chip in the device matches the corresponding latest firmware version information in the upgrade server, including the following steps: In response to the version information comparison instruction, a version comparison request is sent to the upgrade server. The version comparison request includes the device identifier of the local device and the current firmware version information. The upgrade server receives a comparison result, which is obtained by comparing the latest firmware version information queried by the upgrade server based on the device identifier with the current firmware version information.

3. The firmware upgrade method according to claim 1, characterized in that, After obtaining the firmware upgrade package from the upgrade server, which includes upgrade metadata and firmware upgrade data corresponding to each target chip, when the firmware upgrade data is firmware image data, the following steps are included: The firmware upgrade package is decrypted using a preset decryption key to obtain the upgrade metadata and the firmware image data. The firmware image data is generated by the upgrade server performing cross-obfuscation on independent firmware images based on preset obfuscation rules. The hash value corresponding to the firmware image data is compared with the standard hash value corresponding to the upgrade metadata to verify whether the firmware upgrade data is complete. When the firmware upgrade data is complete, the corresponding deobfuscation operation is performed on the firmware image data to restore it to the independent firmware image. This independent firmware image is used as firmware upgrade data for subsequent firmware upgrades based on the chip upgrade sequence information.

4. The firmware upgrade method according to claim 3, characterized in that, When the firmware upgrade data is complete, perform the corresponding deobfuscation operation on the firmware image data to restore it to the independent firmware image, including the following steps: Based on the rule identifier in the upgrade metadata and the preset rule mapping table, the data restoration rule corresponding to the obfuscation rule is determined; According to the data restoration rules, the firmware image data is reverse-engineered and reconstructed to restore the independent firmware image.

5. The firmware upgrade method according to claim 1, characterized in that, After obtaining the firmware upgrade package from the upgrade server, which includes upgrade metadata and firmware upgrade data corresponding to each target chip, when the firmware upgrade data is firmware differential data, the following steps are included: Parse the upgrade metadata to determine the base version identifier of the chip to be upgraded; Read the source firmware image corresponding to the base version identifier from the non-volatile memory of the target device; Based on the firmware differential data, the source firmware image is reconstructed to generate a target firmware image. This target firmware image serves as firmware upgrade data for subsequent firmware upgrades based on the chip upgrade sequence information.

6. The firmware upgrade method according to claim 1, characterized in that, Based on the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip, driving the target chip to perform a firmware upgrade, including the following steps: Based on the chip dependency information in the upgrade metadata, check whether the firmware version of the associated chip that the chip to be upgraded depends on meets the preset compatibility conditions. The chip dependency information represents the firmware version dependency relationship between chips. When the compatibility conditions are met, the corresponding firmware upgrade data is sent to the chip to be upgraded, driving the chip to perform a firmware upgrade. If the compatibility conditions are not met, the current upgrade process is aborted and a firmware version rollback operation is performed.

7. The firmware upgrade method according to claim 1, characterized in that, Based on the chip upgrade order information in the upgrade metadata, the firmware upgrade data is sent sequentially to the corresponding target chip to drive the target chip to perform the firmware upgrade. The process also includes the following steps: When any target chip is detected to have failed to upgrade or malfunction, a firmware rollback command is sent to the upgraded chips in reverse order according to the chip upgrade sequence information. In response to the firmware rollback command, the source firmware image, which was previously backed up in the secure storage area, is re-burned to the upgraded chip so that the target device can be restored to the expected working state before the upgrade. A corresponding upgrade anomaly report is generated and sent to the upgrade server.

8. A firmware upgrade device, characterized in that, include: The firmware version detection module is configured to respond to firmware upgrade events, determine whether the current firmware version information of each chip in the local device is consistent with the latest firmware version information in the upgrade server, and identify each target chip with inconsistent version information. The firmware upgrade package acquisition module is configured to acquire a firmware upgrade package from the upgrade server. The firmware upgrade package includes upgrade metadata and firmware upgrade data corresponding to each target chip. The firmware upgrade execution module is configured to send the firmware upgrade data sequentially to the corresponding target chip according to the chip upgrade order information in the upgrade metadata, and drive the target chip to perform firmware upgrade.

9. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images