Firmware management method and device of electronic equipment, equipment and medium

Abstract

The invention relates to the field of firmware upgrading, in particular to a firmware management method and device for electronic equipment, equipment and a medium. A plurality of mutually independent firmware management programs are arranged in the electronic equipment. The method comprises the following steps: detecting the states of the firmware management programs; a target firmware management program to be started is determined based on the state, firmware of the electronic equipment is upgraded, and the target firmware management program is used for upgrading the firmware management programs except the target firmware management program.

Description

Technical Field

[0001] This disclosure relates to the field of firmware upgrades, and more specifically, to a firmware management method, apparatus, device, and medium for an electronic device. Background Technology

[0002] In existing firmware management solutions for electronic devices, a single firmware management program is typically relied upon. This program is responsible for the initial boot process, maintaining the device's operational status, and performing firmware updates. This architecture centralizes all firmware management functions into a single entity, and its design and operational status directly determine whether the device can boot and be upgraded normally.

[0003] Because only a single firmware management program exists, if this program fails due to code defects, storage corruption, or interruptions during upgrades, the device will lose its critical boot and update capabilities, causing the system to fail to start or become paralyzed. In this situation, restoring device functionality often requires external tools or manual intervention, significantly increasing maintenance costs and system downtime. Summary of the Invention

[0004] One object of this disclosure is to provide a firmware management method for electronic devices that can solve the problem of electronic devices malfunctioning when firmware programs encounter problems.

[0005] According to a first aspect of this disclosure, a firmware management method for an electronic device is provided, wherein the electronic device has multiple independent firmware management programs configured therein, the method comprising: Detect the status of the firmware management program; Based on the state, a target firmware management program is determined to be launched to upgrade the firmware of the electronic device, wherein the target firmware management program is used to upgrade firmware management programs other than the target firmware management program. According to a second aspect of this disclosure, a firmware management device for an electronic device is provided, wherein the electronic device has a plurality of independent firmware management programs, the device comprising: The detection module is used to detect the status of the firmware management program; A determination module is used to determine a target firmware management program to be launched based on the state, so as to upgrade the firmware of the electronic device, wherein the target firmware management program is used to upgrade the firmware management program other than the target firmware management program.

[0006] According to a third aspect of this disclosure, an electronic device is provided, including a processor and a memory, the memory storing computer instructions that, when executed by the processor, implement any of the methods in the first aspect.

[0007] According to a fourth aspect of this disclosure, a storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement any of the methods of the first aspect.

[0008] One technical advantage of this disclosure is that it provides a method for verifying the security and reliability of firmware upgrades. By setting up multiple independent firmware management programs and determining the target program for startup and upgrade based on their status, any program can perform upgrades for other programs. This creates a redundancy and mutual repair mechanism at the firmware management layer. This solution directly addresses the single point of failure problem caused by relying on a single firmware management program in the background technology. It can automatically switch to the normal program to maintain startup capability when a program fails, and achieve firmware self-recovery by relying on the mutual upgrade function between programs. This significantly reduces the risk that the device cannot start due to firmware management program abnormalities or must rely on external tools for repair.

[0009] Other features and advantages of the embodiments of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0010] The accompanying drawings, which form part of this specification, illustrate embodiments of the present disclosure and, together with the specification, serve to explain the principles of the embodiments of the present disclosure.

[0011] Figure 1 This is a flowchart of the firmware management method for the electronic device provided in this application; Figure 2 This is a schematic diagram of the firmware management device for the electronic device provided in this application; Figure 3 This is a schematic diagram of the electronic device provided in this application. Detailed Implementation

[0012] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the invention.

[0013] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0014] Technologies and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such technologies and equipment should be considered part of the instruction manual.

[0015] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0016] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0017] It should be noted that all actions involving the acquisition of signals, information, or data in this embodiment are carried out in compliance with the relevant data protection laws and regulations of the country where the location is situated, and with authorization from the owner of the relevant equipment.

[0018] In one example of this embodiment, a firmware management method for an electronic device is provided. The electronic device has multiple independent firmware management programs. The method includes steps S11-S13. Step S11: Detect the status of the firmware management program; In this embodiment, two or more firmware management programs can be pre-configured within the electronic device. These programs are isolated from each other in terms of storage space and operating logic. For example, the device's non-volatile memory can be divided into multiple partitions, each storing a complete and functionally identical firmware management program code and its related data. They act like multiple independent "administrators" within the device, each possessing the complete capability to boot the device and manage upgrades.

