Firmware application upgrading method and device, electronic equipment and storage medium

Abstract

The present disclosure relates to the technical field of artificial intelligence, in particular to edge computing and software upgrade library technology, which can be applied in a cloud computing scenario, and more particularly to a firmware application upgrade method and device, an electronic device and a storage medium. The specific implementation scheme is as follows: when the first program triggers the upgrade process, the current upgrade state of the upgrade process is obtained; the first program determines whether the action corresponding to the current upgrade state is executed by the second program; in response to the action being executed by the second program, the first program instructs the second program to execute the corresponding action based on the current upgrade state until the current upgrade state flows to the terminal state. The present disclosure provides a firmware application upgrade method and device, an electronic device and a storage medium. Through the division of labor and cooperation between the first program and the second program, the upgrade process and the specific upgrade action are decoupled, which can flexibly adjust the specific content of the upgrade action and has strong expansibility; and breakpoint recovery can be realized, and the process of firmware upgrade is more stable.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, specifically to edge computing and software upgrade library technology, which can be applied in cloud computing scenarios, and particularly to firmware application upgrade methods, devices, electronic devices and storage media. Background Technology

[0002] In the context of intelligent edge devices, the delivery is typically a unified hardware and software package, referred to as firmware. As products iterate, the firmware also needs upgrades and updates. However, since the intelligent edge devices are already in use in the field, we cannot require all devices to be returned to the factory for upgrades. Therefore, a remote firmware upgrade method needs to be designed. Existing firmware upgrade methods generally involve mailing the firmware back to the manufacturer, who then performs the upgrade locally. The upgrade process and specific actions are performed as a single, integrated process. Because the existing firmware upgrade program is integrated, it becomes fixed and cannot be flexibly modified with different versions. Furthermore, existing firmware upgrade operations cannot be interrupted; once interrupted, they cannot self-heal and return to a stable state. Summary of the Invention

[0003] This disclosure provides a firmware application upgrade method, apparatus, device, and storage medium.

[0004] According to a first aspect of this disclosure, a firmware application upgrade method is provided, comprising:

[0005] When the first program triggers the upgrade process, it obtains the current upgrade status of the upgrade process;

[0006] The first program determines whether the action corresponding to the current upgrade state is to be executed by the second program;

[0007] In response to the action being performed by the second program, the first program instructs the second program to perform the corresponding action based on the current upgrade state until the current upgrade state transitions to the final state.

[0008] According to a second aspect of this disclosure, a firmware application upgrade apparatus is provided, comprising:

[0009] The acquisition module is configured to acquire the current upgrade status of the upgrade process when the upgrade process is triggered by the first program;

[0010] The first judgment module is configured to determine, through the first program, whether the action corresponding to the current upgrade state is to be executed by the second program.

[0011] The instruction module is configured to, in response to the action being executed by the second program, instruct the second program via the first program to execute the corresponding action based on the current upgrade state until the current upgrade state transitions to the final state.

[0012] According to a third aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in any one of the above technical solutions.

[0013] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method according to any one of the above-described technical solutions.

[0014] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method according to any one of the above-described technical solutions.

[0015] This disclosure provides a firmware application upgrade method, apparatus, device, and storage medium. By dividing the work between a first program and a second program, the upgrade process and the specific upgrade actions are decoupled. The first program executes the upgrade process, and the second program executes the specific upgrade actions. This allows for flexible adjustment of the specific content of the upgrade actions and provides strong scalability. Furthermore, after the first program triggers the execution of the upgrade process, it will eventually run to the final state, with low dependence on the central system. Offline upgrades are possible, and even after the device restarts, the firmware of the edge device can be transferred to a stable state, enabling breakpoint recovery.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0017] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0018] Figure 1 This is a schematic diagram of the steps of the firmware application upgrade method in the embodiments of this disclosure;

[0019] Figure 2 This is an overall diagram of the firmware application upgrade method in the embodiments of this disclosure;

[0020] Figure 3 This is a schematic block diagram of the firmware application upgrade device in the embodiments of this disclosure;

