Firmware self-management method and device, electronic equipment and storage medium

Abstract

This application belongs to the field of firmware upgrade and recovery technology, and relates to a firmware self-management method, device, electronic device, and storage medium. By acquiring firmware information of the second boot module and application module during the boot phase of the first boot module, and selecting a path based on jumpability verification conditions, the system enters the application execution flow under the premise that the firmware has basic runnability. Furthermore, during application execution, the health status of the second boot module is determined, and corresponding repair operations are triggered based on the determination result, realizing dynamic perception and processing of the status of key modules in the boot chain. Simultaneously, when the firmware information does not meet the jumpability conditions, differentiated anomaly recovery processes are executed according to different abnormal combinations of modules, enabling the system to select the corresponding repair path during the boot phase. Based on this, this application improves the system's boot reliability, path flexibility, and self-recovery capability.

Description

Technical Field

[0001] This application belongs to the field of firmware upgrade and recovery technology, specifically relating to a firmware self-management method, device, electronic device, and storage medium. Background Technology

[0002] Embedded devices typically rely on a bootloader to perform firmware verification, system initialization, and loading and execution of the application program (APP). To enable system startup and subsequent functionality, multiple firmware modules are usually configured within the device, participating in the startup or operation process sequentially according to a pre-defined workflow.

[0003] In existing technologies, some devices employ a single-stage boot structure, where the bootloader handles initialization and application loading; others employ a multi-stage boot structure, where multiple boot modules complete the system startup in stages. Regardless of the method used, the firmware modules typically execute in a predetermined order (e.g., BOOT1 → BOOT2 → APP) and form certain dependencies during the startup process.

[0004] In the process of developing this application, the inventors discovered at least the following problems in the prior art: (1) In the existing boot structure, there are dependencies between firmware modules. When a critical module fails, it may affect the subsequent boot process, causing the system to fail to enter the normal operating state, which poses a single point of failure risk. (2) The startup process in the prior art usually follows a fixed path. When some firmware modules are in an abnormal state, there is a lack of flexible path selection mechanism, making it difficult to adjust the execution process according to the actual situation, thus affecting the availability of the system. (3) When the firmware module malfunctions during the operation or startup of the device, there is often a lack of perfect handling methods in the existing technology. The self-recovery capability of the device is limited, and in some cases, external intervention is still required to complete the recovery, which affects the continuity and stability of the system operation.

[0005] Therefore, how to implement a more reasonable firmware management method in embedded devices, enabling the device to execute corresponding processing flows under different firmware states, and improving the overall reliability and self-recovery capability of the system, has become an urgent problem to be solved by those skilled in the art. Summary of the Invention

[0006] To address the aforementioned issues, this application provides a firmware self-management method, apparatus, electronic device, and storage medium to enable hierarchical judgment and path selection based on firmware status during device startup and operation, and to trigger corresponding repair processes in abnormal situations, thereby improving the stability and self-recovery capability of system operation.

[0007] To solve the above-mentioned technical problems, one technical solution adopted in this application is: providing a firmware self-management method applied to an electronic device. The electronic device includes a first boot module, a second boot module, an application module, a backup module, and a communication module. The electronic device communicates with the cloud through the communication module. The method includes: after the first boot module is powered on, performing an initialization operation to obtain first firmware information and second firmware information; wherein, the first firmware information is obtained by reading the firmware header of the second boot module, and the second firmware information is obtained by reading the firmware header of the application module; when the first firmware information and the second firmware information meet a preset jumpability verification condition, executing a normal startup process; wherein, the normal startup process includes: the application module performing peripheral initialization operations and obtaining health flag information of the second boot module; when... When the health indicator information does not meet the preset first health verification condition, a first repair operation is performed on the second boot module based on the application module, the first boot module, and the cloud. When the first firmware information and the second firmware information do not meet the jumpability verification condition, an anomaly recovery process is executed. The anomaly recovery process includes: if the first firmware information and the second firmware information meet the first preset condition, a first repair operation is performed on the second boot module based on the application module, the first boot module, and the cloud; if the first firmware information and the second firmware information meet the second preset condition, a second repair operation is performed on the application module based on the second boot module, the cloud, and the first boot module; if the first firmware information and the second firmware information meet the third preset condition, a third repair operation is performed on the second boot module and the application module based on the first boot module and the backup module.

[0008] To solve the above-mentioned technical problems, another technical solution adopted in this application is: providing a firmware self-management device applied to an electronic device. The electronic device includes a first boot module, a second boot module, an application module, a backup module, and a communication module. The electronic device communicates with the cloud through the communication module. The device includes: a firmware information acquisition module, which is used to perform initialization operations after the first boot module is powered on, and acquire first firmware information and second firmware information; wherein, the first firmware information is obtained by reading the firmware header of the second boot module, and the second firmware information is obtained by reading the firmware header of the application module; and a normal startup process execution module, which is used to execute a normal startup process when the first firmware information and the second firmware information meet preset jumpability verification conditions; wherein, the normal startup process includes: the application module performing peripheral initialization operations and acquiring the second boot module. The system includes: a health indicator information block; when the health indicator information does not meet the preset first health verification condition, a first repair operation is performed on the second boot module based on the application module, the first boot module, and the cloud; an abnormal recovery process execution module is used to execute an abnormal recovery process when the first firmware information and the second firmware information do not meet the jumpability verification condition; wherein, the abnormal recovery process includes: if the first firmware information and the second firmware information meet the first preset condition, a first repair operation is performed on the second boot module based on the application module, the first boot module, and the cloud; if the first firmware information and the second firmware information meet the second preset condition, a second repair operation is performed on the application module based on the second boot module, the cloud, and the first boot module; if the first firmware information and the second firmware information meet the third preset condition, a third repair operation is performed on the second boot module and the application module based on the first boot module and the backup module.

[0009] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-mentioned method.

[0010] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium that stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the above-mentioned method.

[0011] Unlike related technologies, this application provides a firmware self-management method, apparatus, electronic device, and storage medium. By acquiring firmware information of the second boot module and application module during the first boot module startup phase and selecting a path based on jumpability verification conditions, the system can enter the application execution flow provided the firmware has basic runnability. Furthermore, during application execution, the health status of the second boot module is continuously assessed, and corresponding repair operations are triggered based on the assessment results, thereby achieving dynamic perception and processing of the status of key modules in the boot chain. Simultaneously, when the firmware information does not meet the jumpability conditions, differentiated anomaly recovery processes are executed based on different combinations of abnormal modules, enabling the system to select the corresponding repair path based on the fault distribution during the boot phase. Therefore, by introducing hierarchical verification and multi-path processing mechanisms in the startup and execution phases respectively, the traditional single-path-dependent startup method is broken, reducing the impact of critical module anomalies on the overall system, and providing executable recovery paths in various anomaly scenarios, thereby effectively improving the system's startup reliability, path flexibility, and overall self-recovery capability. Attached Figure Description

[0012] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0013] Figure 1 This is a schematic diagram of the structure of a firmware self-management system provided in an embodiment of this application; Figure 2 This is a flowchart of a firmware self-management method provided in an embodiment of this application; Figure 3 This is a flowchart of the first repair operation provided in the embodiments of this application; Figure 4 This is a flowchart of the second repair operation provided in the embodiments of this application; Figure 5 This is a flowchart of the third repair operation provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of a firmware self-management device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0015] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0016] When an element is described as "connected" to another element, it can be directly connected to the other element, or there may be one or more intervening elements between them.

[0017] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more.

[0018] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application.

[0019] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a firmware self-management system provided in an embodiment of this application. For example... Figure 1As shown, the firmware self-management system 1000 includes an electronic device 100 and a cloud platform 200. The electronic device 100 includes a first boot module 10 (BOOT1), a second boot module 20 (BOOT2), an application module 30 (APP), a backup module 40 (general backup area), and a communication module 50 (IoT). The first boot module 10 is connected to the second boot module 20, the application module 30, and the backup module 40, respectively. The second boot module 20 is also connected to the application module 30. The first boot module 10, the second boot module 20, the application module 30, and the backup module 40 are modules integrated into the microcontroller unit (MCU) of the electronic device 100, and the application module 30 communicates with the cloud platform 200 through the communication module 50. It should be noted that, for ease of description below, the above-mentioned functional modules are referred to by their respective English abbreviations.

