Program upgrading method, computer system, program upgrading device and program product

Abstract

The invention discloses a program upgrading method, a computer system, a program upgrading device and a program product.The method comprises the steps that under the condition that it is determined that a first subprogram stored in a first subprogram partition is in a to-be-upgraded state, first subprogram firmware for upgrading the first subprogram is obtained, the first subprogram partition is any one of N subprogram partitions arranged in a computer system, and the subprogram partition is used for storing subprograms; and loading the first subprogram firmware into the first subprogram partition to upgrade the first subprogram. Through the program upgrading method and device, the technical problem that more storage space is occupied by program upgrading in related technologies is solved, and the effect of upgrading the program under the condition that the storage space is saved is achieved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the computer field, in particular, to a program upgrading method and computer system, program upgrading apparatus, and program product. BACKGROUND

[0002] In a computer system, program upgrading is a key link to ensure continuous optimization of device performance and functions. Currently, for program upgrading, a commonly used method is to download and write program firmware through an external system or device, and to set a redundant backup partition inside the device to cope with abnormal interruption that may occur during the upgrading process, so as to ensure that the system can recover from the error state. However, these methods will cause additional burden on the originally limited storage space, increase the hardware cost of the device, and limit the effective use of storage resources. SUMMARY

[0003] Embodiments of the present application provide a program upgrading method and computer system, program upgrading apparatus, and program product to at least solve the technical problem of program upgrading occupying more storage space in the related art.

[0004] According to an aspect of embodiments of the present application, a program upgrading method is provided, including: in a case where it is determined that a first subprogram stored in a first subprogram partition is in a to-be-upgraded state, acquiring first subprogram firmware for upgrading the first subprogram, wherein the first subprogram partition is any one of N subprogram partitions set in a computer system, the subprogram partition is configured to store a subprogram, and N is a natural number greater than or equal to 1; and loading the first subprogram firmware into the first subprogram partition to upgrade the first subprogram.

[0005] According to another aspect of embodiments of the present application, a computer system is also provided, including: a processor, a main program partition configured to store a main program, and N subprogram partitions configured to store N subprograms, the processor is configured to implement the steps of the method according to any one of claims 1 to 8 when executing the main program, and N is a natural number greater than or equal to 1.

[0006] According to another aspect of embodiments of the present application, a program upgrading apparatus is also provided, including: a first acquisition module configured to, in a case where it is determined that a first subprogram stored in a first subprogram partition is in a to-be-upgraded state, acquire first subprogram firmware for upgrading the first subprogram, wherein the first subprogram partition is any one of N subprogram partitions set in a computer system, the subprogram partition is configured to store a subprogram, and N is a natural number greater than or equal to 1; and a first loading module configured to load the first subprogram firmware into the first subprogram partition to upgrade the first subprogram.

[0007] According to a further aspect of the embodiments of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program. The computer program is configured to be executed by a processor to perform the steps in any of the method embodiments.

[0008] According to a further aspect of the embodiments of the present application, a computer program product or a computer program is provided, and the computer program product or the computer program includes computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the steps in any of the method embodiments.

[0009] According to a further aspect of the embodiments of the present application, an electronic device is provided, and the electronic device includes a memory and a processor. The memory stores a computer program, and the processor is configured to execute the computer program to perform the steps in any of the method embodiments.

[0010] According to the embodiments of the present application, because N subprogram partitions are provided in the computer system, each subprogram has a corresponding subprogram partition, so that in a case where it is determined that the first subprogram stored in the first subprogram partition is in a to-be-upgraded state, the first subprogram is upgraded only by acquiring the first subprogram firmware for upgrading the first subprogram, and the entire computer system does not need to be upgraded. In addition, each subprogram has its own partition, and the subprogram partition can be completely upgraded in a normal and abnormal upgrading state without additional backup, so that the storage resource can be more effectively utilized, and the space waste caused by redundant backup is avoided. Therefore, the technical problem that the program upgrading occupies more storage space in the related art can be solved, and the effect of upgrading the program while saving the storage space is achieved. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 is an application scenario schematic diagram of a program upgrading method according to an embodiment of the present application;

[0012] Figure 2 is a flow schematic diagram of an optional program upgrading method according to an embodiment of the present application;

[0013] Figure 3 is a schematic diagram of an optional device firmware storage area according to an embodiment of the present application;

[0014] Figure 4 is a flow schematic diagram of a boot loader in the optional example;

[0015] Figure 5 is a flow schematic diagram of an upgraded subprogram in the optional example;

[0016] Figure 6 is a structural block diagram of an optional program upgrading method and device according to an embodiment of the present application;

[0017] Figure 7 is a structural block diagram of a computer system of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to enable persons skilled in the art to better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0019] It should be noted that the terms “first”, “second”, etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms “include” and “have” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0020] According to an aspect of an embodiment of the present application, a program upgrading method is provided. Optionally, in the present embodiment, the above-mentioned program upgrading method can be applied in, but is not limited to, a hardware environment as shown in Figure 1 The server 104 can be connected with the terminal device 102 through a network, and can be used to provide services (for example, application services, etc.) for the terminal device 102 or a client installed on the terminal device 102, and a database can be set on the server 104 or independently of the server 104, and used to provide data storage services for the server 104.

[0021] The network can include, but is not limited to, at least one of the following: a wired network, a wireless network. The wired network can include, but is not limited to, at least one of the following: a wide area network, a metropolitan area network, a local area network. The wireless network can include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI), Bluetooth. The terminal device 102 can be, but is not limited to, a personal computer (PC), a mobile phone, a tablet computer, and the like. The server 104 can be, but is not limited to, a cloud server, a server cluster, or other server types.

[0022] The program upgrading method of the embodiments of the present application can be executed by the server 104, or by the terminal device 102, or by the server 104 and the terminal device 102 jointly. The terminal device 102 executing the program upgrading method of the embodiments of the present application can also be executed by a client installed thereon.

[0023] Taking the server 104 executing the program upgrading method in the embodiments as an example, Figure 2 is a flow diagram of an optional program upgrading method according to an embodiment of the present application, as Figure 2 shown, the flow of the method can include the following steps:

[0024] Step S202, in a case where it is determined that a first subprogram stored in a first subprogram partition is in a to-be-upgraded state, acquiring first subprogram firmware for upgrading the first subprogram, wherein the first subprogram partition is any one of N subprogram partitions set in a computer system, the subprogram partition is used to store a subprogram, and N is a natural number greater than or equal to 1;

[0025] Step S204, loading the first subprogram firmware into the first subprogram partition to upgrade the first subprogram.