[0021] Figure 4 This is a schematic block diagram of an example electronic device in an embodiment of this disclosure. Detailed Implementation

[0022] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0023] This disclosure provides a firmware application upgrade method, such as Figure 1 As shown, it includes:

[0024] Step S101: When the first program triggers the upgrade process, it obtains the current upgrade status. This disclosure pre-designs multiple upgrade statuses, including a series of transition states such as downloading, download successful, download failed, upgrading, upgrade successful, upgrade failed and rollback in progress, rollback successful, rollback failed, cancel, cancellation successful, and cancellation failed. Figure 2 As shown, the initial state is "Downloading," followed by two states: download successful or download failed. If the download is successful, the program enters the upgrade state; subsequently, it has two states: upgrade successful or upgrade failed and rollback in progress; and if the upgrade fails and rollback is in progress, it has two states: rollback successful or rollback failed. Therefore, when executing the upgrade process, the first program needs to determine which upgrade state the process has reached. This way, if the upgrade is interrupted and resumed, it knows from which state to start execution. For example, if the current upgrade state is "Download successful," meaning the upgrade package has been successfully downloaded and passed verification, the upgrade logic can be executed based on the downloaded upgrade package.

[0025] In step S102, the first program determines whether the action corresponding to the current upgrade state is to be executed by the second program. In this disclosure, the actions executed by the first program and the second program are different. For example, according to the state transition rules shown in Table 1, actions 1, 2, 3, 4, 10, and 11 are executed by the first program, while actions 5, 6, 7, 8, and 9 are executed by the second program. Therefore, after obtaining the current upgrade state, the first program determines whether the action corresponding to the current upgrade state is to be executed by the second program. For example, if the current upgrade state is "upgrade failed, rollback in progress," then the first program determines that the rollback action is to be executed by the second program.

[0026]

[0027] Table 1. State transition conditions and actions during firmware application upgrades

[0028] In step S103, in response to the action being executed by the second program, the first program instructs the second program to execute the corresponding action based on the current upgrade state. Before instructing the second program to execute the corresponding action, the first program first determines whether the second program is running. Only if the second program is running can the first program be further instructed to execute the corresponding action. If the second program is running, there is no need to restart it; the first program is directly commanded to execute the specific upgrade logic based on the current upgrade state, such as upgrade failure and rollback, rollback success, rollback failure, etc., executing the corresponding action based on the current state. If the second program is not running, the first program starts the second program and instructs it to execute the corresponding action based on the current upgrade state until the current upgrade state transitions to a final state (e.g., upgrade success, rollback success, rollback failure). The first program can add a scheduled task to periodically start the second program, with "period" meaning starting the second program at regular intervals (e.g., 20s, 30s, 1 minute, etc.). This way, if the second program exits unexpectedly, periodic starting ensures that restarting the second program will allow it to continue execution, promptly restoring the upgrade action and ensuring the stability of the upgrade process.

[0029] This disclosure, through the aforementioned technical solution, ensures that after the first program triggers and executes the upgrade process, it will eventually reach the final state. It has minimal dependence on the call center, allows for offline upgrades, and guarantees that the edge device firmware can transition to a stable state even after a device restart, preventing upgrade failures due to network instability that could render the device unusable. The upgrade process is triggered and controlled by the first program, which instructs the second program to execute the specific upgrade logic. This decouples the upgrade process and upgrade logic. The first program's upgrade process can remain fixed, while the second program's upgrade logic can be flexibly adjusted with version changes, resulting in greater scalability.

[0030] As an optional implementation, before obtaining the current upgrade status of the upgrade process when triggering the upgrade process, the first program further includes: the first program receiving an upgrade task, which instructs the first program to trigger the upgrade process. In this embodiment, the first program must first be triggered to start running the upgrade process. This can be achieved by the first program's call center notifying the first program to start the upgrade process, the first program actively triggering the upgrade process, or the first program periodically starting to execute the upgrade process.