[0020] Among them, BOOT1, as the highest priority boot unit of the system, is deployed in the protected storage area (read-only or locked Flash / ROM) and is used to perform the lowest-level boot control and path decision after the device is powered on. This module mainly includes: (1) Boot verification unit: used to quickly verify the firmware information of BOOT2 and APP after the system is powered on, so as to determine whether each firmware has the basic executable conditions and provide a basis for subsequent jumps. (2) Decision unit: determined by the verification results of BOOT2 and APP. When the firmware is in normal condition (e.g., both BOOT2 and APP are normal), it jumps directly from BOOT1 to APP; when APP is abnormal and BOOT2 is normal, BOOT1 jumps to BOOT2, allowing BOOT2 to perform the repair process on APP; when BOOT2 is abnormal and APP is normal, it jumps from BOOT1 to APP, where APP senses and reports the abnormal state to the cloud, and obtains the firmware of BOOT2 through interaction with the cloud to repair BOOT2; when both BOOT2 and APP are abnormal, it enters BOOT1 recovery mode and selects firmware from the general backup area for repair processing. (3) Recovery mode unit: When both BOOT2 and APP are abnormal, it enters the recovery process, traverses the FLASH IAP area of ​​the general backup area, identifies the firmware type, performs segmented copy and write operations according to the firmware type, thereby recovering the corresponding module and rebuilding the boot chain to ensure that the system has the final self-recovery capability. It should be noted that the FLASH IAP area is a unit that can be operated by BOOT1, BOOT2, and APP.

[0021] BOOT2, as the intermediate boot and maintenance module of the system, is mainly used to upgrade the APP and assist in the recovery of the APP. Its permissions are lower than those of BOOT1, but its operational capabilities are higher than those of the APP. This module mainly includes: (1) APP upgrade writer (FLASH IAP compatible): BOOT2 can complete the following through the IAP area interface: APP image CRC / signature verification; segmented writing to the APP area or backup area; breakpoint resume writing and record offset; complete the recovery or update of the APP; and ensure that the APP upgrade is controllable and secure. It can be understood that by performing verification and segmented writing operations on the APP firmware, it supports firmware integrity verification, breakpoint resume writing and data offset control, thereby achieving a stable and reliable APP upgrade process. (2) APP restorer: When BOOT1 jumps to BOOT2, BOOT2 will: read the abnormal information transmitted by BOOT1; select the correct APP image in FLASH IAP; restore the APP main area or complete the switch; and provide a reliable repair channel for the APP. (3) Self-check and reporting unit: During the startup phase, it performs integrity verification on its own firmware and reports status information to other modules of the system (such as APP or BOOT1) when an anomaly is detected, so as to form a multi-level health awareness mechanism. It can be understood that when the jump to BOOT2 fails, the status will be changed to jump to APP immediately, and BOOT1 will immediately execute the jump to APP action. After the APP successfully jumps, it will immediately report the BOOT2 anomaly. (4) Permission and security verification unit: When receiving the BOOT2 upgrade request from APP, it verifies the source of the request and the permissions to avoid the APP being attacked and the BOOT2 firmware being maliciously replaced.

[0022] The APP is the main operating module of the system. After the startup jump is completed, it executes business logic and undertakes the functions of running status monitoring and cloud interaction. This module mainly includes: (1) Peripheral initialization and health detection unit: Before the APP initializes peripherals such as communication, storage, and sensors: reads BOOT2 health flag information (from BOOT1 or BOOT2); if BOOT2 is abnormal, it records the local log and prepares to report it. It can be understood that the BOOT2 health flag information is designed according to the latest version number. For example, a firmware APP version number is 10001.01.01, and the BOOT2 version number is 10001.00.01. When the APP is running, if BOOT2 is abnormal, the BOOT2 version number will be set to the abnormal state (1001.00.00) and uploaded to the cloud. It can be known that BOOT2 is now abnormal and an upgrade is initiated. If the APP jumps to BOOT2 abnormally, the APP version number will be uploaded to the abnormal state (10001.01.00), so that the cloud can find that the APP is abnormal. (2) Status reporting and recovery triggering unit: When a BOOT2 anomaly is detected, the APP records the relevant anomaly information and reports the device identifier, BOOT2 version information and anomaly code to the cloud via IoT (Internet of Things). The BOOT2 repair process can be triggered when conditions are met. (3) Upgrade authorization control unit: When the APP initiates a BOOT2 upgrade request, it needs to make a judgment based on the cloud authorization information and the local security verification results to ensure that the upgrade operation is performed under controlled conditions and improve system security.

[0023] The general backup area is used to store various firmware images and their related metadata, including firmware type, version information, verification information, and timestamps. This module provides the system with a data source for firmware recovery and rollback, supports reading firmware from the backup area in abnormal situations, and completes the recovery of the main area firmware through a unified write mechanism.

[0024] IoT is used to enable data interaction between devices and the cloud, supporting multiple communication protocols (such as HTTP / TLS, MQTT, CoAP, CAN / UDP, etc.) to meet the connectivity needs of different application scenarios. Its main functions include: reporting device status, version information, and anomaly information to the cloud; receiving firmware update instructions and control commands issued by the cloud; participating in firmware download and upgrade processes under authorized conditions; and supporting the execution of remote maintenance and upgrade policies.

[0025] The cloud typically consists of servers, primarily including upgrade control services for unified device management and firmware distribution. Its main functions include: managing firmware resource libraries and version information; receiving operational status and anomaly information reported by devices; executing firmware distribution strategies and prioritizing scheduling based on device status; recording historical data of firmware distribution and upgrade processes to support statistics and analysis; and prioritizing the triggering of repair processes for critical modules when necessary.

[0026] It should be noted that the system uses a unified internal interface to operate the firmware, including functions such as jump, copy, verification, and recovery, applicable to BOOT1, BOOT2, and the APP. This mechanism is used to: enable secure jumps between the application module and the boot module; support segmented copying and verification of firmware between the general backup area and the main area; provide a unified firmware writing and upgrade interface to avoid inconsistencies in implementation methods across different modules; and support automatic recovery processes based on the general backup area in abnormal situations. Through this unified mechanism, the system establishes a consistent firmware management and operation system across different modules, thereby improving the overall stability and reliability of operation.

[0027] The firmware self-management system provided in this embodiment constructs a layered boot and management architecture composed of BOOT1, BOOT2, APP, and a general backup area. During the startup phase, BOOT1 performs unified integrity verification and jump decisions, and implements parallel path selection based on the health status of BOOT2 and APP. This allows the system to continue running or enter the repair process through other paths even if any module malfunctions, thus avoiding single-point failures that could prevent device startup. Simultaneously, during the APP's operation phase, the BOOT2 status is monitored a second time, and anomaly reporting and remote upgrade control are achieved in conjunction with IoT, forming a closed-loop mechanism of "device self-check—cloud decision—device execution." Furthermore, the firmware image is centrally stored, segmented, verified, and rolled back through the FLASH IAP general area of ​​the general backup area. This allows BOOT1, BOOT2, and APP to perform recovery and upgrade operations based on a unified data source, thereby achieving firmware verifiability, recoverability, and consistency management at the system level. Based on the above multi-layered collaborative mechanism, this system significantly improves the startup reliability, operational stability, and overall fault tolerance of devices in complex operating environments, achieving a "non-brickable" engineering effect.

[0028] Please see Figure 2 , Figure 2 This is a flowchart illustrating a firmware self-management method provided in an embodiment of this application. This firmware self-management method is applied to the electronic device 100 within the aforementioned firmware self-management system 1000. For example... Figure 2 As shown, the method includes steps S1-S3: S1: After the first boot module is powered on, an initialization operation is performed to obtain the first firmware information and the second firmware information; wherein, the first firmware information is obtained by reading the firmware header of the second boot module, and the second firmware information is obtained by reading the firmware header of the application module.

[0029] S2: When the first firmware information and the second firmware information meet the preset jumpability verification conditions, the normal startup process is executed; wherein, the normal startup process includes: the application module performs peripheral initialization operation and obtains the health flag information of the second boot module; when the health flag information does not meet the preset first health verification conditions, the second boot module performs a first repair operation according to the application module, the first boot module and the cloud.

[0030] BOOT1 is first loaded and executed after the electronic device is powered on and reset, and then enters the initialization phase. This initialization phase includes the establishment of the basic operating environment, such as completing the clock system configuration, stack space initialization, Flash controller initialization, and temporary mapping settings of the interrupt vector table, to ensure that the firmware areas stored in non-volatile memory can be safely accessed later.

[0031] After initialization, BOOT1 accesses the Flash partitions where BOOT2 and the APP reside, respectively, based on pre-defined storage address information, and reads the corresponding firmware header structure data from fixed offset positions in each partition. Based on this, BOOT1 parses the read data to form first firmware information and second firmware information. The first firmware information, obtained by reading and parsing the firmware header area of ​​the BOOT2 partition, characterizes the existence and basic state of the BOOT2 firmware; the second firmware information, obtained by reading and parsing the firmware header area of ​​the APP partition, characterizes the validity and executable state of the APP firmware.

