System upgrade method, device and electronic device based on asymmetric partitioning

Abstract

The present invention provides a system upgrade method, device, and electronic device based on asymmetric partitioning. When the system is started, the boot partition flag for starting the first system partition is read, and the first system in the first system partition is started; if the flag for identifying the failure of the second system upgrade in the second system partition is read, the upgrade failure information of the second system is obtained, and the storage space of the second system partition is larger than the storage space of the first system partition; the second system is upgraded again according to the upgrade failure information of the second system, and after the upgrade is successful, the second system in the second system partition is started. The technical solution provided by the present invention can save costs and avoid wasting resources because the storage space of the second system partition is larger than the storage space of the first system partition. When the flag for identifying the failure of the second system upgrade in the second system partition is read, the second system is upgraded again to ensure the normal operation of the second system.

Description

Technical Field

[0001] The embodiments of the present invention belong to the field of Internet technology, and specifically relate to a system upgrade method, device and electronic device based on asymmetric partitioning. Background Art

[0002] As an independently operating device, an embedded system's software includes its runtime and operating system. Embedded systems can be upgraded through online iterative upgrades during use, gradually improving the user experience. During the upgrade process, the updated system files can be directly overwritten with the existing ones. However, during the upgrade process, problems such as power outages or version errors may occur, causing the upgraded embedded system to malfunction.

[0003] In the prior art, an embedded system is configured with two identical system boot partitions, each containing a new version of system files and an old version of system files. The two versions of the system files serve as backups for each other. During an embedded system upgrade, if a problem occurs with the system files in one partition and the system fails to run, the system can be run using the system files in the other partition, thus ensuring normal operation of the embedded system.

[0004] Although the prior art uses two identical system boot partitions to solve the problem of a system failing to operate normally after an upgrade, any one of the two system partitions only functions when a problem occurs with the system files in the other system partition, resulting in a certain degree of resource waste and increasing the cost of the embedded system. Summary of the Invention

[0005] In order to solve the above-mentioned problems in the prior art, that is, to solve the problem that the existing two identical system partitions increase the cost of the embedded system and cause waste of resources, the embodiments of the present invention provide a system upgrade method, device and electronic device based on asymmetric partitioning.

[0006] An embodiment of the present invention provides a system upgrade method based on asymmetric partitioning, the system upgrade method based on asymmetric partitioning comprising:

[0007] When the system is started, the startup partition flag for starting the first system partition is read, and the first system in the first system partition is started.

[0008] If a flag for identifying a second system upgrade failure in the second system partition is read, the upgrade failure information of the second system is obtained, and the storage space of the second system partition is larger than the storage space of the first system partition.

[0009] The second system is upgraded again according to the upgrade failure information of the second system, and after the upgrade is successful, the second system in the second system partition is started.

[0010] Optionally, the upgrade failure information includes version error information or upgrade error information.

[0011] The step of re-upgrading the second system according to the upgrade failure information and starting the second system in the second system partition after the upgrade is successful includes:

[0012] If the upgrade failure information is version error information, the target version is determined based on the old version before the upgrade failure and the version where the upgrade failed.

[0013] A target upgrade package corresponding to the target version is downloaded from the server, and the second system is upgraded again using the target upgrade package. After the upgrade is successful, the second system in the second system partition is started.

[0014] If the upgrade failure information is upgrade error information, the second system is upgraded again using the upgrade package corresponding to the version that failed to be upgraded, and after the upgrade is successful, the second system in the second system partition is started.

[0015] Optionally, before the system is started and the boot partition flag for booting the first system partition is read, the method further includes:

[0016] When the system is started, the startup partition flag for starting the second system partition is read, and the second system in the second system partition is started.

[0017] If an indication of the second system to be upgraded is detected, an upgrade package is downloaded from the server, and an erasing operation is performed in the second system partition according to the upgrade package to write the upgrade package into the second system partition.

[0018] After the writing is completed, the boot partition flag is set as an upgrade verification flag for verifying whether the second system is successfully upgraded, and the system is restarted to verify whether the second system is successfully upgraded.

[0019] If an upgrade indication of the first system is detected, the boot partition flag is set to a boot partition flag for booting the first system partition, and the system is restarted.

[0020] Optionally, restarting the system to verify whether the second system is successfully upgraded includes:

[0021] After the system is restarted, an upgrade verification flag for verifying whether the second system is successfully upgraded is read, and a verification counter and a new second system are started.

[0022] If the new second system is successfully started, the startup verification counter is cleared.

[0023] If the new second system fails to start up for the first time, the count of the startup verification counter is controlled to be increased by 1, and the second system is started up for the second time.

[0024] Repeat the above steps until the new second system is successfully started, or the count of the verification counter is greater than or equal to a first preset threshold.

[0025] When the count of the verification counter is greater than or equal to the first preset threshold, the boot partition flag is set to the boot partition flag for booting the first system partition, a flag for identifying the failure of the second system upgrade in the second system partition is set, the upgrade failure information of the second system is saved, and the system is restarted.

[0026] Optionally, after starting the first system in the first system partition, the method further includes:

[0027] If the flag used to indicate that the second system upgrade in the second system partition has failed is not read, the upgrade package corresponding to the first system is downloaded from the server, and according to the upgrade package corresponding to the first system, an erasing operation is performed in the first system partition to write the upgrade package corresponding to the first system into the first system partition.

[0028] After writing is completed, the boot partition flag is set as an upgrade verification flag for verifying whether the first system is successfully upgraded, and the system is restarted to verify whether the first system is successfully upgraded.

[0029] Optionally, restarting the system to verify whether the first system is successfully upgraded includes:

[0030] After the system is restarted, an upgrade verification flag for verifying whether the first system is successfully upgraded is read, and a verification counter and a new first system are started.

[0031] If the new first system is successfully started, the startup verification counter is cleared.