[0031] As an optional implementation, when the first program triggers the upgrade process, obtaining the current upgrade status includes: the first program obtaining the status file corresponding to the upgrade process; the status file is used to record the upgrade status after each upgrade action is performed in the upgrade process; and the first program obtaining the current upgrade status based on the status file. As shown in Table 1, after the first and second programs complete their respective actions, they record the corresponding upgrade status in the status file, which is jointly maintained by the first and second programs. The status file is an upgrade-related database containing the current upgrade status. The first and second programs communicate with the status file to obtain the current upgrade status and execute the corresponding actions. When the upgrade process is interrupted, the first program can start from the previously interrupted state when the upgrade process restarts, without having to start the upgrade process from scratch, thus achieving breakpoint recovery. Even if the upgrade is abnormally interrupted in the middle, it can continue to flow to the final state (upgrade successful, rollback successful, rollback failed) based on this state.

[0032] As an optional implementation, the first program obtains the status file corresponding to the upgrade process, including: determining whether the upgrade process is being triggered for the first time; if the upgrade process is being triggered for the first time, the first program obtains and updates the status file locally; if the upgrade process is not being triggered for the first time, the first program loads the status file from the server. If the upgrade process is being triggered for the first time, it means that the upgrade status corresponding to the upgrade process has not yet been recorded, and the original status file needs to be obtained and the current upgrade status updated. If the first program is not being triggered for the first time, it means that this is not the first time the upgrade process has been executed, and an existing status file can be loaded directly.

[0033] As an optional implementation, the first program instructs the second program to perform corresponding actions based on the current upgrade status, including:

[0034] When the current upgrade status of the upgrade process is "download successful", the first program calls the corresponding upgrade logic interface of the second program and instructs the second program to perform the upgrade action through the upgrade logic interface.

[0035] When the current upgrade status of the upgrade process is rollback, the first program calls the rollback logic interface corresponding to the second program and instructs the second program to perform the rollback operation through the rollback logic interface.

[0036] When the current upgrade status of the upgrade process is canceled, the first program calls the corresponding cancellation interface of the second program, and instructs the second program to cancel the upgrade action and restore the current version.

[0037] In this embodiment, the upgrade logic, rollback logic, and cancellation logic of the second program can be customized and modified to support the fixed entry point call of the first program and maintain the local state file according to the agreement.

[0038] As an optional implementation, after the first program instructs the second program to perform the corresponding action based on the current upgrade status, it further includes: the second program updating the current upgrade status. The first program only controls the overall upgrade process and does not concern itself with the upgrade logic of the second program. Therefore, after performing the corresponding action, the second program needs to update the status file promptly to record the latest upgrade status. The first program can understand the current upgrade status through the status file.

[0039] As an optional implementation, the final state includes any of the following: upgrade successful; rollback failed; rollback successful; cancellation successful; cancellation failed. The first program will control the upgrade process until the final state is reached. When the first program determines that the current upgrade state is the final state, the first program cancels the scheduled task and does not start the second program.

[0040] As an optional implementation, after the first program determines whether the action corresponding to the current upgrade state is to be executed by the second program, it further includes: in response to the action not being executed by the second program, the first program executes the action corresponding to the current upgrade state. As shown in Table 1, the actions executed by the first program and the second program are different. For example, in the state transition rules shown in Table 1, actions 1, 2, 3, 4, 10, and 11 are executed by the first program, while actions 5, 6, 7, 8, and 9 are executed by the second program. After executing the corresponding action, the first program also records the latest state in the state file. By having the first program and the second program jointly maintain the state file, the current upgrade state can be retrieved from the state file at any time when the upgrade process is interrupted, and tasks can be assigned based on the current upgrade state, with each program executing its own responsible steps.

[0041] As an optional implementation, the first program performs the actions corresponding to the current upgrade state, including:

[0042] When the upgrade process is currently in the "downloading" state, the first step is to download the upgrade package and verify its MD5 hash (Message-Digest Algorithm). Before upgrading the firmware, it's typically necessary to download the upgrade package and verify its MD5 hash. If the verification passes, the download is successful; otherwise, it fails, and the upgrade package is unusable.

[0043] When the current upgrade status is "download failed", it means that the MD5 checksum of the upgrade package failed, and the first program cleans up the upgrade package.

