Software upgrading method, device, electronic device and storage medium

Abstract

The present application provides a software upgrade method, device, electronic device, and storage medium, which belong to the field of computer technology. The method includes: obtaining an upgrade software package of the software to be upgraded, the upgrade software package including a first upgrade identifier and an upgrade package; determining a target upgrade method corresponding to the upgrade package based on the first upgrade identifier; determining the current local upgrade method of the software to be upgraded; determining a target storage area for the upgrade package in a firmware partition based on the local upgrade method, the firmware partition being the storage area for the software to be upgraded in the terminal device; storing the upgrade package in the target storage area, and upgrading the software to be upgraded using the target upgrade method based on the upgrade package. The solution provided by the embodiment of the present application can better meet the needs of software upgrades.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically, to a software upgrading method, device, electronic device, and storage medium. Background Art

[0002] To better meet actual application needs and enhance users' software experience, continuous upgrades of terminal device software have become an indispensable part of real-world life. For example, for embedded devices, the software running on the embedded device may need to be remotely upgraded to fix program bugs, improve performance, and so on. This is known as OTA (over the air) upgrade. This upgrade typically occurs over a Wi-Fi network, enabling online firmware updates for embedded devices to provide users with a better service version experience.

[0003] Currently, there are multiple software upgrade methods. A device typically uses only one upgrade method, and multiple upgrade methods are not supported. The AB upgrade method is a commonly used dual-system upgrade method, meaning the device has two equal partitions, A and B, and the firmware size is no larger than the size of partition A or B. However, in practice, when users use the AB upgrade method, after a period of technical development, if the software firmware exceeds half of the firmware partition (and therefore the size of partition A or B), the software upgrade becomes unavailable. Therefore, existing upgrade methods cannot effectively meet actual needs. Summary of the Invention

[0004] The purpose of the embodiments of the present application is to provide a software upgrade method, device, electronic device, and storage medium that can better meet the needs of actual applications. To achieve this purpose, the embodiments of the present application provide the following solutions:

[0005] In one aspect, an embodiment of the present application provides a software upgrade method, the method comprising:

[0006] Obtain upgrade data for the software to be upgraded, the upgrade data including a first upgrade identifier and an upgrade package; determine a target upgrade method corresponding to the upgrade package based on the first upgrade identifier; determine a current local upgrade method for the software to be upgraded; determine a target storage area for the upgrade package in a firmware partition based on the local upgrade method, where the firmware partition is a storage area for the software to be upgraded in a terminal device; store the upgrade package in the target storage area, and upgrade the software to be upgraded using the target upgrade method based on the upgrade package.

[0007] On the other hand, an embodiment of the present application further provides a software upgrade device, the device comprising:

[0008] An upgrade data acquisition module is used to acquire upgrade data of the software to be upgraded, the upgrade data including a first upgrade identifier and an upgrade package;

[0009] An upgrade mode determination module, configured to determine a target upgrade mode corresponding to the upgrade package according to the first upgrade identifier, and to determine a current local upgrade mode of the software to be upgraded;

[0010] The upgrade processing module is used to determine the target storage area of ​​the upgrade package in the firmware partition according to the local upgrade method, store the upgrade package in the target storage area, and upgrade the software to be upgraded using the target upgrade method based on the upgrade package, wherein the firmware partition is the storage area of ​​the software to be upgraded in the terminal device.

[0011] On the other hand, an embodiment of the present application further provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory, and the processor executes the computer program to implement the steps of the method provided in the embodiment of the present application.

[0012] On the other hand, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method provided in the embodiment of the present application are implemented.

[0013] On the other hand, an embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the method provided in the embodiment of the present application are implemented.

[0014] The beneficial effects of the technical solution provided by the embodiment of the present application are as follows: based on the software upgrade method provided by the embodiment of the present application, when a device needs to upgrade the software to be upgraded, it can determine the target upgrade method corresponding to the currently acquired upgrade package based on the first upgrade identifier carried in the software upgrade package, determine the target storage area of ​​the upgrade package in the firmware partition based on the current local upgrade method of the device, and then store the upgrade package in the target storage area, and implement the software upgrade using the target upgrade method based on the upgrade package. Based on the solution provided by the embodiment of the present application, support for mutual upgrades of multiple different software upgrade methods is achieved. Regardless of whether the software upgrade method is switched, the software can be upgraded, which better meets the actual application needs and improves the user's usage experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments of the present application.

[0016] Figure 1 A flowchart of a software upgrade method provided in an embodiment of the present application;

[0017] Figure 2 A schematic diagram of the format of an upgrade software package provided in an embodiment of the present application;

[0018] Figure 3 A schematic diagram of a firmware partition provided in an embodiment of the present application;

[0019] Figure 4 A schematic diagram of another firmware partition provided in an embodiment of the present application;

[0020] Figure 5 A schematic diagram showing data comparison between new and old firmware provided in an embodiment of the present application;

[0021] Figure 6 A schematic diagram of a differential restoration method provided in an example of the present application;

[0022] Figure 7 A schematic diagram of a differential packet generation method provided in an example of the present application;

[0023] Figure 8 A schematic diagram illustrating the principles of the software upgrade method provided in an embodiment of the present application;

[0024] Figure 9 A schematic diagram of the structure of a software upgrade device provided in an embodiment of the present application;

[0025] Figure 10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] The following describes the embodiments of the present application in conjunction with the accompanying drawings. It should be understood that the embodiments described below in conjunction with the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0027] Those skilled in the art will understand that, unless otherwise stated, the singular forms "a", "an", "said", and "the" used herein may also include plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present application mean that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements, and / or components, but do not exclude implementation as other features, information, data, steps, operations, elements, components, and / or combinations thereof supported by the present technical field. It should be understood that when we say that an element is "connected" or "coupled" to another element, the element can be directly connected or coupled to the other element, or it can refer to the element and the other element establishing a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used here can include wireless connection or wireless coupling. The term "and / or" used here indicates at least one of the items defined by the term, for example, "A and / or B" can be implemented as "A", or as "B", or as "A and B".

[0028] In order to better understand and illustrate the solutions provided by the embodiments of the present application, some technical terms involved in the embodiments of the present application are explained below.

[0029] Firmware partition: A software firmware partition refers to the storage area in a terminal device (such as an embedded device) used to store the software's firmware.

[0030] AB Upgrade: This upgrade method is a dual-system upgrade method. As the name suggests, there are two systems. The device has two equal partitions, A and B, that is, two storage spaces are opened up, A storage space (A partition) and B storage space (B partition). The size of the firmware is no larger than the size of the A partition or the B partition. The AB upgrade method is a full upgrade method.

[0031] Differential upgrade method: This upgrade method is a single-system upgrade method with only one firmware version. Differential upgrade, also known as incremental update, is to differentiate the data files of the old and new versions to generate a differential package. Based on the differential package, a differential upgrade is performed on the old version. The differential package is generally very small.

[0032] Compression upgrade method: This upgrade method is also a single system upgrade method. There is only one firmware version. The compressed package is generally 50% of the firmware size. The upgrade is completed by decompressing the upgrade package.

[0033] Each upgrade method has its own advantages and disadvantages. The AB upgrade method is a dual-system upgrade. If the current system becomes unavailable, it can be switched to the backup partition. However, this upgrade method requires the firmware to be smaller than half of the total partition (i.e., the firmware partition, which is the combined size of partitions A and B). In the differential upgrade method, the differential packets are generally smaller, which can reduce the use of transmission and upgrade resources. However, this upgrade method relies on the old firmware and is relatively complex to implement. The compression upgrade method is simple to implement and does not rely on the old firmware. However, like the differential upgrade method, it is a single-system upgrade.

[0034] In actual applications, depending on different application scenarios and needs, only one upgrade method is currently used, and switching between multiple upgrade methods is not supported. This will lead to some problems and cannot well meet actual needs. For example, when a user uses the AB upgrade method, after a period of technical development, the firmware exceeds half the size of the firmware partition, and the software upgrade cannot be achieved. In order to solve the above-mentioned problems existing in the prior art, the embodiments of the present application provide a software upgrade method that can support switching between different upgrade methods. Based on the upgrade method provided by the embodiments of the present application, mutual upgrade between multiple different upgrade methods can be achieved, which can better meet user needs.

[0035] Among them, the different software upgrade methods in the embodiments of the present application include but are not limited to any two upgrade methods among the above-mentioned AB upgrade method, differential upgrade method and compression upgrade method. The method provided in the embodiments of the present application can be applicable to but not limited to OTA upgrade scenarios. The software to be upgraded can be any upgradeable software in the terminal device, including but not limited to the system software of the device or other applications downloaded and installed. The terminal device can include but is not limited to embedded devices.

[0036] The following describes several exemplary embodiments to illustrate the technical solutions of the embodiments of the present application and the technical effects produced by the technical solutions of the present application. It should be noted that the following embodiments can refer to, draw on, or combine with each other, and the same terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0037] Figure 1 This is a flowchart of a software upgrade method provided in an embodiment of the present application. The method can be executed by any electronic device. Optionally, the method can be executed by an embedded device. For the convenience of description, the following embodiment description will take the embedded device as the execution subject of the method as an example. Figure 1 As shown in , the method may include the following steps S110 to S140.

[0038] Step S110: Acquire upgrade data of the software to be upgraded, where the upgrade data includes a first upgrade identifier and an upgrade package.

[0039] Upgrade data, i.e., data used to implement the upgrade of the software to be upgraded, that is, data for implementing the firmware version of the software to be upgraded in the embedded device. Upgrade data can also be called an upgrade software package or an upgrade firmware package. The first upgrade identifier is used to indicate which upgrade method the currently acquired upgrade package belongs to, that is, it is used to identify the target upgrade method corresponding to the upgrade package. For example, if the above-mentioned upgrade package is a differential package, the first upgrade identifier indicates that the target upgrade method is the differential upgrade method. If the upgrade package is a compressed package (the data package corresponding to the compressed upgrade method can also be called a compressed upgrade package), the first upgrade identifier indicates that the target upgrade method is the compressed upgrade method.