[0019] When the device is powered on or reset, it first checks the status of each firmware management program. Here, "status" primarily refers to the program's integrity and availability. One method is to verify the integrity of the memory area storing the program, for example, by calculating the cyclic redundancy check (CRC) value of its code data and comparing it with a pre-stored correct value. If the check value matches, the program is considered intact and in a normal state; conversely, if the check fails or a read times out, the program is considered to be in an abnormal state. Alternatively, this can be determined by reading specific version flags or status words within the program. This detection process provides the basis for subsequently deciding which program should take over the device.

[0020] Step S12: Determine the target firmware management program to be launched based on the status, so as to upgrade the firmware of the electronic device. The target firmware management program is used to upgrade firmware management programs other than the target firmware management program. Based on the detection of the status of various firmware management programs, the device will determine which program should lead the boot process according to a predetermined set of logic. This selected program becomes the target firmware management program. For example, it can be set to prioritize trying to boot the program stored in the first partition. If the detection finds its status to be normal, it is loaded and executed; if an anomaly is found, the status of the program stored in the second partition is checked, and if it is normal, it is started. This selection mechanism ensures that the device can always boot normally from an available management program entry point.

[0021] In this example, after the target firmware management program starts, it not only handles the normal operation of the device but also updates other firmware within the device. It can also upgrade another firmware management program. This means that the running program has the ability to write to and modify the memory partition where other programs are stored. For example, when the device is running a management program from the first partition, it can receive a new firmware package via the communication interface and then securely write this new firmware to the storage space of the second partition. During this process, the storage area of ​​the currently running program in the first partition is not modified, thus ensuring that the risk of the upgrade operation is isolated. After the write is complete, the newly written firmware data is usually verified to ensure its integrity. Only when the upgrade is confirmed to be successful will a flag or pointer inside the device be updated to indicate that the newly updated version of the program from the second partition should be attempted to boot on the next startup. In this way, multiple firmware management programs form a closed loop of mutual backup and update, greatly enhancing the system's reliability and self-maintenance capabilities.

[0022] This example provides a method for verifying the security and reliability of firmware upgrades. By setting up multiple independent firmware management programs and determining the target program for startup and upgrade based on their status, any program can perform upgrades for other programs. This creates a redundancy and mutual repair mechanism at the firmware management layer. This solution directly addresses the single point of failure problem caused by relying on a single firmware management program in the background technology. It can automatically switch to the normal program to maintain startup capability when a program fails, and achieve firmware self-recovery by relying on the mutual upgrade function between programs. This significantly reduces the risk that the device cannot start due to firmware management program abnormalities or must rely on external tools for repair.

[0023] In one example of this embodiment, determining the target firmware management program to be started based on its state includes: starting the first firmware management program in response to detecting that the state of the first firmware management program is normal; detecting the state of the second firmware management program in response to detecting that the state of the first firmware management program is abnormal, and starting the second firmware management program when the state of the second firmware management program is normal; and starting a minimum functional system or a security recovery program in response to detecting that the states of multiple independent firmware management programs are all abnormal.

[0024] In this example, when determining which firmware management program to launch, the device first checks the status of the first firmware management program. If the check indicates that the program is functioning correctly—that is, its code is complete and expected to run—the device will directly load and launch this program, which will then take over all subsequent management responsibilities. If an anomaly is found in the status of the first program, such as a failure to verify critical data or unresponsiveness, the device will not stop there. It will immediately check the status of the second firmware management program. If the second program passes all checks, including integrity checks, and its status is determined to be normal, then the device will launch this second program as the currently available and reliable alternative.

[0025] Furthermore, testing revealed that all pre-configured, independent firmware management programs were abnormal and unusable. In this situation, the device will not attempt to launch any complete firmware management program, but will instead execute a minimal system or a specific security recovery procedure. This minimal system or recovery procedure typically has only very basic functionality, such as providing a simple communication interface to allow receiving repair commands or new firmware images from the outside. Its core purpose is to preserve the possibility of repair for the device in the worst-case scenario, preventing it from becoming completely "bricked".

[0026] In one example of this embodiment, the method further includes: monitoring the running status of the target firmware management program during its operation; and recording abnormal information and triggering the electronic device to restart in response to an abnormal running status of the target firmware management program, so as to re-execute the step of detecting the status of the firmware management program.