[0032] Furthermore, during the formation of the first firmware information and the second firmware information, BOOT1 performs detection processing of different granularities on BOOT2 and APP: First, BOOT1 performs a fast validity check (coarse check) on BOOT2 and APP based on the first firmware information and the second firmware information. The coarse check is used to determine whether there is valid firmware data in the target partition. The implementation method includes checking whether the firmware header area is in an erased state (e.g., the stored content is all 0xFF) and judging whether there is obvious abnormal data distribution in the key identifier area, thereby identifying the situation of missing or obviously damaged firmware, and the detection results are reflected in the first firmware information and the second firmware information respectively.

[0033] Based on this, BOOT1 further performs integrity verification (fine-grained inspection) only on the APP firmware corresponding to the second firmware information. Specifically, this includes parsing the structured fields in the APP firmware header (including firmware identifier field, version number field, length field, entry address field, and integrity verification field), and performing consistency verification and integrity verification processing based on the above fields. This includes determining whether the identifier field is valid, whether the version number or status field is within the allowed boot range, performing CRC recalculation or signature verification on the specified data area and comparing it with the verification value recorded in the firmware header, and verifying whether the entry address is within the valid Flash address range, thereby generating second firmware information containing the integrity verification results.

[0034] It should be noted that for the BOOT2 firmware corresponding to the first firmware information, only the above coarse detection is performed in the BOOT1 stage, and no integrity verification is performed, in order to reduce the processing overhead in the power-on stage and shorten the startup time.

[0035] Subsequently, BOOT1 performs a preset jumpability verification condition based on the first firmware information and the second firmware information: when the second firmware information indicates that the APP has passed the coarse detection and integrity verification, and the first firmware information indicates that BOOT2 has at least passed the coarse detection (the APP is normal and BOOT2 is normal), the system is determined to meet the jumpability verification condition, and BOOT1 performs a jump operation according to the entry address in the second firmware information to enter the APP running stage.

[0036] If any firmware information fails to meet the jumpability verification conditions (e.g., BOOT2 is abnormal and APP is normal, BOOT2 is normal and APP is abnormal, both BOOT2 and APP are abnormal), then BOOT1 will not perform a normal jump, but will enter the abnormal recovery process.

[0037] During the normal startup process, after BOOT1 has completed the jumpability verification of the first firmware information and the second firmware information and switched control to the APP, the APP first enters its own startup initialization phase. In this phase, the APP completes peripheral initialization operations in a preset order. Peripheral initialization operations include, but are not limited to, system clock configuration, GPIO port initialization, communication interface initialization (such as UART, SPI, I2C, CAN or network communication interface), memory interface initialization, and necessary interrupt and task scheduling environment configuration to ensure that subsequent business logic and communication functions can run normally. While completing the basic peripheral initialization, the APP synchronously or sequentially executes the status detection process of BOOT2.

[0038] In this detection process, the APP performs an integrity check on BOOT2 based on the first firmware information or by rereading the BOOT2 firmware header information (consistent with the detailed detection of the APP mentioned above). This includes performing CRC verification or signature verification on the BOOT2 firmware and determining its health status in conjunction with the version number or status flag. When the detection result indicates that BOOT2 is normal or abnormal, the APP generates the corresponding health flag information and reports it to the cloud through the communication module, thereby triggering the subsequent repair or upgrade process for BOOT2.

[0039] It is understandable that the health flag information is not a single value, but a set of status flags constructed based on preset rules. Its sources include at least one of the following: first, the BOOT2 status flag bit recorded and transmitted by BOOT1 during the startup phase; second, the version number field and verification status field in the BOOT2 firmware header; third, the status flag data maintained in a specific Flash storage area during BOOT2 operation; and fourth, the exception flag actively modified and written by BOOT2 when an exception occurs. In the specific implementation, the APP obtains the health flag information by reading a predetermined Flash address or through an internal interface, and then parses and judges it.

[0040] Furthermore, the criteria for determining health status information typically include the validity of the version number and the consistency of the status code. For example, under normal circumstances, the version number field of BOOT2 should be a preset valid version format (such as "10001.00.01"), and the status flag should be in the "normal" state. If BOOT2 encounters an anomaly during historical operation, its health status information will be modified to an abnormal state, for example, by setting a specific bit of the version number or the status field to an abnormal code (such as "10001.00.00" or the corresponding abnormal status code) to distinguish it from the normal version state. After reading the health status information, the APP comprehensively judges whether BOOT2 is in a normal operating state by comparing the version number structure, status field, and verification field (such as CRC or signature status).

[0041] After parsing the health indicator information, the APP performs subsequent processing based on the judgment result: if the BOOT2 health indicator information shows that it is in a normal state, the current state is recorded for local operation logs, and subsequent business logic continues to be executed; if the BOOT2 health indicator information indicates that it is in an abnormal state, the APP records the abnormal state locally after completing the necessary peripheral initialization, and reports the data including device identifier, BOOT2 version information and abnormal flag to the cloud through the communication module, so that the cloud can perform status statistics and upgrade scheduling, and provide a basis for possible subsequent BOOT2 repair processes.

[0042] In some embodiments, the method further includes: when the health flag information meets the first health verification condition and the second guidance module receives the update instruction of the application module sent by the cloud, updating the application module according to the second guidance module, the cloud and the first guidance module.

[0043] Specifically, the application module is updated based on the second boot module, the cloud, and the first boot module. This includes: the second boot module receiving the application update file sent by the cloud and verifying the application update file to obtain a first verification result; when the first verification result meets a fourth preset condition, the second boot module writes the application update file to the backup module and updates the application module; after updating the application module, the first boot module copies the application update file from the backup module to a designated storage area in the application module, and after copying the application update file, the first boot module jumps to the application module.

[0044] After the app completes peripheral initialization, it obtains the health flag information of BOOT2 and determines that the health flag information meets the preset first health verification condition. When BOOT2 receives the app's update command sent from the cloud, the system enters the app update process. The first health verification condition refers to a comprehensive judgment on the version number field, status flag field, and integrity verification field contained in the BOOT2 health flag information, ensuring that it simultaneously meets the following requirements: valid version format, normal status flag, and consistent firmware header verification (such as CRC or signature verification). This confirms that BOOT2 is in an executable and serviceable state, capable of undertaking firmware writing and upgrade tasks.

[0045] Under this premise, BOOT2, acting as the upgrade execution entity, first establishes a communication connection with the cloud (e.g., establishing an MQTT / HTTP / TLS link via IoT) and receives the APP update command issued by the cloud. The cloud, based on the device identifier and version policy, sends the corresponding application update file to the electronic device. The application update file refers to a data set containing the complete executable code of the APP, typically including a binary code segment, vector table, initialization data segment, and accompanying firmware header information. The firmware header information includes at least a file identifier, target version number, data length, segmentation information, and a CRC or digital signature for integrity verification.

[0046] After receiving the application update file, BOOT2 first parses the firmware header of the update file and performs integrity and legality checks on it. Specifically, this includes: performing CRC calculation or signature verification on the entire or segmented data of the update file and comparing it with the checksum carried in the firmware header; checking whether the version number field meets the upgrade policy requirements and whether the file length is consistent with the actual received data length; if all the above checks pass, a first verification result is obtained. The first verification result is used to indicate that the application update file meets the preset requirements in terms of data integrity, source legality, and structural correctness.

[0047] When the first verification result meets the fourth preset condition (the fourth preset condition means that the first verification result shows that the application update file has passed integrity verification, signature verification, and the version is valid and has not been marked as an abnormal version), BOOT2 considers that the application update file is safe to write. Based on this, BOOT2 writes the application update file to the backup module storage area according to a preset segmentation strategy. During the writing process, a segmented writing mechanism is adopted, that is, the update file is divided into multiple data blocks of fixed size and written to the backup module block by block. After each data block is written, the current write offset address and status flag are recorded to support breakpoint resume and abnormal recovery. At the same time, after all the update data is written, BOOT2 records the write completion flag and candidate identifier in the backup module, so that the update file is marked as a candidate version that can be used for subsequent system updates.

[0048] After writing the application update file in the backup module, the system enters the copying and activation phase led by BOOT1. When the system re-enters the BOOT1 execution path due to a restart or reset, BOOT1 identifies the application update file that needs to be updated based on the candidate flags in the backup module and the preset update strategy, and reads the application update file from the backup module. Subsequently, BOOT1 copies the application update file from the backup module segment by segment to the main storage area where the APP is located, according to the segmented copying mechanism corresponding to the writing, to obtain the application image file. During the copying process, write verification (such as CRC check or read-after-write check) is performed on each data segment, and the current write progress is recorded to ensure the consistency and integrity of the data write. After all data is copied, BOOT1 performs an overall integrity check on the target APP main area again to confirm that the copied application image file is consistent with the application update file in the backup module and is executable.