[0026] Optionally, the program upgrade method in this embodiment can be applied to many fields such as Internet of Things, smart home, industrial automation, automotive electronics, medical devices, remote monitoring systems, etc., and is especially suitable for scenarios that run under network conditions, need to update firmware regularly, and the upgrade process cannot be interrupted. For example, Internet of Things devices are deployed outdoors or in locations that are difficult to manually intervene, and are upgraded remotely through a network to ensure their long-term stable operation and functional updates. The upgrade method can effectively deal with upgrade failures caused by sudden power failure or network instability, automatically recover and complete the upgrade, avoiding the inconvenience and cost of manual on-site maintenance. For another example, automated production line equipment, numerical control machine tools, robot control systems, etc. in a factory, the normal operation of these devices directly affects production efficiency and safety, and the upgrade method can update part of the functions of the devices without interrupting the operation of the production line. Even if a fault occurs during the upgrade process, it can automatically recover, reducing downtime and maintenance costs.

[0027] Optionally, the main program partition in this embodiment is a specific storage area for storing the main program, which is used for functions such as starting, initializing, managing the upgrade of subprograms, and calling. The main program mainly includes the basic functions of the computer system, upgrade functions, and program loading functions, and this partition is generally not upgraded. Optionally, when the firmware boot startup program has multi-address startup and booting capability, the main program partition can be configured with a backup partition to upgrade and reinforce the software functions in the main program partition.

[0028] Optionally, the first subprogram in this embodiment is one of the programs executed by the main program, which is used to implement a specific function or application. The first subprogram refers to a subprogram that needs to be upgraded. The N subprogram partitions are composed of one or several independent subprogram partitions, and these subprograms are compiled and built as address-independent programs that can be dynamically loaded. When the business functions / properties are decoupled and split into multiple independent application sub-partitions, the purpose of on-demand upgrade can be achieved.

[0029] Optionally, the upgrade status in this embodiment is information stored in the device, which is used to indicate whether each subprogram partition needs to be upgraded. The upgrade status can be a flag bit, a record in a file or database, which tells the main program which subprograms currently have new firmware versions available for download and installation.

[0030] Optionally, the first subprogram firmware in this embodiment is a new software package for upgrading the first subprogram, including updated program code and data, which can be a binary file, a compressed package, or any other format suitable for storage and transmission.

[0031] Optionally, in the normal operation of the device, the code in the main program partition is usually unchanged, which is responsible for the system management and firmware upgrade process of the device. The program in the first sub-program partition can be upgraded periodically as needed for functional expansion, performance optimization or security updates. The check of the upgrade state and the acquisition of the firmware are key steps in the entire upgrade process, ensuring that the upgrade process is triggered only when a real upgrade is needed, avoiding unnecessary network traffic and consumption of storage resources.

[0032] For example, in one specific embodiment, assume that there is an intelligent security device, such as a network camera, which needs to upgrade its image processing sub-program to enhance the clarity of night video and reduce the false alarm rate. The specific steps include:

[0033] S1, identify and start the first sub-program (such as the image processing sub-program), and check the upgrade state of the first sub-program during the start process.

[0034] S2, once it is confirmed that the first sub-program is in the upgrade pending state, the first sub-program firmware will be acquired through the network. This may involve communication with the server to download the firmware through the Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS) or other protocols.

[0035] S3, the network module of the device (usually part of an embedded device) establishes a connection with the server and requests the latest firmware version of the first sub-program.

[0036] S4, the server responds to the request and transmits the firmware data to upgrade the first sub-program.

[0037] Through the embodiments provided in the present application, since N sub-program partitions are set in the computer system, each sub-program has a corresponding sub-program partition, so that in the case where it is determined that the first sub-program stored in the first sub-program partition is in the upgrade pending state, only the first sub-program firmware for upgrading the first sub-program is acquired to upgrade the first sub-program, and there is no need to upgrade all programs in the computer system. Moreover, each sub-program has its own partition, which can ensure that the sub-program partition can be completely upgraded in normal and abnormal upgrade states without additional backup, thereby more effectively utilizing storage resources and avoiding space waste caused by redundant backup. Therefore, the technical problem of program upgrade occupying a large amount of storage space in the related art can be solved, and the effect of upgrading the program while saving storage space can be achieved.

[0038] In one example embodiment, in step S202, in the case where it is determined that the first subprogram stored in the first subprogram partition is in the to-be-upgraded state, the first subprogram firmware for upgrading the first subprogram is acquired, including: starting the first subprogram by executing a main program stored in a main program partition, wherein the main program partition is a partition set in the computer system, the first subprogram is a program allowed to be called by the main program, and the main program has the capability of upgrading the first subprogram; acquiring the upgrading state of the first subprogram when the first subprogram is started, and in the case where it is determined that the first subprogram is in the to-be-upgraded state, acquiring the first subprogram firmware.

[0039] Optionally, the main program partition in the present embodiment can be one or multiple. Optionally, in a computer system (for example, an embedded system) or an Internet of Things device, the main program partition contains core code necessary for device startup and operation, as well as logic for managing other functional modules (i.e., subprograms). The first subprogram can be a program responsible for a specific function or service, such as network communication, data processing, user interface control, etc. The process of the main program starting the first subprogram involves the following steps:

[0040] S1, the main program first performs hardware initialization when starting, ensuring that all necessary device resources (such as Central Processing Unit (CPU), memory, network interface, storage, etc.) are in a usable state.

[0041] S2, the main program reads information about the subprogram partition, including the address, size, and whether it is upgradeable, etc. metadata. These information are stored in the partition table, which is the basis for starting and managing subprograms.

[0042] S3, the main program locates the first subprogram partition according to the partition description information, and loads the code and data of the subprogram from the non-volatile storage (such as Flash) to the system Random Access Memory (RAM). If the memory supports XIP (Execute In Place), the instructions can be read directly from the memory for execution, without the need to copy the instructions to the RAM first.

[0043] S4, the loaded subprogram code may need to be address relocated to ensure that its position in the RAM is compatible with its position in the firmware. In addition, the main program will also call the initialization function of the subprogram, such as setting the initial value of the variable, allocating resources, checking dependencies, etc., to prepare for the running of the subprogram.

[0044] S5, after initialization is complete, the main program calls the entry point of the first subprogram, starting the execution of the subprogram code. This usually means jumping to the subprogram's main function or other predefined starting point, starting the execution of the subprogram logic.

[0045] S6, the main program may also be responsible for monitoring the running state of the first subprogram, ensuring its normal operation, and performing resource management such as allocating additional memory, managing network connections, etc. when needed.

[0046] Optionally, the code in the main program partition in this embodiment is usually unchanged, which is responsible for the system management and firmware upgrade process of the device. The program in the first subprogram partition may be upgraded regularly as needed for functional expansion, performance optimization or security updates. The check of the upgrade state and the acquisition of the firmware are key steps in the entire upgrade process, ensuring that the upgrade process is triggered only when a real upgrade is needed, avoiding unnecessary network traffic and storage resource consumption.

[0047] For example, in a specific embodiment, assume there is a smart security device such as a network camera that needs to upgrade its image processing subprogram to enhance night video clarity and reduce false alarm rate. The main program in the device is responsible for coordinating and executing the entire upgrade process. The specific steps include:

[0048] S1, the main program reads the partition description information, identifies and starts the first subprogram (such as the image processing subprogram), and during the startup process, the main program checks the upgrade state of the first subprogram.

[0049] S2, by reading the upgrade state partition, the main program determines whether the first subprogram partition is marked as a to-be-upgraded state. If so, continue to execute the upgrade process; if not, consider that the current version is the latest and does not need further upgrade.

[0050] S3, once it is confirmed that the first subprogram is in the to-be-upgraded state, the main program will acquire the first subprogram firmware through the network. This may involve communication with the server, downloading the firmware through HTTP, HTTPS or other protocols.

[0051] S4, the network module of the device establishes a connection with the server and requests the latest firmware version of the first subprogram.

[0052] S5, the server responds to the request and transmits firmware data, and the main program of the device is responsible for receiving and storing these data, which will usually be temporarily saved in a secure area for subsequent write operations.

[0053] The first subprogram is started by the main program, and the upgrade state of the first subprogram is obtained when the first subprogram is started, so that only the subprogram that needs to be updated is upgraded, unnecessary data transmission is avoided, network resource usage is reduced, and the upgrade efficiency of the device is improved.

[0054] In one example embodiment, when the first subprogram is started, the upgrade state of the first subprogram is obtained, and when it is determined that the first subprogram is in the to-be-upgraded state, the firmware of the first subprogram is obtained, including: when the first subprogram is started, reading a first upgrade marker of the first subprogram from an upgrade marker partition, wherein the upgrade marker partition is a partition in the computer system that is set to store upgrade markers of programs; when the first upgrade marker is used to indicate that the first subprogram is in the to-be-upgraded state, reading first partition information of the first subprogram partition from a partition table partition, wherein the partition table partition is a partition in the computer system that is set to store partition information; and obtaining the firmware of the first subprogram based on the first partition information.

[0055] Optionally, the upgrade marker partition in the embodiment is used to store upgrade state markers of all subprograms, each marker corresponding to a subprogram partition and used to indicate whether the corresponding subprogram is ready for upgrade or is currently in an upgrade state. If the marker is set to a to-be-upgraded state, it means that the program in the subprogram partition needs to be updated.

[0056] Optionally, the first upgrade marker in the embodiment is a marker that is used to identify the upgrade state of the first subprogram partition and that tells the main program whether the first subprogram needs to be upgraded. The marker can be a binary value (for example, 0 indicating no need to upgrade and 1 indicating a need to upgrade), a string (such as NEED_UPDATE), or another form of state indicator.

[0057] Optionally, the partition table partition in the embodiment is an area that stores detailed information about all partitions (including the main program partition, the subprogram partition, the upgrade marker partition, and other data partitions), such as the starting address, size, and type of the partition. The main program uses the information to identify and access different partitions.

[0058] Optionally, the first partition information of the first subprogram partition in the embodiment refers to specific details about the first subprogram partition that are stored in the partition table partition, including but not limited to the storage location (starting address), size, and whether to support XIP or PIC technology features.

[0059] Optionally, the upgrade marker partition and the partition table partition are present to make the upgrade process more orderly and controllable. At each boot of the device, the main program first checks the upgrade marker partition to determine which sub-programs need to be upgraded. This avoids unnecessary checks on each sub-program partition, saving boot time. At the same time, the partition table partition provides specific information of each sub-program partition, which is very important for the main program, as it needs to know how to correctly access and operate these partitions.

[0060] For example, in one specific embodiment, assume a smart air conditioner with multiple sub-program partitions, such as temperature regulation program, air purification program, user interface display program, etc. Assume that the temperature regulation program, i.e. the first sub-program, needs to be upgraded. The specific implementation steps include:

[0061] S1, the main program reads the upgrade markers of all sub-programs in the upgrade marker partition during device boot. It is found that the upgrade marker corresponding to the first sub-program (temperature regulation program) is set to the "to be upgraded" state.

[0062] S2, the main program then accesses the partition table partition to find the first partition information related to the first sub-program partition, and determines the storage location of the first sub-program and its characteristics (such as whether it supports XIP).

[0063] S3, based on the information of the first sub-program partition, the main program downloads the latest firmware of the first sub-program (temperature regulation program) through the network. The download process may include breakpoint resume, compressed transmission and encryption protection of the firmware to ensure the integrity and security of the firmware data.

[0064] S4, write the downloaded firmware data to the first sub-program partition to replace the original version of the program.

[0065] This embodiment can accurately know which sub-program needs to be upgraded by reading the first upgrade marker of the first sub-program from the upgrade marker partition. The upgrade marker and partition information make the upgrade process more systematic and automated, reducing the need for manual intervention, while also reducing the complexity of the upgrade operation and improving the overall success rate of the upgrade. And using the upgrade marker partition instead of redundant storage space effectively saves storage resources.

[0066] In one example embodiment, before reading the first upgrade marker of the first sub-program from the upgrade marker partition, the method further comprises: in the case of receiving an upgrade request, storing the first upgrade marker into the upgrade marker partition, wherein the upgrade request is used to request to upgrade the first sub-program.

[0067] Optionally, the upgrade request in this embodiment comes from an operation instruction outside or inside the device, indicating that a certain subprogram (such as the first subprogram) of the device needs to be upgraded. This request can be initiated by the user or automatically generated by the device when the system detects that a new version is available.

[0068] Optionally, the first upgrade flag in this embodiment is stored in the upgrade flag partition, and the flag corresponding to the first subprogram is used to indicate whether the subprogram is in the upgrade-ready state. Generally, if there is no upgrade request, the first upgrade flag will be set to "un-upgraded"; once an upgrade request is received, the first upgrade flag will be changed to "upgrade-ready".

[0069] Optionally, in the program upgrade process, the upgrade request is the key point that triggers the entire upgrade process, which can come from the following ways:

[0070] User interface operation: the user manually triggers the upgrade of a certain subprogram through the interface of the device or the remote management platform, and the system generates a corresponding upgrade request at this time.

[0071] Automatic upgrade trigger: the device may have a preset upgrade mechanism to check the firmware version on the cloud or server regularly, and when it detects a newer firmware than the current running version, the system automatically generates an upgrade request.

[0072] Fault detection-based upgrade: during the operation of the device, if it detects that a subprogram has a fault or abnormal behavior, the system will generate an upgrade request to try to fix these problems through upgrade.

[0073] The role of the first upgrade flag is to synchronize the device state to the ready-to-upgrade state after receiving the upgrade request. In this way, when the device starts next time, the main program will read the partition description information at the same time, and read the first upgrade flag to determine whether the first subprogram needs to be upgraded. This synchronization mechanism ensures the accuracy and reliability of the upgrade process, avoiding the loss or neglect of upgrade instructions.

