Equipment system upgrade methods and devices, electronic devices and storage media

Abstract

This invention proposes a method, apparatus, electronic device, and storage medium for upgrading a device system. The method includes: determining a first partition based on the currently running first firmware of the device system, wherein the first firmware is stored in the first partition; storing a second firmware in a second partition; upgrading the device system according to the second firmware; determining whether the upgrade is successful; and if the upgrade fails, controlling the device system to enter the first partition and run the first firmware. This invention achieves device system upgrades by storing the upgrade firmware in a second partition that is not currently running on the device system, and then controlling the device system to switch to running in the second partition. Furthermore, when the upgrade fails, the device system is controlled to switch back to the first partition and run the original first firmware, thus solving the problem of the inability to self-recover after a failed upgrade in related technologies.

Description

Technical Field

[0001] This invention relates to the field of household appliance technology, and more specifically, to a method and apparatus for upgrading a device system, an electronic device, and a storage medium. Background Technology

[0002] With the rapid development of IoT technology, market demand for IoT devices is also changing daily. To meet these evolving user needs, upgrading the software of existing IoT devices via OTA (Over-The-Air) updates is crucial. However, traditional upgrade methods suffer from the inability to recover from upgrade failures. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art or related art.

[0004] Therefore, the first aspect of the present invention proposes a method for upgrading a device system.

[0005] A second aspect of the present invention provides an upgrade device for an equipment system.

[0006] A third aspect of the present invention provides an electronic device.

[0007] A fourth aspect of the present invention provides a storage medium.

[0008] In view of this, according to a first aspect of the present invention, a method for upgrading a device system is proposed, comprising: determining a first partition based on a first firmware currently running on the device system, wherein the first firmware is stored in the first partition; storing a second firmware in a second partition; upgrading the device system based on the second firmware; determining whether the upgrade of the device system is successful; and if the upgrade of the device system fails, controlling the device system to enter the first partition and run the first firmware.

[0009] The device system upgrade method provided by this invention is mainly used for upgrading devices via OTA (Over-The-Air) technology. The device has multiple partitions, including: a boot partition, a first partition, a second partition, a firmware information partition, and a user data partition. The boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first or second partition based on data from the firmware information and user data partitions. The first and second partitions store the firmware; the device system's operating logic is implemented by the code in these partitions, and the OTA upgrade targets the firmware in these partitions. The firmware information partition stores the basic data required by the boot partition to select the running partition, such as firmware length information and the firmware's CRC (Cyclic Redundancy Checksum) checksum. The user data partition mainly stores data that needs to be saved during power loss, such as device operating parameters, device unique code, and rollback flags. The device system upgrade method mainly includes: firstly, determining the first partition based on the first firmware currently running on the device system, where the first firmware is stored in the first partition, i.e., determining which partition the device system was running on before the upgrade, and then using this partition as the first partition. The second firmware is then stored in a second partition. This second partition may contain other firmware or no firmware at all. The second firmware is the upgraded firmware, stored in a non-currently running partition of the device system. The device system is then upgraded based on the second firmware, meaning the device system switches its running partition from the first partition before the upgrade to the second partition. This allows the device system to run the second firmware in the second partition, thus completing the upgrade. Next, the success of the upgrade is determined by whether the device system runs the second firmware smoothly. If the device system runs the second firmware smoothly and normally, the upgrade is successful, and the device system can continue running the second firmware in the second partition. If the device system cannot run the second firmware normally, the upgrade has failed, and the device system needs to return to the first partition to run the original firmware, thus achieving self-recovery. This invention achieves device system upgrades by storing the upgraded firmware in a second partition that is not currently running on the device system, and then controlling the device system to switch from the first partition to the second partition. Simultaneously, when the device system upgrade fails, the device system switches back to the first partition to run the original firmware, thus solving the problem of the inability to self-recover after a failed device system upgrade in related technologies.

[0010] The upgrade method for the device system according to the present invention may also have the following technical features:

[0011] In some technical solutions, optionally, the steps for determining whether the upgrade of the device system is successful include: controlling the device system to enter the boot partition and incrementing the number of times the boot partition is run by one to obtain a first number of runs, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; obtaining a second number of runs for the second partition; determining a first difference between the first number of runs and the second number of runs; and determining that the device system upgrade has failed if the first difference is greater than a first preset threshold.

[0012] In this technical solution, the steps for determining whether a device system upgrade is successful include: recording the number of times the device system enters the boot partition each time it does so. Similarly, when the device system enters the first and second partitions, the number of times it enters each partition is also recorded after the firmware runs normally. Therefore, after the device system completes the upgrade and restarts, it first controls the device system to enter the boot partition and increments the boot partition's running count (i.e., the number of times the device system enters the boot partition) to obtain the first running count. The boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first or second partition based on data in the firmware information area and user data area through a series of checks. Then, the second running count of the second partition is obtained, i.e., the number of times the device system enters the second partition. Since this is after the device system upgrade, the second firmware in the second partition is the upgraded firmware, so the device system needs to enter the second partition to run the second firmware, hence the need to obtain the second running count of the second partition. Then, the first number of runs is compared with the second number of runs to determine a first difference between them. If the first difference is greater than a first preset threshold, it indicates that the device system cannot run the second firmware normally in the second partition. Therefore, it is not necessary to control the device system to enter the second partition, and the device system upgrade is directly judged as failed. If the first difference is less than the first preset threshold, the device system is controlled to enter the second partition normally. If the device system can run the second firmware normally in the second partition, the second run count for the second partition is incremented by one, and then the system is controlled to run normally. If the device system cannot run the second firmware normally in the second partition, the device system is controlled to restart and the above steps are repeated until the first difference is greater than the first preset threshold or the device system can run the second firmware normally in the second partition. This invention realizes the judgment of the success or failure of the device system upgrade by calculating the difference between the number of times the device system enters the boot partition and the number of times it enters the second partition.

[0013] In some technical solutions, optionally, the step of controlling the device system to enter the first partition and run the first firmware if the device system upgrade fails includes: determining the validity of the first firmware in the first partition; if the first firmware is valid, controlling the device system to enter the first partition and run the first firmware, clearing the rollback flag, and marking the second partition; if the first firmware is invalid, controlling the device system to send a reminder message to the user.

[0014] In this technical solution, the steps for controlling the device system to enter the first partition and run the first firmware when the device system upgrade fails include: Since the device system upgrade failed, meaning the device system cannot run the second firmware normally in the second partition, in order to enable the device system to run normally again, it is necessary to control the device system to re-enter the first partition and run the first firmware before the upgrade, i.e., the device system needs to perform a rollback operation. When the device system performs a rollback operation, it is first necessary to determine the validity of the first firmware in the first partition, i.e., to determine whether the first firmware in the first partition is complete and usable. When the first firmware is valid, the device system is controlled to enter the first partition and run the original first firmware, while simultaneously clearing the rollback flag. The rollback flag is stored in the user data partition; when a rollback operation is detected, the rollback flag is automatically set. Therefore, when the system enters the first partition and re-runs the original first firmware, i.e., the device system rollback operation is complete, the rollback flag needs to be cleared. Simultaneously, the second partition also needs to be marked. Since the device system cannot run the second firmware in the second partition, it indicates that the second firmware in the second partition is invalid, therefore the second partition needs to be marked as invalid. When the first firmware is invalid, it means the device system cannot access the first partition to run the first firmware. Therefore, a reminder message needs to be sent to the user, informing them that the device system is damaged and to contact after-sales service. This invention ensures that the rollback operation can proceed normally by determining the validity of the first firmware in the first partition during the rollback operation of the device system.

[0015] In some technical solutions, optionally, the steps for determining whether the device system upgrade is successful include: controlling the device system to enter the boot partition and recording the current time, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; obtaining the first time when the device system last entered the boot partition; determining a second difference between the current time and the first time; and determining that the device system upgrade failed if the second difference is within a preset range.