[0049] After confirming that the copy result meets the preset correctness requirements, BOOT1 remaps the configuration vector table and sets the program entry address, then jumps the execution flow to the APP's entry function, thereby completing the application update and normal startup, and enabling the device to enter the business operation state based on the new image.

[0050] During the APP update process, a status determination mechanism based on health flag information is introduced, enabling the system to identify the current state of BOOT2 before executing the update operation and select an appropriate processing strategy accordingly, rather than creating a strong dependency constraint on the upgrade path. Specifically, when the health flag information of BOOT2 meets the first health verification condition, it indicates that it has the ability to perform firmware writing and verification. At this time, BOOT2 participates in the APP update process as a controlled execution subject, thereby completing the receiving, verification, and writing operations of the application update file. When the health flag information of BOOT2 does not meet the first health verification condition, the system does not block the normal operation of the APP, but triggers the corresponding repair process through the APP to restore BOOT2. It can be understood that the role of health flag information determination is to schedule and select the current execution path of the system, rather than to serve as a precondition for the APP update operation, so that the APP operation link and the upgrade link are logically decoupled: the APP can continue to run and trigger its repair when BOOT2 is abnormal, and then participate in the upgrade process after BOOT2 recovers to a healthy state. This mechanism avoids the strong dependence on a single boot node found in traditional serial boot structures, ensuring the safety of the upgrade process while maintaining the continuity and recoverability of system operation.

[0051] In its implementation, BOOT2, as the controlled execution entity, receives the application update file from the cloud. Before writing, it performs integrity and legality checks on the update file to obtain the first verification result. Only if this verification result meets the fourth preset condition is the update file written to the backup module, reducing the risk of invalid or corrupted files entering the system from the source. Subsequently, after a system restart or reset, BOOT1 reads the verified update file from the backup module and copies it in segments to the APP's main storage area. After copying, it performs a secure jump again through entry address configuration and vector table remapping, ensuring the new image officially takes effect after double verification and dual-stage write confirmation. Through this closed-loop mechanism of "health status determination—file verification—staged writing—dual boot collaboration," the reliability and anomaly resistance of the APP update process are improved, while the risk of system unavailability due to file corruption, transmission anomalies, or write failures during the upgrade process is reduced. This significantly enhances the security, stability, and overall fault tolerance of the system firmware upgrade.

[0052] Specifically, when the health indicator information does not meet the preset first health verification condition, the second boot module performs a first repair operation based on the application module, the first boot module, and the cloud. This includes: when the health indicator information does not meet the first health verification condition, the application module sends a first firmware request instruction to the cloud, so that the cloud sends a first firmware repair file according to the first firmware request instruction; the application module receives the first firmware repair file and stores it in the backup module; the first boot module copies the first firmware repair file from the backup module to obtain a first firmware repair image file, and repairs the second boot module according to the first firmware repair image file.

[0053] After the APP completes the peripheral initialization, it obtains the health flag information of BOOT2 and parses the health flag information. If it determines that the health flag information does not meet the preset first health verification condition, the system enters the BOOT2 repair process. The health flag information does not meet the first health verification condition, which means that there is at least an anomaly in the status flag, version information or integrity verification result of BOOT2. For example, the version number is marked as an abnormal code, the CRC or signature verification fails, or the status bit is set to a fault flag, which indicates that BOOT2 does not currently have the ability to perform normal boot or upgrade.

[0054] like Figure 3 As shown, in this scenario, the APP, acting as the running main control module, first constructs and sends a first firmware request command to the cloud based on the device identification information (DeviceID) and BOOT2 abnormal status information. This first firmware request command is a standard communication command used to request the cloud to send the firmware data required for BOOT2 repair. Its content includes at least the device's unique identifier, the current BOOT2 version information, the abnormality type identifier, and the type of repair image expected to be obtained, so that the cloud can accurately match the corresponding repair resources. Upon receiving the first firmware request command, the cloud generates and sends a download link for the corresponding first firmware repair file to the electronic device based on the device status and the version management policy in the firmware library, allowing the electronic device to download it. The first firmware repair file refers to a complete set of firmware data used to restore or rebuild BOOT2 functionality. It typically includes a BOOT2 program code segment, a vector table, an initialization data segment, and firmware header information. The firmware header information includes the repair image's identification information, version number information, data length information, and verification fields (such as CRC or digital signature) for integrity verification.

[0055] After receiving the first firmware repair file from the cloud, the APP first performs a basic integrity check on the repair file, such as verifying the data integrity during transmission, file length consistency, and firmware header structure validity. After confirming that the data is not corrupted, the APP writes the first firmware repair file to the general backup area according to the preset storage rules. During the writing process, the APP stores the repair file in segments and records the offset address and writing status after each segment is written. At the same time, the APP marks the repair file as a BOOT2 candidate repair image in the general backup area for subsequent boot module calls.

[0056] After the system completes the above storage operations and a reset or restart occurs, BOOT1 is reloaded and executed. After initialization, BOOT1 scans the data records and image identifiers in the general backup area to identify the candidate firmware for BOOT2 repair and reads the corresponding first firmware repair file from the general backup area. During the reading process, BOOT1 performs integrity verification on the repair file again, including CRC verification or signature verification, to confirm that the file has not been damaged or tampered with during storage and transmission.

[0057] After verification, BOOT1 parses the first firmware repair file into an executable first firmware repair image file. The first firmware repair image file refers to the firmware data image that has been verified by BOOT1 and is ready to be written to the target partition of BOOT2. Subsequently, BOOT1 writes the repair image file into segments according to the preset Flash partition address to the storage area where BOOT2 is located. During the writing process, a segment-by-segment writing and segment-by-segment verification mechanism is used to ensure that each data block is written correctly and to record the writing progress to support abnormal recovery. After all data is written, BOOT1 performs an overall consistency verification on the target area of ​​BOOT2 to confirm that the repaired BOOT2 image is complete and valid in structure and content.

[0058] After confirming successful repair, BOOT1 updates the status flag information of BOOT2 to restore its health flag to normal, and selects the execution path according to the system startup policy. Under normal circumstances, after BOOT2 is repaired, BOOT1 will prioritize jumping to the APP, so that the system can resume operation without interrupting business.

[0059] When BOOT2's health status is abnormal, a tiered repair mechanism involving the APP, cloud, and BOOT1 is constructed, enabling the system to automatically recover BOOT2 without manual intervention. Specifically, when the APP detects that the health flag information does not meet the preset first health verification condition, it proactively sends a first firmware request command to the cloud, triggering the cloud to issue the corresponding first firmware repair file. After the APP receives the repair file, it is reliably stored in the general backup area as the data basis for subsequent repairs. Subsequently, when the system restarts or switches to the boot stage, BOOT1 reads and copies the repair file from the general backup area to form a first firmware repair image file, and performs write and verification repair operations on BOOT2 based on this image file, restoring BOOT2 to a normal operating state. Through the above process, not only is rapid location and remote repair of BOOT2 anomalies achieved, but the system risks caused by directly writing critical boot module operations during APP runtime are also avoided, thereby significantly improving the system's self-recovery capability for boot module failures, repair success rate, and overall operational continuity and stability.

[0060] S3: When the first firmware information and the second firmware information do not meet the jumpability verification conditions, an abnormal recovery process is executed; wherein, the abnormal recovery process includes: if the first firmware information and the second firmware information meet the first preset conditions, a first repair operation is performed on the second boot module according to the application module, the first boot module, and the cloud; if the first firmware information and the second firmware information meet the second preset conditions, a second repair operation is performed on the application module according to the second boot module, the cloud, and the first boot module; if the first firmware information and the second firmware information meet the third preset conditions, a third repair operation is performed on the second boot module and the application module according to the first boot module and the backup module.

[0061] When BOOT1 determines that the first firmware information and the second firmware information do not meet the preset jumpability verification conditions, the system will no longer execute the normal startup process, but will enter the abnormal recovery process.

[0062] In this anomaly recovery process, BOOT1 first classifies and determines the anomaly type based on the acquired firmware information, and then further determines whether the first preset condition is met. The first preset condition refers to the following: BOOT2 is in an abnormal state, while the APP remains in a normal executable state. Specifically, this means that BOOT2's firmware header information fails CRC or signature verification, or its status flag is marked as abnormal, while the APP's second firmware information meets the legality requirements in terms of the identification field, integrity verification field, and entry address verification, and can be loaded and executed normally.

[0063] After confirming that the first preset condition is met, the first repair operation is performed on BOOT2 based on the APP, BOOT1, and the cloud. It should be noted that the first repair operation in step S3 is the same as the first repair operation in step S2 above, and will not be described again here.