[0074] For example, in a specific embodiment, assume that there are multiple subprograms in the intelligent lighting system, such as brightness adjustment program, color temperature control program, energy consumption monitoring program, etc. The user initiates an upgrade request for the brightness adjustment program (i.e. the first subprogram) on the system management platform to obtain a more energy-efficient firmware version. The specific implementation steps include:

[0075] S1, the user clicks the "brightness adjustment program upgrade" button on the management platform, which is converted into an upgrade request signal and sent to the intelligent lighting system.

[0076] S2, after the system receives the upgrade request, a "to-be-upgraded" mark is set for the brightness adjustment program in the upgrade mark partition, so that the main program can identify the state next time the device is started.

[0077] S3, the updated first upgrade mark is written into the upgrade mark partition, and at this time, the brightness adjustment program is marked as a subprogram that needs to be upgraded.

[0078] S4, when the device is started next time, the main program reads the information in the partition table partition and also checks the upgrade mark partition. When it is found that the upgrade mark of the brightness adjustment program is "to-be-upgraded", the upgrade process is entered to prepare to download and install new firmware.

[0079] In the embodiment, the first upgrade mark is stored in the upgrade mark partition when the upgrade request is received, so that the upgrade operation can be automatically identified and performed next time the program is started, the efficiency of program upgrade is greatly improved, and the upgrade omission or failure caused by human operation error is avoided.

[0080] In an example embodiment, the first subprogram firmware is obtained based on the first partition information, including: performing a verification operation on the first subprogram partition based on the first partition information, wherein the verification operation includes at least one of the following: integrity verification of the first subprogram partition, legality verification of the first subprogram partition; and in a case where a verification result of the verification operation indicates that the first subprogram partition passes the verification, the first subprogram firmware is obtained.

[0081] Optionally, the first partition information in the embodiment includes the specific storage location, size, type of the first subprogram partition, and any additional parameters for accessing and managing the partition, which is the basis for the main program to identify and operate the first subprogram partition.

[0082] Optionally, the integrity verification in the embodiment is a means for checking whether data is damaged or modified in the transmission or storage process. In the upgrade process, the checksum (such as Cyclic Redundancy Check (CRC), Message-Digest Algorithm 5 (MD5), or Secure Hash Algorithm 256 (SHA256)) of the first subprogram partition is calculated and compared with the known checksum to confirm whether the new firmware is complete and intact.

[0083] Optionally, the legality verification in this embodiment is a method to ensure that the firmware comes from a legitimate source, preventing malicious software or illegal firmware from being installed. This usually involves digital signature or certificate verification, and the firmware can only pass the legality verification if it has the correct digital signature or certificate.

[0084] For example, in one specific embodiment, assume that the device needs to upgrade its network protocol processing subprogram (i.e., the first subprogram). The specific implementation steps include:

[0085] S1. The main program reads the relevant information of the first subprogram partition (the network protocol processing subprogram partition) from the partition table partition, including its storage location, size, and whether it supports XIP or PIC technology.

[0086] S2. The main program calculates the hash value of the current firmware in the first subprogram partition using the MD5 algorithm, and compares it with the hash value provided on the server.

[0087] If the hash values match, it means that the firmware in the current partition is intact; if they do not match, it means that the firmware may have been damaged during the last upgrade, in which case the upgrade process needs to be restarted.

[0088] S3. The main program checks the digital signature of the first subprogram firmware, verifies whether the signature is valid, and whether it matches the pre-set public key. If the signature verification passes, it is considered that the firmware comes from a reliable source, and the upgrade process can continue; otherwise, the firmware will be considered illegal, and the main program will refuse to install it and may attempt to download the firmware from a backup server.

[0089] S4. After the first subprogram partition passes the integrity verification and the legality verification, the main program determines the upgrade state and downloads the latest network protocol processing subprogram firmware from the server. After the firmware is verified to be correct, it is stored in the specified location of the first subprogram partition, ready to replace the current program.

[0090] This embodiment ensures that the downloaded firmware is consistent with the original version on the server and has not been damaged or modified in network transmission, thereby avoiding upgrade failure due to data damage. The legality verification further ensures that the firmware comes from a legitimate source and has not been maliciously tampered with. Through these two verifications, it can be ensured that only correct and safe firmware will be installed, thereby avoiding potential risks and system instability.

[0091] In one example embodiment, loading the first subprogram firmware into the first subprogram partition to upgrade the first subprogram includes loading the first subprogram firmware into the first subprogram partition by executing a main program stored in a main program partition to upgrade the first subprogram, wherein the main program partition is a partition provided in the computer system, and the first subprogram is a program allowed to be called by the main program.

[0092] Optionally, the upgrading of the first subprogram in this embodiment involves writing new firmware into the corresponding first program partition to replace the old version of firmware. This process is performed by the main program in the main program partition, which not only ensures the automation of the upgrading process, but also performs error handling and recovery mechanisms when necessary, ensuring the stability and reliability of the upgrading process.

[0093] For example, in one specific embodiment, in a smart home hub control device, it needs to upgrade its environment sensor processing subprogram (i.e. the first subprogram). The device has a main program partition and multiple subprogram partitions for different functions. The specific implementation steps include:

[0094] S1, the main program detects that the first upgrade flag of the first subprogram partition is in the "to be upgraded" state, i.e. the environment sensor processing subprogram needs to be upgraded.

[0095] S2, the main program downloads the latest environment sensor processing subprogram firmware from the network and stores it in the temporary storage area of the device after downloading. The main program executes the upgrade script and starts writing the new firmware into the first subprogram partition.

[0096] S3, the new firmware is written into the storage area of the environment sensor processing subprogram according to the format and order agreed in advance, covering the original firmware code and data.

[0097] S4, after the writing process is completed, the main program performs integrity verification on the new firmware to ensure that the data is not damaged or missing. At the same time, legality verification is also performed to verify whether the firmware comes from a trusted source to prevent the injection of malicious software.

[0098] S5, if the new firmware passes all verifications, the main program updates the first upgrade flag to set it to the "upgrade completed" state, indicating that the upgrade is successful. If the verification fails, the main program will keep and update the first upgrade flag of the first subprogram partition, indicating that the upgrade fails, and re-upgrade the first subprogram.

[0099] S6, after completing all necessary verifications and updating the flag, the main program restarts the environment sensor processing subprogram so that the device can collect and process environment data using the upgraded function.

[0100] The embodiment loads new firmware directly in the first subprogram partition, thus saving the need to backup firmware in RAM and saving memory space.

[0101] In one example embodiment, after the first subprogram is upgraded by loading the main program stored in the main program partition into the first subprogram partition, the method further comprises at least one of the following: deleting the first upgrade marker of the first subprogram from the upgrade marker partition, wherein the upgrade marker partition is a partition in the computer system configured to store upgrade markers of programs, and the first upgrade marker is used to indicate that the first subprogram is in a state of being upgraded; and restarting the upgraded subprogram stored in the first subprogram partition.