[0040] This embodiment does not limit the specific form of the first upgrade identifier, as long as it can be used to distinguish different upgrade methods. For example, if the first upgrade identifier is 0, it indicates that the target upgrade method is a dual-system upgrade method, and if the first upgrade identifier is 1, it indicates that the target upgrade method is a single-system upgrade method. In actual applications, if the dual-system upgrade method or the single-system upgrade method is one of at least two types, the upgrade identifier can further identify which of the at least two types is the target upgrade method. For example, if the target upgrade method is a single-system upgrade method, and the single-system upgrade method can be a compression upgrade method or a differential upgrade method, when the first upgrade identifier is 1a, it indicates that the target upgrade method is a compression upgrade method, and when the first upgrade identifier is 1b, it indicates that the target upgrade method is a differential upgrade method.

[0041] The embodiment of the present application does not limit the package format of the upgrade software package. Optionally, the upgrade software package may include a header and a body. The header carries a first upgrade identifier, and the body contains the actual data used for the upgrade, i.e., the upgrade package. It is understandable that in actual applications, in addition to the first upgrade identifier, the header may also contain other additional data related to the upgrade, such as upgrade package content verification information. As an example, Figure 2 The figure shows a schematic diagram of the package format of an upgrade software package provided in an embodiment of the present application. The package header (i.e., Head) contains information such as the distinguishing identification of each upgrade package (i.e., the first upgrade identifier) ​​and the upgrade package content verification. The package body is the upgrade package corresponding to the upgrade method identified by the first upgrade identifier, such as a differential package (Diffpackage) for differential upgrade, a compressed package (CMZ package) for compressed upgrade, or an upgrade package (AB package) for AB upgrade.

[0042] When the software to be upgraded (that is, the old firmware of the software) needs to be upgraded, the embedded device can obtain the software upgrade package from the server by communicating with the server. Optionally, when obtaining the software package, the embedded device can first obtain the header data of the upgrade package, i.e., the packet header, from the server, and after determining the target upgrade method according to the first upgrade identifier in the packet header, obtain the upgrade package part from the server, and store the upgrade package in the target storage area of ​​the firmware partition according to the method described later. Of course, the embedded device can also download the entire software upgrade package from the server and store it (such as caching) in a designated area of ​​the device (non-firmware partition), and then, by parsing the software upgrade package and determining the target upgrade method according to the first upgrade identifier in the packet header, store the upgrade package in the target storage area.

[0043] As an optional method, when the embedded device needs to perform a software upgrade, the server can send the above-mentioned header data and the acquisition address of the upgrade package to the embedded device. The embedded device can determine the target upgrade method based on the first software identifier in the received header data, and obtain the upgrade package according to the above-mentioned acquisition address. The embodiment of this application does not limit the form of the acquisition address. For example, the acquisition address can be the address where the upgrade package is stored, such as a URL (Uniform Resource Locator) address. The embedded device can download the upgrade package according to the acquired URL address.

[0044] Step S120: determining the target upgrade mode corresponding to the upgrade package according to the first upgrade identifier, and determining the current local upgrade mode of the software to be upgraded.

[0045] The local upgrade method refers to the software upgrade method used by the embedded device before the upgrade is performed based on the acquired upgrade package. Because the partition format requirements of the firmware partition in the embedded device may be different for different upgrade methods (for example, for a dual-system upgrade method, the firmware partition includes two partitions, while for a single-system upgrade method, the firmware partition is one partition), in order to ensure the normal upgrade of the software, it is necessary not only to determine the target upgrade method but also to know the current local upgrade method of the embedded device to ensure that the upgrade package can be stored in the correct location in the firmware partition and the software upgrade can be implemented according to the upgrade package.

[0046] Optionally, the device may store identification information of a local upgrade mode, and the device may determine the local upgrade mode by reading the identification information. Specifically, the above-mentioned determination of the current local upgrade mode of the software to be upgraded may include:

[0047] Obtain a second upgrade identifier of the locally stored software to be upgraded, and determine a local upgrade mode according to the second upgrade identifier; wherein, if the local upgrade mode is a dual-system upgrade mode, the second upgrade identifier is also used to identify the upgrade partition targeted by the upgrade.

[0048] Wherein, when the target upgrade mode and the local upgrade mode are different, the method further includes:

[0049] Updating the second upgrade identifier to the upgrade identifier corresponding to the target upgrade method;

[0050] If both the local upgrade mode and the target upgrade mode are dual-system upgrade modes, the method further includes:

[0051] Update the upgrade partition identified by the second upgrade identifier.

[0052] The second upgrade identifier is used to determine the local upgrade method, and the second upgrade identifier can also be called a local upgrade identifier. The embodiment of the present application does not limit the storage location of the second upgrade identifier in the embedded device (i.e., the location of local storage). Optionally, the second upgrade identifier can be stored in a specified area of ​​the firmware partition, such as the header area, and the embedded device can read the identifier from the specified area of ​​the firmware partition to determine the local upgrade method. If the local upgrade method is different from the target upgrade method, after the software is upgraded or the software package is stored in the target storage area, it is also necessary to update the locally stored second upgrade identifier to the upgrade identifier corresponding to the target upgrade method to ensure that the local upgrade method can be accurately determined based on the updated identifier when an upgrade is required next time. Among them, updating the second upgrade identifier can be performed after obtaining the upgrade package used for this upgrade, or it can be performed after the software to be upgraded is upgraded, wherein, after the software to be upgraded is upgraded, it can refer to after the software to be upgraded is successfully upgraded.

[0053] When the local upgrade method is a dual-system upgrade method, since the firmware partition includes two partitions, in order to determine which partition is being upgraded this time, the above-mentioned second upgrade identifier is also used to identify the upgrade partition targeted by this upgrade, that is, in which partition of the firmware partition the old firmware is to be upgraded. Correspondingly, if the local upgrade method and the target upgrade method are both dual-system upgrade methods, after the software to be upgraded is upgraded, the upgrade partition identified by the second upgrade identifier also needs to be updated. For example, the dual-system upgrade method is an AB upgrade method, and the firmware partition includes an A partition and a B partition. Partition A stores the first firmware of the software to be upgraded, and partition B stores the second firmware of the software to be upgraded. If the upgrade partition identified by the second upgrade identifier before this upgrade is partition A, that is, the first firmware of partition A is upgraded, after completing this upgrade, the upgrade partition identified by the second upgrade identifier needs to be updated to partition B, so as to identify that partition B will be upgraded during the next upgrade.

[0054] The specific form of the second upgrade identifier is not limited in the present embodiment and can be configured according to actual application requirements. Optionally, the second upgrade identifier may include two flag bits, which correspond to the single-system upgrade mode and the dual-system upgrade mode, respectively. For example, the first flag bit corresponds to the dual-system upgrade mode, and the second flag bit corresponds to the single-system upgrade mode. If the first flag bit is 1 and the second flag bit is 0, it indicates that the local upgrade mode is the dual-system upgrade mode. If the first flag bit is 0 and the second flag bit is 1, it indicates that the local upgrade mode is the single-system upgrade mode. For the dual-system upgrade mode, since the second upgrade identifier is also used to indicate the upgrade partition targeted by the current upgrade, the flag bit corresponding to the dual-system upgrade mode can also be used to distinguish which partition is targeted by the different values ​​of the flag bit. For example, for the AB upgrade mode, if the first flag bit is 1A or A, the upgrade partition is identified as partition A. If the first flag is 1B or B, the upgrade mode is partition B. It is understandable that when performing this upgrade, if the target upgrade mode is different from the local upgrade mode, the local upgrade identifier needs to be updated after the upgrade. For example, if the local upgrade method is a dual-system upgrade method, the first flag bit of the local upgrade identifier is 1 and the second flag bit is 0. The target upgrade method is a single-system upgrade method. After this upgrade, the first flag bit of the local upgrade identifier needs to be updated to 0 and the second flag bit needs to be updated to 1.

[0055] Step S130: Determine the target storage area of ​​the upgrade package in the firmware partition according to the local upgrade method.

[0056] Step S140: The upgrade package is stored in the target storage area, and the software to be upgraded is upgraded in a target upgrade manner based on the upgrade package.

[0057] Among them, the firmware partition is the storage area of ​​the software to be upgraded in the terminal device, that is, the storage area allocated in the embedded device for storing the firmware of the software to be upgraded. For example, if the local upgrade method is AB upgrade method, the firmware partition refers to partition A and partition B.

[0058] Since different upgrade methods have different storage methods for the software firmware and upgrade processing methods during the upgrade, after determining the local upgrade method, it is necessary to determine the current storage method of the firmware based on the local upgrade method, so that the upgrade package can be correctly stored in the target storage area in the firmware partition. Since the upgrade package is the upgrade firmware package corresponding to the target upgrade method, after the upgrade package is stored in the target storage area, the upgrade processing method of the target upgrade method can be used based on the upgrade package to process the upgrade software, realize the software upgrade, and obtain the upgraded firmware. For example, if the target upgrade method is a differential upgrade method, the above-mentioned upgrade package is a differential package, and differential restoration can be performed based on the differential package stored in the target storage area and the old firmware stored in the firmware partition (i.e., the current firmware of the software to be upgraded) to obtain the target firmware of the software to be upgraded and realize the upgrade.

[0059] Based on the solution provided in the embodiment of the present application, support for mutual upgrading of multiple different software upgrade methods is achieved. Even if the software upgrade method is switched, software upgrade can be achieved, which better meets actual application needs and improves the user's usage experience.

[0060] Optionally, in actual applications, if it is determined that the upgrade method has changed based on the target upgrade method and the local upgrade method, in order to improve the user's usage experience, the embedded device can prompt that the upgrade method has changed before performing a software upgrade based on the upgrade package of the target upgrade method. For example, it can prompt the user that if the upgrade is performed, the upgrade method will change from upgrade method a to upgrade method b. The user can also be further prompted with the differences or advantages and disadvantages of the two upgrade methods, and the user can choose whether to continue the upgrade. If the user is sure to upgrade, the software will be upgraded using the target upgrade method based on the upgrade package. If the user indicates not to upgrade, the current firmware version can continue to be used to provide services to the user.

[0061] In an optional embodiment of the present application, the target upgrade mode is a dual-system upgrade mode or a single-system upgrade mode, and the local upgrade mode is a dual-system upgrade mode or a single-system upgrade mode.