[0064] If the first firmware information and the second firmware information meet the second preset conditions, a second repair operation is performed on the application module according to the second boot module, the cloud, and the first boot module. This includes: if the first firmware information and the second firmware information meet the second preset conditions, the second boot module sends a second firmware request instruction to the cloud, so that the cloud sends a second firmware repair file according to the second firmware request instruction; the second boot module receives the second firmware repair file and stores it in the backup module; the first boot module copies the second firmware repair file from the backup module to obtain a second firmware repair image file, and repairs the application module according to the second firmware repair image file.

[0065] like Figure 4 As shown, after BOOT1 completes the parsing of the first firmware information and the second firmware information, if it determines that the two do not meet the preset jumpability verification conditions, but further determines that they meet the second preset conditions based on the verification results, status flags and version / structure information of the two, then the system enters the second repair process of the APP. The second preset condition refers to the following: BOOT2 is in a normal executable state (its firmware header integrity verification is passed, the entry address is valid and the status flag is normal), while the APP has an abnormal state (for example, its firmware header CRC / signature verification fails, the vector table or entry address is abnormal or the status flag is marked as damaged), that is, the combination of "BOOT2 is normal and APP is abnormal".

[0066] After confirming that the second preset condition is met, the system uses BOOT2 as the repair execution entity and the cloud as the repair resource provider. First, BOOT2, based on the detected abnormal APP state, constructs and sends a second firmware request instruction to the cloud. This second firmware request instruction is a communication instruction used to request the cloud to send APP repair resources. Its content includes at least the device's unique identifier, the current APP version information, the abnormality type identifier, and the required APP image type, so that the cloud can accurately locate and return the corresponding application repair file. Upon receiving the second firmware request instruction, the cloud, based on the device identifier and version management policy, retrieves the application image resource matching the device from the firmware library and generates a link to the second firmware repair file, which is then sent to the electronic device for download. The second firmware repair file is a complete firmware data set used to restore or rebuild the APP. Its structure is consistent with the APP executable image, containing program code segments, initialization data segments, vector tables, and firmware header information. The firmware header information includes the target version number, data length, segmentation information, and verification fields (such as CRC or digital signature) for integrity verification.

[0067] Upon receiving the second firmware repair file, BOOT2 first parses the firmware header and performs integrity and legality checks, including performing CRC calculations or signature verification on the data content and comparing it with the checksum in the firmware header. It also checks whether the version number, length field, and structure field are consistent. After confirming that the verification is successful, BOOT2 stores the second firmware repair file in the general backup area according to a preset segmentation strategy, and records the candidate identifier and storage completion status of the image in the general backup area as the data source for subsequent repairs.

[0068] After completing the above storage, the system enters the repair execution phase led by BOOT1. When the system is reset or restarted and re-enters the BOOT1 execution process, BOOT1 scans the firmware records in the general backup area, identifies the second firmware repair file marked for APP repair purposes, and reads the file from the general backup area. During the reading process, BOOT1 performs a second verification on the second firmware repair file, including CRC verification or signature verification, to confirm that the file has not been damaged or tampered with during storage and transmission. After the verification is successful, BOOT1 parses the file into a second firmware repair image file. The second firmware repair image file refers to the complete image data that can be directly written to the APP main storage area after verification by BOOT1, and contains the corresponding program entry information and memory layout information.

[0069] Subsequently, BOOT1 writes the second firmware repair image file into the designated storage area of ​​the APP in segments according to the address mapping relationship of the Flash partition where the APP is located. During the writing process, a segment-by-segment writing and segment-by-segment verification mechanism is adopted. After writing, read verification or CRC verification is performed on each data block, and the writing progress and offset address are recorded to ensure the integrity and consistency of the writing process. After all data is written, BOOT1 performs an overall integrity verification on the APP main area to confirm that the repaired application image file meets the executable requirements.

[0070] After confirming successful repair, BOOT1 updates the health flag information of the APP to restore it to normal status, and redirects the execution process to the APP through vector table remapping and entry address configuration according to the startup policy, so that the system can resume normal business operation after the APP is repaired.

[0071] When the first firmware information and the second firmware information meet the second preset conditions, the second repair operation on the APP is performed collaboratively by BOOT2, the cloud, and BOOT1. This allows the system to proactively trigger the repair process even when the APP is abnormally damaged but BOOT2 is in a normal state. BOOT2 sends a second firmware request command to the cloud to obtain the corresponding application repair resources, and the cloud distributes a second firmware repair file that matches the target device. BOOT2 then receives and backs up the repair file, and BOOT1 copies and parses it from the backup module to form a writable second firmware repair image file. Based on this, the APP is rebuilt and restored, thereby achieving automated and hierarchical repair of the APP. This solution can quickly restore APP functionality without manual intervention, reduce system downtime caused by APP abnormalities, and improve system reliability and availability. At the same time, through unified cloud distribution and local multi-module collaborative verification and writing mechanisms, the accuracy and security of the repair process are improved, avoiding system risks caused by writing erroneous firmware.

[0072] If the first firmware information and the second firmware information meet the third preset condition, a third repair operation is performed on the second boot module and the application module according to the first boot module and the backup module. This includes: if the first firmware information and the second firmware information meet the third preset condition, the first boot module reads the target firmware header information from the backup module and identifies the target firmware header information to obtain firmware type information; if the firmware type information is a firmware type corresponding to the second boot module, the first boot module copies the firmware repair file corresponding to the firmware type information to obtain a first target firmware repair image file, and repairs the second boot module according to the first target firmware repair image file; after repairing the second boot module, the first boot module repairs the application module; if the firmware type information is a firmware type corresponding to the application module, the first boot module copies the firmware repair file corresponding to the firmware type information to obtain a second target firmware repair image file, and repairs the application module according to the second target firmware repair image file; after repairing the application module, the first boot module repairs the second boot module.

[0073] like Figure 5 As shown, after BOOT1 completes the parsing of the first firmware information and the second firmware information, if it determines that neither of them can meet the jumpability verification conditions, but further determines that they meet the third preset condition based on the verification failure status, missing version information, or structural abnormality of the two, then it enters the global recovery mode. The third preset condition refers to the fact that both BOOT2 and APP are in an abnormal and unusable state, that is, the firmware header information verification of both of them fails, the entry address is invalid, or the status flag is marked as abnormal, thus causing the system to be unable to complete normal startup by relying on the main storage area.

[0074] Under the condition that the third preset condition is met, BOOT1 takes the lead in the recovery process and selectively repairs the abnormal modules by combining the firmware resources pre-stored in the general backup area. First, BOOT1 performs a scan operation on the storage area where the general backup area is located, and reads the target firmware header information stored continuously from the preset starting address of the general backup area. The target firmware header information refers to the descriptive header data attached to each backup firmware image when it is stored. It is usually located at the beginning of the image data and contains metadata fields used to identify the attributes of the image, such as version number, data length, checksum, and firmware identifier field.

[0075] After reading the target firmware header information, BOOT1 parses and identifies it, extracting predefined identifier fields, type markers, or magic numbers to determine the firmware type to which the corresponding image belongs, thus obtaining firmware type information. The firmware type information is used to characterize whether the image file belongs to the boot firmware corresponding to BOOT2 or the application firmware corresponding to APP. This type information is obtained by matching and identifying the type field or feature code in the firmware header.

[0076] After obtaining the firmware type information, BOOT1 performs branch processing based on the type information: if the identification result is the firmware type corresponding to BOOT2, BOOT1 locates the firmware repair file that matches the type from the general backup area, and performs a copy operation on the firmware repair file to generate the first target firmware repair image file; wherein, the first target firmware repair image file refers to the complete executable image data of BOOT2 after being read, verified and reassembled by BOOT1. The image file contains the complete code segment, initialization data and entry vector information of BOOT2, and has the format to be directly written to the BOOT2 storage partition.

[0077] Subsequently, BOOT1 writes the first target firmware repair image file into the storage area corresponding to BOOT2 in segments according to the address mapping relationship of the Flash partition where BOOT2 is located. During the writing process, block-by-block verification and address alignment are performed to ensure the integrity and consistency of the written data, thereby completing the repair of BOOT2.

[0078] After repairing BOOT2, BOOT1 continues the recovery process for the APP. Specifically, BOOT1 first performs an integrity verification process on the repaired BOOT2, including rereading the version field, status flag field, and CRC check field in the BOOT2 firmware header information, and verifying the validity of the BOOT2 entry address to confirm that BOOT2 has been restored to an executable state and has the ability to perform subsequent collaborative recovery.