[0102] Optionally, the upgrade marker partition in the embodiment is used to record the upgrade status of each subprogram in the system. Whenever a subprogram is marked as needing to be upgraded, the corresponding upgrade marker is written into this partition.

[0103] Optionally, the first upgrade marker in the embodiment indicates the upgrade status of the first subprogram. When the first subprogram is marked as “to be upgraded”, the marker is created or updated, and is deleted or updated to “upgrade completed” after the upgrade is successful.

[0104] For example, in one specific embodiment, an intelligent unmanned aerial vehicle control system needs to periodically upgrade its flight stability control subprogram (i.e. the first subprogram) to improve flight performance and safety. The specific implementation steps include:

[0105] S1, the main program confirms that the new firmware is successfully written into the first subprogram partition, and passes the integrity check and the legality check, confirming that the upgrade is successful.

[0106] S2, the main program accesses the upgrade marker partition and finds the first upgrade marker corresponding to the flight stability control subprogram.

[0107] Delete or update the marker to change its status from “to be upgraded” to “upgrade completed”, which ensures that the system will not repeat the upgrade of the same subprogram in the future.

[0108] S3, the main program restarts the flight stability control subprogram in the first subprogram partition. During this process, the main program may need to stop all tasks related to the first subprogram that are currently running, then load the upgraded new firmware, and finally initialize and start the new version of the flight stability control subprogram.

[0109] S4, once the upgraded subprogram successfully runs, the main program performs some basic function tests to confirm whether the upgrade has achieved the desired effect. After the test passes, the main program may report to the user interface that the upgrade is successful, or send a status update to the remote server indicating that the flight stability control subprogram has been upgraded and is running normally.

[0110] The embodiment can release storage space in time by deleting the first upgrade mark of the first subprogram from the upgrade mark partition; and restart the upgraded subprogram stored in the first subprogram partition to confirm whether the upgrade is successful in time.

[0111] In an example embodiment, the above method further comprises: in the case where it is determined that the main program stored in the main program partition is in a state to be upgraded, backing up the main program to a backup program partition to store a backup main program of the main program in the backup program partition, wherein the main program partition and the backup program partition are both partitions provided in the computer system; obtaining main program firmware of the main program by executing the backup main program, and loading the main program firmware into the main program partition to upgrade the main program.

[0112] Optionally, the main program firmware in the embodiment is a new version of code and data set for upgrading or replacing the existing program in the main program partition. It includes improved algorithms, fixed errors, added functions or enhanced security features.

[0113] The upgrade process of the main program partition is more complex and sensitive than the upgrade of the subprogram, because it directly affects the starting ability of the device and the stability of the system. In order to avoid catastrophic errors that may occur during the upgrade process, the following strategies can be used:

[0114] Backup strategy: when upgrading, download the new main program to the main program backup partition, and after the download is completed and the integrity and legality are verified, update the main program firmware from the backup partition to the main program partition by the boot program, reducing the recovery process of the upgrade failure.

[0115] Dual-partition strategy: in some system designs, the main program partition will contain a backup partition in advance, but in order to avoid the consumption of additional storage space, a more flexible backup program partition is used for backup in this proposal.

[0116] Hot backup and cold backup: hot backup refers to backup when the main program is running, while cold backup refers to backup when the system is turned off or the main program is stopped running. The backup strategy in this proposal is more inclined to cold backup, that is, temporarily backing up the main program before the system is ready for upgrade or during the upgrade process.

[0117] Optionally, when the main program in the main program partition is marked as "to be upgraded" state, the entire upgrade process will go through the following steps:

[0118] S1, cold backup main program: Before system restart or entering upgrade mode, the main program will backup the current running version to the backup program partition completely.

[0119] S2, get main program firmware: The system downloads the latest main program firmware from the remote server, which usually involves verifying the integrity and legality of the firmware.

[0120] S3, according to the steps of downloading firmware to the backup partition first, and then updating from the backup partition to the main partition, which can maximize the problem of avoiding upgrade errors that cause the device to fail to start.

[0121] S4, check the upgrade result: After upgrading, the system will perform integrity check and function verification on the new version of the main program to ensure successful upgrade and stability.

[0122] S5, restore or clear backup: If the upgrade is successful, the cold backup in the backup program partition will be cleared to release storage space; if the upgrade fails, the system will automatically restore to the backup main program to ensure normal operation of the device.

[0123] The embodiment backs up the main program to the backup program partition, so that even if there are errors in the upgrade process or defects in the upgraded main program, the system can still roll back to the backup state, avoiding the risk of device failure due to main program upgrade failure.

[0124] According to another aspect of the embodiment of the present application, a computer system is also provided, comprising: a processor, a main program partition for storing a main program, and N sub-program partitions for storing N sub-programs, the processor being configured to execute the main program to implement the steps of the method in the above embodiment, and N being a natural number greater than or equal to 1.

[0125] Optionally, the system further comprises at least one of the following: an upgrade marker partition for storing upgrade markers of the sub-programs; a partition table partition for storing partition information of the main program partition and the N sub-program partitions; a backup program partition for storing a backup main program of the main program.

[0126] Optionally, the upgrade marker partition in the embodiment is used to store upgrade state markers of all sub-programs, each marker corresponding to a sub-program partition, and being used to indicate whether the corresponding sub-program is ready for upgrade or is currently in an upgrade state. If the marker is set to "to be upgraded" state, it means that the program in the sub-program partition needs to be updated.

[0127] Optionally, the partition table partition in the embodiment is a region that stores detailed information about all partitions, including the main program partition, the subprogram partition, the upgrade marker partition, and other data partitions, such as the starting address, size, type, and the like of the partition. The main program uses this information to identify and access different partitions.

[0128] Optionally, the backup program partition is a specially configured storage area in an embedded system or computer device, and its main function is to save a complete copy of the main program before the main program partition is upgraded or the firmware is updated. This design strategy is a key component of the device self-recovery upgrade method, which aims to ensure that the system can quickly fall back to a stable state before the upgrade in case of any problems during or after the upgrade, thereby maintaining the basic operation and function of the device.

[0129] The program upgrade method in the embodiment of the application will be explained below in conjunction with an optional example.

[0130] The program upgrade method in the optional example is an embedded system self-recovery upgrade method, which is executed in an embedded system. The device firmware storage area in the embedded system is divided into multiple partitions. As shown in the figure, Figure 3 the device firmware storage area is split into a main program partition and a plurality of subprogram partitions. Among them, the main program partition is used to store the resident main program, mainly including system basic functions, upgrade functions, and program loading functions, and this partition is generally not upgraded; optionally, when the firmware boot startup program has multi-address startup and booting capability, the main program partition can be configured with a backup partition to upgrade and reinforce the software functions in the main program partition. The partition table partition is used to record the partition division information of the storage medium, and the main program reads the information recorded in this partition to complete the verification, loading, and upgrading of the subprogram. The subprogram partition is composed of one or a plurality of independent subprogram partitions, and these subprograms are compiled and built as dynamically loadable address-independent programs; when the business functions / attributes are decoupled and split into multiple independent application sub-partitions, the purpose of on-demand upgrade can be achieved. The upgrade marker partition is used to mark the current upgrade state. Other data partitions, such as the backup program partition, can also be included.