[0016] In this technical solution, the steps for determining whether a device system upgrade is successful include: After the device system enters the running partition, if firmware execution fails, the watchdog timer (embedded system monitoring device) will cause the device system to periodically restart. Therefore, the current time is recorded each time the device system enters the boot partition. After the device system upgrade is complete and the device system restarts, it first controls the device system to enter the boot partition and records the current time the device system enters the boot partition. The boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first partition or the second partition based on data in the firmware information area and the user data area through a series of judgments. Then, the first time the device system last entered the boot partition is obtained. Then, the first time is compared with the current time to determine the second difference between the current time and the first time. When the second difference is within a preset range, where the preset range is determined by the watchdog timer time, it indicates that the device system cannot run the second firmware normally in the second partition. Therefore, it is not necessary to control the device system to enter the second partition, and the device system upgrade is directly judged as failed. When the second difference is not within the preset range, the control device system normally enters the second partition. If the device system can run the second firmware normally within the second partition, the control system operates normally. If the device system cannot run the second firmware normally within the second partition, the watchdog timer (embedded system monitoring device) is reset to restart the device system and repeat the above steps until the second difference is within the preset range or the device system can run the second firmware normally within the second partition. This invention calculates the difference between the current time when the device system enters the boot partition and the first time it entered the boot partition last time, thereby determining the success or failure of the device system upgrade.

[0017] In some technical solutions, optionally, the step of controlling the device system to enter the first partition and run the first firmware based on the failure of the device system upgrade includes: determining the validity of the first firmware in the first partition when the number of device system upgrade failures exceeds a second preset threshold; controlling the device system to enter the first partition and run the first firmware based on the validity of the first firmware, clearing the rollback flag bit, and marking the second partition; and controlling the device system to send a reminder message to the user based on the invalidity of the first firmware.

[0018] In this technical solution, the steps for controlling the device system to enter the first partition and run the first firmware when the device system upgrade fails include: Since the device system upgrade failed, meaning the device system cannot run the second firmware normally in the second partition, in order to enable the device system to run normally again, it is necessary to control the device system to re-enter the first partition and run the first firmware before the upgrade, i.e., the device system needs to perform a rollback operation. During the rollback operation, the number of times the device system upgrade failed is first recorded. When the number is less than a second preset threshold, the device system is controlled to enter the second partition and run the second firmware, i.e., the device system is controlled to try again. If the number is greater than the second preset threshold, the validity of the first firmware in the first partition needs to be determined, i.e., whether the first firmware in the first partition is complete and usable. When the first firmware is valid, the control system enters the first partition and runs the original first firmware. Simultaneously, the rollback flag is cleared. This rollback flag, stored in the user data partition, is automatically set when a rollback operation is detected. Therefore, when the control system enters the first partition and re-runs the original first firmware (i.e., the rollback operation is complete), the rollback flag needs to be cleared. The second partition also needs to be marked. Since the device system cannot run the second firmware in the second partition, it indicates that the second firmware in the second partition is invalid, hence the second partition needs to be marked as invalid. When the first firmware is invalid, the device system also cannot enter the first partition to run the first firmware. Therefore, a reminder message needs to be sent to the user, informing them that the device system is damaged and requesting after-sales service. This invention ensures that the rollback operation can function correctly by determining the validity of the first firmware in the first partition during the rollback operation.

[0019] In some technical solutions, the device system upgrade method may optionally include: based on the successful upgrade of the device system, receiving the user's first operation, wherein the first operation is to cause the device system to perform a version rollback operation; setting the rollback flag and controlling the device system to restart; determining the validity of the first firmware in the first partition; based on the validity of the first firmware, controlling the restarted device system to enter the first partition and run the first firmware, and clearing the rollback flag.

[0020] In this technical solution, the device system upgrade method also includes: when a user performs an OTA firmware upgrade and finds that the upgraded firmware does not meet their usage habits, and the device system continues to use the old firmware, a version rollback operation can be performed on the device system. That is, after a successful device system upgrade, the system can receive the user's first operation, which is to perform a version rollback operation. For example, the user can perform a version rollback operation via remote control, APP (Application), voice, or physical buttons on the device. After receiving the first operation, the rollback flag in the user data partition is set, and then the device system is restarted. The validity of the first firmware in the first partition is then determined, i.e., whether the first firmware in the first partition is complete and usable. If the first firmware is valid, the device system is controlled to enter the first partition and run the original first firmware, while the rollback flag is cleared. If the first firmware is invalid, it means that the device system cannot enter the first partition to run the first firmware, so a reminder message needs to be sent to the user to inform them of the rollback failure. This invention solves the problem in related technologies where users cannot revert after upgrading by receiving the user's first operation and then controlling the device system to roll back to the first partition and run the first firmware before the upgrade.

[0021] In some technical solutions, optionally, the step of setting the rollback flag and controlling the device system to restart includes: determining whether the second firmware in the second partition allows rollback; and setting the rollback flag and controlling the device system to restart if the second firmware allows rollback.

[0022] In this technical solution, the steps of setting the rollback flag and controlling the device system to restart include: when the user performs a rollback operation, it is necessary to first determine whether the firmware currently running on the device system, i.e., the second firmware in the second partition, allows rollback. If rollback is not allowed, an audible and visual prompt is issued to remind the user. Generally, when the currently running firmware (the second firmware) is fixing some critical issues, such as vulnerabilities that seriously affect device performance, user safety, or adding anti-attack methods, rollback is prohibited. If the second firmware allows rollback, the rollback flag is set, and the device system is controlled to restart. By determining whether the currently running firmware allows rollback during the rollback operation, the normal operation of the device system is ensured.

[0023] In some technical solutions, optionally, the step of determining the legitimacy of the first firmware in the first partition includes: controlling the restarted device system to enter the boot partition, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; detecting the state of the rollback flag bit in the boot partition; and determining the legitimacy of the first firmware in the first partition based on the rollback flag bit being set.

[0024] In this technical solution, the steps for determining the legitimacy of the first firmware within the first partition include: firstly, controlling the rebooted device system to enter the boot partition, where the boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first or second partition based on data in the firmware information area and user data area through a series of checks. Then, the status of the rollback flag is checked within the boot partition. If the rollback flag is zero, it indicates that the device system does not need to perform a rollback operation, and the device system is directly controlled to enter the second partition to run the second firmware. If the rollback flag is set, it indicates that the device system needs to perform a rollback operation, therefore, the legitimacy of the first firmware within the first partition needs to be determined.

[0025] In some technical solutions, optionally, the step of determining the legality of the first firmware in the first partition further includes: calculating the first verification information of the first firmware in the first partition; obtaining the second verification information of the stored first firmware; and determining the legality of the first firmware based on the first verification information and the second verification information.

[0026] In this technical solution, the step of determining the legality of the first firmware within the first partition further includes: firstly, calculating the first verification information of the first firmware within the first partition, wherein the first verification information includes the length information of the first firmware and the CRC checksum of the first firmware. Then, obtaining the second verification information of the first firmware previously stored in the firmware information partition, wherein the second verification information includes the previously stored length information and the previously stored CRC checksum of the first firmware. The first and second verification information are then compared. If they match, the first firmware is legal, meaning the device system can run the first firmware. If they do not match, the first firmware is invalid, meaning the device system cannot run the first firmware.

[0027] In some technical solutions, optionally, the step of upgrading the device system according to the second firmware includes: writing the third verification information of the second firmware into the firmware information partition and setting the upgrade flag bit, wherein the firmware information partition includes the basic data required when selecting the boot partition; controlling the device system to enter the boot partition and detecting the upgrade flag bit; calculating the fourth verification information of the second firmware in the second partition based on the upgrade flag bit being set; and controlling the device system to enter the second partition and run the second firmware based on the fourth verification information being the same as the third verification information, and clearing the upgrade flag bit.