[0079] After confirming the successful repair of BOOT2, BOOT1 first searches for a valid firmware repair resource corresponding to the APP based on the firmware index information in the general backup area. If a valid firmware repair file corresponding to the APP is found in the general backup area (e.g., firmware header verification passes, type identifier matches and integrity verification is consistent), BOOT1 directly reads the complete APP firmware image data and its attached firmware header information from the backup area, and reassembles and encapsulates the APP firmware repair file, converting it into a second target firmware repair image file that conforms to the APP partition write format.

[0080] If BOOT1 fails to find a valid firmware repair file corresponding to the APP in the general backup area, or detects that the APP firmware in the backup area has verification failure, version abnormality, or incomplete data, then BOOT1 establishes a communication link with the cloud through the restored BOOT2 and requests the cloud to send the corresponding APP firmware repair resources. After receiving the APP firmware data sent by the cloud, BOOT2 or BOOT1 performs integrity verification on the firmware (such as CRC or signature verification), and writes it to the general backup area after the verification is passed. Then, BOOT1 reads the verified firmware data and generates a second target firmware repair image file.

[0081] After generating the second target firmware repair image file, BOOT1 performs segmented writing operations on the image according to the APP partition mapping relationship, writing it block by block to the Flash storage area corresponding to the APP, and performing post-write read verification or CRC consistency verification after each block is written to ensure that there is no data loss or misalignment during the writing process; after all writing is completed, BOOT1 performs overall integrity verification on the APP main storage area again, thereby completing the repair of the APP.

[0082] If the firmware type information is identified as corresponding to the APP, BOOT1 copies the corresponding firmware repair file from the general backup area and generates a second target firmware repair image file. This second target firmware repair image file is a complete executable image used to restore the APP, and its structure includes program code segments, data segments, system initialization information, and entry address information for startup. After generating this image file, BOOT1 writes the second target firmware repair image file to the APP's corresponding Flash storage area, following the partition layout of the APP's main storage area. During the writing process, segmentation and integrity checks are performed to ensure correct data writing.

[0083] After repairing the app, BOOT1 continues the recovery process for BOOT2. Specifically, BOOT1 first performs a pre-boot verification process on the repaired app, including re-parses the app firmware header information to verify its version validity, whether the status flag is in a normal state, and performs a consistency check on the app entry vector table to confirm that the app has the ability to run normally.

[0084] After confirming successful APP recovery, BOOT1 first searches for the firmware repair file corresponding to BOOT2 in the general backup area. This search process is based on matching the type identifier field or feature code in the firmware header to ensure that the candidate image resource corresponding to BOOT2 is obtained. If there is a BOOT2 firmware repair file that meets the integrity verification requirements in the general backup area, BOOT1 directly reads and encapsulates the firmware to generate the first target firmware repair image file.

[0085] If BOOT1 does not detect a valid BOOT2 firmware repair file in the general backup area, or if it detects that the corresponding firmware has failed verification or is corrupted, BOOT1 establishes a communication connection with the cloud through the currently restored APP. The APP sends a BOOT2 repair request command to the cloud, requesting the download of the corresponding version of BOOT2 firmware repair resources. After the cloud returns the target BOOT2 firmware file according to the device identifier and version policy, the APP or BOOT1 performs signature verification and integrity verification on the firmware. After the verification is successful, it is written to the general backup area and marked as an available repair resource. Then, BOOT1 reads the firmware and generates the first target firmware repair image file.

[0086] After generating the first target firmware repair image file, BOOT1 performs segmented writing operations according to the address mapping relationship of the BOOT2 Flash partition. During the writing process, block-by-block verification and address alignment control are performed to avoid writing misalignment or abnormal data overwriting. After all writing is completed, BOOT1 re-verifies the BOOT2 firmware header information, entry address, and CRC check value to confirm that BOOT2 has finally recovered to a stable and usable state, thereby completing the repair of BOOT2.

[0087] When the first and second firmware information meet the third preset condition—that is, both BOOT2 and APP are in an abnormal and unavailable state—a third repair operation process, led by BOOT1 and involving the general backup area and the cloud, enables the system to maintain stable and reliable self-recovery capabilities even in extreme scenarios where both modules fail simultaneously. Specifically, on the one hand, BOOT1 parses the target firmware header information and identifies the firmware type in the general backup area, enabling precise differentiation and on-demand access to different types of firmware resources. This allows the system to prioritize the use of locally stored trusted firmware resources for targeted repair of BOOT2 or APP, thereby reducing the dependence of the recovery process on the external environment and shortening the recovery time. On the other hand, when there is no valid firmware in the general backup area or the firmware integrity verification fails, a cloud request mechanism based on the recovered module (BOOT2 or APP) is introduced to remotely acquire firmware resources. After local verification, the firmware is written to the backup area and then uniformly persisted to disk by BOOT1, ensuring the security and data consistency of the recovery process. Furthermore, through a phased closed-loop repair mechanism of "restore one module first → verify success → then restore another module," not only is the risk of conflict caused by simultaneous writing of multiple modules avoided, but the boot chain is also ensured to be rebuilt step by step according to BOOT2 and APP, thereby achieving an orderly recovery of the system from a completely unbootable state to a runnable state. Thus, based on the traditional firmware recovery mechanism, a multi-path self-healing system of "local priority + cloud backup + hierarchical reconstruction" is realized, significantly improving the system's fault tolerance, recovery success rate, and overall operational reliability under multi-level fault conditions, while effectively avoiding the risk of the device becoming "unrecoverable" or "bricked."

[0088] In some embodiments, the method further includes: when the second firmware information meets a preset second health verification condition and an upgrade instruction from the second boot module sent by the cloud is received, the application module receives the target upgrade firmware file sent by the cloud according to the upgrade instruction and stores the target upgrade firmware file in the backup module; after receiving the target upgrade firmware file, the application module performs local administrator signature verification to obtain a second verification result, and when the second verification result meets a fifth preset condition, sends an upgrade request instruction to the second boot module so that the second boot module verifies the upgrade request instruction to obtain a third verification result; when the third verification result meets a sixth preset condition, the first boot module upgrades the second boot module according to the target upgrade firmware file.

[0089] When the second firmware information meets the preset second health check conditions, it indicates that the APP is in normal operating condition and the system has basic service capabilities. The second health check conditions refer to a comprehensive judgment of the APP's running status, peripheral initialization status, and basic communication capabilities, ensuring that the program is executable, the communication link is normal, and there are no critical anomaly flags. Based on this, the APP continuously monitors and reports the health flag information of BOOT2 during operation, providing feedback to the cloud on the current BOOT2 version status, running status, and anomaly flags, thereby enabling the cloud to dynamically perceive the boot chain status.

[0090] When the app is healthy and the system is running stably, if an upgrade command for BOOT2 is simultaneously received from the cloud, the controlled BOOT2 upgrade process begins. The upgrade command is a control instruction issued by the cloud based on device status, version policy, and security policy, used to trigger the BOOT2 firmware update. After receiving the upgrade command, the app either requests the target upgrade firmware file from the cloud or directly receives the target upgrade firmware file pushed by the cloud. The target upgrade firmware file refers to the complete firmware data used to update BOOT2, which includes at least the BOOT2 program code segment, initialization data segment, version information, and integrity verification information.

[0091] Upon receiving the target upgrade firmware file, the APP first stores it in the backup module as an intermediate cache for subsequent secure writing, avoiding system risks caused by direct manipulation of the runtime area. Subsequently, the APP performs a local administrator signature verification process on the target upgrade firmware file to obtain a second verification result. The local administrator signature verification refers to verifying the digital signature in the firmware file using a locally pre-installed administrator public key or trusted root certificate to confirm that the firmware file originates from a legitimate authorized entity and has not been tampered with. The second verification result is used to characterize whether the firmware file meets the preset security requirements in terms of source credibility and integrity.

[0092] When the second verification result meets the fifth preset condition, the fifth preset condition is used to indicate that the local signature verification is successful and the firmware integrity verification is consistent. At this time, the APP does not directly perform the Flash write operation, but constructs and sends an upgrade request instruction to BOOT2. The upgrade request instruction is an internal control instruction used to notify BOOT2 to enter the upgrade receiving and verification mode. It contains at least the target firmware summary information, version identifier and verification parameters, which are used by BOOT2 to perform consistency verification and request legality confirmation.

[0093] After receiving the upgrade request instruction, BOOT2 performs verification processing on the request instruction to obtain a third verification result. This verification process includes verifying the legality of the request source, the consistency of parameters, and the current system operating status to confirm whether the upgrade request was initiated by an APP in a trusted state under secure conditions. When the third verification result meets the sixth preset condition, which indicates that BOOT2 confirms the request is legal and the current system allows the upgrade operation, BOOT2 enters the upgrade receiving mode.

[0094] In this mode, BOOT2 receives the target upgrade firmware file forwarded by the APP, and performs segmented reception and caching processing on it, while performing segmented integrity verification to ensure that there is no packet loss or damage during the data transmission process; however, in this stage, BOOT2 only has the permission to receive and verify, and does not have the permission to directly write to the Flash main running area.