[0131] The embedded system self-recovery upgrade method in the optional example mainly includes a startup loading program, an upgrade subprogram, and a compiled and built subprogram.

[0132] Figure 4 is a flowchart of the startup loading program in the optional example, as shown in Figure 4 the flow of the startup loading program can include the following steps:

[0133] Step S401, after the device is powered on or restarted, the main program (usually the boot program or part of the operating system kernel of the device) begins to execute.

[0134] Step S402, the primary task of the main program is to load the partition table from the partition description information, which details the location, size, type and status of all partitions, including the main program partition itself, sub-program partitions, backup program partitions, upgrade marker partitions and other data partitions.

[0135] The main program parses the partition table to understand the current state of each partition, such as whether it is in the upgrade state, whether it needs to load a specific sub-program, etc.

[0136] At this stage, the main program also initializes the necessary hardware resources and network communication capabilities to prepare for possible online upgrades.

[0137] The main program begins to traverse each sub-program partition information in the partition table, checking the status of each sub-program partition to ensure their integrity and legality.

[0138] Step S403, for each sub-program partition, the main program first checks whether it is marked as an upgrade state.

[0139] Step S404, if the partition is in the upgrade state, the main program will perform integrity (such as through CRC check) and legality verification on its existing firmware. Legality verification usually involves checking the signature or certificate of the firmware to confirm its source and prevent the injection of malicious code.

[0140] Step S405, if the sub-program partition's storage medium supports XIP (execute in place), and the verification is successful, the main program can choose to only process the data segment that needs to be relocated (such as.data and.bss), while preserving the code segment and read-only data segment for execution in place. This can save RAM space, which is particularly important for resource-constrained devices.

[0141] Step S406, once the verification is passed, the main program loads the sub-program into memory (if it is not XIP) or ensures the correct execution path of the code segment and read-only data segment under XIP conditions, thus preparing to execute the corresponding sub-program.

[0142] If an exception is found during the verification process of any sub-program partition, such as firmware damage or verification failure, the main program will start the exception handling process. For the exception sub-program partition, the main program will not attempt to load the existing firmware, but will automatically jump to the upgrade process of the sub-program. This may include downloading new firmware, verifying new firmware, writing new firmware to the partition, and clearing the upgrade marker to indicate that the upgrade is complete.

[0143] During the upgrade process, the main program updates the upgrade marker partition, recording the sub-programs being upgraded and the progress of the upgrade, so that even if the device suddenly loses power during the upgrade process, the upgrade can continue from the breakpoint at the next start-up.

[0144] Step S407, after all sub-program partitions have been checked and upgraded if necessary, and all sub-programs have been loaded, the main program finally starts the application program or user interface of the device.

[0145] The main program checks the status of all sub-program partitions again, confirming that they are all in the ready or updated state. After all sub-programs are ready, the main program will start the application program of the device, making the device enter its normal use state, providing the expected functions and services.

[0146] Through the above process, the device can achieve robust self-recovery upgrade, minimizing the impact of upgrade failure on device operation, while also avoiding long service interruptions caused by the upgrade process, improving the reliability and user experience of the device.

[0147] Figure 5 is the flowchart of the upgrade sub-program in this optional example, as shown in Figure 5 The flow of the upgrade sub-program can include the following steps:

[0148] Step S501, before the upgrade flow starts, it is necessary to determine that sub-program x needs to be upgraded. This step is usually performed by the main program, which updates the status information of sub-program x in the upgrade marker partition, marking it as "to be upgraded". The main program accesses the upgrade marker partition and modifies the upgrade status of sub-program x from "completed" or "unchanged" to "to be upgraded", which is the trigger condition for the subsequent upgrade flow.

[0149] Step S502, in some cases, the device may need to restart to ensure the smooth progress of the upgrade flow, especially when the storage medium does not support XIP (execution in place), or the code segment and read-only data segment of the sub-program need to be relocated in memory to perform the upgrade operation.

[0150] If the storage medium of sub-program partition x supports XIP, and the code segment and read-only data segment before the upgrade have not been relocated in memory, the device may need to restart to ensure that execution starts from the new partition state, which helps to prevent interference from old code during the upgrade process.

[0151] On the contrary, if the code segment and read-only data segment before the upgrade have been relocated in memory, the device does not need to restart, and the main program can directly proceed to the subsequent upgrade flow, as the execution environment of the code is ready.

[0152] Step S503, once the device is in the upgradeable state, the main program will download the new subprogram x firmware from the network or pre-set storage and write it into the storage partition corresponding to the subprogram x. The main program uses the network capability of the device to download the latest firmware file of the subprogram x from the designated server or cloud storage. After the download is completed, the new firmware will be written into the storage partition of the subprogram x, replacing the original firmware data.

[0153] Step S504, after the firmware is written, the main program will perform integrity check (such as CRC, MD5 or SHA check) and legality verification (such as digital signature verification) to ensure that the new firmware has not been tampered with or damaged.

[0154] If the check fails, it indicates that the firmware may have problems, at which time the main program will re-label the subprogram x as the upgrade pending state and attempt to re-download the firmware, repeating steps b) and c) until success.

[0155] Step S505, after the firmware is successfully downloaded, written and verified, the device needs to perform the final restart or reload to make the new firmware effective.

[0156] In the simplest case, the device will directly restart, causing all subprograms to be reloaded from the storage medium, including the upgraded subprogram x. Restarting ensures that the device runs in a completely new state after upgrading.

[0157] If the code segment and read-only data segment of the subprogram have been relocated in the memory in the above steps, the upgraded subprogram x and any associated subprograms need to be unloaded and stopped from the memory first. Then, the main program will reload the latest version of these subprograms to ensure that they run in the correct memory location, and finally start the application program.

[0158] Through these detailed steps, the device can autonomously manage its firmware upgrade process, ensuring the integrity of the upgrade and the stability of the device's operation even in poor network conditions or limited hardware resources. This not only enhances the self-maintenance capability of the device, but also improves user satisfaction and the market competitiveness of the device.

[0159] The process of subprogram compilation and construction includes:

[0160] 1) Use Keil MDK to build:

[0161] Keil MDK is an integrated development environment (IDE) widely used in embedded system development. To make the output of the subprogram an address-independent dynamic loader, specific compilation and linking configurations need to be made in the project settings.