[0062] In actual applications, since the firmware partition corresponding to the single-system upgrade method is a whole partition, and the firmware partition corresponding to the dual-system upgrade method requires two partitions (for example, for the AB upgrade method, the firmware partition contains two partitions of equal size), based on this, in this optional embodiment of the present application, the software upgrade method can be divided into two categories, one is the dual-system upgrade method, and the other is the single-system upgrade method. Optionally, the dual-system upgrade method can be but not limited to the AB upgrade method, and the single-system upgrade method can be but not limited to the differential upgrade method or the compression upgrade method. Since the forms of the firmware partitions and the upgrade processing methods corresponding to different types of upgrade methods are different, the methods for determining the target storage area of ​​the upgrade package are also different for different types of upgrade methods.

[0063] In an optional embodiment of the present application, determining the target storage area of ​​the upgrade package in the firmware partition according to the local upgrade method may include:

[0064] When the local upgrade mode is a dual-system upgrade mode, determining a target partition in the firmware partition where the software to be upgraded is currently running, and determining a non-target partition of the firmware partition as a target storage area;

[0065] When the local upgrade method is a single-system upgrade method, if the target upgrade method is a single-system upgrade method, the tail area of ​​the firmware partition is determined as the target storage area. If the target upgrade method is a dual-system upgrade method, the firmware partition is divided into a first partition and a second partition corresponding to the dual-system upgrade method, and the head area of ​​the second partition is determined as the target storage area, wherein the storage area of ​​the second partition is located after the storage area of ​​the first partition.

[0066] For the dual-system upgrade method, the firmware partition includes two partitions. For example, for the AB upgrade method, the two partitions are commonly referred to as partition A and partition B. The firmware versions stored in the two partitions may be the same or different, and in most cases they are different. In the embodiment of the present application, for the dual-system upgrade method, the partition currently running on the embedded device is called the target partition, and the other partition is called the non-target partition.

[0067] If the local upgrade method is a dual-system upgrade method, the firmware partition includes two partitions. Since the target partition is the partition where the device is currently running, the upgrade package needs to be stored in the non-target partition. If the local upgrade method is a single-system upgrade, the device's firmware partition is a single entity, while a dual-system upgrade requires two partitions. Therefore, if the local upgrade method is a single-system upgrade, the target upgrade method needs to be further considered when determining the target storage area for the upgrade package. Specifically, if the target upgrade method is also a single-system upgrade, the upgrade package can be directly stored in the tail area of ​​the entire firmware partition. If the target upgrade method is a dual-system upgrade, the firmware partition needs to be divided into two partitions, namely the first partition and the second partition mentioned above. The storage area of ​​the first partition is located before the second partition. Since the local upgrade method is a single-system upgrade, the firmware before the upgrade is usually stored in the header area of ​​the firmware partition (i.e., the firmware is stored in the firmware partition starting from the starting position of the firmware partition). Therefore, the upgrade package can be stored in the partition with the later storage position of the two partitions. Furthermore, if the dual-system upgrade method uses a full upgrade method, the upgrade package can be stored in the header area of ​​the partition with the later storage position. In other words, the upgrade can be completed by burning the upgrade package to the fourth partition starting from the starting storage position of the second partition.

[0068] It is understood that when switching from a single-system upgrade to a target upgrade, the size of the previous firmware (i.e., the old firmware in the firmware partition) must not exceed the size of the first partition, and the upgraded firmware (the new firmware in the second partition) must not exceed the size of the second partition. When the dual-system upgrade is an AB upgrade, the sizes of the first and second partitions are equal, and neither the pre-upgrade nor the upgraded firmware is larger than half of the entire firmware partition.

[0069] In an optional embodiment of the present application, the upgrade data further includes a storage address identifier, which is used to indicate a starting storage address of the upgrade package in the firmware partition when the target upgrade mode is a single system upgrade mode.

[0070] If the target upgrade method is a dual-system upgrade method, such as an AB upgrade method, since it is a full upgrade method, after determining the target storage area, the upgrade package can be stored in the target storage area starting from the starting position of the target storage area. When the target upgrade method is a single-system upgrade method, since the target storage area for the upgrade package is the tail area of ​​the firmware partition, that is, the area from the tail of the entire firmware partition upwards, the embedded device needs to know the starting storage position of the upgrade package in the firmware partition, that is, the storage start address (which can be simply referred to as the start address or start position), and store the upgrade package in the firmware partition starting from this starting position.

[0071] In an optional embodiment of the present application, the single system upgrade method can be a compression upgrade method or a differential upgrade method. The above-mentioned storage address identifier can also be called a differential compression address identifier, which identifies the starting address of the upgrade package storage. This address identifier is valid only when the first upgrade identifier is a differential upgrade identifier or a compression upgrade identifier. In other words, this address identifier is valid only when the target upgrade method is a single system upgrade method.

[0072] The embodiment of the present application does not limit the specific data form of the above-mentioned storage address identifier. Optionally, the storage address identifier can be an address offset. Specifically, the address offset can be the offset of the storage start address of the upgrade package in the firmware partition relative to the starting position of the firmware partition (i.e., the starting storage address). The embedded device can determine the storage start address of the upgrade package in the firmware partition based on the starting storage address of the firmware partition and the address offset. Optionally, the storage address identifier can also be the size of the upgrade package. The embedded device can determine the storage start address of the upgrade package in the firmware partition based on the ending storage address of the firmware partition and the size of the upgrade package. For example, if the ending storage address of the firmware partition is address a and the size of the upgrade package is b, then the last storage space area of ​​the firmware partition with a size of b is the storage area of ​​the upgrade package. The starting position of the area can be determined based on the address a and the size b of the upgrade package, that is, the storage address with a forward offset of size b relative to address a.

[0073] After the upgrade package is stored in the target storage area, the software can be upgraded in a target upgrade manner based on the upgrade package.

[0074] In an optional embodiment of the present application, the dual-system upgrade mode is an AB upgrade mode, and the single-system upgrade mode is a differential upgrade mode or a compression upgrade mode; when the local upgrade mode is the dual-system upgrade mode and the target upgrade mode is the single-system upgrade mode, the above-mentioned storing the upgrade package in the target storage area and upgrading the software to be upgraded using the target upgrade mode based on the upgrade package may include:

[0075] If the storage area of ​​the target partition is located before the non-target partition, the upgrade package is stored in the tail area of ​​the non-target partition;

[0076] When the target upgrade mode is a compression upgrade mode, the upgrade package stored in the tail area of ​​the non-target partition is decompressed, and the decompressed data is stored in the firmware partition starting from the beginning of the firmware partition;

[0077] When the target upgrade mode is a differential upgrade mode, a differential upgrade is performed based on the upgrade package stored in the tail area of ​​the non-target partition and the data stored in the first partition.

[0078] In an optional embodiment of the present application, when the local upgrade mode is a dual-system upgrade mode and the target upgrade mode is a single-system upgrade mode, storing the upgrade package in the target storage area and upgrading the software to be upgraded using the target upgrade mode based on the upgrade package may include:

[0079] If the storage area of ​​the target partition is located after the non-target partition, the upgrade package is stored in the first space at the end of the non-target partition;

[0080] According to the size of the upgrade package, a second space of corresponding size is divided from the tail area of ​​the target partition, and the data stored in the first space is exchanged with the data stored in the second space;

[0081] When the target upgrade mode is a compression upgrade mode, decompressing the upgrade package stored in the second space, and storing the decompressed data in the firmware partition starting from the starting position of the firmware partition;

[0082] When the target upgrade method is a differential upgrade method, a differential upgrade is performed based on the upgrade package stored in the second space, the data stored in the third space of the target partition, and the data stored in the first space, and the upgraded data is stored in the firmware partition starting from the starting position of the firmware partition, wherein the third space is the storage area in the target partition except the second space.

[0083] The above optional solution provides an upgrade processing method when switching from a dual-system upgrade method to a single-system upgrade method. In actual applications, when the local upgrade method is a dual-system upgrade method, the partition where the embedded device is currently running may be a partition near the front of the storage area or a partition near the back of the storage area. If it is running in the partition near the front, the upgrade package is stored in the tail area of ​​the non-target partition, that is, the tail area of ​​the entire firmware partition. After the upgrade package is stored in this tail area, the upgrade processing method corresponding to the single-system upgrade method can be used based on the upgrade package.

[0084] Specifically, when the upgrade mode is switched from the dual-system upgrade mode to the single-system upgrade mode, if the single-system upgrade mode is a compression upgrade mode, the compressed package can be directly decompressed, and the decompressed data can be stored in the firmware partition starting from the starting position of the firmware partition. If the single-system upgrade mode is a differential upgrade mode, since the old firmware data, that is, the data of the target partition currently running, is required, it is necessary to perform differential restoration based on the differential package and the old firmware in the target partition to obtain the new firmware, and the data of the new firmware can be stored in the firmware partition starting from the starting position of the firmware partition.

[0085] It is understandable that if the local upgrade method and the target upgrade method are both AB upgrade methods, when the device is currently running in the front partition, the upgrade package can be stored in the tail area of ​​the non-target partition, and then the upgrade package can be burned to the first partition from the starting position of the target partition.

[0086] When the local upgrade method is the dual-system upgrade method and the target upgrade method is the single-system upgrade method, if the partition where the embedded device is currently running is a later partition, the upgrade package is stored in the tail area (first space) of the non-target partition. When performing the upgrade process, it is necessary to exchange the upgrade package stored in the tail area of ​​the non-target partition with the data in the tail area (second space) of the same size in the target partition, and exchange the upgrade package to the tail area of ​​the entire firmware partition. Then, based on the upgrade package, the corresponding single-system upgrade method is used for upgrade processing.

[0087] Specifically, for the differential upgrade method, since the upgrade depends on the old firmware, that is, the firmware data in the target partition, before the above-mentioned data exchange, the old firmware data required for the upgrade is the data stored in the target partition, that is, the data stored in the partition from the starting position of the target partition. Through the above-mentioned data exchange process, the old firmware becomes the data stored in the third space of the target partition and the data in the first space of the non-target partition (the data previously stored in the tail area of ​​the target partition). Therefore, the differential upgrade at this time needs to perform differential restoration based on the differential package stored in the second space, the old firmware data stored in the third space and the first space, and store the obtained new firmware in the firmware partition starting from the starting position of the entire firmware partition.