[0095] After the target upgrade firmware file is fully received and basic verification is completed, BOOT2 transfers the upgrade execution authority to BOOT1 for unified control. BOOT1, as the only module with write permissions to the Flash main storage area, performs segmented write operations on the Flash partition where BOOT2 is located based on the target upgrade firmware file in the backup module and the verification pass status. During the write process, it performs block-by-block readback verification and address consistency checks to ensure the correctness and integrity of the written data.

[0096] After BOOT1 completes the write update to BOOT2, BOOT1 updates the version information and status flag of BOOT2 and performs a boot chain consistency check, so that the updated BOOT2 enters a usable state; thus completing the security upgrade process under the conditions of "APP healthy operation + cloud authorization + local signature verification + controlled reception of BOOT2 + unified writing of BOOT1".

[0097] When the APP is running healthily, a controlled upgrade mechanism combining cloud authorization, local administrator signature verification, and hierarchical verification by the boot module ensures that the BOOT2 upgrade process always occurs under the premise of stable system operation. This avoids directly executing firmware writing operations when the boot chain is abnormal or the system is not ready, thus significantly reducing the impact of the upgrade process on system operation. Simultaneously, by having the APP first receive and perform local trusted verification of the target upgrade firmware file, then having BOOT2 perform a secondary request verification to confirm the legitimacy of the upgrade intent, and finally having BOOT1 uniformly execute the Flash writing operation, a "cloud policy control—local security verification—boot module" mechanism is implemented. The multi-level security loop of "block permission confirmation - unified disk write at the underlying level" effectively prevents the risk of BOOT2 tampering caused by malicious firmware injection and APP layer attacks. In addition, since BOOT1 is the only module with write permissions to the main storage area and participates in the final write process, the upgrade behavior is uniformly constrained at the hardware access level, which further improves the consistency and controllability of firmware updates. Overall, it not only improves the security and reliability of BOOT2 upgrades, but also ensures that the device can maintain normal business operation during the upgrade process through the decoupling design of the operation chain and the upgrade chain, thereby significantly enhancing the system's stability, anti-anomaly capability, and engineering availability of remote OTA upgrades.

[0098] This application provides a firmware self-management method. By reconstructing the traditional serial boot structure and introducing multi-level health detection, firmware type identification, hierarchical recovery mechanism and end-to-cloud collaborative OTA strategy, significant improvements are achieved at the system architecture and operation mechanism levels, thereby achieving comprehensive enhancements in reliability, security and recoverability.

[0099] Firstly, regarding the system boot architecture, this application further clarifies and strengthens the parallel boot mechanism design based on the original reconstruction. The traditional single-link structure of "BOOT1→BOOT2→APP" is transformed into a parallel path structure with BOOT1 as the sole decision-making core node. This allows BOOT1 to simultaneously possess two independent scheduling paths: one is the main running link "BOOT1→APP," used for normal system startup and business operation; the other is the upgrade and repair link "BOOT1→BOOT2," used to perform firmware updates and recovery operations for BOOT2. Under this parallel mechanism, BOOT2 is no longer a necessary node for APP startup but is decoupled as an optional execution unit. Its existence does not affect the startup and operation logic of the main link, structurally eliminating the constraint that "failure of any node leads to a complete link interruption" in the traditional serial architecture.

[0100] Based on this parallel structure, when BOOT2 is damaged, missing, or fails verification, BOOT1 can still directly jump to the APP along the main link to complete the system startup, thus ensuring that the basic operating capabilities of the device are not affected. Simultaneously, when BOOT2 needs to be upgraded or repaired, BOOT1 switches to the upgrade link, and BOOT2 receives and executes the update task under controlled conditions. This physically and logically isolates the upgrade behavior from the operational behavior, achieving a parallel, conflict-free scheduling mechanism between the operational and upgrade chains. This design makes BOOT1 a true dual-path scheduling center, realizing dynamic selection and redundancy switching capabilities for the boot path.

[0101] Secondly, regarding health monitoring and fault detection, this application proactively detects the BOOT2 health status during the initialization phase via the APP and reports the health status information to the cloud in conjunction with IoT. This allows the cloud to make OTA decisions based on the actual operating status of the device rather than a single version number. This mechanism transforms the firmware upgrade strategy from "version-driven" to "health status-driven," enabling the cloud to perform differentiated resource scheduling and priority ranking for different fault types (such as BOOT2 anomalies, APP anomalies, or both), thereby improving the targeting and effectiveness of firmware distribution and reducing the risk of false pushes and resource waste.

[0102] Regarding the anomaly recovery mechanism, this application constructs a hierarchical anomaly handling and path selection strategy. When only the APP is abnormal, BOOT1 switches to BOOT2 to execute the APP repair process, making BOOT2 a dedicated recovery node participating in APP reconstruction. When only BOOT2 is abnormal, the APP triggers a reporting and repair request during operation, and BOOT1 cooperates to complete the repair and reconstruction of BOOT2 when conditions permit. When both BOOT2 and the APP are abnormal, BOOT1 enters recovery mode, scans the general backup area, identifies the firmware type, and restores BOOT2 and the APP, thereby achieving layer-by-layer repair and system reconstruction under multi-level anomaly conditions. This hierarchical mechanism, through the mapping relationship between "anomaly type - recovery path," ensures that different fault scenarios correspond to a unique and executable recovery strategy, avoiding recovery path conflicts or deadlock issues.

[0103] Furthermore, regarding the firmware management mechanism, this application introduces a firmware type identification and unified scheduling mechanism in BOOT1. By parsing firmware header information, identification fields, and signature information, it achieves accurate differentiation and verification between BOOT2 firmware and APP firmware. Based on the identification results, BOOT1 performs classification processing and targeted copying of the firmware, thereby constructing an indexable multi-type firmware resource pool in the general backup area, enabling the system to automatically select and schedule firmware in the coexistence of multiple firmware. Thus, BOOT1 is upgraded from a traditional single boot role to a core control node with firmware identification, verification, scheduling, and writing capabilities.

[0104] Regarding OTA upgrade security, this application introduces a multi-level security verification chain consisting of "cloud verification + local administrator signature verification + BOOT2 permission verification". When an app initiates an upgrade request, the cloud first performs legality and policy verification, then the local firmware undergoes administrator-level signature verification, and finally BOOT2 confirms the upgrade request's permissions, thus forming a three-layer protection mechanism of client-cloud-boot module. By setting independent verification points at different execution layers, unauthorized firmware injection and potential malicious attacks can be effectively prevented, significantly improving the security and reliability of the upgrade process.

[0105] Furthermore, this application decouples the runtime link from the upgrade link, achieving mutual isolation between system operation and firmware updates. Specifically, normal system operation relies on BOOT1 directly jumping to the APP, while BOOT2 is mainly used for upgrade and repair tasks, and will not affect the main runtime link during the upgrade process; at the same time, all critical firmware writing and disk write operations are uniformly executed by BOOT1, making it assume the final control responsibility in the underlying Flash writing process, thereby avoiding the problem of main firmware area corruption due to interruption, power failure or write failure, thus improving the stability and success rate of the OTA process.

[0106] Based on this, this application achieves a system evolution from "single-link dependency" to "multi-path redundancy + state-driven + hierarchical recovery" by organically combining a parallel boot structure, firmware type identification mechanism, hierarchical anomaly recovery strategy, general backup area reconstruction mechanism, and end-to-cloud collaborative OTA scheduling system. This not only eliminates the risk of single-point failure at the structural level, but also enhances the system's ability to perceive anomalies, recover from faults, and control the upgrade process at the operational level. This enables the device to maintain availability and recoverability under various complex anomaly scenarios, significantly improving the overall reliability, security, and engineering practical value of the system.

[0107] Based on the firmware self-management method provided in the above embodiments, this application further provides a firmware self-management device. Please refer to... Figure 6 , Figure 6 This is a schematic diagram of the firmware self-management device. (For example...) Figure 6 As shown, the firmware self-management device 300 includes: a firmware information acquisition module 310, a normal startup process execution module 320, and an abnormal recovery process execution module 330.