[0162] Enable Ropi and Rwpi options: Ropi (Read Only, Position Independent) and Rwpi (Read Write, Position Independent) options are used to create read-only and read-write data segments that are position-independent. In Keil MDK, open the project file (usually.uvproj or.uvprojx), go to Target Settings -> Linker -> Command Line, and add --rorwxip --rwxwpi (for Ropi and Rwpi) to the Linker command line to enable these features. This ensures that the code and data segments in the output ELF file can be executed at any address without the need for relocation.

[0163] 2) Build with GCC:

[0164] GCC (GNU Compiler Collection) is a collection of open-source compilation tools for multiple programming languages. When building address-independent programs, the main approach is to add specific options during the compilation and linking stages.

[0165] Compilation parameter -fPIC: The GCC compiler uses the -fPIC (Position-Independent Code) option to generate position-independent code. This means that the compiled object code can be loaded and executed in different virtual address spaces, regardless of its loading address.

[0166] Linking parameter -shared: During the linking stage, use the -shared option to link multiple object files into a shared library (.so file). Such libraries can be loaded into the process's address space at runtime through dynamic loading. For embedded system subprograms, this can be seen as creating a dynamic link library, allowing subprograms to run at different address locations without conflicts.

[0167] Subprograms built by the above method have the following advantages: Dynamic loading: Address-independent subprograms can be dynamically loaded into memory at runtime, started or stopped as needed, providing flexibility for on-demand upgrades. Easy to upgrade: Subprograms are independent of the main program and can be upgraded separately, avoiding the complexity and time-consuming nature of recompiling the entire system. Storage efficiency: No additional backup storage space is required, reducing the occupation of device storage resources, especially in resource-constrained embedded devices. Enhanced security: Position-independent code and data segments reduce the potential attack surface, such as buffer overflow, as attackers cannot predict or rely on specific memory layouts to conduct attacks.

[0168] Through the above compiling and linking strategy, the generated subprogram not only meets the functional requirements, but also enhances the maintainability and security of the system, and is an indispensable part of realizing self-recovery upgrade of embedded devices.

[0169] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited by the action sequence described, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0170] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and a necessary general hardware platform, and of course it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as Flash (including Nor-Flash and Nand-Flash) and eMMC, etc.), and includes a plurality of instructions for causing an end device (which can be an embedded and Internet of Things device with an MCU and SoC as the main controller, such as a network camera, an Internet of Things gateway and device, an electric vehicle charging pile controller, etc.) to execute the method described in each embodiment of the present application.

[0171] According to another aspect of the embodiments of the present application, a program upgrade device is also provided, which can be used to implement the program upgrade method provided in the above embodiments, which has been described and will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware is also possible and contemplated.

[0172] Figure 6 is a structural block diagram of an optional program upgrade device according to the embodiments of the present application, as shown in Figure 6 The program upgrade device includes:

[0173] The first obtaining module 62 is configured to, in a case where it is determined that the first subprogram stored in the first subprogram partition is in a to-be-upgraded state, obtain first subprogram firmware for upgrading the first subprogram, wherein the first subprogram partition is any one of N subprogram partitions provided in the computer system, the subprogram partition is configured to store a subprogram, and N is a natural number greater than or equal to 1.

[0174] The first loading module 64 is configured to load the first subprogram firmware into the first subprogram partition to upgrade the first subprogram.

[0175] According to the embodiments provided in the present application, since N subprogram partitions are arranged in the computer system, each subprogram has a corresponding subprogram partition, so that when it is determined that the first subprogram stored in the first subprogram partition is in the to-be-upgraded state, the first subprogram is upgraded only by acquiring the first subprogram firmware for upgrading the first subprogram, without the need to upgrade all programs in the computer system. In addition, each subprogram has its own partition, without the need for additional backup, so that the storage resources can be more effectively utilized, and the waste of space caused by redundant backup is avoided. Therefore, the technical problem that the program upgrade occupies more storage space in the related art can be solved, and the effect of upgrading the program while saving the storage space is achieved.

[0176] In one example embodiment, the first obtaining module 62 includes: a first starting unit, configured to start the first subprogram by executing a main program stored in a main program partition, wherein the main program partition is a partition arranged in the computer system, the first subprogram is a program allowed to be called by the main program, and the main program has the capability of upgrading the first subprogram; and a first obtaining unit, configured to, when the first subprogram is started, obtain an upgrade state of the first subprogram, and obtain the first subprogram firmware in a case where it is determined that the first subprogram is in the to-be-upgraded state.

[0177] In one example embodiment, the first obtaining unit includes: a first reading subunit, configured to, when the first subprogram is started, read a first upgrade marker of the first subprogram from an upgrade marker partition, wherein the upgrade marker partition is a partition arranged in the computer system and used for storing upgrade markers of programs; a second reading subunit, configured to, in a case where the first upgrade marker is used to indicate that the first subprogram is in the to-be-upgraded state, read first partition information of the first subprogram partition from a partition table partition, wherein the partition table partition is a partition arranged in the computer system and used for storing partition information; and a first obtaining subunit, configured to obtain the first subprogram firmware based on the first partition information.

[0178] In one example embodiment, the apparatus further includes: a first storage module, configured to, before reading a first upgrade marker of the first subprogram from an upgrade marker partition when the first subprogram is started, store the first upgrade marker into the upgrade marker partition in a case where an upgrade request is received, wherein the upgrade request is used to request to upgrade the first subprogram.

[0179] In an example embodiment, the first obtaining subunit is further configured to perform a verification operation on the first subprogram partition based on the first partition information, wherein the verification operation comprises at least one of the following: integrity verification of the first subprogram partition, and legality verification of the first subprogram partition; and the first subprogram firmware is obtained when a verification result of the verification operation indicates that the first subprogram partition passes the verification.

[0180] In an example embodiment, the first loading module comprises a first loading unit configured to load the first subprogram firmware into the first subprogram partition by executing a main program stored in a main program partition, so as to upgrade the first subprogram, wherein the main program partition is a partition set in the computer system, and the first subprogram is a program allowed to be called by the main program.

[0181] In an example embodiment, the apparatus further comprises at least one of the following: a deletion module configured to delete a first upgrade marker of the first subprogram from an upgrade marker partition after the first subprogram firmware is loaded into the first subprogram partition by executing the main program stored in the main program partition, so as to upgrade the first subprogram, wherein the upgrade marker partition is a partition set in the computer system for storing upgrade markers of programs, and the first upgrade marker is used to indicate that the first subprogram is in a state to be upgraded; and a starting module configured to restart the upgraded subprogram stored in the first subprogram partition.

[0182] In an example embodiment, the apparatus further comprises: a backup module configured to backup the main program to a backup program partition when the main program stored in the main program partition is in a state to be upgraded, so as to store a backup main program of the main program in the backup program partition, wherein the main program partition and the backup program partition are both partitions set in the computer system; and a second obtaining module configured to obtain main program firmware of the main program by executing the backup main program, and load the main program firmware into the main program partition, so as to upgrade the main program.