[0044] When the current upgrade status is "cancellation successful," the first program terminates the upgrade process and reports the current upgrade status to the call center. The first program can receive a cancellation upgrade command from the call center and instruct the second program to cancel the upgrade.

[0045] When the current upgrade status is "cancelled and failed," it indicates that the upgrade is complete, and the first program reports the current upgrade status to the call center. The first program reports the latest status to the call center after executing each action. The first program controls the overall upgrade process. After triggering the upgrade process, it will eventually reach the final state. It has minimal dependence on the call center, can perform offline upgrades, and ensures that the edge device firmware can flow to the final state even after a device restart, guaranteeing that upgrade failures due to network instability will not render the device unusable.

[0046] This disclosure also provides a firmware application upgrade device, such as Figure 3 As shown, it includes:

[0047] The acquisition module 301 is configured to acquire the current upgrade status of the upgrade process when the first program triggers the upgrade process. This disclosure pre-designs multiple upgrade statuses, including downloading, download successful, download failed, upgrading, upgrade successful, upgrade failed and rollback in progress, rollback successful, rollback failed, canceled, cancellation successful, and cancellation failed, among other transitional states. When the first program executes the upgrade process, it first needs to determine which upgrade status the process has transitioned to. This allows it to know from which status to resume execution after an interruption. For example, if the current upgrade status is download successful, meaning the upgrade package has been successfully downloaded and passed verification, the upgrade logic can be executed based on the downloaded upgrade package.

[0048] The first judgment module 302 is configured to determine, through a first program, whether the action corresponding to the current upgrade state is to be executed by a second program. In this disclosure, the actions executed by the first program and the second program are different. For example, as shown in the state transition rules in Table 1, actions 1, 2, 3, 4, 10, and 11 are executed by the first program, while actions 5, 6, 7, 8, and 9 are executed by the second program. Therefore, after obtaining the current upgrade state, the first program determines whether the action corresponding to the current upgrade state is to be executed by the second program. For example, if the current upgrade state is "upgrade failed, rollback in progress," then the first program determines that the rollback action is to be executed by the second program.

[0049] The instruction module 303 is configured to respond to actions executed by the second program. The first program instructs the second program to perform corresponding actions based on the current upgrade state until the current upgrade state transitions to the final state. Before instructing the second program to perform the corresponding action, the first program first determines whether the second program is running. If the second program is running, it can then be instructed to perform the corresponding action. If the second program is running, it does not need to be restarted; it directly commands the second program to execute specific upgrade logic based on the current upgrade state, such as upgrade failure and rollback, rollback success, rollback failure, etc., executing the corresponding action based on the current state. If the second program is not running, the first program starts the second program and instructs it to perform the corresponding action based on the current upgrade state until the current upgrade state transitions to the final state (e.g., upgrade success, rollback success, rollback failure). The first program can add a scheduled task to periodically start the second program, specifying that the second program starts at regular intervals (e.g., 20s, 30s, 1 minute, etc.). This ensures that if the second program exits unexpectedly, periodic startup guarantees that it can resume execution upon restart, promptly restoring the upgrade process and ensuring its stability.

[0050] This disclosure, through the aforementioned technical solution, ensures that after the first program triggers and executes the upgrade process, it will eventually reach the final state. It has minimal dependence on the call center, allows for offline upgrades, and guarantees that the edge device firmware can transition to a stable state even after a device restart, preventing upgrade failures due to network instability that could render the device unusable. The upgrade process is triggered and controlled by the first program, which instructs the second program to execute the specific upgrade logic. This decouples the upgrade process and upgrade logic. The first program's upgrade process can remain fixed, while the second program's upgrade logic can be flexibly adjusted with version changes, resulting in greater scalability.

[0051] As an optional implementation, before the acquisition module 301 acquires the current upgrade status of the upgrade process through the first program, it further includes a receiving module, configured to receive an upgrade task through the first program, the upgrade task being used to instruct the first program to trigger the upgrade process. In this embodiment, the first program must first be triggered to start running the upgrade process. This can be achieved by the first program's call center notifying the first program to start the upgrade process, the first program actively triggering the start of the upgrade process, or the first program periodically starting to execute the upgrade process.