[0027] In this example, after the target firmware management program successfully starts and enters the running phase, its operating status is continuously or periodically monitored to ensure its stable performance. For example, a hardware watchdog timer is used to detect whether the program has deadlocked or crashed; or the program itself periodically sends a "heartbeat" signal to a health check module to indicate that it is still executing its logic normally. Once the monitoring mechanism detects an abnormality in the target program's operating status, such as the watchdog not being triggered for an extended period, the heartbeat signal being lost, or the program actively reporting a serious error, relevant information about this abnormal event, such as the exception type, the time of occurrence, and the program identifier, is recorded in a specific storage area that will not be lost even when power is off. A restart of the electronic device is then proactively triggered.

[0028] After the device restarts, it will again perform the initial status check steps for all firmware management programs. This means that the system will reassess and select a healthy target from all available programs to start based on the latest status. Through this closed-loop mechanism of "monitoring-recording-reselection," the device achieves self-monitoring during operation and automatic recovery after failures, thereby significantly improving long-term operational reliability.

[0029] In one example of this embodiment, the target firmware manager is used to upgrade a firmware manager other than the target firmware manager, including: when the first firmware manager is running, using the first firmware manager to write and upgrade the storage area storing the second firmware manager; when the second firmware manager is running, using the second firmware manager to write and upgrade the storage area storing the first firmware manager.

[0030] In this example, if the device is currently booted by a firmware management program stored in the first partition, this running program can receive update commands and data packets from external sources. It doesn't write this new data to its own first partition, but instead writes it to the partition specifically storing the second firmware management program. Throughout the writing process, the code and data in the first partition remain intact, ensuring the stability of its operation. After the write is complete, an integrity check is typically performed immediately on the newly written content in the second partition, such as calculating its checksum, to confirm that the data was not corrupted during transmission and storage.

[0031] Conversely, if the device is currently being run by the program in the second partition, the roles are reversed. In this case, the running program in the second partition is responsible for receiving updated data and securely writing it to the storage space of the first partition. Similarly, the contents of its own second partition are protected during this process. Regardless of which program performs the upgrade operation, a global flag that determines the device's next boot choice must ultimately be updated. For example, when the program in the first partition successfully upgrades the second partition, it modifies this global flag to point to the second partition. Thus, when the device restarts next time, the status check will detect that the second partition has been updated and is in a normal state, and it will then choose to boot from this new version. Through this cross-upgrade method, the device always retains a usable, known, and healthy older version as a backup, greatly ensuring the security of the upgrade process.

[0032] In one example of this embodiment, the method further includes: associating and storing the abnormal information with the corresponding firmware management program identifier and timestamp; reading and analyzing the stored abnormal information when the device starts up or during a periodic task, and adjusting the preset selection strategy or triggering a predefined maintenance operation based on the analysis results.

[0033] In this example, when the device records operational anomaly information, to facilitate subsequent accurate diagnosis and trend analysis, each record binds the specific anomaly details (e.g., watchdog timeout, memory check error), the identifier of the firmware management program that caused the anomaly (e.g., distinguishable as "Program A" or "Program B"), and the precise time the anomaly occurred. These three elements are then saved as a complete data packet in a dedicated area of ​​non-volatile memory. This is like creating a file with identification information and time and location for each fault. These historical files can be actively read and analyzed at the initial stage of each device startup or during background tasks periodically executed during the main program's operation. For example, analysis might reveal that a specific program has frequently experienced the same type of anomaly recently; or that two programs began showing signs of instability within a similar timeframe.

[0034] Based on these analytical conclusions, the device can intelligently adjust its behavior. One approach is to adjust the startup selection strategy. For example, if analysis shows that program A's reliability has recently declined, even if its current status is normal, its startup priority may be temporarily lowered, prioritizing the startup of the more stable program B. Another approach is to trigger preset maintenance operations. For instance, when analysis determines that a program may have a potential defect, the system can proactively mark the program and attempt to prioritize its repair or replacement in the next upgrade opportunity. In this way, the device not only records faults but also transforms historical information into knowledge for optimizing its own reliability and maintenance efficiency.

[0035] In one example of this embodiment, the target firmware management program is used to upgrade a firmware management program other than the target firmware management program, and further includes: after completing the writing of upgrade data, executing one or more verification processes including integrity verification and functional simulation verification; if all verification processes pass, updating the configuration information used for startup selection and clearing the temporary status mark of the target upgrade area; if any verification process fails, marking the upgrade data as invalid and maintaining the original startup selection configuration unchanged.