[0032] If the new first system fails to start up for the first time, the count of the startup verification counter is controlled to increase by 1, and the first system is started up for the second time.

[0033] Repeat the above steps until the new first system is successfully started, or the count of the verification counter is greater than or equal to a second preset threshold.

[0034] When the count of the verification counter is greater than or equal to the second preset threshold, the boot partition flag is set to the boot partition flag for booting the second system partition, a flag for identifying the failure of the second system upgrade in the second system partition is set, the upgrade failure information of the first system is saved, and the system is restarted.

[0035] Optionally, after setting the boot partition flag to a boot partition flag for booting the second system partition and restarting the system, the method further includes:

[0036] When the system is started, the startup partition flag for starting the second system partition is read, and the second system in the second system partition is started.

[0037] If a flag for identifying that the first system upgrade in the first system partition has failed is read, upgrade failure information of the first system is obtained.

[0038] The first system is upgraded again according to the upgrade failure information of the first system.

[0039] An embodiment of the present invention further provides a system upgrade device based on asymmetric partitioning, comprising:

[0040] The startup module is used to read the startup partition flag used to start the first system partition when the system is started, and start the first system in the first system partition.

[0041] The reading module is configured to obtain upgrade failure information of the second system if a flag indicating that the second system upgrade in the second system partition has failed is read, wherein the storage space of the second system partition is larger than the storage space of the first system partition.

[0042] The upgrading module is used to upgrade the second system again according to the upgrading failure information of the second system, and start the second system in the second system partition after the upgrading is successful.

[0043] Optionally, the upgrade failure information includes version error information or upgrade error information; the upgrade module is specifically used to determine the target version based on the old version before the upgrade failure and the version that failed to upgrade when the upgrade failure information is version error information; download the target upgrade package corresponding to the target version from the server, and upgrade the second system again through the target upgrade package, and after the upgrade is successful, start the second system in the second system partition; and when the upgrade failure information is upgrade error information, upgrade the second system again through the upgrade package corresponding to the version that failed to upgrade, and after the upgrade is successful, start the second system in the second system partition.

[0044] Optionally, the startup module is further configured to, when the system is started, read a boot partition flag for booting the second system partition and boot the second system in the second system partition; upon detecting an indication that the second system is to be upgraded, download an upgrade package from the server, perform an erase operation on the second system partition based on the upgrade package, and write the upgrade package into the second system partition; and upon detecting an indication that the first system is to be upgraded, set the boot partition flag to the boot partition flag for booting the first system partition and restart the system.

[0045] The device further includes a verification module, which is configured to, after writing is completed, set a boot partition flag as an upgrade verification flag for verifying whether the second system is successfully upgraded, and restart the system to verify whether the second system is successfully upgraded.

[0046] Optionally, the verification module is specifically used to read the upgrade verification flag used to verify whether the second system is successfully upgraded after restarting the system, start the verification counter and the new second system; when the new second system is successfully started, clear the startup verification counter; when the new second system fails to start for the first time, control the startup verification counter to add 1, and start the second system for the second time; repeat the above steps until the new second system is successfully started, or the count of the verification counter is greater than or equal to a first preset threshold; when the count of the verification counter is greater than or equal to the first preset threshold, set the startup partition flag to the startup partition flag for starting the first system partition, set the flag for identifying the failure of the second system upgrade in the second system partition, save the upgrade failure information of the second system, and restart the system.

[0047] Optionally, the upgrade module is further configured to, when no flag for indicating that the second system upgrade has failed is read in the second system partition, download an upgrade package corresponding to the first system from the server, and perform an erasing operation on the first system partition based on the upgrade package corresponding to the first system, and write the upgrade package corresponding to the first system into the first system partition;

[0048] The verification module is further configured to, after writing is completed, set the boot partition flag as an upgrade verification flag for verifying whether the first system has been successfully upgraded, and restart the system to verify whether the first system has been successfully upgraded.

[0049] Optionally, the verification module is specifically used to read the upgrade verification flag used to verify whether the first system is successfully upgraded after restarting the system, start the verification counter and the new first system; when the new first system is successfully started, clear the startup verification counter; when the new first system fails to start for the first time, control the startup verification counter to add 1, and start the first system for the second time; repeat the above steps until the new first system is successfully started, or the count of the verification counter is greater than or equal to a second preset threshold; when the count of the verification counter is greater than or equal to the second preset threshold, set the startup partition flag to the startup partition flag for starting the second system partition, set the flag for identifying the failure of the second system upgrade in the second system partition, save the upgrade failure information of the first system, and restart the system.

[0050] Optionally, the startup module is further configured to read a startup partition flag for starting the second system partition when the system starts, and start the second system in the second system partition.

[0051] The reading module is further configured to obtain upgrade failure information of the first system when a flag for identifying the failure of the first system upgrade in the first system partition is read.

[0052] The upgrading module is further configured to upgrade the first system again according to the upgrading failure information of the first system.

[0053] An embodiment of the present invention further provides an electronic device, which includes: a processor, and a memory communicatively connected to the processor.

[0054] The memory stores computer-executable instructions.

[0055] The processor executes the computer-executable instructions stored in the memory to implement the system upgrade method based on asymmetric partitioning described in any one of the above-mentioned preferred technical solutions.

[0056] An embodiment of the present invention further provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the system upgrade method based on asymmetric partitioning described in any of the above-mentioned preferred technical solutions is implemented.

[0057] An embodiment of the present invention further provides a computer program product, including a computer program. When the computer program is executed by a processor, the system upgrade method based on asymmetric partitioning described in any of the above preferred technical solutions is implemented.