[0108] The firmware information acquisition module 310 is used to perform initialization operations and acquire first firmware information and second firmware information after the first boot module is powered on. The first firmware information is obtained by reading the firmware header of the second boot module, and the second firmware information is obtained by reading the firmware header of the application module. The normal startup process execution module 320 is used to execute the normal startup process when the first firmware information and the second firmware information meet preset jumpability verification conditions. The normal startup process includes: the application module performing peripheral initialization operations and acquiring health flag information from the second boot module; when the health flag information meets preset health verification conditions, updating the application module according to the second boot module, the cloud, and the first boot module; when the health flag information does not meet the health verification conditions, updating the application module according to the preset health verification conditions. The application module, the first boot module, and the cloud perform a first repair operation on the second boot module. The abnormal recovery process execution module 330 is used to execute an abnormal recovery process when the first firmware information and the second firmware information do not meet the jumpability verification conditions. The abnormal recovery process includes: if the first firmware information and the second firmware information meet the first preset conditions, the application module, the first boot module, and the cloud perform a first repair operation on the second boot module; if the first firmware information and the second firmware information meet the second preset conditions, the application module performs a second repair operation based on the second boot module, the cloud, and the first boot module; if the first firmware information and the second firmware information meet the third preset conditions, the second boot module and the application module perform a third repair operation based on the first boot module and the backup module.

[0109] It should be noted that the aforementioned firmware self-management device can execute the firmware self-management method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the firmware self-management device embodiments can be found in the firmware self-management method provided in the embodiments of this application.

[0110] This application also provides an electronic device 100, please refer to... Figure 7 This document illustrates a hardware structure diagram of an electronic device 100 capable of performing the methods described in the above embodiments. The electronic device 100 includes: at least one processor 101; and a memory 102 communicatively connected to the at least one processor 101. Figure 7 Taking a processor 101 as an example, the memory 102 stores instructions executable by at least one processor 101. These instructions, when executed by at least one processor 101, enable the at least one processor 101 to perform the firmware self-management method described in the above embodiment. The processor 101 and the memory 102 can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0111] The memory 102, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the firmware self-management method in the embodiments of this application. The processor 101 executes various cloud-based functional applications and data processing by running the non-volatile software programs, instructions, and modules stored in the memory 102, thereby implementing the firmware self-management method of the above embodiments.

[0112] Memory 102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computing device. Furthermore, memory 102 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 102 may optionally include memory remotely located relative to processor 101, and this remote memory may be connected to the computing device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0113] One or more modules are stored in memory 102, and when executed by one or more processors 101, they execute the firmware self-management method of the above embodiments.

[0114] The above-described product can execute the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the methods. Technical details not described in detail in this embodiment can be found in the firmware self-management method of the embodiments of this application.

[0115] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions. These instructions are executed by one or more processors to enable at least one processor to perform the firmware self-management method described in the above embodiments. For example, the non-volatile computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0116] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by an electronic device, enable the electronic device to perform the firmware self-management method in any of the above method embodiments.

[0117] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, cloud, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A firmware self-management method applied to an electronic device, the electronic device comprising a first boot module, a second boot module, an application module, a backup module, and a communication module, wherein the electronic device communicates with the cloud through the communication module, characterized in that... The method includes: After the first boot module is powered on, an initialization operation is performed to obtain first firmware information and second firmware information; wherein, the first firmware information is obtained by reading the firmware header of the second boot module, and the second firmware information is obtained by reading the firmware header of the application module. When the first firmware information and the second firmware information meet the preset jumpability verification conditions, the normal startup process is executed; wherein, the normal startup process includes: the application module performs peripheral initialization operation and obtains the health flag information of the second boot module; when the health flag information does not meet the preset first health verification conditions, the second boot module performs a first repair operation according to the application module, the first boot module and the cloud. When the first firmware information and the second firmware information do not meet the jumpability verification condition, an anomaly recovery process is executed; wherein, the anomaly recovery process includes: if the first firmware information and the second firmware information meet a first preset condition, performing the first repair operation on the second boot module according to the application module, the first boot module, and the cloud; if the first firmware information and the second firmware information meet a second preset condition, performing a second repair operation on the application module according to the second boot module, the cloud, and the first boot module; if the first firmware information and the second firmware information meet a third preset condition, performing a third repair operation on the second boot module and the application module according to the first boot module and the backup module.

2. The firmware self-management method according to claim 1, characterized in that, The method further includes: When the health indicator information meets the first health verification condition, and the second guidance module receives the update instruction of the application module sent by the cloud, the application module is updated according to the second guidance module, the cloud and the first guidance module.

3. The firmware self-management method according to claim 2, characterized in that, The step of updating the application module based on the second guidance module, the cloud, and the first guidance module includes: The second guidance module receives the application update file sent from the cloud and verifies the application update file to obtain a first verification result; When the first verification result meets the fourth preset condition, the second boot module writes the application update file to the backup module and updates the application module. After updating the application module, the first boot module copies the application update file from the backup module to a designated storage area in the application module, and after copying the application update file, the first boot module jumps to the application module.

4. The firmware self-management method according to claim 1, characterized in that, When the health indicator information does not meet the preset first health verification condition, a first repair operation is performed on the second guide module according to the application module, the first guide module, and the cloud, including: When the health flag information does not meet the first health verification condition, the application module sends a first firmware request instruction to the cloud, so that the cloud sends a first firmware repair file according to the first firmware request instruction; The application module receives the first firmware repair file and stores the first firmware repair file in the backup module; The first boot module copies the first firmware repair file from the backup module to obtain a first firmware repair image file, and repairs the second boot module according to the first firmware repair image file.

5. The firmware self-management method according to claim 1, characterized in that, If the first firmware information and the second firmware information meet the second preset conditions, a second repair operation is performed on the application module according to the second boot module, the cloud, and the first boot module, including: If the first firmware information and the second firmware information meet the second preset condition, the second boot module sends a second firmware request instruction to the cloud, so that the cloud sends a second firmware repair file according to the second firmware request instruction; The second boot module receives the second firmware repair file and stores the second firmware repair file in the backup module; The first boot module copies the second firmware repair file from the backup module to obtain the second firmware repair image file, and repairs the application module according to the second firmware repair image file.

6. The firmware self-management method according to claim 1, characterized in that, If the first firmware information and the second firmware information meet the third preset condition, a third repair operation is performed on the second boot module and the application module according to the first boot module and the backup module, including: If the first firmware information and the second firmware information meet the third preset condition, the first boot module reads the target firmware header information from the backup module and identifies the target firmware header information to obtain firmware type information; If the firmware type information is a firmware type corresponding to the second boot module, the first boot module copies the firmware repair file corresponding to the firmware type information to obtain a first target firmware repair image file, and repairs the second boot module according to the first target firmware repair image file; after repairing the second boot module, the first boot module repairs the application module. If the firmware type information is a firmware type corresponding to the application module, the first boot module copies the firmware repair file corresponding to the firmware type information to obtain a second target firmware repair image file, and repairs the application module according to the second target firmware repair image file; after repairing the application module, the first boot module repairs the second boot module.

7. The firmware self-management method according to any one of claims 1 to 6, characterized in that, The method further includes: When the second firmware information meets the preset second health check condition and receives the upgrade instruction from the second boot module sent by the cloud, the application module receives the target upgrade firmware file sent by the cloud according to the upgrade instruction and stores the target upgrade firmware file in the backup module; After receiving the target upgrade firmware file, the application module performs local administrator signature verification to obtain a second verification result. When the second verification result meets the fifth preset condition, it sends an upgrade request instruction to the second boot module so that the second boot module verifies the upgrade request instruction to obtain a third verification result. When the third verification result meets the sixth preset condition, the first boot module upgrades the second boot module according to the target upgrade firmware file.

8. A firmware self-management device, applied to an electronic device, the electronic device comprising a first boot module, a second boot module, an application module, a backup module, and a communication module, the electronic device communicating with the cloud through the communication module, characterized in that, The device includes: A firmware information acquisition module is used to perform an initialization operation after the first boot module is powered on, and to acquire first firmware information and second firmware information; wherein, the first firmware information is obtained by reading the firmware header of the second boot module, and the second firmware information is obtained by reading the firmware header of the application module. A normal startup process execution module is used to execute a normal startup process when the first firmware information and the second firmware information meet preset jumpability verification conditions; wherein, the normal startup process includes: the application module performing peripheral initialization operations and obtaining health flag information of the second boot module; when the health flag information does not meet preset first health verification conditions, a first repair operation is performed on the second boot module according to the application module, the first boot module and the cloud. An abnormal recovery process execution module is provided, which is used to execute an abnormal recovery process when the first firmware information and the second firmware information do not meet the jumpability verification condition. The abnormal recovery process includes: if the first firmware information and the second firmware information meet a first preset condition, performing a first repair operation on the second boot module according to the application module, the first boot module, and the cloud; if the first firmware information and the second firmware information meet a second preset condition, performing a second repair operation on the application module according to the second boot module, the cloud, and the first boot module; and if the first firmware information and the second firmware information meet a third preset condition, performing a third repair operation on the second boot module and the application module according to the first boot module and the backup module.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by an electronic device, cause the electronic device to perform the method described in any one of claims 1-7.

Images