[0036] In this example, integrity verification is a fundamental verification, primarily checking the accuracy of the original data written to the storage area. For instance, the system calculates the checksum of the newly written data and compares it with the correct checksum pre-stored in the upgrade package. If they match, it indicates that the data was error-free during transmission and storage and meets basic usability requirements. Functional simulation verification goes a step further, aiming to identify potential execution logic problems in advance. The system loads the core code segment from the new firmware in a controlled, isolated environment and attempts to simulate its execution. This environment typically contains only the necessary hardware abstractions and limited resources, enabling the detection of serious runtime exceptions, instruction errors, or initialization failures in the code without affecting the actual system.

[0037] If all the above verification steps pass successfully, the system will perform the final switchover operation: First, it updates the configuration information used to determine the next boot target, pointing it to the upgraded storage area; then, it clears any temporary markers that may have been set in this area during the upgrade process, restoring it to a stable and usable state. If any verification step fails, the system will abort the upgrade process, mark the newly written firmware data as invalid, and retain the original boot configuration. In this way, the device will still boot to the original, stable firmware version upon the next reboot, completely avoiding situations where the device cannot boot due to upgrade failure. This entire mechanism improves the upgrade success rate while ensuring the continuity of device operation.

[0038] In one example of this embodiment, determining the target firmware management program to be launched based on its status includes: querying the historical running records of each firmware management program, the historical running records including the cumulative running time, the number of historical anomalies and the version number of the last successful run; and determining the target firmware management program to be launched based on the historical running records and status using a weighted scoring algorithm, wherein firmware management programs with fewer historical anomalies or longer cumulative running time are given higher weights.

[0039] In this example, when selecting which firmware management program to launch, not only is its current status checked, but its historical operation record is also referenced. This record typically includes the total stable running time of the program since its inception, the number of anomalies encountered during previous runs, and the version number of its last successful launch and run. A preset weighted scoring algorithm incorporates this historical record along with the currently detected program state into its calculation. The algorithm's rules dictate that programs with a more robust historical record receive a higher score. Specifically, a program with fewer historical anomalies indicates greater past reliability, while a program with a longer cumulative runtime demonstrates proven stability over time. These factors are given higher weight, giving them an advantage in the score. Finally, the firmware management program with the highest weighted score is launched.

[0040] In this example, this approach adds a layer of intelligent optimization logic based on long-term operational experience on top of the simple "normal / abnormal" state judgment. This allows the system to automatically select the one that is considered more stable and reliable to assume management responsibilities when multiple program states are normal, thereby further improving the long-term reliability of system startup.

[0041] This application provides a firmware management device 100 for an electronic device, wherein the electronic device has multiple independent firmware management programs, such as... Figure 2 As shown, it includes: a detection module 101 for detecting the status of the firmware management program; and a determination module 102 for determining the target firmware management program to be started based on the status, so as to upgrade the firmware of the electronic device, wherein the target firmware management program is used to upgrade firmware management programs other than the target firmware management program.

[0042] Optionally, determining the target firmware management program to be started based on the state includes: starting the first firmware management program in response to detecting that the state of the first firmware management program is normal; detecting the state of the second firmware management program in response to detecting that the state of the first firmware management program is abnormal, and starting the second firmware management program when the state of the second firmware management program is normal; and starting a minimum functional system or a security recovery program in response to detecting that the states of multiple independent firmware management programs are all abnormal.

[0043] Optionally, the device further includes: a monitoring module for monitoring the running status of the target firmware management program during its operation; and a response module for recording abnormal information and triggering the electronic device to restart in response to an abnormal running status of the target firmware management program, so as to re-execute the step of detecting the status of the firmware management program.

[0044] Optionally, the target firmware manager is used to upgrade a firmware manager other than the target firmware manager, including: when the first firmware manager is running, using the first firmware manager to write and upgrade the storage area storing the second firmware manager; when the second firmware manager is running, using the second firmware manager to write and upgrade the storage area storing the first firmware manager.

[0045] Optionally, the device further includes: a storage module for storing abnormal information in association with the corresponding firmware management program identifier and timestamp; and an analysis module for reading and analyzing the stored abnormal information when the device starts up or during periodic tasks, and adjusting the preset selection strategy or triggering predefined maintenance operations based on the analysis results.

[0046] Optionally, the target firmware manager is used to upgrade firmware managers other than the target firmware manager, and also includes: after completing the upgrade data writing, performing one or more verification processes including integrity verification and functional simulation verification; if all verification processes pass, updating the configuration information used for boot selection and clearing the temporary status flag of the target upgrade area; if any verification process fails, marking the upgrade data as invalid and maintaining the original boot selection configuration unchanged.