[0052] As an optional implementation, when the upgrade process is triggered, the first program of module 301 obtains the current upgrade status of the upgrade process, including: the first program obtaining the status file corresponding to the upgrade process; the status file is used to record the upgrade status after each upgrade action is performed in the upgrade process; and the first program obtains the current upgrade status based on the status file. As shown in Table 1, after the first program and the second program complete the corresponding actions, they will record the corresponding upgrade status in the status file. The status file is jointly maintained by the first program and the second program. The status file is an upgrade-related database, which stores the current upgrade status. The first program and the second program communicate with the status file to obtain the current upgrade status and execute the corresponding actions. When the upgrade process is interrupted, the first program can start from the previously interrupted state when the upgrade process is restarted, without having to start the upgrade process from the beginning, thereby realizing breakpoint recovery. Even if the upgrade is abnormally interrupted in the middle, it can continue to flow to the final state (upgrade successful, rollback successful, rollback failed) based on this state.

[0053] As an optional implementation, the first program obtains the status file corresponding to the upgrade process, including: determining whether the upgrade process is being triggered for the first time; if the upgrade process is being triggered for the first time, the first program obtains and updates the status file locally; if the upgrade process is not being triggered for the first time, the first program loads the status file from the server. If the upgrade process is being triggered for the first time, it means that the upgrade status corresponding to the upgrade process has not yet been recorded, and the original status file needs to be obtained and the current upgrade status updated. If the first program is not being triggered for the first time, it means that this is not the first time the upgrade process has been executed, and an existing status file can be loaded directly.

[0054] As an optional implementation, the first program instructs the second program to perform corresponding actions based on the current upgrade status, including:

[0055] When the current upgrade status of the upgrade process is "download successful", the first program calls the corresponding upgrade logic interface of the second program and instructs the second program to perform the upgrade action through the upgrade logic interface.

[0056] When the current upgrade status of the upgrade process is rollback, the first program calls the rollback logic interface corresponding to the second program and instructs the second program to perform the rollback operation through the rollback logic interface.

[0057] When the current upgrade status of the upgrade process is canceled, the first program calls the corresponding cancellation interface of the second program, and instructs the second program to cancel the upgrade action and restore the current version.

[0058] In this embodiment, the upgrade logic, rollback logic, and cancellation logic of the second program can be customized and modified to support the fixed entry point call of the first program and maintain the local state file according to the agreement.

[0059] As an optional implementation, after the first program instructs the second program to perform the corresponding action based on the current upgrade status, it further includes: the second program updating the current upgrade status. The first program only controls the overall upgrade process and does not concern itself with the upgrade logic of the second program. Therefore, after performing the corresponding action, the second program needs to update the status file promptly to record the latest upgrade status. The first program can understand the current upgrade status through the status file.

[0060] As an optional implementation, the final state includes any of the following: upgrade successful; rollback failed; rollback successful; cancellation successful; cancellation failed. The first program will control the upgrade process until the final state is reached. When the first program determines that the current upgrade state is the final state, the first program cancels the scheduled task and does not start the second program.

[0061] As an optional implementation, after the first program determines whether the action corresponding to the current upgrade state is to be executed by the second program, it further includes: in response to the action not being executed by the second program, the first program executes the action corresponding to the current upgrade state. As shown in Table 1, the actions executed by the first program and the second program are different. For example, in the state transition rules shown in Table 1, actions 1, 2, 3, 4, 10, and 11 are executed by the first program, while actions 5, 6, 7, 8, and 9 are executed by the second program. After executing the corresponding action, the first program also records the latest state in the state file. By having the first program and the second program jointly maintain the state file, the current upgrade state can be retrieved from the state file at any time when the upgrade process is interrupted, and tasks can be assigned based on the current upgrade state, with each program executing its own responsible steps.

[0062] As an optional implementation, the first program performs the actions corresponding to the current upgrade state, including:

[0063] When the upgrade process is currently in the "downloading" state, the first step is to download the upgrade package and verify its MD5 hash. Before upgrading the firmware, it's usually necessary to download the upgrade package and verify its MD5 hash. If the verification passes, the download is successful; otherwise, it fails, and the upgrade package is unusable.

[0064] When the current upgrade status is "download failed", it means that the MD5 checksum of the upgrade package failed, and the first program cleans up the upgrade package.

[0065] When the current upgrade status is "cancellation successful," the first program terminates the upgrade process and reports the current upgrade status to the call center. The first program can receive a cancellation upgrade command from the call center and instruct the second program to cancel the upgrade.

[0066] When the current upgrade status is "cancelled and failed," it indicates that the upgrade is complete, and the first program reports the current upgrade status to the call center. The first program reports the latest status to the call center after executing each action. The first program controls the overall upgrade process. After triggering the upgrade process, it will eventually reach the final state. It has minimal dependence on the call center, can perform offline upgrades, and ensures that the edge device firmware can flow to the final state even after a device restart, guaranteeing that upgrade failures due to network instability will not render the device unusable.

[0067] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0068] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0069] Figure 4 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0070] like Figure 4 As shown, device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 402 or a computer program loaded from storage unit 408 into random access memory (RAM) 403. RAM 403 may also store various programs and data required for the operation of device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0071] Multiple components in device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of monitors, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0072] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as firmware application upgrade methods. For example, in some embodiments, the firmware application upgrade method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the firmware application upgrade method described above may be performed. Alternatively, in other embodiments, the computing unit 401 may be configured to perform firmware application upgrade methods by any other suitable means (e.g., by means of firmware).

[0073] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0074] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0075] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0076] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0077] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0078] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0079] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0080] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A firmware application upgrade method, comprising: When the first program triggers the upgrade process, it obtains the current upgrade status of the upgrade process; The first program determines whether the action corresponding to the current upgrade state is to be executed by the second program; In response to the action being executed by the second program, the first program instructs the second program to execute the corresponding action based on the current upgrade state until the current upgrade state transitions to the final state; Wherein, when the first program triggers the upgrade process, obtaining the current upgrade status of the upgrade process includes: The first program obtains a status file corresponding to the upgrade process; the status file is used to record the upgrade status after each upgrade action is performed in the upgrade process; after the first program and the second program complete the corresponding action, they will record the corresponding upgrade status in the status file, and the status file is jointly maintained by the first program and the second program. The first program obtains the current upgrade status based on the status file.

2. The method according to claim 1, further comprising, before the first program obtains the current upgrade status of the upgrade process: The first program receives an upgrade task, which instructs the first program to trigger the upgrade process.

3. The method according to claim 1, wherein, The first program obtains the status file corresponding to the upgrade process, including: The first program determines whether the upgrade process is being triggered for the first time; In response to the upgrade process being triggered for the first time, the first program retrieves the status file from the local machine and updates it; In response to the upgrade process not being triggered for the first time, the first program loads the status file from the server.

4. The method according to claim 1, wherein, The first program instructs the second program to perform the corresponding action based on the current upgrade status, including: When the current upgrade status is a successful download status, the first program calls the upgrade logic interface corresponding to the second program, and instructs the second program to perform the upgrade action through the upgrade logic interface. When the current upgrade state is a rollback state, the first program calls the rollback logic interface corresponding to the second program, and instructs the second program to perform the rollback operation through the rollback logic interface. When the current upgrade status is canceled, the first program calls the cancellation interface corresponding to the second program, and instructs the second program to cancel the upgrade action and restore the current version.

5. The method according to claim 4, after the first program instructs the second program to perform the corresponding action based on the current upgrade state, it further includes: The second program updates the current upgrade status.

6. The method according to claim 1, wherein, The first program starts the second program by: Add a scheduled task to the first program; The first program periodically starts the second program based on the scheduled task.

7. The method according to any one of claims 1-6, wherein, The termination state includes any of the following: download failed; upgrade successful; rollback failed; rollback successful. Cancel the success status; Cancel the failure status.

8. The method according to claim 1, after the first program determines whether the action corresponding to the current upgrade state is executed by the second program, it further includes: In response to the action not being performed by the second program, the first program performs the action corresponding to the current upgrade state.