[0028] In this technical solution, the steps for upgrading the device system based on the second firmware include: when the second firmware is stored in the second partition, the third verification information of the second firmware is written to the firmware information partition, and the upgrade flag bit in the firmware information partition is set. The firmware information partition stores basic data required for the boot partition to select the running partition, such as: boot partition startup count, startup time, firmware length in the first or second partition, firmware CRC checksum, startup count, software version number, whether rollback is allowed, current running partition, upgrade flag bit, number of startup failures, and upgrade result. The third verification information includes the length information of the second firmware and the CRC checksum. Then, the device system is controlled to restart and enter the boot partition. When the upgrade flag bit is detected as set in the boot partition, the fourth verification information of the second firmware in the second partition is calculated, i.e., the length information of the second firmware and the CRC checksum are calculated. Verification is then performed. If the calculated fourth verification information is the same as the previously stored third verification information, the verification is successful, and the device system is controlled to enter the second partition and run the second firmware, while the upgrade flag bit is cleared. This invention ensures that the device system can operate normally with the second firmware by verifying the length information and CRC checksum of the second firmware.

[0029] According to a second aspect of the present invention, an upgrade apparatus for a device system is provided, comprising: a first determining module, configured to determine a first partition based on a first firmware currently running on the device system, wherein the first firmware is stored in the first partition; a first storing module, configured to store a second firmware in the second partition; a first control module, configured to upgrade the device system according to the second firmware; a judging module, configured to judge whether the upgrade of the device system is successful; and a second control module, configured to control the device system to enter the first partition and run the first firmware if the upgrade of the device system fails.

[0030] The device system upgrade apparatus provided by this invention mainly includes: a first determining module, a first storing module, a first controlling module, a judging module, and a second controlling module. Firstly, the first determining module determines a first partition based on the first firmware currently running on the device system. The first firmware is stored in the first partition, meaning it determines which partition the device system was running on before the upgrade, and then designates this partition as the first partition. Next, the first storing module stores the second firmware in a second partition. The second partition may contain other firmware or no firmware; the second firmware is the upgraded firmware, meaning it is stored in a non-currently running partition of the device system. Then, the first controlling module upgrades the device system based on the second firmware, i.e., it controls the device system to switch its running partition from the first partition before the upgrade to the second partition, thereby allowing the device system to run the second firmware in the second partition, thus completing the upgrade. Finally, the judging module judges whether the upgrade of the device system is successful, i.e., whether the device system runs the second firmware smoothly. If the device system runs the second firmware smoothly, i.e., it can operate normally, it indicates that the upgrade is successful, and the device system can continue to run the second firmware in the second partition. If the device system fails to run properly when running the second firmware, it indicates an upgrade failure. The second control module then needs to control the device system to return to the first partition and run the original firmware, thus achieving self-recovery. This invention achieves the upgrade by storing the upgrade firmware in a second partition that is not currently running on the device system, and then controlling the device system to switch from the first partition to the second partition. Simultaneously, when the device system upgrade fails, it switches back to the first partition to run the original firmware, thus solving the problem of the inability to self-recover after a failed upgrade in related technologies.

[0031] According to a third aspect of the present invention, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the device system upgrade method as described in any of the preceding claims.

[0032] The electronic device provided by the present invention, when the processor executes a computer program, implements the steps of the above-mentioned device system upgrade method, which can achieve the technical effects of any of the above technical solutions, and will not be elaborated here.

[0033] According to a fourth aspect of the invention, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the steps of the device system upgrade method as described in any of the preceding claims.

[0034] The storage medium provided by this invention, when the computer program is executed by the processor, implements the steps of the above-described device system upgrade method, and can achieve the technical effects of any of the above technical solutions, which will not be elaborated here.

[0035] Additional aspects and advantages of the invention will become apparent in the following description or may be learned by practice of the invention. Attached Figure Description

[0036] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0037] Figure 1 One of the flowcharts illustrating an embodiment of the device system upgrade method of the present invention is shown;

[0038] Figure 2 This is a flowchart illustrating one of the steps in a device system upgrade method according to an embodiment of the present invention for determining whether the device system upgrade is successful;

[0039] Figure 3 This is one of the flowcharts illustrating the steps of a device system upgrade method according to an embodiment of the present invention, which involves controlling the device system to enter a first partition and running the first firmware if the device system upgrade fails.

[0040] Figure 4 This is a second flowchart illustrating the step of determining whether the upgrade of the device system is successful in a device system upgrade method according to an embodiment of the present invention.

[0041] Figure 5 The second flowchart illustrates the steps of controlling the device system to enter the first partition and run the first firmware in a device system upgrade method according to an embodiment of the present invention if the device system upgrade fails.

[0042] Figure 6 A second schematic flowchart illustrating an embodiment of the device system upgrade method of the present invention is shown.

[0043] Figure 7 The diagram illustrates a step in an upgrade method for a device system according to an embodiment of the present invention, which involves setting a rollback flag and controlling the device system to restart.

[0044] Figure 8 This is one of the flowcharts illustrating the step of determining the legality of the first firmware within the first partition in an upgrade method for a device system according to an embodiment of the present invention;

[0045] Figure 9 This is a second flowchart illustrating the step of determining the legality of the first firmware within the first partition in an upgrade method for a device system according to an embodiment of the present invention.

[0046] Figure 10A flowchart illustrating the step of upgrading the device system according to a second firmware in a device system upgrade method according to an embodiment of the present invention is shown.

[0047] Figure 11 A schematic block diagram of a device according to an embodiment of the present invention is shown;

[0048] Figure 12 A schematic diagram of a user rollback system method according to an embodiment of the present invention is shown;

[0049] Figure 13 One of the schematic diagrams illustrates a device system self-recovery method according to an embodiment of the present invention;

[0050] Figure 14 A second schematic diagram of a device system self-recovery method according to an embodiment of the present invention is shown;

[0051] Figure 15 A schematic block diagram of an upgrade apparatus for a device system according to an embodiment of the present invention is shown;

[0052] Figure 16 A schematic block diagram of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0053] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other.

[0054] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0055] Figure 1 A flowchart illustrating one embodiment of a device system upgrade method according to the present invention is shown. The method includes:

[0056] Step 102: Determine the first partition based on the first firmware currently running on the device system, wherein the first firmware is stored in the first partition;

[0057] Step 104: Store the second firmware to the second partition;

[0058] Step 106: Upgrade the device system according to the second firmware;

[0059] Step 108: Determine whether the device system upgrade was successful;

[0060] Step 110: If the device system upgrade fails, control the device system to enter the first partition and run the first firmware.

[0061] The device system upgrade method provided by this invention is mainly used for upgrading devices via OTA (Over-The-Air) technology. The upgrade method primarily includes: First, determining the first partition based on the currently running first firmware of the device system. The first firmware is stored in the first partition, which determines the partition the device system was running on before the upgrade, and this partition is then designated as the first partition. Then, storing the second firmware in the second partition. The second partition may contain other firmware or none; the second firmware is the upgraded firmware, meaning the upgraded firmware is stored in a non-currently running partition of the device system. Next, upgrading the device system based on the second firmware involves controlling the device system to switch its running partition from the first partition to the second partition, allowing the device system to enter the second partition and run the second firmware, thus completing the upgrade. Finally, determining whether the upgrade was successful involves checking if the device system runs the second firmware smoothly. If the device system runs the second firmware smoothly and normally, the upgrade is successful, and the device system can continue running the second firmware in the second partition. If the device system cannot run the second firmware normally, the upgrade has failed, and the device system needs to return to the first partition and run the first firmware before the upgrade, thus achieving self-recovery of the device system. This invention upgrades the device system by storing the upgrade firmware in a second partition that is not currently running on the device system, and then controlling the device system to switch from the first partition to the second partition. Simultaneously, if the device system upgrade fails, the system switches back to the first partition to run the original firmware, thus solving the problem of the inability to self-recover after a failed upgrade in related technologies.

[0062] Figure 2 This illustration shows one of the flowcharts illustrating a step in a device system upgrade method according to an embodiment of the present invention for determining whether the device system upgrade is successful; wherein, the step of determining whether the device system upgrade is successful includes:

[0063] Step 202: Control the device system to enter the boot partition, and increment the number of times the boot partition is run by one to obtain the first number of runs. The boot partition is used to determine whether the device system enters the first partition or the second partition.

[0064] Step 204: Obtain the second run count for the second partition;

[0065] Step 206: Determine the first difference between the first number of runs and the second number of runs;