[0047] Optionally, determining the target firmware management program to be launched based on its status includes: querying the historical operation records of each firmware management program, the historical operation records including the cumulative runtime, the number of historical anomalies and the version number of the last successful run; and determining the target firmware management program to be launched based on the historical operation records and status through a weighted scoring algorithm, wherein firmware management programs with fewer historical anomalies or longer cumulative runtime are given higher weights.

[0048] This application also provides an electronic device 200, as shown in FIG3, including a processor 201 and a memory 202. The memory 202 stores computer instructions. When the computer instructions are executed by the processor 201, they implement any one of the firmware management method embodiments of the above-mentioned electronic device and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0049] This application also provides a storage medium storing computer instructions. When executed by a processor, these computer instructions implement any one of the firmware management embodiments of the above-described electronic device and achieve the same technical effect. To avoid repetition, further details are omitted here. The various embodiments in this disclosure are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and apparatus embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0050] The foregoing has described specific embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0051] Embodiments of this disclosure may be systems, methods, and / or computer program products. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of the embodiments of this disclosure.

[0052] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0053] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0054] Computer program instructions used to perform the operations of embodiments of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized based on state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the embodiments of this disclosure.

[0055] Various aspects of embodiments of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0056] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0057] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0058] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It will be known to those skilled in the art that implementation in hardware, implementation in software, and implementation in a combination of software and hardware are equivalent.

[0059] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A firmware management method for an electronic device, characterized in that, The electronic device has multiple independent firmware management programs, and the method includes: Detect the status of the firmware management program; Based on the state, a target firmware management program is determined to be launched to upgrade the firmware of the electronic device, wherein the target firmware management program is used to upgrade firmware management programs other than the target firmware management program.

2. The method according to claim 1, characterized in that, The process of determining the target firmware management program to be launched based on the state includes: In response to the detection that the first firmware management program is in a normal state, the first firmware management program is started; In response to detecting an abnormal state of the first firmware management program, the state of the second firmware management program is detected, and the second firmware management program is started when the state of the second firmware management program is normal; In response to the detection that the states of the multiple independent firmware management programs are all abnormal, a minimum functional system or a security recovery procedure is initiated.

3. The method according to claim 1, characterized in that, The method also includes During the operation of the target firmware management program, the running status of the target firmware management program is monitored; In response to an abnormal running state of the target firmware management program, the abnormal information is recorded and the electronic device is restarted to re-execute the step of detecting the state of the firmware management program.

4. The method according to claim 1, characterized in that, The target firmware manager is used to upgrade firmware managers other than the target firmware manager, including: When the first firmware management program is running, it is used to write to and upgrade the storage area storing the second firmware management program. When the second firmware management program is running, it is used to write to and upgrade the storage area where the first firmware management program is stored.

5. The method according to claim 3, characterized in that, The method further includes: The abnormal information is associated with and stored in relation to the corresponding firmware management program identifier and timestamp; When the device starts up or during a periodic task, the stored abnormal information is read and analyzed, and the preset selection strategy is adjusted or a predefined maintenance operation is triggered based on the analysis results.

6. The method according to claim 4, characterized in that, The target firmware manager is used to upgrade firmware managers other than the target firmware manager, and further includes: After completing the upgrade data writing, execute one or more verification processes, including integrity checks and functional simulation verification. Once all verification processes have passed, update the configuration information used to launch the selected system and clear the temporary status marker for the target upgrade region. If any verification process fails, the upgrade data will be marked as invalid, and the original startup selection configuration will remain unchanged.

7. The method according to claim 1, characterized in that, The process of determining the target firmware management program to be launched based on the state includes: Query the historical running records of each firmware management program. The historical running records include the cumulative running time, the number of historical anomalies, and the version number of the last successful run. Based on the historical operation records and the status, a weighted scoring algorithm is used to determine the target firmware management program to be launched, wherein firmware management programs with fewer historical anomalies or longer cumulative runtime are given higher weights.

8. A firmware management device for an electronic device, characterized in that, The electronic device has multiple independent firmware management programs, and the device includes: The detection module is used to detect the status of the firmware management program; A determination module is used to determine a target firmware management program to be launched based on the state, so as to upgrade the firmware of the electronic device, wherein the target firmware management program is used to upgrade the firmware management program other than the target firmware management program.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer instructions that, when executed by the processor, implement the method according to any one of claims 1-7.

10. A storage medium, characterized in that, It stores computer instructions, which, when executed by a processor, implement the steps of the method described in any one of claims 1-7.

Images