[0058] It will be understood by those skilled in the art that an embodiment of the present invention provides a system upgrade method based on asymmetric partitioning. When the system is started, the boot partition flag for starting the first system partition is read, and the first system in the first system partition is started; if the flag for identifying the failure of the second system upgrade in the second system partition is read, the upgrade failure information of the second system is obtained, and the storage space of the second system partition is larger than the storage space of the first system partition; the second system is upgraded again according to the upgrade failure information of the second system, and after the upgrade is successful, the second system in the second system partition is started. The technical solution provided by the present invention enables the storage space of the second system partition to be larger than the storage space of the first system partition, ensuring that the second system partition can realize the complete functions of the embedded system product, while saving production costs and avoiding waste of resources. In addition, after the first system, when the flag for identifying the failure of the second system upgrade in the second system partition is read, the second system is upgraded again, which can avoid the problem that the second system cannot run after the upgrade fails, resulting in the inability of the embedded system to operate normally, thereby ensuring the normal operation of the second system, that is, ensuring the normal use of the product. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 A schematic diagram of the structure of an embedded system partition in the prior art provided by an embodiment of the present invention;

[0060] Figure 2 A schematic diagram of the structure of an asymmetric partition of an embedded system provided by an embodiment of the present invention;

[0061] Figure 3 A schematic diagram of a system upgrade method based on asymmetric partitioning provided by an embodiment of the present invention;

[0062] Figure 4 A schematic diagram of a flow chart of another system upgrade method based on asymmetric partitioning provided by an embodiment of the present invention;

[0063] Figure 5 A schematic diagram of the structure of a system upgrade device based on asymmetric partitioning provided by an embodiment of the present invention;

[0064] Figure 6 This is a structural schematic diagram of an electronic device provided by the present invention. DETAILED DESCRIPTION

[0065] First, those skilled in the art should understand that these embodiments are merely for explaining the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art may adjust them as needed to suit specific applications.

[0066] Secondly, it should be noted that in the description of the embodiments of the present invention, terms such as "inside" and "outside" indicating directions or positional relationships are based on the directions or positional relationships shown in the accompanying drawings. This is only for the convenience of description and does not indicate or imply that the device or component must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it cannot be understood as a limitation on the present invention.

[0067] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0068] The technical solution provided by the embodiment of the present invention can be applied to the scenario of embedded system partitioning. During the use of embedded system products, the user experience can be gradually improved through online iterative upgrades. However, there may be a system upgrade failure during the upgrade process, which makes the system unable to start normally after the upgrade, resulting in the product being unusable. At present, it is mainly achieved by setting up two identical system partitions in the embedded system, namely A and B partitions, to save the new version and the old version of the system, and A and B serve as backups for each other. When the upgrade fails in the new version, the old version can be used for recovery. For details, please refer to Figure 1 As shown, Figure 1 The present invention provides a schematic diagram of the structure of an embedded system partition in the prior art. Figure 1 It can be seen that the embedded system may include a bootloader, an environment variable env, an A partition, a B partition, an environment variable partition of the A partition, an environment variable partition of the B partition, and a data storage space data.

[0069] For example, according to Figure 1 The partitions of the embedded system shown, the bootloader of the embedded system, when determining to start the upgraded system of partition A based on the information in the environment partition of partition A mixed into the environment partition of partition B, if the system of partition A fails to upgrade during the upgrade process, the system startup of partition A fails. At this time, the system of partition B can be started, so that the embedded system product can be used normally.

[0070] While setting up A and B partitions can effectively resolve the issue of a product failing to function properly due to an upgrade failure, the rising cost of chips has increased the cost of using A and B partitions. Furthermore, any system partition in A or B only functions when a problem occurs with the system files in the other partition, resulting in a waste of resources.

[0071] To address the high cost and resource waste of using two identical system partitions, you can set up two asymmetric partitions, that is, two system partitions with different storage capacities. The smaller of the two asymmetric partitions serves as the minimum system, retaining only its upgrade and recovery functions. The larger partition, however, retains all system functions. This allows the smaller partition to re-upgrade the system files in the larger partition if it detects an upgrade failure, ensuring that the system in the larger partition can always boot normally. This solves the issue of system upgrade failure preventing normal booting while significantly saving costs.

[0072] Figure 2 A schematic diagram of the structure of an asymmetric partition of an embedded system provided by an embodiment of the present invention. Figure 2 As shown, an embedded system may include a bootloader, an environment variable env, a first system partition, a second system partition, an environment variable partition for the first system partition, an environment variable partition for the second system partition, and data storage space data. The first system partition is a smaller partition, and the second system partition is a larger partition. According to the technical solution provided by an embodiment of the present invention, during normal system startup, the bootloader can read the environment variable partition for the second system partition in the environment variable env and boot the system of the second system partition. Since the second system partition is a larger partition, that is, the system of the second system partition is a fully functional system, booting the system of the second system partition during each normal system startup ensures normal product use. The bootloader reads the environment variable partition for the first system partition in the environment variable env to boot the system of the first system partition. If, after booting the system of the second system partition, it is detected that the system of the second system partition needs to be upgraded, the upgrade operation is performed on the system of the second system partition. If the upgrade of the system of the second system partition fails, the system is restarted to boot the system of the first system partition. After the system of the first system partition is booted, the system of the second system partition is upgraded again until the upgrade of the system of the second system partition is successful. After the upgrade is successful, the system is restarted to boot the system of the second system partition.

[0073] For example, if after starting the system of the second system partition, it is detected that the system of the first system partition needs to be upgraded, the system is restarted to start the system of the first system partition and upgrade it. After the upgrade is successful, the system is restarted to start the system of the second system partition.

[0074] Therefore, the technical solution provided by the embodiment of the present invention is that the system of the first system partition is started only when it needs to be upgraded or the system upgrade of the second system partition fails, and the system of the second system partition is restarted after the upgrade task is completed. Under normal circumstances, the system of the second system partition is started, which can ensure that the embedded system always runs normally, save costs, and avoid waste of resources.