9. The method according to claim 8, wherein, The first program performs the action corresponding to the current upgrade state, including: When the current upgrade status is "downloading", the first program downloads the upgrade package and verifies the MD5 hash of the upgrade package; When the current upgrade status is download failure, it means that the MD5 checksum of the upgrade package has failed, and the first program cleans up the upgrade package; When the current upgrade status is a cancellation success status, the first program ends the upgrade process and reports the current upgrade status to the call center; When the current upgrade status is cancellation failed, it means that the upgrade has been completed, and the first program reports the current upgrade status to the call center.

10. A firmware application upgrade device, comprising: The acquisition module is configured to acquire the current upgrade status of the upgrade process when the upgrade process is triggered by the first program; The first judgment module is configured to determine, through the first program, whether the action corresponding to the current upgrade state is to be executed by the second program. The instruction module is configured to, in response to the action being executed by the second program, instruct the second program through the first program to execute the corresponding action based on the current upgrade state until the current upgrade state transitions to the final state; The acquisition module, through the first program, acquires the current upgrade status of the upgrade process when the upgrade process is triggered, including: The first program obtains a status file corresponding to the upgrade process; the status file is used to record the upgrade status after each upgrade action is performed in the upgrade process; after the first program and the second program complete the corresponding action, they will record the corresponding upgrade status in the status file, and the status file is jointly maintained by the first program and the second program. The first program obtains the current upgrade status based on the status file.

11. The apparatus according to claim 10, further comprising, before the acquisition module acquires the current upgrade status of the upgrade process through the first program: The receiving module is configured to receive an upgrade task through the first program, the upgrade task being used to instruct the first program to trigger an upgrade process.

12. The apparatus according to claim 11, wherein, The acquisition module acquires the status file corresponding to the upgrade process through the first program, including: The first program determines whether the upgrade process is being triggered for the first time; In response to the upgrade process being triggered for the first time, the first program retrieves the status file from the local machine and updates it; In response to the upgrade process not being triggered for the first time, the first program loads the status file from the server.

13. The apparatus according to claim 10, wherein, The first program instructs the second program to perform the corresponding action based on the current upgrade status, including: When the current upgrade status is a successful download status, the first program calls the upgrade logic interface corresponding to the second program, and instructs the second program to perform the upgrade action through the upgrade logic interface. When the current upgrade state is a rollback state, the first program calls the rollback logic interface corresponding to the second program, and instructs the second program to perform the rollback operation through the rollback logic interface. When the current upgrade status is canceled, the first program calls the cancellation interface corresponding to the second program, and instructs the second program to cancel the upgrade action and restore the current version.

14. The apparatus according to claim 13, wherein, After the first program instructs the second program to perform the corresponding action based on the current upgrade state, it further includes: The second program updates the current upgrade status.

15. The apparatus according to claim 10, wherein, The first program starts the second program by: Add a scheduled task to the first program; The first program periodically starts the second program based on the scheduled task.

16. The apparatus according to any one of claims 10-15, wherein, The termination state includes any of the following: download failed; upgrade successful; rollback failed; rollback successful. Cancel the success status; Cancel the failure status.

17. The apparatus according to claim 10, after the first program determines whether the action corresponding to the current upgrade state is executed by the second program, it further includes: In response to the action not being performed by the second program, the first program performs the action corresponding to the current upgrade state.

18. The apparatus according to claim 17, wherein, The first program performs the action corresponding to the current upgrade state, including: When the current upgrade status is "downloading", the first program downloads the upgrade package and verifies the MD5 hash of the upgrade package; When the current upgrade status is download failure, it means that the MD5 checksum of the upgrade package has failed, and the first program cleans up the upgrade package; When the current upgrade status is a cancellation success status, the first program ends the upgrade process and reports the current upgrade status to the call center; When the current upgrade status is cancellation failed, it means that the upgrade has been completed, and the first program reports the current upgrade status to the call center.

19. An electronic device comprising: 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 of any one of claims 1-9.

20. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

21. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.

Images