[0066] Step 208: If the first difference is greater than the first preset threshold, the device system upgrade is determined to have failed.

[0067] In this embodiment, the step of determining whether the device system upgrade is successful includes: recording the number of times the device system enters the boot partition each time it enters the boot partition. Similarly, when the device system enters the first partition and the second partition, the number of times it enters that partition is also recorded after the device system runs the firmware normally. Therefore, after the device system completes the upgrade and restarts, it first controls the device system to enter the boot partition and increments the number of times the boot partition is run (i.e., the number of times the device system enters the boot partition) to obtain the first run count. The boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first partition or the second partition based on data in the firmware information area and the user data area through a series of judgments. Then, the second run count of the second partition is obtained, i.e., the number of times the device system enters the second partition. Since this is after the device system upgrade, the second firmware in the second partition is the upgraded firmware, so the device system needs to enter the second partition to run the second firmware, hence the need to obtain the second run count of the second partition. Then, the first number of runs is compared with the second number of runs to determine a first difference between them. If the first difference is greater than a first preset threshold, it indicates that the device system cannot run the second firmware normally in the second partition. Therefore, it is not necessary to control the device system to enter the second partition, and the device system upgrade is directly judged as failed. If the first difference is less than the first preset threshold, the device system is controlled to enter the second partition normally. If the device system can run the second firmware normally in the second partition, the second run count for the second partition is incremented by one, and then the system is controlled to run normally. If the device system cannot run the second firmware normally in the second partition, the device system is controlled to restart and the above steps are repeated until the first difference is greater than the first preset threshold or the device system can run the second firmware normally in the second partition. This invention realizes the judgment of the success or failure of the device system upgrade by calculating the difference between the number of times the device system enters the boot partition and the number of times it enters the second partition.

[0068] Figure 3 This illustration shows one of the flowcharts illustrating the steps of a device system upgrade method according to an embodiment of the present invention, whereby, if the device system upgrade fails, the device system is controlled to enter a first partition and run the first firmware. The steps of controlling the device system to enter the first partition and run the first firmware based on the device system upgrade failure include:

[0069] Step 302: Determine the validity of the first firmware within the first partition;

[0070] Step 304: Based on the validity of the first firmware, the control device system enters the first partition and runs the first firmware, clears the rollback flag, and marks the second partition.

[0071] Step 306: If the first firmware is invalid, the control device system sends a reminder message to the user.

[0072] In this embodiment, the step of controlling the device system to enter the first partition and run the first firmware based on the failure of the device system upgrade includes: Since the device system upgrade failed, meaning the device system cannot run the second firmware normally in the second partition, in order to enable the device system to run normally again, it is necessary to control the device system to re-enter the first partition and run the first firmware before the upgrade, i.e., the device system needs to perform a rollback operation. When the device system performs a rollback operation, it is first necessary to determine the legality of the first firmware in the first partition, that is, to determine whether the first firmware in the first partition is complete and can be used normally. When the first firmware is legal, the device system is controlled to enter the first partition and run the original first firmware, while the rollback flag is cleared to zero. The rollback flag is stored in the user data partition. When the device system detects that a rollback operation is needed, the rollback flag is automatically set. Therefore, when the system enters the first partition and re-runs the original first firmware, i.e., the device system rollback operation is completed, the rollback flag needs to be cleared to zero. At the same time, the second partition also needs to be marked. Since the device system cannot run the second firmware in the second partition, it means that the second firmware in the second partition is illegal, so the second partition needs to be marked as illegal. When the first firmware is invalid, it means the device system cannot access the first partition to run the first firmware. Therefore, a reminder message needs to be sent to the user, informing them that the device system is damaged and to contact after-sales service. This invention ensures that the rollback operation can proceed normally by determining the validity of the first firmware in the first partition during the rollback operation of the device system.

[0073] Figure 4 This is a second flowchart illustrating a step in determining whether the upgrade of a device system is successful in a device system upgrade method according to an embodiment of the present invention; wherein, the step of determining whether the upgrade of the device system is successful includes:

[0074] Step 402: Control the device system to enter the boot partition and record the current time. The boot partition is used to determine whether the device system enters the first partition or the second partition.

[0075] Step 404: Obtain the first time the device system last entered the boot partition;

[0076] Step 406: Determine the second difference between the current time and the first time;

[0077] Step 408: If the second difference is within a preset range, the device system upgrade is determined to have failed.

[0078] In this embodiment, the steps for determining whether the device system upgrade was successful include: after the device system enters the running partition, if the firmware fails to run, the device system will periodically restart due to the watchdog timer (embedded system monitoring device). Therefore, the current time is recorded each time the device system enters the boot partition. After the device system upgrade is completed and the device system restarts, it first controls the device system to enter the boot partition and records the current time of entering the boot partition. The boot partition is the first piece of code loaded after the device system powers on. In this code, the device system determines whether to run in the first partition or the second partition based on a series of judgments according to the data in the firmware information area and the user data area. Then, the first time the device system entered the boot partition last time is obtained. Then, the first time is compared with the current time to determine the second difference between the current time and the first time. When the second difference is within a preset range, where the preset range is determined by the watchdog timer time, it means that the device system cannot run the second firmware normally in the second partition. Therefore, it is not necessary to control the device system to enter the second partition, and the device system upgrade is directly judged to have failed. When the second difference is not within the preset range, the control device system normally enters the second partition. If the device system can run the second firmware normally within the second partition, the control system operates normally. If the device system cannot run the second firmware normally within the second partition, the watchdog timer (embedded system monitoring device) is reset to restart the device system and repeat the above steps until the second difference is within the preset range or the device system can run the second firmware normally within the second partition. This invention calculates the difference between the current time when the device system enters the boot partition and the first time it entered the boot partition last time, thereby determining the success or failure of the device system upgrade.

[0079] Figure 5 This is a second flowchart illustrating the step of controlling the device system to enter the first partition and run the first firmware in a device system upgrade method according to an embodiment of the present invention if the device system upgrade fails; wherein, the step of controlling the device system to enter the first partition and run the first firmware if the device system upgrade fails includes:

[0080] Step 502: If the number of device system upgrade failures exceeds the second preset threshold, then determine the validity of the first firmware in the first partition;

[0081] Step 504: Based on the validity of the first firmware, the control device system enters the first partition and runs the first firmware, clears the rollback flag, and marks the second partition.

[0082] Step 506: If the first firmware is invalid, the control device system sends a reminder message to the user.

[0083] In this embodiment, the step of controlling the device system to enter the first partition and run the first firmware based on the failure of the device system upgrade includes: Since the device system upgrade failed, that is, the device system cannot run the second firmware normally in the second partition, in order to enable the device system to run normally again, it is necessary to control the device system to re-enter the first partition and run the first firmware before the upgrade, that is, the device system needs to perform a rollback operation. When the device system performs the rollback operation, the number of times the device system upgrade failed is first recorded. When the number is less than a second preset threshold, the device system is controlled to enter the second partition and run the second firmware, that is, the device system is controlled to try again. If the number is greater than the second preset threshold, it is necessary to determine the legality of the first firmware in the first partition, that is, to determine whether the first firmware in the first partition is complete and can be used normally. When the first firmware is valid, the control system enters the first partition and runs the original first firmware. Simultaneously, the rollback flag is cleared. This rollback flag, stored in the user data partition, is automatically set when a rollback operation is detected. Therefore, when the control system enters the first partition and re-runs the original first firmware (i.e., the rollback operation is complete), the rollback flag needs to be cleared. The second partition also needs to be marked. Since the device system cannot run the second firmware in the second partition, it indicates that the second firmware in the second partition is invalid, hence the second partition needs to be marked as invalid. When the first firmware is invalid, the device system also cannot enter the first partition to run the first firmware. Therefore, a reminder message needs to be sent to the user, informing them that the device system is damaged and requesting after-sales service. This invention ensures that the rollback operation can function correctly by determining the validity of the first firmware in the first partition during the rollback operation.

[0084] Figure 6 A second schematic flowchart illustrating an embodiment of the device system upgrade method of the present invention is shown; wherein, the device system upgrade method further includes:

[0085] Step 602: Based on the successful upgrade of the device system, receive the user's first operation, wherein the first operation is to revert the device system to a previous version.

[0086] Step 604: Set the rollback flag and restart the device system;

[0087] Step 606: Determine the validity of the first firmware within the first partition;

[0088] Step 608: Based on the validity of the first firmware, control the restarted device system to enter the first partition and run the first firmware to clear the rollback flag.

[0089] In this embodiment, the device system upgrade method further includes: when a user performs an OTA firmware upgrade and finds that the upgraded firmware does not meet their usage habits, and the device system continues to use the old firmware, a version rollback operation can be performed on the device system. That is, after the device system upgrade is successful, a first user operation can be received, where the first operation is to instruct the device system to roll back to its original version. For example, the user can instruct the device to roll back via remote control, APP (Application), voice, or physical buttons on the device. After receiving the first operation, the rollback flag of the user data partition is set, and then the device system is restarted. Then, the validity of the first firmware in the first partition is determined, i.e., whether the first firmware in the first partition is complete and usable. If the first firmware is valid, the device system is controlled to enter the first partition and run the original first firmware, while the rollback flag is cleared. If the first firmware is invalid, it means that the device system cannot enter the first partition to run the first firmware, therefore a reminder message needs to be sent to the user to inform them of the rollback failure. This invention solves the problem in related technologies where users cannot revert after upgrading by receiving the user's first operation and then controlling the device system to roll back to the first partition and run the first firmware before the upgrade.

[0090] Figure 7 The diagram illustrates a step in an upgrade method for a device system according to an embodiment of the present invention, which involves setting a rollback flag and controlling the device system to restart. The step of setting the rollback flag and controlling the device system to restart includes:

[0091] Step 702: Determine whether the second firmware within the second partition allows rollback;

[0092] Step 704: If rollback is allowed based on the second firmware, the rollback flag is set and the device system is restarted.

[0093] In this embodiment, the step of setting the rollback flag and controlling the device system to restart includes: when the user performs a rollback operation, it is necessary to first determine whether the firmware currently running on the device system, i.e., the second firmware in the second partition, allows rollback. If rollback is not allowed, an audible and visual prompt is issued to remind the user. Generally, when the currently running firmware, i.e., the second firmware, is fixing some critical issues, such as fixing vulnerabilities that seriously affect device performance, user safety, or adding anti-attack methods, rollback is prohibited. If the second firmware allows rollback, the rollback flag is set, and the device system is controlled to restart. By determining whether the currently running firmware allows rollback during the rollback operation, the normal operation of the device system is ensured.

[0094] Figure 8 This illustration shows one of the flowcharts illustrating the step of determining the legality of the first firmware within a first partition in a device system upgrade method according to an embodiment of the present invention; wherein, the step of determining the legality of the first firmware within the first partition includes:

[0095] Step 802: Control the restarted device system to enter the boot partition, where the boot partition is used to determine whether the device system enters the first partition or the second partition;

[0096] Step 804: Check the status of the rollback flag within the boot partition;

[0097] Step 806: Based on the rollback flag being set, determine the validity of the first firmware in the first partition.

[0098] In this embodiment, the step of determining the legality of the first firmware in the first partition includes: firstly, controlling the rebooted device system to enter the boot partition, where the boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first partition or the second partition based on data in the firmware information area and the user data area through a series of checks. Then, the state of the rollback flag is checked within the boot partition. If the rollback flag is zero, it indicates that the device system does not need to perform a rollback operation, and the device system is directly controlled to enter the second partition to run the second firmware. If the rollback flag is set, it indicates that the device system needs to perform a rollback operation, therefore the legality of the first firmware in the first partition needs to be determined.

[0099] Figure 9 This is a second flowchart illustrating the step of determining the legality of the first firmware within a first partition in a device system upgrade method according to an embodiment of the present invention; wherein, the step of determining the legality of the first firmware within the first partition further includes:

[0100] Step 902: Calculate the first verification information of the first firmware in the first partition;

[0101] Step 904: Obtain the second verification information of the stored first firmware;

[0102] Step 906: Determine the legitimacy of the first firmware based on the first verification information and the second verification information.

[0103] In this embodiment, the step of determining the legality of the first firmware within the first partition further includes: firstly, calculating the first verification information of the first firmware within the first partition, wherein the first verification information includes the length information of the first firmware and the CRC checksum of the first firmware. Then, obtaining the second verification information of the first firmware previously stored in the firmware information partition, wherein the second verification information includes the previously stored length information and the previously stored CRC checksum of the first firmware. The first verification information and the second verification information are then compared. If they match, the first firmware is legal, meaning the device system can run the first firmware. If they do not match, the first firmware is invalid, meaning the device system cannot run the first firmware.

[0104] Figure 10 The diagram illustrates a step of upgrading the device system according to a second firmware in a device system upgrade method according to an embodiment of the present invention; wherein the step of upgrading the device system according to the second firmware includes:

[0105] Step 1002: Write the third verification information of the second firmware into the firmware information partition and set the upgrade flag bit. The firmware information partition includes the basic data required when selecting the boot partition.

[0106] Step 1004: The control device system enters the boot partition and checks the upgrade flag bit;

[0107] Step 1006: Based on the upgrade flag being set, calculate the fourth verification information of the second firmware in the second partition;

[0108] Step 1008: Based on the fact that the fourth verification information is the same as the third verification information, the control device system enters the second partition, runs the second firmware, and clears the upgrade flag bit.

[0109] In this embodiment, the step of upgrading the device system according to the second firmware includes: when the second firmware is stored in the second partition, the third verification information of the second firmware is written to the firmware information partition, and the upgrade flag bit in the firmware information partition is set. The firmware information partition stores basic data required when the boot partition selects the running partition, such as: boot partition startup count, startup time, firmware length in the first or second partition, firmware CRC checksum, startup count, software version number, whether rollback is allowed, current running partition, upgrade flag bit, number of startup failures, and upgrade result. The third verification information includes the length information of the second firmware and the CRC checksum. Then, the device system is controlled to restart and enter the boot partition. When the upgrade flag bit is detected to be set in the boot partition, the fourth verification information of the second firmware in the second partition is calculated, i.e., the length information of the second firmware and the CRC checksum are calculated. Verification is then performed. If the calculated fourth verification information is the same as the previously stored third verification information, the verification is successful, and the device system is controlled to enter the second partition and run the second firmware, while the upgrade flag bit is cleared. This invention ensures that the device system can operate normally with the second firmware by verifying the length information and CRC checksum of the second firmware.

[0110] Figure 11 A schematic block diagram of a device according to an embodiment of the present invention is shown. The device 1100 has multiple partitions, including: a boot partition 1102, a first partition 1104, a second partition 1106, a firmware information partition 1108, and a user data partition 1110. The boot partition 1102 is the first piece of code loaded after the device system is powered on. Within this code, the device system determines whether to run in the first partition 1104 or the second partition 1106 based on data in the firmware information partition 1108 and the user data partition 1110 through a series of judgments. The first partition 1104 and the second partition 1106 are partitions for storing firmware. The operating logic of the device system is implemented by the code in this partition, and OTA upgrades target the firmware in this partition. The firmware information partition 1108 stores the basic data required by the boot partition 1102 when selecting the running partition, such as firmware length information and the firmware's CRC (Cyclic Redundancy Checksum) checksum. User data partition 1110 mainly stores data that needs to be saved when power is off during user operation, such as device operating parameters, device unique code, rollback flag, etc.