[0075] The following will describe in detail the system upgrade method based on asymmetric partitioning provided by the present invention through specific embodiments. It is understood that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0076] Figure 3 This is a flow chart of a system upgrade method based on asymmetric partitioning provided by an embodiment of the present invention. The system upgrade method based on asymmetric partitioning can be executed by software and / or hardware devices. For example, the hardware device can be a system upgrade device based on asymmetric partitioning, and the system upgrade device based on asymmetric partitioning can be a terminal or a processing chip in the terminal. For example, see Figure 3 As shown, the system upgrade method based on asymmetric partitioning may include:

[0077] S301. When the system starts, read a boot partition flag for starting a first system partition, and start a first system in the first system partition.

[0078] According to the above embodiment, the first system partition in the embodiment of the present invention only has upgrade and recovery functions. Therefore, in one possible implementation method, when the upgrade of the second system partition fails, the system can be restarted so that when the system starts, the boot partition flag for starting the first system partition can be read, thereby the first system in the first system partition.

[0079] In this possible implementation, before the system is started and the boot partition flag for booting the first system partition is read, the following steps may be included:

[0080] When the system starts, the boot partition flag for starting the second system partition is read, and the second system in the second system partition is started; if an indication of a pending upgrade of the second system is detected, the upgrade package is downloaded from the server, and according to the upgrade package, an erase operation is performed in the second system partition, and the upgrade package is written to the second system partition; after the writing is completed, the boot partition flag is set to an upgrade verification flag for verifying whether the second system has been successfully upgraded, and the system is restarted to verify whether the second system has been successfully upgraded; if an indication of a pending upgrade of the first system is detected, the boot partition flag is set to the boot partition flag for starting the first system partition, and the system is restarted. Among them, starting the system before reading the boot partition flag for starting the first system partition is a normal startup of the system. It can be understood that when the system starts normally, it is necessary to start the second system of the second system partition first.

[0081] For example, after the second system is started in the second system partition, it is necessary to detect whether there is an indication of system upgrade. When an indication of a pending upgrade of the second system is detected, the second system is upgraded. This includes downloading an upgrade package from a server, writing the upgrade package to the second system partition, and restarting the system after the upgrade is complete to verify whether the second system has been successfully upgraded.

[0082] In an embodiment of the present invention, after starting the second system in the second system partition, it is detected whether the first system and the second system need to be upgraded, and corresponding operations are performed, so that when the first system needs to be upgraded, the system is restarted to perform the upgrade operation on the first system. It is possible to determine whether the first system needs to be upgraded without starting the first system, thereby avoiding the problem of the first system being unable to be upgraded.

[0083] For example, when restarting the system to verify whether the second system is successfully upgraded, the upgrade verification flag used to verify whether the second system is successfully upgraded can be read after restarting the system, and the verification counter and the new second system can be started; if the new second system is successfully started, the startup verification counter is cleared; if the new second system fails to start for the first time, the startup verification counter is controlled to add 1, and the second system is started for the second time; the above steps are repeated until the new second system is successfully started, or the count of the verification counter is greater than or equal to the first preset threshold; when the count of the verification counter is greater than or equal to the first preset threshold, the startup partition flag is set to the startup partition flag for starting the first system partition, and a flag for identifying the failure of the second system upgrade in the second system partition is set, the upgrade failure information of the second system is saved, and the system is restarted.

[0084] It is understood that the verification counter is used to record the number of times the second system has verified restarts, and each time the restart fails, the verification counter is incremented by 1. The first preset threshold may be a value greater than or equal to 2, which is not limited in this embodiment of the present invention.

[0085] For example, when the new second system successfully boots, only the boot verification counter needs to be cleared. When the verification counter counts greater than or equal to a first preset threshold, the boot partition flag needs to be set to the boot partition flag used to boot the first system partition, a flag needs to be set to indicate that the second system upgrade in the second system partition has failed, the upgrade failure information for the second system needs to be saved, and the system needs to be restarted. After the system is restarted, the boot partition flag used to boot the first system partition is read, and the first system in the first system partition is started.

[0086] In this embodiment of the present invention, by restarting the new second system to verify whether the second system upgrade was successful, the upgrade status of the second system can be promptly checked. If the second system upgrade fails, a flag indicating the failure of the second system upgrade is set in the second system partition, and the second system upgrade failure information is saved. The system is then restarted. This allows the first system to obtain the second system failure information after starting the first system, allowing it to perform targeted operations. Furthermore, setting a first preset threshold when restarting the new second system can prevent the system from being unusable due to the ongoing restart operation if the second system upgrade fails, thereby improving the user experience.

[0087] S302: If a flag for identifying a second system upgrade failure in the second system partition is read, obtain upgrade failure information of the second system, and the storage space of the second system partition is larger than the storage space of the first system partition.

[0088] For example, setting the storage space of the second system partition larger than that of the first system partition can save costs and enable the second system in the second system partition to have the full functionality of an embedded system product. The embodiment of the present invention does not impose any limitation on the specific product functions.

[0089] S303: Upgrade the second system again according to the upgrade failure information of the second system, and after the upgrade is successful, start the second system in the second system partition.

[0090] For example, the upgrade failure information includes version error information or upgrade error information. When the second system is upgraded again based on the upgrade failure information, if the upgrade failure information is version error information, a target version is determined based on the old version before the upgrade failure and the version that failed to upgrade; a target upgrade package corresponding to the target version is downloaded from the server, and the second system is upgraded again using the target upgrade package. After the upgrade is successful, the second system in the second system partition is started; if the upgrade failure information is upgrade error information, the second system is upgraded again using the upgrade package corresponding to the version that failed to upgrade, and after the upgrade is successful, the second system in the second system partition is started.