[0088] It is understandable that if both the local upgrade method and the target upgrade method are single-system upgrade methods, the firmware partition is a whole, the old firmware is stored in the firmware partition from the starting position of the firmware partition, and the upgrade package is stored in the tail area of ​​the firmware partition. When upgrading, the upgrade processing method corresponding to the single-system upgrade method is directly used based on the upgrade package, and the obtained new firmware is stored in the firmware partition from the starting position of the firmware partition. For example, if the target upgrade method is a compression upgrade method, the upgrade package is decompressed, and the decompressed data is stored in the firmware partition from the starting position of the firmware partition to complete the upgrade. If the target upgrade method is a differential upgrade method, differential restoration is performed based on the upgrade package and the old firmware stored in the firmware partition, and the data obtained by differential restoration is stored in the firmware partition from the starting position of the firmware partition.

[0089] The following example illustrates the software upgrade process for an embedded device provided in an embodiment of the present application when the upgrade method is switched from a dual-system upgrade method to a single-system upgrade method. In this example, the local upgrade method is the AB upgrade method, and the firmware partition includes two partitions, A and B, which are the same size. In this example, Partition A is located before Partition B. Figure 3 The figure shows the firmware partitions corresponding to the AB upgrade method before this upgrade. Figure 3 Firmware area A and firmware area B are the entire firmware partitions. Firmware area A corresponds to the above-mentioned A partition (referred to as A area), and firmware area B corresponds to the above-mentioned B partition (referred to as B area). Figure 3 The other areas shown in the figure are other storage areas outside the firmware partition of the embedded device. For the convenience of description, the old firmware stored in firmware area A is called firmware A, and the old firmware stored in firmware area B is called firmware B. The data of firmware A is from the starting position of firmware area A ( Figure 3 In the schematic diagram shown, the data for firmware A is stored in firmware area A starting at the left endpoint of firmware area A, and the data for firmware B is stored in firmware area B starting at the starting position of firmware area B. Since the local upgrade method is an AB upgrade method, firmware A and firmware B must not exceed half of the entire firmware partition. If the embedded device is currently running in area A, after obtaining the upgrade package for a single-system upgrade method (compression or differential upgrade method), the upgrade package is stored starting at the end of area B. That is, based on the size of the upgrade package or the starting storage location of the upgrade package (which can be determined based on the storage address identifier in the upgrade data), the upgrade package is stored in the storage space of the corresponding size at the end of area B. Afterwards, the specific upgrade method of the single-system upgrade method can be further determined. If it is a compression upgrade method, the upgrade package is decompressed and the decompressed firmware data is stored in the firmware partition starting at the starting position of area A. If it is a differential upgrade method, a differential recovery is performed based on the old firmware in area A and the upgrade package, and the resulting new firmware data is stored in the firmware partition starting at the starting position of area A.

[0090] If the embedded device is currently running in area B, Figure 4 A schematic diagram of a firmware partition at this time is shown in FIG. Figure 4 As you can see, the firmware partition is now divided into four parts: space L1, space L2, space L3, and space L4. Spaces L1 and L2 are area A, and spaces L3 and L4 are area B. In terms of storage space size, L1 + L2 = L3 + L4, L1 = L3, L2 = L4. The size of space L2 and space L4 is determined by the size of the upgrade package.

[0091] Specifically, when the current operation is in area B, that is, the target partition is area B, if the target upgrade mode is determined to be a single system upgrade mode according to the first upgrade identifier, after obtaining the upgrade package, the upgrade package is stored in the tail area of ​​area A, that is, the first space, such as Figure 4 The L2 space in the B zone is divided into a second space of the same size from the end of the B zone according to the size of the upgrade package. Figure 4 The L4 space in the partition is swapped, and the data in the L4 space and L2 space are swapped. That is, the upgrade package is swapped and stored in the L4 space (the end of the entire firmware partition), and the part of firmware B's data originally stored in the L4 space is stored in the L2 space. The swapped firmware B data is composed of the L3+L2 parts. The data of firmware B is stored starting from the L3 space. If the data size of firmware B is not larger than the size of the L3 space, the data of firmware B is actually the data stored in the L3 space. If the data size of firmware B is larger than the L3 space, the data of firmware B is the data in the L3 space plus the data in the L2 space. Optionally, the data originally stored in the L4 space can be stored in the L2 space starting from the starting position of the L2 space.

[0092] If the target upgrade method is compression upgrade, the upgrade package is a compressed package. The upgrade does not depend on the old firmware. After the above swap, the compressed package is located at the end of the entire firmware area. You can directly decompress it to get the new firmware and burn it sequentially into the overall firmware partition to achieve the upgrade.

[0093] If it is a differential upgrade, the upgrade package is a differential package, and the upgrade depends on the old firmware, that is, firmware B. After the above exchange, the data of firmware B is located in the L3 space and L2 space. Based on the differential package stored in the L4 space and the old firmware data in the L3 space and L2 space, differential restoration is performed to obtain the new firmware, and it is sequentially burned in the overall firmware partition to achieve the upgrade. During the differential restoration process, the content with a differential rule greater than the L3 space (that is, the data of the old firmware stored in the L4 space before the exchange is needed) can be obtained starting from the L2 space.

[0094] Based on the method provided by the embodiment of the present application, regardless of whether the upgrade mode of the device changes, the software upgrade can be achieved, which can better meet the actual application needs. It should be noted that the solution provided by the embodiment of the present application supports switching between two or more different upgrade modes. If switching between two upgrade modes is supported, that is, whether it is a target upgrade mode or a local upgrade mode, it is one of the two upgrade modes, such as an AB upgrade mode and a differential upgrade mode. At this time, the first upgrade identifier in the upgrade data can only need to identify which type of upgrade mode it is. For example, the identifier 0 identifies the dual-system upgrade mode and the identifier 1 identifies the single-system upgrade mode. Then, after the device obtains the first upgrade identifier, it can know whether the target upgrade mode is the AB upgrade mode or the differential upgrade mode according to 0 or 1. As for the local upgrade identifier (i.e., the second upgrade identifier), if it is the AB upgrade mode, the identifier not only indicates that it is the AB upgrade mode, but also needs to indicate whether the upgrade partition targeted by the upgrade is the A partition or the B partition. If the upgrade switch supports switching between more than two upgrade methods, the first upgrade identifier must also be able to indicate which specific upgrade method is used. For example, AB upgrade method, differential upgrade method and compression upgrade method are supported. If the target upgrade method is a single-system upgrade method, the first upgrade identifier should also be able to determine whether it is a differential upgrade method or a compression upgrade method.

[0095] After storing the upgrade package in the target storage area of ​​the firmware partition or completing the upgrade based on the upgrade package, the local upgrade identifier also needs to be updated, and the identifier is updated to the identifier corresponding to the target upgrade method. For example, if the local upgrade method is a dual-system upgrade identifier and the target upgrade method is a single-system upgrade method, the second upgrade identifier needs to be updated to the upgrade identifier corresponding to the single-system upgrade method. If the local upgrade method is a single-system upgrade method and the target upgrade method is a dual-system upgrade method, the second upgrade identifier needs to be updated to the identifier corresponding to the dual-system upgrade method, and the upgrade partition corresponding to the dual-system upgrade method must be updated. That is, if the target upgrade method is still the dual-system upgrade method for the next upgrade, which partition's firmware will be upgraded next time? For example, the new firmware after this upgrade is stored in partition A, and the upgrade partition indicated by the updated second upgrade identifier is partition B.

[0096] It is understood that if both the local upgrade method and the target upgrade method are AB upgrade methods, the local upgrade identifier needs to be updated after the upgrade package is stored in the target storage area or the upgrade is completed, and the upgrade partition indicated by it is updated. If both the local upgrade method and the target upgrade method are single-system upgrade methods, the local upgrade identifier does not need to be updated. Of course, if both the local upgrade method and the target upgrade method are single-system upgrade methods but the upgrade methods are different, the local upgrade identifier can still be updated.

[0097] When the target upgrade method is a differential upgrade method, the above-mentioned upgrade package is a differential package. The specific generation method of the differential package is not limited in this embodiment of the application. The differential package can be generated by using any existing differential algorithm. After the embedded device obtains the differential package, it can use the differential restoration method corresponding to the backward differential algorithm based on the differential package to perform upgrade processing.

[0098] The principle of the differential algorithm is simply that the new firmware (upgraded firmware) searches for the largest similar block in the original firmware (i.e., the old firmware) (the method for determining whether two data blocks are similar is not limited in this embodiment of the application). If a similar block is found, a subtraction operation, i.e., differential processing, is performed. The difference value is mostly 0, which greatly improves the compression rate and makes the differential packet very small. When searching for similar blocks in the old firmware, the similar blocks of the new firmware may be offset forward or backward in the old firmware. If no similar blocks are found, additional blocks are formed.

[0099] The differential packet contains two parts, namely the differential block and the newly added block. The restoration of the differential block requires the participation of the old firmware, that is, the addition operation is used to reversely calculate the content in the new firmware. The newly added block does not require the participation of the old firmware and can be directly filled into the corresponding address of the new firmware.

[0100] As an optional method, a backward differencing algorithm can be used to generate differential packets. When the backward differencing algorithm performs differential processing on the new firmware and the old firmware, similar blocks only select data blocks that are located later than the old firmware. That is, if a data block in the new firmware has a similar data block in the old firmware, then the position of the similar data block in the old firmware (the offset relative to the starting position of the old firmware storage area) must be no less than the position of the corresponding data block in the new firmware in the new firmware (the offset relative to the starting position of the new firmware storage area).

[0101] For the convenience of description, the data blocks of the new firmware are divided into two types in the following description: one is the target block and the other is the newly added block. The target block refers to the data block that has a similar data block in the old firmware. The similar block of the target block in the old firmware is called a similar block. The newly added block refers to the data block that does not have a similar block in the old firmware.

[0102] As an example, Figure 5 A schematic diagram of the generation principle of a differential packet is shown in the figure. Figure 5The rectangular blocks in the upper middle represent the data blocks of the old firmware, and the rectangular blocks in the lower middle represent the data blocks of the new firmware. In this diagram, there are 4 pairs of similar blocks between the new firmware and the old firmware. Data blocks 1 to 4 of the old firmware are similar blocks that correspond one to one to data blocks 1 to 4 of the new firmware. Since the position of the similar block 4 of the new firmware's data block 4 in the old firmware is located at the offset of the data block 4 in the new firmware, when using the backward difference processing method, the new firmware's data block 4 is not considered to be the target block, but is treated as a newly added block. Using backward difference, when performing differential restoration based on differential packets, when restoring data blocks 1 to 3 in the new firmware, these three data blocks can be sequentially stored in the corresponding areas in the old firmware. For example, after restoring data block 1 in the new firmware, the data block will be stored in the corresponding storage area in the old firmware, that is, the area before data block 4 in the old firmware. Using backward difference, there will definitely not be a situation where a similar block of a target block in the new firmware appears before the storage position corresponding to the target block, and the differential restoration process is relatively simple. However, due to Figure 5 It can be seen that the backward difference algorithm discards the forward difference blocks, resulting in an increase in the size of the difference packet.

[0103] In order to reduce the size of the differential packet, an embodiment of the present application also provides another optional differential packet generation algorithm, which can be called an improved differential algorithm. Through this algorithm, a similar block of a data block of a new firmware can be moved to a relatively later position in the firmware partition of the old firmware by moving a data block that is relatively forward in the old firmware. Therefore, when performing differential restoration of the data block of the new firmware, a corresponding similar block can be found at a later position in the storage location of the data block in the firmware partition.

[0104] for Figure 5 In the example shown in , if the improved differential algorithm is used, for data block 4 in the new firmware, this data block will not be treated as a newly added block, but as a target block, and differential processing will be performed with the corresponding similar block in the old firmware. When performing differential restoration, if the restored data of the new firmware needs to be stored in the area where its similar block (i.e., data block 4 in the old firmware) is located, the storage location of the similar block can be moved backward according to the translation control information in the differential packet.

[0105] The core of the improved differential algorithm is to perform processing such as translation on the data of the old firmware. By adding only a small amount of differential control information and translation control information, the resources occupied by the old firmware can be reasonably used. The differential control information is used to determine the data in the old firmware required to restore the target block, and the translation control information is used to determine the storage space before and after the data block in the old firmware that has been moved. Compared with the old firmware, the new firmware has differential blocks (difference data between the target block and the similar blocks of the target block) and inserted blocks (that is, newly added blocks). The differential blocks require the participation of the old firmware. When the new firmware searches for similar blocks of the old firmware, it can use the translation operation to translate the data of similar blocks in the old firmware to the free area of ​​the old firmware area to re-form differential blocks.

[0106] Consider three scenarios: 1. The new firmware is smaller than the old firmware; 2. The new firmware is equal to the old firmware; 3. The new firmware is larger than the old firmware.

[0107] For scenarios 1 and 2, the new firmware contains additional blocks in addition to the target block. Therefore, the old firmware area contains data equal to at least the size of the additional blocks and is not included in the restore calculation. Regarding the target block, if similar blocks can be found at the same location in the old firmware for multiple target blocks, then the old firmware data area of ​​the corresponding size is not included in the restore calculation, and the similar block locations in the original firmware area can be reused after the differential block is generated. For scenario 3, the portion of the new firmware that is larger than the old firmware is all free blocks and is not included in the differential calculation. This results in more free data blocks than in the above two scenarios. Clearly, there will always be free areas in the old firmware area that can store similar block data after the restore location. This data can then be shifted to a location outside the differential calculation after the restore point in the old firmware area (i.e., the location where the restored data blocks are stored) to re-form similar blocks. Therefore, shifting can satisfy all of the above application scenarios, finding one-to-one corresponding similar blocks in the old firmware after the restore point to form differential packets.

[0108] Optionally, when creating a differential packet, a maximum differential restoration length X can be defined. If the size of a similar block or a newly added block is greater than X, segmentation is performed to form adjacent similar blocks or adjacent newly added blocks after splitting, and the size of each data block after splitting is equal to or less than the set size X. The specific value and unit of X are not limited in this embodiment of the application and can be configured based on experimental values ​​or empirical values. Optionally, the unit of X can be bytes. If the block length is greater than the number of bytes of the set size, fragmentation can be performed.

[0109] When performing differential restoration, the restoration is performed in sequence according to the starting position of the new firmware. If the restored data contains similar blocks of data in the storage location of the firmware partition, then this part of the data needs to be moved to the idle part of the firmware partition that has not been differentiated. The idle part that has not been differentiated includes the part that has been released by differential restoration (the idle area recovered later).

[0110] The improved differential algorithm can be divided into the following four parts:

[0111] Differential algorithm module: used to generate differential data based on the original firmware (ie old firmware).

[0112] Data link module: used to manage free blocks (i.e. free intervals, which are the storage space for data other than similar blocks in the old firmware), differential blocks, and newly added blocks, as well as to insert blocks after sharding.

[0113] Space management module: used to manage, recycle, merge and allocate idle areas.

[0114] Sharding processing module: used to shard data blocks larger than the restoration step size X.

[0115] The following diagrams are used to visualize the implementation process of the improved differential algorithm. The implementation steps of the process can be as follows:

[0116] Step 1. Align the new and old firmware

[0117] The original firmware and the new firmware can definitely be stored in the upgrade area (i.e., the firmware partition). When the old firmware is smaller than the new firmware, the old firmware and the new firmware are aligned in size, and the tail of the alignment is used as a free block. For example, if the new firmware size is A and the old firmware size is B, if A>B, the storage space occupied by the old firmware is padded with storage space equal to A minus B, and this space is used as free space.

[0118] Step 2. Colorize the firmware regions. Similar blocks in the old firmware are yellow, free blocks are white, target blocks in the new firmware (data blocks with similar blocks in the old firmware) are red, newly added blocks are blue, and restored blocks (data blocks in the new firmware restored from differential data) are green. This coloring is only for the purpose of illustrating the differential algorithm and is not a required step. The colors used in the coloring are illustrated in the diagram using the corresponding text. For example, "Red 1" in the new firmware represents the first target block in the new firmware, while "Yellow 1" in the old firmware represents a block similar to "Red 1."

[0119] This step actually determines, based on the new firmware and the old firmware, similar blocks between the two, newly added blocks in the new firmware, and free blocks in the old firmware.

[0120] The old firmware only has similar blocks and free blocks, while the new firmware has target blocks and newly added blocks. The number of target blocks in the new firmware is equal to the number of similar blocks in the old firmware. A target block in the new firmware may be located before or after its corresponding similar block in the old firmware. Furthermore, in practice, different target blocks may or may not be the same size, but the principle of differential processing remains the same. For ease of description, the following example uses the same block size as an example.

[0121] Figure 6 The schematic diagram of the principle of the differential restoration method is shown in FIG. Figure 6 As shown in part a, the target blocks in the new firmware are Red 1, Red 2, Red 3, and Red 4. The corresponding blocks in the old firmware are Yellow 1, Yellow 2, Yellow 3, and Yellow 4. White 1, White 2, White 3, and White 4 in the old firmware are free blocks. Blue 1 through Blue 4 in the new firmware are newly added blocks.

[0122] When the size of the old firmware is equal to the new firmware, the total size of the new firmware's newly added blocks is equal to the total size of the old firmware's free blocks. When the old firmware is smaller than the new firmware, due to alignment, the total size of the newly added blocks is equal to the total size of the free blocks. When the old firmware is larger than the new firmware, the total size of the newly added blocks is less than the total size of the free blocks.

[0123] Step 3. Differential movement processing

[0124] Currently, only the old firmware FLASH area (i.e., the firmware partition of the old firmware) is an actual physical resource. The new firmware is the firmware to be upgraded from the old firmware. During forward differential processing, the data in Yellow Area 1 and Red Area 1 form a differential block. After the formation of this differential block, i.e., the rule, Yellow Area 1 can be reclaimed. Correspondingly, during restoration according to the rule, Yellow Area 1 is no longer used. That is, after the embedded device restores the new firmware data in Red Area 1 based on this differential block and the old firmware data in Yellow Area 1, it can delete the data in Yellow Area 1 and reclaim Yellow Area 1 as a free block.

[0125] Specifically, during differential restoration, differential restoration is first performed based on the differential block between the yellow 1 area and the red 1 area and the data of the yellow 1 area ( Figure 6 The restored data (that is, the data in the red 1 area) is stored in the white 1 area (the position in the old firmware corresponding to the red 1 position). The white 1 area is occupied, and the free block white 1 is deleted (that is, the free block white 1 is no longer a free block, but becomes green 1, storing the data of red 1 in the new firmware). Since the yellow 1 area is no longer used after the restoration, the yellow 1 area is recycled into the free block. The firmware partition of the old firmware after restoring the red 1 area is as follows: Figure 6As shown in part b in the figure, white 1 becomes green 1 and yellow 1 becomes white 5.

[0126] Then insert and restore the blue 1 area (that is, the newly added block 1) ( Figure 6 The data in the Blue 1 area is inserted into the corresponding position of the firmware partition, that is, the Yellow 3 area. After the Blue 1 area is restored, the Yellow 3 area will be used, and the data in the Yellow 3 area is a similar block. The data in the Yellow 3 area needs to be moved to the free block behind. After the move, a similar block corresponding to the Red 3 area is formed again. The firmware partition of the old firmware after restoring the Blue 1 area is as follows Figure 6 As shown in part c of , the original yellow 3 becomes green 2, and the data originally stored in yellow 3 is moved to the original white 4 as a new similar block of red 3.

[0127] Then the red 2 area is differentially restored ( Figure 6 Similarly, based on the differential data between the Red 2 area and the Yellow 2 area and the data in the Yellow 2 area, the data in the Red 2 area is restored and stored in the White 2 area in the old firmware corresponding to the position of the Red 2 area. The firmware partition of the old firmware after restoring the Red 2 area is as follows: Figure 6 As shown in part d, the original white 2 becomes green 3, and the original yellow 2 is recycled into the free block, white 6.

[0128] Next is to insert and restore the blue 2 area ( Figure 6 The data in the Blue 2 area is stored in the White 5 area. The firmware partition of the old firmware after restoring the Blue 2 area is as follows: Figure 6 As shown in part e.

[0129] Then perform differential restoration on Red 3 ( Figure 6 3), after performing differential restoration on the red 3 area based on the data in the yellow 3 area and the differential data between red 3 and yellow 3, the firmware partition of the old firmware is as follows Figure 6 As shown in part f, the restored data is stored in the original white 3 area, becoming green 5, and the original yellow 3 area is recycled as white 7.

[0130] Next, insert and restore the blue 3 area ( Figure 6 As shown in the restoration of blue 3), at this time, it is necessary to move the data in the yellow 4 area to the free block, and re-form the similar block corresponding to the red 3 area after the move. After restoring the blue 3 area, the firmware partition of the old firmware is as follows Figure 6 As shown in the g part, the data in the original yellow 4 is moved to the original white 6. After that, the red 4 area is differentially restored, and the resources of the yellow 4 area are recovered after the restoration, that is, the data in the yellow 4 area is deleted, and the firmware partition of the old firmware after the red 4 area is restored is as follows Figure 6 Finally, insert and restore the blue 4 area. The firmware partition of the restored old firmware is as follows Figure 6 As shown in the i part, the data in the storage area of ​​the firmware partition is the new firmware obtained by restoration.

[0131] The above differential restoration steps show that: 1. The total size of the free area is greater than or equal to the newly added area; 2.

[0132] When duplicate areas appear in the differential block (at least two new firmware data blocks correspond to the same old firmware differential block), the free area will increase by the same size. 3. Similar blocks after differentiation (the area where the data in the old firmware used during differential restoration is located) can be recycled and reused. 4. When shifting data blocks, free areas can always be found to store the data to be shifted.

[0133] As can be seen from the above description, differential restoration is performed based on the order of differences with the new firmware. Therefore, the restoration process can be fragmented, that is, each restoration or insertion of a data segment of size X, reducing the resources used for each restoration. Before fragmentation, the length is arbitrary (the data block size of the differential block and the newly added block may be the same or different).

[0134] The following diagram is used to visually illustrate the differential packet generation process based on the fragmentation processing method (i.e., the differential process between the new firmware and the old firmware).

[0135] As an example, Figure 7 Part a shows a schematic diagram of the data blocks in the new and old firmware. Similarly, similar blocks in the old firmware are colored yellow, free blocks are colored white, target blocks in the new firmware are colored red, and newly added blocks are colored blue. The new firmware's differential blocks have the same numbers as their corresponding old firmware differential blocks. For example, a red block in the new firmware corresponds to a yellow block.

[0136] The new firmware is sliced ​​in sequence according to the set size X. The diagram of the first slice processing is as follows Figure 7 As shown in part b, the data size before the vertical line is the set size X. The data before the vertical line in the yellow 3 area (the diagonal line filling part of part b) needs to be moved to the free block behind. Optionally, it can be moved to any block in white 2, white 3 or white 4 (in this example, it is moved to white 2, that is, Figure 7 The yellow 5 in the diagonal filled part of part c) is updated and divided into two parts, one is the original remaining part (the red 3 in part c), and the other is the moved part (the red 5 in part c, which is the similar data corresponding to the yellow 5 in part c). The corresponding relationship between the new firmware and the old firmware after the first fragmentation process is as follows: Figure 7This is shown in section c of the figure. During differential processing, the data before the vertical line in Red Zone 1 forms differential data with the data of the corresponding size in Yellow Zone 1. This is because during differential restoration, the differential data corresponding to the first sub-block (i.e., the data block of size X) of the new firmware obtained after this fragmentation is differentially restored with the data of the corresponding size in Yellow Zone 1 to obtain the sub-block. Afterwards, this part of the data in Yellow Zone 1 can be recycled as a free area. Therefore, the area of ​​White Zone 2 in section c becomes larger.

[0137] The second sharding process is as follows Figure 7 As shown in the d part of , similarly, the data before the vertical line in the yellow 3 area (the part filled with the diagonal line in the d part) needs to be moved to the free block behind, and can be moved to any block among white 2, white 3 or white 4, as shown in Figure 7 As shown in part e of , this part of the data is moved to yellow 6, which is the original white 3 area, and the red 3 in part d is updated (the similar data corresponding to the moved part of the data) and divided into two parts, one is the original remaining part (red 3 in part e), and the other is the moved part (red 6 in part e). The result after the second sharding process is as follows Figure 7 As shown in part e.

[0138] The position of the third sharding is like the vertical line in part f. After this sharding process, the data in yellow 3 before the vertical line in part f is moved to the white 4 area, such as yellow 7 in part g, and the red 3 in part f is divided into red 7 and red 3 in part g.

[0139] The location of the fourth shard is as follows Figure 7 The vertical line in the g part of the fragmentation, the part after the vertical line in the yellow 3 area of ​​the f part and the yellow 5 part of the f part are moved to the yellow 3 area and yellow 5 area shown in the g part respectively. By repeating the fragmentation process, the new target block, new similar block, new newly added block and new free block after the fragmentation process are obtained. According to the above fragmentation processing principle, the differential restoration information (that is, the information used to determine the similar block corresponding to each differential block in the differential packet), the storage location of each new similar block before moving and the storage location after moving (used to indicate where the similar block should be moved during differential restoration) can be obtained. For example, Figure 7 In the example shown, when performing differential restoration based on the differential block between the first small red block after sharding and its corresponding yellow block, the location of the yellow block corresponding to the differential block in the firmware partition can be known based on the differential restoration information. The data of the first small red block can be restored based on the data in the found yellow block and the differential block. The restored data needs to be stored starting from the starting position of the firmware partition, that is, Figure 7The area before the vertical line in the old firmware in part b contains part of the data of yellow 3 and needs to be shifted to the free block behind it. During differential restoration, the shift control information of this part of the data in the differential packet can be used to know which area behind the firmware partition this part of the data needs to be moved to.

[0140] From the above differential process, we can see that: when the differential process is set to length X, the number of fragments n is the firmware size divided by X and the result is rounded down. In the differential process, the differential packet can be formed according to the original differential algorithm, such as Figure 7 As shown in part a, according to the differential packet content, free block nodes (i.e., the above-mentioned free blocks), old firmware differential block nodes (i.e., similar blocks in the above-mentioned old firmware), new firmware differential nodes (target blocks in the new firmware), and newly added block nodes (newly added blocks in the new firmware) are formed respectively. Each node contains the size / length of the node (i.e., the size of the data block) and the original position of the node in the firmware partition (e.g., the offset position of the starting position of the data block relative to the starting position of the firmware partition).

[0141] Afterwards, the differential packet can be regenerated based on the differential nodes and newly added nodes of the new firmware. If the block length is greater than X, it will be fragmented and divided into multiple new differential nodes or newly added nodes less than or equal to X (that is, the new target blocks and newly added blocks obtained after the fragmentation process). After the differential part is completed, the differential resource block in the old firmware is recovered. The differential block content within the length of 0 (that is, the starting position) to n*X in the firmware partition is translated, and the offset position of the differential block is changed to form the translation control information. The differential restoration process is as follows: each time the content with a length of X is restored, the differential restoration is performed according to the differential data, and the translation operation is performed according to the translation control information to find the differential nodes of the old firmware corresponding to the differential nodes of each new firmware after the fragmentation process.

[0142] The software upgrade method provided in the embodiment of the present application can be applicable to, but not limited to, switching between any two of the upgrade modes of AB upgrade mode, differential upgrade mode, and compression upgrade mode. The following uses these upgrade modes as examples to further illustrate the principles of the solution provided in the embodiment of the present application.

[0143] Since the differential upgrade method and the compressed upgrade method only use a single firmware partition, the differential package and the compressed package can be stored from the end of the firmware partition upwards (that is, they can be stored in the tail area of ​​the firmware partition). When using the differential upgrade method or the compressed upgrade method to upgrade, you only need to be able to identify whether the upgrade package at the end is a differential package or an upgrade package. Similarly, in the AB upgrade method, when the firmware is running on the A firmware (that is, the A partition, the partition at the front of the storage area), the position is consistent with the single system firmware. When switching to other upgrade methods, the current upgrade package can be stored from the end of the B firmware partition upwards. In other words, for the upgrade packages of differential packages and compressed packages, it is sufficient to be able to distinguish and identify them.

[0144] Optionally, the upgrade process can be divided into two parts, the first part is the download process, and the second part is the upgrade process. Figure 3 When downloading the upgrade data shown, you can first download the header. If it is determined to be an AB upgrade package (that is, the data packet corresponding to the AB upgrade method), you only need to download the part except the header to the spare partition of the AB upgrade method. After the upgrade is completed, it will be notified that a new partition (that is, the partition upgraded this time) needs to be started at the next startup, that is, the local upgrade identifier is updated.

[0145] For differential upgrade and compression upgrade, the download process is to download the contents of the upgrade package to the storage space from the end of the partition upwards. The upgrade process is to restore the difference or decompress and restore to the original firmware area to replace the original firmware data.

[0146] If the current upgrade method is AB, and the target upgrade method is also AB, after the download process is complete, the boot partition mark is updated to complete the upgrade. If the target upgrade method is differential or compressed, the header content will also be stored to distinguish whether the upgrade package is a differential package or a compressed package during the upgrade.

[0147] It can be seen that when the upgrade mode is switched, since the differential upgrade mode and the compression upgrade mode are single firmware upgrades, the firmware is stored in the firmware partition starting from the starting address of the entire firmware partition, and the upgrade package is saved at the end of the firmware partition. During the upgrade, only the partition upgrade package type is needed to complete the upgrade mode switch. The upgrade package type can be distinguished in the header of the upgrade package (that is, it can be distinguished by the first upgrade identifier).

[0148] When converting from differential or compressed upgrade mode to AB upgrade mode, since the firmware of differential and compressed upgrade modes is stored starting from the starting address of the entire firmware partition, after switching to AB upgrade mode, the upgrade package header information is used to determine that it is an AB upgrade mode. In this case, the entire firmware partition needs to be identified as two system partitions. The upgrade package is first stored in partition B (i.e., the partition with the later storage location). Subsequent upgrades are performed by switching between partitions A and B.

[0149] When the AB upgrade mode is converted to a differential upgrade mode or a compressed upgrade mode, the upgrade package is stored in the backup partition. When the system is currently running in partition A, the upgrade package is stored from the end of partition B upwards. The header distinguishes the upgrade package type, and the system restores the package accordingly during the restore process. When the system is currently running in partition B, the upgrade package is stored from the end of partition A upwards.

[0150] The upgrade method provided in the embodiment of the present application involves the following upgrade identification flags:

[0151] AB upgrade flag, indicating whether to boot from partition A or partition B. When it is differential upgrade mode, this flag is cleared to 0. If it is AB upgrade mode, this flag is valid. If it is switched from AB upgrade mode to differential upgrade mode or compression upgrade mode, this flag is cleared to 0 after the upgrade package is downloaded, and the differential compression upgrade flag is set to 1.

[0152] The differential compression upgrade flag. A value of 1 indicates a differential or compression upgrade. The flag is obtained from the upgrade package header. If the upgrade package uses differential or compression upgrade mode, this flag is set after the upgrade package is downloaded. If the compression or differential upgrade mode is switched to AB upgrade mode, this flag is cleared to 0 and the AB upgrade flag is set to A or B.

[0153] The differential compression address identifier identifies the starting storage address of the upgrade package. It is valid only when the differential compression upgrade identifier is valid.

[0154] Optionally, in actual applications, the local upgrade identifier may include the above-mentioned AB upgrade identifier and the differential compression upgrade identifier. If whichever identifier is valid (such as the above-mentioned setting to 1 indicates valid), it means that the local upgrade method is the upgrade method corresponding to the valid identifier. Of course, the local upgrade identifier can also be an identifier. If the identifier is set to A, it means that the local upgrade method is the AB upgrade method, and the partition targeted by the upgrade is the A partition. If the identifier is set to B, it means that the local upgrade method is the AB upgrade method, and the partition targeted by the upgrade is the B partition. If the identifier is set to 1 (or other values ​​except A and B), it means that the local upgrade method is the compression upgrade method or the differential upgrade method. The form of the first upgrade identifier in the header of the upgrade software package is not limited in the embodiment of the present application. It can be used to distinguish which specific target upgrade method is.

[0155] In addition, the AB upgrade method is a full upgrade method. When the firmware version iteration reaches a certain level, it is impossible to determine the current latest basic version and the partition of the running version. That is, due to various real-world situations, since AB issues a series of version upgrades, but there are individual versions in the middle that are not upgraded, skipping version upgrades may occur during the series upgrade process.

[0156] For example, historical release versions are 1.0.0, 2.0.0, 3.0.0, 4.0.0, and 5.0.0. A consistently online board: The factory version is 1.0.0, running on partition A. After four upgrades, it is upgraded to 5.0.0, also running on partition A. A board that has been online for a period of time: The factory version is 1.0.0, running on partition A. It was not online when 2.0.0 / 3.0.0 / 4.0.0 was released, or it missed the upgrade. It was upgraded once to 5.0.0, running on partition B. Because the AB upgrade method is a full AB upgrade, you can upgrade to the latest version based on any base version.

[0157] When releasing version 6.0.0, if the firmware size exceeds the size of partition A or partition B, the issue of running 5.0.0 on different partitions needs to be considered. Since differential upgrades require consideration of the base version number, 6.0.0 can only be upgraded based on 5.0.0. Non-5.0.0 versions must first be upgraded to 5.0.0 according to the previous upgrade strategy. When version 5.0.0 is running on partition A, the differential package is downloaded to the end of partition B and then the normal differential restore process can be performed upwards. When version 5.0.0 is running on partition B, the differential package can only be stored in the reverse direction at the end of partition A.

[0158] During the specific upgrade process, you can identify the upgrade method (i.e., local upgrade method) in the header of the firmware (second upgrade identifier), and indicate which upgrade package it is (i.e., target upgrade method) in the header of the upgrade software package (first upgrade identifier). The current firmware identifies the firmware area in which it is running (i.e., the target partition in which the device is currently running). After that, the software can be upgraded according to the upgrade method provided in the embodiment of the present application. When the local upgrade method is a differential / compression upgrade method, it is only necessary to identify which upgrade package it is based on the first upgrade identifier. Since the old firmware itself is stored in front of the entire firmware area, the upgrade package is located at the tail of the firmware area. When the upgrade package is an AB upgrade package, it is necessary to start burning from half of the firmware area. At this time, it is necessary to ensure that the previous firmware and the upgraded firmware are not larger than half of the entire firmware area.

[0159] Figure 8 FIG. 1 shows a schematic diagram of a principle of an upgrade method supporting switching between the above three upgrade modes provided in an embodiment of the present application. Figure 8The information in the first column on the left indicates the possible situations of the local upgrade method, which can be determined according to the firmware header (the second upgrade identifier). "Differential" indicates that the local upgrade method is the differential upgrade method, "Compression" indicates that the local upgrade method is the compression upgrade method, "AB→A" indicates that the local upgrade method is the AB upgrade method, and the partition targeted by this upgrade is partition A, and "AB→B" indicates that the local upgrade method is the AB upgrade method, and the partition targeted by this upgrade is partition B. Figure 8 The second column on the left indicates the possible target upgrade methods, which can be determined based on the header of the upgrade software package (the first upgrade identifier). Among them, "differential package" indicates that the target upgrade method is the differential upgrade method, "compressed package" indicates that the target upgrade method is the compressed upgrade method, and "AB package" indicates that the target upgrade method is the AB upgrade method.

[0160] like Figure 8 As shown in , if the local upgrade mode is differential upgrade mode or compressed upgrade mode, and the target upgrade mode is differential upgrade mode or compressed upgrade mode, the upgrade package (differential package or compressed package) can be stored in the tail area of ​​the entire firmware partition ( Figure 8 The ones shown in are stored at the end of partition B), and then you can upgrade using the corresponding upgrade method.

[0161] If the local upgrade method is differential upgrade or compression upgrade, and the target upgrade method is AB upgrade, the AB package needs to be burned from the general location of the firmware partition to the firmware partition (as shown in the figure, based on the current partition (the first 1 / 2 partition of the firmware partition), it is stored in the backup partition (the last 1 / 2 partition of the firmware partition). After this upgrade, the boot partition mark needs to be updated to run the firmware of the B partition (that is, enable the firmware of the backup partition) at the next startup, and the local upgrade mark also needs to be updated.

[0162] If the local upgrade method is AB→A, it means that the system is currently running in partition A. If the target upgrade method is differential or compressed, the differential or compressed package needs to be stored at the end of partition B and the upgrade process will be performed using the corresponding differential or compressed upgrade method. If the local upgrade method is AB→B, it means that the system is currently running in partition B. If the target upgrade method is differential or compressed, the differential or compressed package needs to be stored at the end of partition A and partition B will be restored using differential or compressed methods.

[0163] If both the local upgrade method and the target upgrade method are AB upgrade methods, the AB package is stored in the non-target partition (i.e., the backup partition) according to the currently running target partition (current partition). After the upgrade is completed according to the AB package, the local upgrade flag is updated to inform which partition to start from next time ( Figure 8That is, if the firmware of partition A is upgraded this time, it indicates that the firmware of partition B will be upgraded next time.

[0164] Based on the software upgrade method provided in the embodiment of the present application, when a software upgrade is required, the target upgrade method of the upgrade can be determined based on the first upgrade identifier carried in the software upgrade package, the local upgrade method can be determined based on the second upgrade representation stored locally, and the target storage area of ​​the upgrade package in the firmware partition can be determined based on the local upgrade method. The upgrade package can then be stored in the target storage area. Furthermore, the software upgrade can be implemented using the target upgrade method. Based on this method, software upgrades can be implemented regardless of whether the local upgrade method and the target upgrade method of the software are the same, which can better meet actual application needs.

[0165] Based on the same principle as the method provided in the embodiment of the present application, the embodiment of the present application also provides a software upgrade device, which includes an upgrade data acquisition module 110, an upgrade method determination module 120 and an upgrade processing module 130.

[0166] The upgrade data acquisition module 110 is used to acquire the upgrade data of the software to be upgraded, the upgrade data including the first upgrade identifier and the upgrade package;

[0167] An upgrade mode determination module 120 is configured to determine a target upgrade mode corresponding to the upgrade package according to the first upgrade identifier, and to determine a current local upgrade mode of the software to be upgraded;

[0168] The upgrade processing module 130 is used to determine the target storage area of ​​the upgrade package in the firmware partition according to the local upgrade method, store the upgrade package in the target storage area, and upgrade the software to be upgraded using the target upgrade method based on the upgrade package, wherein the firmware partition is the storage area of ​​the software to be upgraded in the terminal device.

[0169] Optionally, the target upgrade mode is dual-system upgrade mode or single-system upgrade mode, and the local upgrade mode is dual-system upgrade mode or single-system upgrade mode. Optionally, the dual-system upgrade mode is AB upgrade mode, and the single-system upgrade mode is differential upgrade mode or compressed upgrade mode.

[0170] Optionally, when the upgrade processing module determines the target storage area of ​​the upgrade package in the firmware partition according to the local upgrade method, it can be used to: when the local upgrade method is a dual-system upgrade method, determine the target partition where the software to be upgraded is currently running in the firmware partition, and determine the non-target partition of the firmware partition as the target storage area; when the local upgrade method is a single-system upgrade method, if the target upgrade method is the single-system upgrade method, determine the tail area of ​​the firmware partition as the target storage area; if the target upgrade method is the dual-system upgrade method, divide the firmware partition into a first partition and a second partition corresponding to the dual-system upgrade method, and determine the head area of ​​the second partition as the target storage area, wherein the storage area of ​​the second partition is located after the storage area of ​​the second partition.

[0171] Optionally, when the local upgrade mode is a dual-system upgrade mode and the target upgrade mode is a single-system upgrade mode, the upgrade processing module stores the upgrade package in the target storage area and upgrades the upgrade software based on the upgrade package in a target upgrade mode. It can be used to: if the storage area of ​​the target partition is before the non-target partition, store the upgrade package in the tail area of ​​the non-target partition; when the target upgrade mode is a compression upgrade mode, decompress the upgrade package stored in the tail area of ​​the non-target partition, and store the decompressed data in the firmware partition starting from the starting position of the firmware partition; when the target upgrade mode is a differential upgrade mode, perform a differential upgrade based on the upgrade package stored in the tail area of ​​the non-target partition and the data stored in the target partition.

[0172] Optionally, when the local upgrade mode is a dual-system upgrade mode and the target upgrade mode is a single-system upgrade mode, the upgrade processing module can be used to:

[0173] If the storage area of ​​the target partition is located after the non-target partition, the upgrade package is stored in the first space at the end of the non-target partition;

[0174] A second space having the same size as the first space is divided from the tail area of ​​the target partition, and the data stored in the first space is exchanged with the data stored in the second space;

[0175] When the target upgrade mode is a compression upgrade mode, decompressing the upgrade package stored in the second space, and storing the decompressed data in the firmware partition starting from the starting position of the firmware partition;

[0176] When the target upgrade method is a differential upgrade method, a differential upgrade is performed based on the upgrade package stored in the second space, the data stored in the third space of the target partition, and the data stored in the first space, and the upgraded data is stored in the firmware partition starting from the starting position of the firmware partition, wherein the third space is the storage area in the target partition except the second space.

[0177] Optionally, when determining the current local upgrade method of the software to be upgraded, the upgrade method determination module can be used to: obtain a second upgrade identifier of the locally stored software to be upgraded, and determine the local upgrade method based on the second upgrade identifier; wherein, if the local upgrade method is a dual-system upgrade method, the second upgrade identifier is also used to identify the upgrade partition targeted by the upgrade.

[0178] Optionally, when the target upgrade method and the local upgrade method are different, the upgrade processing module is also used to: update the second upgrade identifier to the upgrade identifier corresponding to the target upgrade method when the target upgrade method and the local upgrade method are different; if the local upgrade method and the target upgrade method are both dual-system upgrade methods, the upgrade processing module is also used to: update the upgrade partition identified by the second upgrade identifier.

[0179] Optionally, the upgrade data further includes a storage address identifier, which is used to indicate a starting storage address of the upgrade package in the firmware partition when the target upgrade mode is a single-system upgrade mode.

[0180] The device of the embodiment of the present application can execute the method provided by the embodiment of the present application, and its implementation principle is similar. The actions performed by each module in the device of each embodiment of the present application correspond to the steps in the method of each embodiment of the present application. For the detailed functional description of each module of the device, please refer to the description in the corresponding method shown in the above text, which will not be repeated here. The software upgrade device provided by the embodiment of the present application, when upgrading the software, regardless of whether the target upgrade mode and the local upgrade mode of the software are switched, can determine the storage area of ​​the upgrade package in the firmware partition according to the local upgrade mode, and can know the target upgrade mode according to the first upgrade identifier in the upgrade data, so that the software upgrade can be achieved according to the target upgrade mode. Based on the software upgrade device provided by the embodiment of the present application, it is possible to support mutual upgrades of multiple different software upgrade modes, and upgrades can be achieved even if the software upgrade mode is switched.

[0181] An embodiment of the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, and the processor executes the above computer program to implement the method provided in any optional embodiment of the present application.

[0182] Figure 10 A schematic diagram of the structure of an electronic device applicable to the implementation of this application is shown in FIG. Figure 10 As shown, the electronic device 4000 includes: a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which may be used for data exchange between the electronic device and other electronic devices, such as data transmission and / or data reception. It should be noted that in actual applications, the number of transceivers 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0183] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0184] Bus 4002 may include a path for transmitting information between the above components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. Bus 4002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0185] The memory 4003 can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, without limitation here.

[0186] The memory 4003 is used to store the computer program for executing the embodiment of the present application, and the execution is controlled by the processor 4001. The processor 4001 is used to execute the computer program stored in the memory 4003 to implement the steps shown in the above method embodiment.

[0187] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented.

[0188] An embodiment of the present application also provides a computer program product, including a computer program, which can implement the steps and corresponding contents of the aforementioned method embodiment when executed by a processor.

[0189] The terms "first," "second," "third," "fourth," "1," "2," and the like (if any) in the specification and claims of this application and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the application described herein can be implemented in an order other than that shown or described in the drawings.

[0190] It should be understood that, although each operation step is indicated by arrows in the flowchart of the embodiment of the present application, the order of implementation of these steps is not limited to the order indicated by the arrows. Unless otherwise clearly stated herein, in some implementation scenarios of the embodiment of the present application, the implementation steps in each flowchart can be performed in other orders according to demand. In addition, some or all of the steps in each flowchart can include multiple sub-steps or multiple stages based on actual implementation scenarios. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage in these sub-steps or stages can also be executed at different times respectively. Under different scenarios at the execution time, the execution order of these sub-steps or stages can be flexibly configured according to demand, and the embodiment of the present application does not limit this.

[0191] The above are only optional implementation methods for some implementation scenarios of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the solution of this application, the use of other similar implementation methods based on the technical ideas of this application also falls within the protection scope of the embodiments of this application.

Claims

1. A software upgrade method, characterized in that: The method is performed by an electronic device, and includes: Acquire upgrade data of the software to be upgraded, the upgrade data including a first upgrade identifier and an upgrade package; wherein the first upgrade identifier is used to indicate an upgrade method corresponding to the upgrade package; Determining a target upgrade mode corresponding to the upgrade package according to the first upgrade identifier; Determining a current local upgrade mode of the software to be upgraded; the local upgrade mode refers to a software upgrade mode of the electronic device before the upgrade is performed according to the upgrade package, the local upgrade mode being a dual-system upgrade mode or a single-system upgrade mode, the firmware partition corresponding to the dual-system upgrade mode including two partitions, and the firmware partition corresponding to the single-system upgrade mode including one partition, the firmware partition being a storage area in the electronic device for the software to be upgraded; When the local upgrade mode is a dual-system upgrade mode, determining a target partition where the software to be upgraded is currently running from the two partitions of the firmware partition, and determining a non-target partition of the firmware partition as a target storage area of ​​the upgrade package in the firmware partition; When the local upgrade mode is a single-system upgrade mode, if the target upgrade mode is a single-system upgrade mode, the tail area of ​​the firmware partition is determined as the target storage area; if the target upgrade mode is a dual-system upgrade mode, the firmware partition is divided into a first partition and a second partition corresponding to the dual-system upgrade mode, and the head area of ​​the second partition is determined as the target storage area; wherein the storage area of ​​the second partition is located after the storage area of ​​the first partition; The upgrade package is stored in the target storage area, and the software to be upgraded is upgraded based on the upgrade package using the target upgrade method.

2. The method according to claim 1, characterized in that The dual-system upgrade mode is an AB upgrade mode, and the single-system upgrade mode is a differential upgrade mode or a compression upgrade mode; When the local upgrade mode is a dual-system upgrade mode and the target upgrade mode is a single-system upgrade mode, storing the upgrade package in the target storage area and upgrading the software to be upgraded based on the upgrade package using the target upgrade mode includes: If the storage area of ​​the target partition is located before the non-target partition, storing the upgrade package in the tail area of ​​the non-target partition; When the target upgrade mode is a compression upgrade mode, decompressing the upgrade package stored in the tail area of ​​the non-target partition, and storing the decompressed data in the firmware partition starting from the starting position of the firmware partition; When the target upgrade mode is a differential upgrade mode, a differential upgrade is performed based on the upgrade package stored in the tail area of ​​the non-target partition and the data stored in the target partition.

3. The method according to claim 1, characterized in that The dual-system upgrade mode is an AB upgrade mode, and the single-system upgrade mode is a differential upgrade mode or a compression upgrade mode; When the local upgrade mode is a dual-system upgrade mode and the target upgrade mode is a single-system upgrade mode, storing the upgrade package in the target storage area and upgrading the software to be upgraded based on the upgrade package using the target upgrade mode includes: If the storage area of ​​the target partition is located after the non-target partition, storing the upgrade package in the first space at the end of the non-target partition; dividing a second space of the same size as the first space from the tail area of ​​the target partition, and exchanging the data stored in the first space with the data stored in the second space; When the target upgrade mode is a compression upgrade mode, decompressing the upgrade package stored in the second space, and storing the decompressed data in the firmware partition starting from the starting position of the firmware partition; When the target upgrade method is a differential upgrade method, a differential upgrade is performed based on the upgrade package stored in the second space, the data stored in the third space of the target partition, and the data stored in the first space, and the upgraded data is stored in the firmware partition starting from the starting position of the firmware partition, wherein the third space is a storage area in the target partition excluding the second space.

4. The method according to any one of claims 1 to 3, characterized in that Determining the current local upgrade mode of the software to be upgraded includes: Obtaining a second upgrade identifier of the software to be upgraded stored locally, and determining the local upgrade method according to the second upgrade identifier; If the local upgrade mode is a dual-system upgrade mode, the second upgrade identifier is further used to identify the upgrade partition targeted by the upgrade.

5. The method according to any one of claims 1 to 3, characterized in that The upgrade data further includes a storage address identifier, and the storage address identifier is used to indicate a starting storage address of the upgrade package in the firmware partition when the target upgrade mode is a single system upgrade mode.

6. A software upgrade device, characterized in that: The device is deployed in an electronic device, and includes: An upgrade data acquisition module, configured to acquire upgrade data of the software to be upgraded, wherein the upgrade data includes a first upgrade identifier and an upgrade package; wherein the first upgrade identifier is used to indicate an upgrade method corresponding to the upgrade package; an upgrade mode determination module, configured to determine, based on the first upgrade identifier, a target upgrade mode corresponding to the upgrade package, and determine a current local upgrade mode of the software to be upgraded; the local upgrade mode refers to a software upgrade mode used by the electronic device before the upgrade is performed based on the upgrade package, the local upgrade mode being a dual-system upgrade mode or a single-system upgrade mode; the firmware partition corresponding to the dual-system upgrade mode includes two partitions, and the firmware partition corresponding to the single-system upgrade mode includes one partition; the firmware partition being a storage area in the electronic device for the software to be upgraded; A software processing module is used to determine, when the local upgrade mode is a dual-system upgrade mode, the target partition where the software to be upgraded is currently running from the two partitions of the firmware partition, and determine the non-target partition of the firmware partition as the target storage area of ​​the upgrade package in the firmware partition; when the local upgrade mode is a single-system upgrade mode, if the target upgrade mode is the single-system upgrade mode, determine the tail area of ​​the firmware partition as the target storage area; if the target upgrade mode is a dual-system upgrade mode, divide the firmware partition into a first partition and a second partition corresponding to the dual-system upgrade mode, and determine the head area of ​​the second partition as the target storage area; wherein the storage area of ​​the second partition is located after the storage area of ​​the first partition; store the upgrade package in the target storage area, and upgrade the software to be upgraded based on the upgrade package using the target upgrade mode.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 5.

Images