[0111] Figure 12 A schematic diagram of a user rollback system method according to an embodiment of the present invention is shown; as follows: Figure 12As shown, when a user performs an OTA firmware upgrade and finds that the upgraded firmware does not match their usage habits, and the system continues to use the old firmware, a version rollback operation can be performed on the device system. Users can perform this operation via remote control, app, voice, or physical buttons on the device. Upon receiving the command, the device system first determines whether rollback is allowed with the currently running firmware (the second firmware). If rollback is not allowed, the system alerts the user through audio-visual prompts, app push notifications, etc. If rollback is allowed, the rollback flag is set, and the device restarts. After restarting, the device enters the boot partition. Once the boot partition detects the rollback flag is set, it verifies the validity of firmware outside the currently running partition (the first firmware in the first partition). If the firmware outside the current partition is valid, the running partition is switched, meaning the device system switches from running the second firmware in the second partition to running the first firmware in the first partition. If the firmware outside the current partition is invalid, the running partition remains unchanged, and the user is notified that the rollback failed. Finally, the flag is cleared, and the device system jumps to the corresponding partition, either the first or second partition. The method for determining firmware legitimacy is as follows: First, check if the firmware length meets the requirements; second, calculate the firmware's CRC checksum and compare it with the corresponding firmware's CRC checksum stored in the firmware information partition. The calculated CRC checksum must match the CRC checksum in the firmware information partition. If the match is found, the firmware is considered legitimate.

[0112] Figure 13 One of the schematic diagrams illustrating a device system self-recovery method according to an embodiment of the present invention is shown; as follows: Figure 13 As shown, when the device powers on or restarts, the device system first enters the boot partition. After entering the boot partition, the device system increments the boot partition count by 1. Then, it obtains the number of times the running partition has been run and calculates the difference N between the boot partition's run count and the running partition's run count. If the difference N is greater than a specific threshold, the device system is considered to have failed to boot / upgrade. The device system will then perform a rollback operation, marking the current running partition as faulty and checking the legitimacy of firmware in non-current running partitions by calculating checksums and determining firmware length. If the non-current running partition firmware is legitimate, it switches to the target running partition and clears the relevant flag bits, while marking the current running partition as an illegal partition; otherwise, it alerts the user that the device is damaged and requests immediate after-sales service. If the difference N is less than or equal to the specific threshold, the running partition remains unchanged, and the device system jumps to the original partition to continue running. When the system successfully enters the running partition, the system increments the running partition count by 1; if the system cannot successfully enter the running partition, it resets and restarts, repeating the process.

[0113] Figure 14 A second schematic diagram of a device system self-recovery method according to an embodiment of the present invention is shown; as follows: Figure 14 As shown, when the device powers on or restarts, the system first enters the boot partition. After entering the boot partition, the system records the current time of entering the boot partition. Then, it obtains the last time it entered the boot partition and calculates the time difference X between the two entries. If the time difference X is approximately equal to the watchdog timer (embedded system monitoring device) reset time, it determines that the boot / upgrade has failed and records the number of boot / upgrade failures, i.e., the device boot failure count (Y) is incremented by 1, and it is determined whether the device boot failure count Y is greater than a specific threshold. If the device boot failure count Y is greater than the specific threshold, the device system will perform a rollback operation, i.e., mark the current running partition as faulty, and check the legality of the firmware in the non-current running partition by calculating the checksum and judging the firmware length. If the firmware in the non-current running partition is legal, the non-current running partition is switched to the target running partition and the relevant flag bits are cleared, while the current running partition is marked as an illegal partition; otherwise, the user is reminded that the device is damaged and should contact after-sales service as soon as possible. If the device boot failure count Y is less than or equal to the specific threshold, the running partition is not changed, and the system jumps to the original partition to continue running. If the system fails to enter the running partition normally, the watchdog (embedded system monitoring device) will be reset and restarted, and the process will be repeated.

[0114] At the same time, if the equipment system performs such Figure 13 or Figure 14 If the device still cannot function properly after the self-recovery method is used, for example: the current running partition is the first partition, and the device system determines that the boot / upgrade has failed, it will switch the running partition to the second partition. If the device is still determined to have failed to boot / upgrade after switching to the second partition, an audible and visual prompt will be issued to remind the user that the device is damaged and to contact after-sales service as soon as possible.

[0115] Figure 15 A schematic block diagram of an upgrade apparatus for a device system according to an embodiment of the present invention is shown; wherein, the upgrade apparatus 150 for the device system includes:

[0116] The first determining module 1502 is used to determine the first partition based on the first firmware currently running in the device system, wherein the first firmware is stored in the first partition;

[0117] The first storage module 1504 is used to store the second firmware to the second partition;

[0118] The first control module 1506 is used to upgrade the device system according to the second firmware;

[0119] The judgment module 1508 is used to determine whether the device system upgrade was successful.

[0120] The second control module 1510 is used to control the device system to enter the first partition and run the first firmware if the device system upgrade fails.

[0121] The device system upgrade apparatus 150 provided by this invention mainly includes: a first determining module 1502, a first storing module 1504, a first control module 1506, a judging module 1508, and a second control module 1510. Firstly, the first determining module 1502 determines a first partition based on the first firmware currently running on the device system. The first firmware is stored in the first partition, meaning it determines which partition the device system was running on before the upgrade, and then designates this partition as the first partition. Next, the first storing module 1504 stores a second firmware in a second partition. The second partition may contain other firmware or no firmware; the second firmware is the upgraded firmware, meaning the upgraded firmware is stored in a non-currently running partition of the device system. Then, the first control module 1506 upgrades the device system based on the second firmware, i.e., it controls the device system to switch its running partition from the first partition before the upgrade to the second partition, thereby allowing the device system to enter the second partition and run the second firmware, thus completing the device system upgrade. Next, the judgment module 1508 determines whether the device system upgrade was successful, that is, whether the device system runs the second firmware smoothly. If the device system runs the second firmware smoothly, that is, it can run normally, then the upgrade is successful, and the device system can continue to run the second firmware in the second partition. If the device system cannot run normally when running the second firmware, then the upgrade has failed. In this case, the second control module 1510 needs to control the device system to return to the first partition and run the first firmware before the upgrade, thereby realizing the self-recovery of the device system. This invention achieves the upgrade of the device system by storing the upgrade firmware in the second partition where the device system is not currently running, and then controlling the device system to switch from the first partition to the second partition to run, thereby realizing the upgrade of the device system. At the same time, when the device system upgrade fails, the device system is controlled to switch back to the first partition and run the original first firmware, thereby solving the problem of the inability to self-recover after the device system upgrade fails in related technologies.

[0122] In some embodiments, optionally, the determination module 1508 is used to control the device system to enter the boot partition and increment the number of times the boot partition is run by one to obtain a first number of runs, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; obtain the second number of runs of the second partition; determine a first difference between the first number of runs and the second number of runs; and determine that the device system upgrade has failed if the first difference is greater than a first preset threshold.

[0123] In this embodiment, the number of times the device system enters the boot partition is recorded each time it does so. Similarly, when the device system enters the first and second partitions, the number of times it enters each partition is also recorded after the firmware runs normally. Therefore, after the device system completes the upgrade and restarts, the determination module 1508 controls the device system to enter the boot partition and increments the boot partition's running count (i.e., the number of times the device system enters the boot partition) to obtain the first running count. The boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first or second partition based on data in the firmware information area and user data area through a series of judgments. Then, the second running count of the second partition is obtained, i.e., the number of times the device system enters the second partition. Since this is after the device system upgrade, the second firmware in the second partition is the upgraded firmware, so the device system needs to enter the second partition to run the second firmware, hence the need to obtain the second running count of the second partition. Then, the first number of runs is compared with the second number of runs to determine a first difference between them. If the first difference is greater than a first preset threshold, it indicates that the device system cannot run the second firmware normally in the second partition. Therefore, it is not necessary to control the device system to enter the second partition, and the device system upgrade is directly judged as failed. If the first difference is less than the first preset threshold, the device system is controlled to enter the second partition normally. If the device system can run the second firmware normally in the second partition, the second run count for the second partition is incremented by one, and then the system is controlled to run normally. If the device system cannot run the second firmware normally in the second partition, the device system is controlled to restart and the above steps are repeated until the first difference is greater than the first preset threshold or the device system can run the second firmware normally in the second partition. This invention realizes the judgment of the success or failure of the device system upgrade by calculating the difference between the number of times the device system enters the boot partition and the number of times it enters the second partition.

[0124] In some embodiments, optionally, the second control module 1510 is used to determine the validity of the first firmware in the first partition; based on the validity of the first firmware, the control device system enters the first partition and runs the first firmware, clears the rollback flag, and marks the second partition; based on the invalidity of the first firmware, the control device system sends a reminder message to the user.