[0091] It is understood that when determining the target version based on the old version before the upgrade failure and the version that failed to upgrade, the upgradeable version can be determined based on the old version before the upgrade failure, and the version that failed to upgrade can be removed from all upgradeable versions. The target version can then be determined based on the version number or the size of the upgrade package, or other factors. This embodiment of the present invention does not impose any restrictions on this. For example, if the old version is 1.12 and the version that failed to upgrade is 1.14, all upgradeable versions determined are 1.14, 1.15, and 1.16. Therefore, based on the size of the version number, version 1.16 can be determined as the target version.

[0092] When the upgrade failure information is an upgrade error information, the upgrade error information may be caused by an upgrade interruption, such as a power failure of the device, or other reasons. The embodiment of the present invention does not impose any limitation on the cause of the upgrade error information.

[0093] In an embodiment of the present invention, different re-upgrade operations are performed for version error messages or upgrade error messages. For upgrade error messages, the second system is re-upgraded using the upgrade package corresponding to the failed version, thereby preventing the correct version upgrade package from being mistaken for an incorrect upgrade package and improving the re-upgrade speed.

[0094] It can be seen from this that the system upgrade method based on asymmetric partitioning provided by the embodiment of the present invention reads the boot partition flag for starting the first system partition when the system starts, and starts the first system in the first system partition; if the flag for identifying the failure of the second system upgrade in the second system partition is read, the upgrade failure information of the second system is obtained, and the storage space of the second system partition is larger than the storage space of the first system partition; the second system is upgraded again according to the upgrade failure information of the second system, and after the upgrade is successful, the second system in the second system partition is started. The technical solution provided by the embodiment of the present invention, since the storage space of the second system partition is larger than the storage space of the first system partition, enables the second system partition to realize the complete functions of the corresponding product, while saving costs and avoiding waste of resources. In addition, after the first system, when the flag for identifying the failure of the second system upgrade in the second system partition is read, the second system is upgraded again, which can avoid the problem that the second system cannot run after the upgrade fails, resulting in the embedded system not being able to operate normally.

[0095] In another embodiment of the present invention, after the first system is started, if the flag for identifying the failure of the second system upgrade in the second system partition is not read, the upgrade package corresponding to the first system is downloaded from the server, and according to the upgrade package corresponding to the first system, an erasing operation is performed in the first system partition, and the upgrade package corresponding to the first system is written to the first system partition; after the writing is completed, the boot partition flag is set to an upgrade verification flag for verifying whether the upgrade of the first system is successful, and the system is restarted to verify whether the upgrade of the first system is successful.

[0096] According to the above embodiment, if the flag indicating that the second system upgrade failed in the second system partition is not read, it means that the second system was started before the first system was started, and it was detected that an update operation for the first system was required. Therefore, if the flag indicating that the second system upgrade failed in the second system partition is not read, the upgrade operation is performed on the first system.

[0097] It is understandable that the process of upgrading the first system is the same as the process of upgrading the second system. For details, please refer to the above-mentioned process of upgrading the second system, which will not be described in detail in the embodiment of the present invention.

[0098] In an embodiment of the present invention, when the flag for indicating that the second system upgrade in the second system partition has failed is not read, the first system is upgraded. This can avoid the problem of not upgrading the first system, thereby ensuring that the first system has the latest version and improving the user experience.

[0099] For example, when verifying whether the first system is successfully upgraded, the following steps may be included:

[0100] After restarting the system, an upgrade verification flag for verifying whether the first system has been successfully upgraded is read, and a verification counter and a new first system are started; if the new first system is successfully started, the startup verification counter is cleared; if the new first system fails to start for the first time, the startup verification counter is controlled to be incremented by 1, and the first system is started for the second time; the above steps are repeated until the new first system is successfully started, or the count of the verification counter is greater than or equal to a second preset threshold; when the count of the verification counter is greater than or equal to the second preset threshold, the startup partition flag is set to a startup partition flag for starting the second system partition, a flag for identifying the failure of the second system upgrade in the second system partition is set, and the upgrade failure information of the first system is saved, and the system is restarted.

[0101] For example, the second preset threshold may be a value greater than or equal to 2, and the second preset threshold may be the same as or different from the first preset threshold, which is not limited in this embodiment of the present invention.

[0102] It can be understood that the process of verifying whether the first system upgrade is successful in the present invention is the same as the process of verifying whether the second system upgrade is successful in the above embodiment. For details, please refer to the above embodiment, and the embodiment of the present invention does not make any limitation here.

[0103] In this embodiment of the present invention, by restarting the new first system to verify whether the first system has been successfully upgraded, timely feedback on the upgrade status of the first system can be provided. This avoids the problem of the embedded system not being able to operate normally due to a failure in the first system upgrade when a problem occurs in the second system, ensuring that the embedded system can always operate normally, thereby improving the user experience. In addition, by setting a second preset threshold, it is possible to avoid the need for continuous restart verification when the first system upgrade fails.

[0104] For example, after a first system upgrade fails, when the system is restarted, the boot partition flag for booting the second system partition is read during system startup, and the second system in the second system partition is booted; if the flag for indicating that the first system upgrade failed in the first system partition is read, upgrade failure information of the first system is obtained; and the first system is upgraded again based on the upgrade failure information of the first system.

[0105] In the present invention, the method of re-upgrading the first system is the same as the method of re-upgrading the second system in the above embodiment. The re-upgrade is performed based on the upgrade failure information of the first system. For details, please refer to the above embodiment, and the embodiments of the present invention will not be repeated here.

[0106] In an embodiment of the present invention, when the first system fails to be upgraded, the first system is upgraded again so that the first system is the latest version, thereby improving user experience.

[0107] In order to facilitate understanding of the system upgrade method based on asymmetric partitions provided by the embodiment of the present invention, the following will take the first system partition as a mini partition and the second system partition as a full partition as an example to describe the technical solution provided by the embodiment of the present invention in detail. For details, please refer to Figure 4 As shown, Figure 4 A schematic flow chart of another system upgrade method based on asymmetric partitioning provided by an embodiment of the present invention.