[0183] It should be noted that each of the above modules can be implemented by software or hardware, and for the latter, the following implementation manners can be used, but are not limited thereto: all of the modules are located in the same processor; or each of the modules is located in a different processor in an arbitrary combination.

[0184] According to still another aspect of the embodiments of the present application, a computer readable storage medium is provided, which comprises a stored program, wherein the program is configured to execute the steps in any of the above method embodiments when running.

[0185] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs such as Nor-Flash, Nand-Flash, and eMMC.

[0186] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0187] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0188] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0189] Figure 7 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which performs various appropriate actions and processes based on programs stored in ROM 702 or loaded into RAM 703 from storage section 708. Random access memory 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0190] The following components are connected to the I / O interface 705: an input part 706 including a keyboard, a mouse, etc.; an output part 707 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage part 708 including a hard disk, etc.; and a communication part 709 including a network interface card such as a LAN card, a modem, etc. The communication part 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as necessary. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 710 as necessary, so that a computer program read therefrom is installed in the storage part 708 as necessary.

[0191] In particular, according to embodiments of the present application, the processes described in the various method flowcharts can be implemented as a computer software program. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit 701, various functions defined in the system of the present application are performed.

[0192] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functions and usage range of embodiments of the present application.

[0193] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present application can be realized by general computing devices, which can be centralized on a single computing device or distributed on a network composed of multiple computing devices, and can be realized by program codes executable by the computing devices, so that they can be stored in storage devices and executed by the computing devices, and in some cases, the steps shown or described can be executed in different orders, or they can be manufactured into individual integrated circuit modules or multiple modules or steps can be manufactured into a single integrated circuit module. Thus, the present application is not limited to any particular combination of hardware and software.

[0194] The above merely describes the preferred embodiments of the present application and should not be used to limit the present application. Those skilled in the art can make various modifications and changes to the present application. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application should be included in the protection scope of the present application.

Claims

1. A program upgrade method characterized by comprising: The method comprises: In a case where it is determined that a first subprogram stored in a first subprogram partition is in a to-be-upgraded state, obtaining first subprogram firmware for upgrading the first subprogram, wherein the first subprogram partition is any one of N subprogram partitions provided in a computer system, the subprogram partitions are used to store subprograms, and N is a natural number greater than or equal to 1; loading the first subprogram firmware into the first subprogram partition to upgrade the first subprogram.

2. The method of claim 1, wherein, In a case where it is determined that a first subprogram stored in a first subprogram partition is in a to-be-upgraded state, obtaining first subprogram firmware for upgrading the first subprogram, comprises: starting the first subprogram by executing a main program stored in a main program partition, wherein the main program partition is a partition provided in the computer system, the first subprogram is a program allowed to be called by the main program, and the main program has the capability of upgrading the first subprogram; obtaining an upgrade state of the first subprogram when the first subprogram is started, and obtaining the first subprogram firmware in a case where it is determined that the first subprogram is in the to-be-upgraded state.

3. The method of claim 2, wherein, obtaining an upgrade state of the first subprogram when the first subprogram is started, and obtaining the first subprogram firmware in a case where it is determined that the first subprogram is in the to-be-upgraded state, comprises: reading a first upgrade marker of the first subprogram from an upgrade marker partition when the first subprogram is started, wherein the upgrade marker partition is a partition provided in the computer system and used to store upgrade markers of programs; reading first partition information of the first subprogram partition from a partition table partition in a case where the first upgrade marker is used to indicate that the first subprogram is in the to-be-upgraded state, wherein the partition table partition is a partition provided in the computer system and used to store partition information; obtaining the first subprogram firmware based on the first partition information.

4. The method of claim 3, wherein, Before reading the first upgrade marker of the first subprogram from the upgrade marker partition when the first subprogram is started, the method further comprises: storing the first upgrade marker into the upgrade marker partition in a case where an upgrade request is received, wherein the upgrade request is used to request to upgrade the first subprogram.

5. The method of claim 3, wherein, obtaining the first subprogram firmware based on the first partition information, comprises: performing a check operation on the first subprogram partition based on the first partition information, wherein the check operation comprises at least one of the following: integrity check on the first subprogram partition, and legality check on the first subprogram partition; obtaining the first subprogram firmware in a case where a check result of the check operation indicates that the first subprogram partition passes the check.

6. The method of claim 1, wherein, loading the first subprogram firmware into the first subprogram partition to upgrade the first subprogram, comprises: loading the first subprogram firmware into the first subprogram partition by executing a main program stored in a main program partition, to upgrade the first subprogram, wherein the main program partition is a partition provided in the computer system, and the first subprogram is a program allowed to be called by the main program.

7. The method of claim 6, wherein, After loading the first subprogram firmware into the first subprogram partition by executing a main program stored in a main program partition, to upgrade the first subprogram, the method further comprises at least one of the following: deleting a first upgrade mark of the first subprogram from an upgrade mark partition, wherein the upgrade mark partition is a partition provided in the computer system for storing upgrade marks of programs, and the first upgrade mark is used to indicate that the first subprogram is in a state to be upgraded; restarting the upgraded subprogram stored in the first subprogram partition.

8. The method of claim 1, wherein, The method further comprises: in a case where it is determined that a main program stored in a main program partition is in a state to be upgraded, backing up the main program into a backup program partition, to store a backup main program of the main program in the backup program partition, wherein the main program partition and the backup program partition are both partitions provided in the computer system; obtaining main program firmware of the main program by executing the backup main program, and loading the main program firmware into the main program partition, to upgrade the main program.

9. A computer system, characterized by comprise: a processor, a main program partition for storing a main program, and N subprogram partitions for storing N subprograms, the processor being configured to execute the steps of the method according to any one of claims 1 to 8, and N being a natural number greater than or equal to 1.

10. The system of claim 9, wherein, The system further comprises at least one of the following: an upgrade mark partition for storing upgrade marks of the subprograms; a partition table partition for storing partition information of the main program partition and the N subprogram partitions; a backup program partition for storing a backup main program of the main program.

11. A program upgrade apparatus characterized by comprising: comprise: a first obtaining module configured to, in a case where it is determined that a first subprogram stored in a first subprogram partition is in a state to be upgraded, obtain first subprogram firmware for upgrading the first subprogram, wherein the first subprogram partition is any one of N subprogram partitions provided in a computer system, the subprogram partitions are configured to store subprograms, and N is a natural number greater than or equal to 1; a first loading module configured to load the first subprogram firmware into the first subprogram partition, to upgrade the first subprogram.

12. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions, when executed by the processor, implement the steps of the method according to any one of claims 1 to 8.

13. A computer-readable storage medium, characterized in that, The computer program / instructions, when executed by the processor, implement the steps of the method according to any one of claims 1 to 8.

14. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The computer program / instructions, when executed by the processor, implement the steps of the method according to any one of claims 1 to 8.

Images