[0125] In this embodiment, since the device system upgrade failed (i.e., the device system cannot run the second firmware normally in the second partition), in order to enable the device system to continue operating normally, it is necessary to control the device system to re-enter the first partition and run the first firmware before the upgrade, i.e., the device system needs to perform a rollback operation. During the rollback operation, the second control module 1510 first needs to determine the validity of the first firmware in the first partition, i.e., whether the first firmware in the first partition is complete and usable. If the first firmware is valid, the device system is controlled to enter the first partition and run the original first firmware, while simultaneously clearing the rollback flag. The rollback flag is stored in the user data partition; when a rollback operation is detected, the rollback flag is automatically set. Therefore, when the system enters the first partition and re-runs the original first firmware, i.e., the rollback operation is complete, the rollback flag needs to be cleared. Simultaneously, the second partition also needs to be marked. Since the device system cannot run the second firmware in the second partition, it indicates that the second firmware in the second partition is invalid, therefore the second partition needs to be marked as invalid. When the first firmware is invalid, it means the device system cannot access the first partition to run the first firmware. Therefore, a reminder message needs to be sent to the user, informing them that the device system is damaged and to contact after-sales service. This invention ensures that the rollback operation can proceed normally by determining the validity of the first firmware in the first partition during the rollback operation of the device system.

[0126] In some embodiments, optionally, the determination module 1508 is further configured to control the device system to enter the boot partition and record the current time, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; obtain the first time when the device system last entered the boot partition; determine the second difference between the current time and the first time; and determine that the device system upgrade has failed when the second difference is within a preset range.

[0127] In this embodiment, after the device system enters the running partition, if the firmware fails to run, the watchdog timer (embedded system monitoring device) will cause the device system to restart periodically. Therefore, the current time is recorded each time the device system enters the boot partition. After the device system upgrade is completed and the device system restarts, the judgment module 1508 first controls the device system to enter the boot partition and records the current time when the device system enters the boot partition. The boot partition is the first piece of code loaded after the device system powers on. In this code, the device system determines whether to run in the first partition or the second partition based on a series of judgments according to the data in the firmware information area and the user data area. Then, the first time when the device system last entered the boot partition is obtained. Then, the first time is compared with the current time to determine the second difference between the current time and the first time. When the second difference is within a preset range, where the preset range is determined by the watchdog timer time, it means that the device system cannot run the second firmware normally in the second partition. Therefore, it is not necessary to control the device system to enter the second partition, and the device system upgrade is directly judged to have failed. When the second difference is not within the preset range, the control device system normally enters the second partition. If the device system can run the second firmware normally within the second partition, the control system operates normally. If the device system cannot run the second firmware normally within the second partition, the watchdog timer (embedded system monitoring device) is reset to restart the device system and repeat the above steps until the second difference is within the preset range or the device system can run the second firmware normally within the second partition. This invention calculates the difference between the current time when the device system enters the boot partition and the first time it entered the boot partition last time, thereby determining the success or failure of the device system upgrade.

[0128] In some embodiments, optionally, the second control module 1510 is further configured to determine the validity of the first firmware in the first partition when the number of device system upgrade failures exceeds a second preset threshold; based on the validity of the first firmware, control the device system to enter the first partition and run the first firmware, clear the rollback flag, and mark the second partition; based on the invalidity of the first firmware, control the device system to send a reminder message to the user.

[0129] In this embodiment, when the device system performs a rollback operation, the second control module 1510 first records the number of times the device system upgrade failed. If the number is less than a second preset threshold, the device system is controlled to enter the second partition to run the second firmware, i.e., the device system is controlled to try again. If the number is greater than the second preset threshold, the validity of the first firmware in the first partition needs to be determined, i.e., whether the first firmware in the first partition is complete and can be used normally. When the first firmware is valid, the device system is controlled to enter the first partition and run the original first firmware, while the rollback flag is cleared. The rollback flag is stored in the user data partition. When the device system detects that a rollback operation is needed, the rollback flag is automatically set. Therefore, when the system enters the first partition and re-runs the original first firmware, i.e., the device system rollback operation is completed, the rollback flag needs to be cleared. At the same time, the second partition also needs to be marked. Since the device system cannot run the second firmware in the second partition, it means that the second firmware in the second partition is invalid, so the second partition needs to be marked as invalid. When the first firmware is invalid, it means the device system cannot access the first partition to run the first firmware. Therefore, a reminder message needs to be sent to the user, informing them that the device system is damaged and to contact after-sales service. This invention ensures that the rollback operation can proceed normally by determining the validity of the first firmware in the first partition during the rollback operation of the device system.

[0130] In some embodiments, the device system upgrade apparatus 150 further includes: a receiving module, configured to receive a first operation from a user based on a successful device system upgrade, wherein the first operation is to cause the device system to perform a version rollback operation; a third control module, configured to set a rollback flag and control the device system to restart; a second determining module, configured to determine the legality of the first firmware in the first partition; and a fourth control module, configured to, based on the legality of the first firmware, control the restarted device system to enter the first partition, run the first firmware, and clear the rollback flag.

[0131] In this embodiment, the device system upgrade device 150 further includes a receiving module, a third control module, a second determining module, and a fourth control module. When a user performs an OTA firmware upgrade and finds that the upgraded firmware does not match their usage habits, and the device system continues to use the old firmware, a version rollback operation can be performed on the device system. That is, after the device system upgrade is successful, the receiving module can receive the user's first operation, which is to perform a version rollback operation on the device system. For example, the user can perform a version rollback operation via remote control, APP (Application), voice, or physical buttons on the device. After receiving the first operation, the third control module sets the rollback flag bit of the user data partition and then controls the device system to restart. Then, the second determining module determines the validity of the first firmware in the first partition, that is, whether the first firmware in the first partition is complete and usable. When the first firmware is valid, the fourth control module controls the device system to enter the first partition and run the original first firmware, while simultaneously clearing the rollback flag bit. When the first firmware is invalid, it means the device system cannot access the first partition to run the first firmware. Therefore, a notification message needs to be sent to the user to inform them of the rollback failure. This invention solves the problem of users being unable to roll back after upgrading in related technologies by receiving the user's first operation and then controlling the device system to roll back to the first partition and run the first firmware before the upgrade.

[0132] In some embodiments, the third control module is optionally used to determine whether the second firmware in the second partition allows rollback; if the second firmware allows rollback, the rollback flag is set and the device system is controlled to restart.

[0133] In this embodiment, when a user performs a rollback operation, the third control module first needs to determine whether the firmware currently running on the device system, i.e., the second firmware in the second partition, allows rollback. If rollback is not allowed, an audible and visual prompt is issued to remind the user. Generally, when the currently running firmware, i.e., the second firmware, is fixing some critical issues, such as vulnerabilities that seriously affect device performance, user safety, or adding anti-attack methods, rollback is prohibited. If the second firmware allows rollback, the rollback flag is set, and the device system is controlled to restart. By determining whether the currently running firmware allows rollback during the rollback operation, the normal operation of the device system is ensured.

[0134] In some embodiments, optionally, the second determining module is used to control the device system after reboot to enter the boot partition, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; detects the state of the rollback flag bit in the boot partition; and determines the legality of the first firmware in the first partition based on the rollback flag bit being set.

[0135] In this embodiment, the second determining module first controls the rebooted device system to enter the boot partition. The boot partition is the first piece of code loaded after the device system powers on. Within this code, the device system determines whether to run in the first or second partition based on data in the firmware information area and user data area through a series of checks. Then, the status of the rollback flag is checked within the boot partition. If the rollback flag is zero, it indicates that the device system does not need to perform a rollback operation, and the system is directly controlled to enter the second partition to run the second firmware. If the rollback flag is set, it indicates that the device system needs to perform a rollback operation, therefore the validity of the first firmware in the first partition needs to be determined.

[0136] In some embodiments, the second determining module is further configured to calculate first verification information of the first firmware within the first partition; obtain second verification information of the stored first firmware; and determine the legality of the first firmware based on the first verification information and the second verification information.