[0108] For example, the two partitions, mini partition and full partition, in the embodiment of the present invention are adjusted through software optimization. The mini partition and the full partition are two asymmetric partitions, one small and one large. The mini partition is the minimum system, which only retains the upgrade and recovery functions. The system of the mini partition can be upgraded, and the system of the full partition can be restored when the system upgrade of the full partition fails. The full partition is a full-function system that can realize complete product functions, and can also realize upgrade and recovery of the mini or full partition separately. It can be understood that by dividing the mini partition and the full partition, the test system can be written to the mini partition during production for production testing. After the product is sold and the network is connected for the first time, the mini partition is upgraded to the minimum system, and the product enters the normal use process.

[0109] according to Figure 4 As shown, the system upgrade method based on asymmetric partitioning provided by the embodiment of the present invention is that after the system starts normally, the bootloader reads the boot partition flag saved in the env partition. For example, in the architecture of the embedded system, the first system partition, i.e., mini, can be represented as the OS_mini partition, and the second system partition, i.e., full partition, can be represented as the OS_full partition. The corresponding boot partitions store the OS_mini system and the OS_full system respectively. After reading the boot partition flag, the following four possible situations may be included:

[0110] Case 1: When the boot partition flag is read as OS_full, the OS_full system in the OS_full partition boots normally. After the OS_full system boots, it checks whether an OS_full or OS_mini upgrade is required. If neither upgrade is required, the OS_full system runs normally. If an OS_mini upgrade is required, the partition boot flag is set to OS_mini, and the system reboots to boot the OS_mini system. If an OS_full upgrade is required, the OS_full upgrade package is downloaded from the server, the existing system files in the OS_full partition are erased, the upgrade package is written to the OS_full partition, the boot partition flag is set to OS_full, the upgrade verification flag is set, and the system reboots. After the system reboots, the boot loader reads the boot partition flag and the upgrade verification flag. If the verification counter is less than or equal to 1, it attempts to boot the upgraded OS_full system for the first time, incrementing the verification counter. If the boot is successful, the upgrade verification flag in env is cleared, and the verification counter is reset. If the boot fails, it will boot again. When the second attempt to boot the upgraded OS_full system fails, the bootloader will set the OS_full system upgrade failure flag, clear the upgrade verification flag, set the boot partition flag to OS_mini, and restart the system.

[0111] Case 2: After the second attempt to start the upgraded OS_full system described in Case 1 fails, when the system is restarted, the bootloader reads the boot partition flag in env, and when it reads the boot OS_mini partition, it starts the OS_mini system. After starting the OS_mini system, it reads the flag indicating that the OS_full system upgrade failed, and reports the relevant version and information of the failed OS_full system upgrade to the server. If the actual cause of the failure is not a version error, it is prioritized to try to restore the previous version and perform a similar upgrade and verification process. The specific relevant versions and information and the upgrade failure information of the second system described in the above embodiment are not described in detail in this embodiment of the present invention.

[0112] Case 3: After booting the OS_full system, if it detects the need to upgrade to OS_mini, the system will be restarted. When the system is restarted, the bootloader reads the boot partition flag in env. When it reads the boot partition flag for the OS_mini partition, it boots the OS_mini system and reads the OS_full upgrade failure flag. If it does not read the OS_full system upgrade failure flag, it executes the OS_mini system upgrade process, downloads the OS_mini system upgrade package from the server, erases the existing system files in the OS_mini partition, writes the upgrade package to the OS_mini partition, sets the partition boot flag to OS_mini, sets the upgrade verification flag, and restarts the system. When the system restarts, the bootloader reads the boot partition flag. When it reads the upgrade verification flag, if the verification counter is less than or equal to 1, it attempts to boot the upgraded OS_mini system for the first time, incrementing the verification counter by 1. If the boot is successful, it clears the upgrade verification flag in env, resets the verification counter, and sets the boot partition flag to OS_full. If the boot fails, a second attempt is made. When the second attempt to boot the upgraded OS_mini system fails, the bootloader sets the OS_mini system upgrade failure flag, clears the upgrade verification flag, sets the boot partition flag to OS_full, and restarts the system.

[0113] Case 4: After the second attempt to start the upgraded OS_mini system as described in Case 3 fails, when the system is restarted, the bootloader reads the boot partition flag in env, reads the boot OS_full partition, and after starting the OS_full system, reads the flag indicating that the OS_mini system upgrade failed, and reports the relevant version and information of the server OS_full system upgrade failure. If the actual cause of the failure is not a version error, it is preferred to try to restore the previous version and perform a similar upgrade and verification upgrade process. The specific relevant versions and information and the upgrade failure information of the first system described in the above embodiment are not described in detail in this embodiment of the present invention.

[0114] To sum up, the technical solution provided by the embodiment of the present invention realizes that the OS_mini system in the OS_mini partition and the OS_full system in the OS_full partition back up each other and repair and upgrade each other by setting asymmetric OS_mini partition and OS_full partition, which saves costs and avoids waste of resources.

[0115] Figure 5 A schematic diagram of a system upgrade device 50 based on asymmetric partitioning according to an embodiment of the present invention is provided. Figure 5 As shown, the system upgrade device 50 based on asymmetric partitioning may include:

[0116] The startup module 501 is used to read the startup partition flag used to start the first system partition when the system starts, and start the first system in the first system partition.

[0117] The reading module 502 is configured to obtain upgrade failure information of the second system if a flag indicating that the second system upgrade in the second system partition has failed is read, and the storage space of the second system partition is larger than the storage space of the first system partition.

[0118] The upgrading module 503 is configured to upgrade the second system again according to the upgrading failure information of the second system, and start the second system in the second system partition after the upgrading is successful.