[0137] In this embodiment, the second determining module is further configured to first calculate the first verification information of the first firmware within the first partition, wherein the first verification information includes the length information of the first firmware and the CRC checksum of the first firmware. Then, it obtains the second verification information of the first firmware previously stored in the firmware information partition, wherein the second verification information includes the previously stored length information and the previously stored CRC checksum of the first firmware. The first verification information and the second verification information are then compared. If they match, the first firmware is considered valid, meaning the device system can run the first firmware. If they do not match, the first firmware is considered invalid, meaning the device system cannot run the first firmware.

[0138] In some embodiments, optionally, the first control module 1506 is specifically configured to write the third verification information of the second firmware into the firmware information partition and set the upgrade flag bit, wherein the firmware information partition includes the basic data required when selecting a partition in the boot partition; control the device system to enter the boot partition and detect the upgrade flag bit; calculate the fourth verification information of the second firmware in the second partition based on the upgrade flag bit being set; and control the device system to enter the second partition and run the second firmware based on the fourth verification information being the same as the third verification information, and clear the upgrade flag bit.

[0139] In this embodiment, the first control module 1506 is specifically used to write the third verification information of the second firmware into the firmware information partition when the second firmware is stored in the second partition, and simultaneously set the upgrade flag bit in the firmware information partition. The firmware information partition stores basic data required for the boot partition to select the running partition, such as: boot partition startup count, startup time, firmware length in the first or second partition, firmware CRC checksum, startup count, software version number, whether rollback is allowed, current running partition, upgrade flag bit, number of startup failures, and upgrade result. The third verification information includes the length information of the second firmware and the CRC checksum. Then, the control device system restarts and enters the boot partition. When the upgrade flag bit is detected as set in the boot partition, the fourth verification information of the second firmware in the second partition is calculated, i.e., the length information of the second firmware and the CRC checksum are calculated. Verification is then performed. If the calculated fourth verification information is the same as the previously stored third verification information, the verification passes, and the control device system enters the second partition and runs the second firmware, while simultaneously clearing the upgrade flag bit. This invention ensures that the device system can operate normally with the second firmware by verifying the length information and CRC checksum of the second firmware.

[0140] Figure 16 A schematic block diagram of an electronic device according to an embodiment of the present invention is shown; wherein, the electronic device 160 includes a memory 1602, a processor 1604, and a computer program stored in the memory 1602 and executable on the processor 1604, wherein the processor 1604 executes the computer program to implement the steps of the device system upgrade method as described above.

[0141] The electronic device 160 provided by the present invention, when the processor 1604 executes a computer program, implements the steps of the above-described device system upgrade method, which can achieve the technical effects of any of the above embodiments, and will not be described again.

[0142] One embodiment of the present invention provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the device system upgrade method as described in any of the preceding claims.

[0143] The storage medium provided by the present invention, when the computer program is executed by the processor, implements the steps of the above-described device system upgrade method, and can achieve the technical effects of any of the above embodiments, which will not be repeated here.

[0144] In the description of this specification, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance, unless otherwise expressly specified and limited. The terms "connection," "installation," and "fixing," etc., should be interpreted broadly. For example, "connection" can mean a fixed connection, a detachable connection, or an integral connection; it can mean a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0145] In the description of this specification, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0146] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for upgrading a device system, characterized in that, include: The first partition is determined based on the first firmware currently running in the device system, wherein the first firmware is stored in the first partition; Store the second firmware in the second partition; The device system is upgraded according to the second firmware; Determine whether the upgrade of the device system was successful; If the device system upgrade fails, the device system is controlled to enter the first partition and run the first firmware. The step of determining whether the upgrade of the device system was successful includes: The device system is controlled to enter the boot partition, and the number of times the boot partition is run is incremented by one to obtain a first number of runs, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; Obtain the second run count for the second partition; Determine a first difference between the first number of runs and the second number of runs; If the first difference is greater than a first preset threshold, then the device system upgrade is determined to have failed; or The step of determining whether the upgrade of the device system was successful includes: The device system is controlled to enter the boot partition, and the current time is recorded, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; Obtain the first time the device system last entered the boot partition; Determine the second difference between the current time and the first time; If the second difference is within a preset range, then the device system upgrade is determined to have failed.

2. The method for upgrading a device system according to claim 1, characterized in that, The step of controlling the device system to enter the first partition and run the first firmware when the device system upgrade fails includes: Determine the validity of the first firmware within the first partition; Based on the validity of the first firmware, the device system is controlled to enter the first partition and run the first firmware, clearing the rollback flag and marking the second partition. If the first firmware is invalid, the system controls the device to send a reminder message to the user.

3. The method for upgrading a device system according to claim 1, characterized in that, The step of controlling the device system to enter the first partition and run the first firmware when the device system upgrade fails includes: If the number of failed device system upgrades exceeds a second preset threshold, the validity of the first firmware in the first partition is determined. Based on the validity of the first firmware, the device system is controlled to enter the first partition and run the first firmware, clearing the rollback flag and marking the second partition. If the first firmware is invalid, the system controls the device to send a reminder message to the user.

4. The method for upgrading a device system according to any one of claims 1 to 3, characterized in that, The upgrade method for the equipment system also includes: Based on the successful upgrade of the device system, the user's first operation is received, wherein the first operation is to cause the device system to perform a version rollback. Set the rollback flag and control the device system to restart; Determine the validity of the first firmware within the first partition; Based on the validity of the first firmware, the device system after reboot is controlled to enter the first partition and run the first firmware to clear the rollback flag.

5. The method for upgrading a device system according to claim 4, characterized in that, The step of setting the rollback flag and controlling the device system to restart includes: Determine whether the second firmware within the second partition allows rollback; If the second firmware allows rollback, the rollback flag is set, and the device system is controlled to restart.

6. The method for upgrading a device system according to claim 4, characterized in that, The step of determining the legality of the first firmware within the first partition includes: The system controls the device system to enter the boot partition after restarting, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; the status of the rollback flag is detected within the boot partition; If the rollback flag is set, the validity of the first firmware within the first partition is determined.

7. The method for upgrading a device system according to claim 6, characterized in that, The step of determining the legality of the first firmware within the first partition further includes: Calculate the first verification information of the first firmware within the first partition; Obtain the second verification information of the stored first firmware; The legitimacy of the first firmware is determined based on the first verification information and the second verification information.

8. The method for upgrading a device system according to claim 1, characterized in that, The step of upgrading the device system according to the second firmware includes: Write the third verification information of the second firmware into the firmware information partition and set the upgrade flag bit, wherein the firmware information partition includes the basic data required when selecting the boot partition; The system is controlled to enter the boot partition and the upgrade flag is detected; Based on the fact that the upgrade flag bit is in the set state, calculate the fourth verification information of the second firmware in the second partition; If the fourth verification information is the same as the third verification information, the device system is controlled to enter the second partition, run the second firmware, and clear the upgrade flag bit.

9. An upgrade device for an equipment system, characterized in that, include: A first determining module is configured to determine a first partition based on a first firmware currently running in the device system, wherein the first firmware is stored in the first partition; A first storage module is used to store the second firmware to a second partition; A first control module is configured to upgrade the device system according to the second firmware. A judgment module is used to determine whether the upgrade of the device system is successful. The second control module is used to control the device system to enter the first partition and run the first firmware if the device system upgrade fails. The judgment module is used to control the device system to enter the boot partition and increment the number of times the boot partition is run to obtain a first number of runs, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; obtain a second number of runs in the second partition; determine a first difference between the first number of runs and the second number of runs; and determine that the device system upgrade has failed if the first difference is greater than a first preset threshold; or it is used to control the device system to enter the boot partition and record the current time, wherein the boot partition is used to determine whether the device system enters the first partition or the second partition; obtain the first time when the device system last entered the boot partition; determine a second difference between the current time and the first time; and determine that the device system upgrade has failed if the second difference is within a preset range.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the device system upgrade method as described in any one of claims 1 to 8.

11. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the device system upgrade method as described in any one of claims 1 to 8.

Images