[0119] Optionally, the upgrade failure information includes version error information or upgrade error information; the upgrade module 503 is specifically used to determine the target version based on the old version before the upgrade failure and the version that failed to upgrade when the upgrade failure information is version error information; download the target upgrade package corresponding to the target version from the server, and upgrade the second system again through the target upgrade package, and after the upgrade is successful, start the second system in the second system partition; and when the upgrade failure information is upgrade error information, upgrade the second system again through the upgrade package corresponding to the version that failed to upgrade, and after the upgrade is successful, start the second system in the second system partition.

[0120] Optionally, the startup module 501 is further configured to, when the system is started, read a boot partition flag for booting the second system partition and boot the second system in the second system partition; upon detecting an indication that the second system is to be upgraded, download an upgrade package from the server, perform an erase operation on the second system partition based on the upgrade package, and write the upgrade package to the second system partition; and upon detecting an indication that the first system is to be upgraded, set the boot partition flag to the boot partition flag for booting the first system partition and restart the system.

[0121] The device further includes a verification module 504, which is configured to, after writing is completed, set the boot partition flag to an upgrade verification flag for verifying whether the second system has been successfully upgraded, and restart the system to verify whether the second system has been successfully upgraded.

[0122] Optionally, the verification module 504 is specifically used to read the upgrade verification flag used to verify whether the second system is successfully upgraded after restarting the system, start the verification counter and the new second system; when the new second system is successfully started, clear the startup verification counter; when the new second system fails to start for the first time, control the startup verification counter to add 1, and start the second system for the second time; repeat the above steps until the new second system is successfully started, or the count of the verification counter is greater than or equal to a first preset threshold; when the count of the verification counter is greater than or equal to the first preset threshold, set the startup partition flag to the startup partition flag for starting the first system partition, set the flag for identifying the failure of the second system upgrade in the second system partition, save the upgrade failure information of the second system, and restart the system.

[0123] Optionally, the upgrade module 503 is also used to download the upgrade package corresponding to the first system in the server when the flag used to identify the failure of the second system upgrade in the second system partition is not read, and perform an erasing operation in the first system partition according to the upgrade package corresponding to the first system, and write the upgrade package corresponding to the first system into the first system partition.

[0124] The verification module 504 is further configured to, after writing is completed, set the boot partition flag as an upgrade verification flag for verifying whether the first system has been successfully upgraded, and restart the system to verify whether the first system has been successfully upgraded.

[0125] Optionally, the verification module 504 is specifically used to read the upgrade verification flag used to verify whether the first system is successfully upgraded after restarting the system, start the verification counter and the new first system; when the new first system is successfully started, clear the startup verification counter; when the new first system fails to start for the first time, control the startup verification counter to add 1, and start the first system for the second time; repeat the above steps until the new first system is successfully started, or the count of the verification counter is greater than or equal to a second preset threshold; when the count of the verification counter is greater than or equal to the second preset threshold, set the startup partition flag to the startup partition flag for starting the second system partition, set the flag for identifying the failure of the second system upgrade in the second system partition, save the upgrade failure information of the first system, and restart the system.

[0126] Optionally, the startup module 501 is further configured to read a startup partition flag for starting the second system partition when the system is started, and start the second system in the second system partition.

[0127] The reading module 502 is further configured to obtain upgrade failure information of the first system when a flag indicating that the first system upgrade has failed is read in the first system partition.

[0128] The upgrading module 503 is further configured to upgrade the first system again according to the upgrading failure information of the first system.

[0129] The system upgrade device based on asymmetric partitioning provided in an embodiment of the present invention can execute the technical solution of the system upgrade method based on asymmetric partitioning in any of the above embodiments. Its implementation principle and beneficial effects are similar to the implementation principle and beneficial effects of the system upgrade method based on asymmetric partitioning. Please refer to the implementation principle and beneficial effects of the system upgrade method based on asymmetric partitioning, and no further details will be given here.

[0130] Figure 6 This is a schematic diagram of the structure of an electronic device provided by the present invention. Figure 6 As shown, the electronic device 600 may include: at least one processor 601 and a memory 602 .

[0131] The memory 602 is used to store programs. Specifically, the programs may include program codes, and the program codes include computer operation instructions.

[0132] The memory 602 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0133] The processor 601 is configured to execute computer-executable instructions stored in the memory 602 to implement the asymmetric partitioning-based system upgrade method described in the aforementioned method embodiment. The processor 601 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention. Specifically, when implementing the asymmetric partitioning-based system upgrade method described in the aforementioned method embodiment, the electronic device may be, for example, an electronic device with processing capabilities, such as a terminal or a server.

[0134] Optionally, the electronic device 600 may further include a communication interface 603. In a specific implementation, if the communication interface 603, the memory 602, and the processor 601 are implemented independently, the communication interface 603, the memory 602, and the processor 601 may be interconnected via a bus and communicate with each other. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified as address buses, data buses, control buses, etc., but this does not mean that there is only one bus or only one type of bus.

[0135] Optionally, in a specific implementation, if the communication interface 603, the memory 602 and the processor 601 are integrated on a chip, the communication interface 603, the memory 602 and the processor 601 can complete communication through an internal interface.

[0136] The present invention also provides a computer-readable storage medium, which may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes. Specifically, the computer-readable storage medium stores program instructions, and the program instructions are used in the method in the above embodiment.

[0137] The present invention also provides a program product including execution instructions stored in a readable storage medium. At least one processor of an electronic device can read the execution instructions from the readable storage medium, and the at least one processor can execute the execution instructions to cause the electronic device to implement the asymmetric partition-based system upgrade method provided in the various embodiments described above.

[0138] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A system upgrade method based on asymmetric partitioning, characterized in that: The method comprises: when the system is started, reading a startup partition flag for starting a first system partition, and starting a first system in the first system partition; If a flag for identifying a second system upgrade failure in the second system partition is read, obtaining upgrade failure information of the second system; wherein the storage space of the second system partition is larger than the storage space of the first system partition; the first system partition is a mini partition, and the second system partition is a full partition; controlling the first system partition to upgrade the second system again according to the upgrade failure information of the second system, and starting the second system in the second system partition after the upgrade is successful; If no flag for identifying that the upgrade of the second system in the second system partition has failed is read, controlling the first system partition to upgrade the first system in the first system partition, and starting the second system in the second system partition after the upgrade is successful; After starting the second system in the second system partition, if an upgrade indication of the second system is detected, upgrading the second system; If the upgrade of the second system fails, the boot partition flag is set to the boot partition flag used to boot the first system partition, a flag for identifying the failure of the second system upgrade in the second system partition is set, the upgrade failure information of the second system is saved, the system is restarted, and the step of reading the boot partition flag used to boot the first system partition is returned.

2. The method according to claim 1, characterized in that The upgrade failure information includes version error information or upgrade error information; The step of re-upgrading the second system according to the upgrade failure information and starting the second system in the second system partition after the upgrade is successful includes: If the upgrade failure information is version error information, the target version is determined based on the old version before the upgrade failure and the version where the upgrade failed; Downloading a target upgrade package corresponding to the target version from the server, upgrading the second system again using the target upgrade package, and starting the second system in the second system partition after the upgrade is successful; If the upgrade failure information is upgrade error information, the second system is upgraded again using the upgrade package corresponding to the version that failed to be upgraded, and after the upgrade is successful, the second system in the second system partition is started.

3. The method according to any one of claims 1 or 2, characterized in that Starting the second system in the second system partition includes: When the system starts, reading the boot partition flag for starting the second system partition, and starting the second system in the second system partition; If an indication of a pending upgrade of the second system is detected, upgrading the second system includes: If an indication of a pending upgrade of the second system is detected, downloading an upgrade package from the server, and performing an erasing operation on the second system partition according to the upgrade package, and writing the upgrade package into the second system partition; After the writing is completed, setting the boot partition flag as an upgrade verification flag for verifying whether the second system is successfully upgraded, and restarting the system to verify whether the second system is successfully upgraded; The method further includes: if an upgrade indication of the first system is detected, setting the boot partition flag to a boot partition flag for booting the first system partition, and restarting the system.

4. The method according to claim 3, characterized in that The restarting the system to verify whether the second system is successfully upgraded includes: After the system is restarted, an upgrade verification flag for verifying whether the second system has been successfully upgraded is read, and a verification counter and a new second system are started; If the new second system is successfully started, the startup verification counter is cleared; If the new second system fails to start up for the first time, the count of the startup verification counter is controlled to increase by 1, and the second system is started up for the second time; Repeat the above steps until the new second system is successfully started, or the count of the verification counter is greater than or equal to a first preset threshold; When the count of the verification counter is greater than or equal to the first preset threshold, the boot partition flag is set to the boot partition flag for booting the first system partition, a flag for identifying the failure of the second system upgrade in the second system partition is set, the upgrade failure information of the second system is saved, and the system is restarted.

5. The method according to claim 1, wherein If the flag for identifying that the upgrade of the second system in the second system partition fails is not read, controlling the first system partition to upgrade the first system in the first system partition includes: If no flag indicating that the second system upgrade in the second system partition has failed is read, downloading an upgrade package corresponding to the first system from the server, performing an erasing operation on the first system partition based on the upgrade package corresponding to the first system, and writing the upgrade package corresponding to the first system into the first system partition; After writing is completed, the boot partition flag is set as an upgrade verification flag for verifying whether the first system is successfully upgraded, and the system is restarted to verify whether the first system is successfully upgraded.

6. The method according to claim 5, characterized in that The restarting the system to verify whether the first system is successfully upgraded includes: After the system is restarted, an upgrade verification flag for verifying whether the first system has been successfully upgraded is read, and a verification counter and a new first system are started; If the new first system is successfully started, the startup verification counter is cleared; If the new first system fails to start up for the first time, the count of the startup verification counter is controlled to increase by 1, and the first system is started up for the second time; Repeat the above steps until the new first system is successfully started, or the count of the verification counter is greater than or equal to a second preset threshold; When the count of the verification counter is greater than or equal to the second preset threshold, the boot partition flag is set to the boot partition flag for booting the second system partition, a flag for identifying the failure of the first system upgrade in the second system partition is set, the upgrade failure information of the first system is saved, and the system is restarted.

7. The method according to claim 6, characterized in that After setting the boot partition flag to a boot partition flag for booting the second system partition and restarting the system, the method further includes: When the system starts, reading the boot partition flag for starting the second system partition, and starting the second system in the second system partition; If a flag for identifying a first system upgrade failure in the first system partition is read, obtaining upgrade failure information of the first system; The first system is upgraded again according to the upgrade failure information of the first system.

8. A system upgrade device based on asymmetric partitioning, characterized in that: include: A startup module, configured to read a startup partition flag for starting the first system partition and start the first system in the first system partition when the system starts; a reading module, configured to obtain upgrade failure information of the second system if a flag indicating a second system upgrade failure is read in the second system partition; wherein the storage space of the second system partition is larger than the storage space of the first system partition; the first system partition is a mini partition, and the second system partition is a full partition; an upgrading module, configured to control the first system partition to upgrade the second system again according to the upgrade failure information of the second system, and to start the second system in the second system partition after the upgrade is successful; The reading module is further configured to control the first system partition to upgrade the first system in the first system partition if no flag for indicating that the upgrade of the second system in the second system partition has failed is read, and to start the second system in the second system partition after the upgrade is successful; The startup module is further configured to set the startup partition flag to the startup partition flag for starting the first system partition if the upgrade of the second system fails, set a flag for identifying the failure of the second system upgrade in the second system partition, save the upgrade failure information of the second system, restart the system, and return to the step of reading the startup partition flag for starting the first system partition.

9. An electronic device comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images