System starting method based on dual systems and electronic equipment

Abstract

The invention discloses a system starting method based on dual systems and electronic equipment. The method comprises the following steps: reading a starting mark corresponding to a bootstrap object of a bootstrap program in a bootstrap communication partition; detecting whether the guide object is normally started at the last time according to the starting mark; if the booting object is normally started last time, resetting the starting mark, and continuously guiding the booting object to start through the booting program; if the guide object is normally started, carrying out marking processing on the starting mark; and if the guide object is not normally started, switching the current partition system into a backup partition system, and guiding the backup partition system to be started through reset operation. According to the invention, when the firmware of the slot which is successfully started originally is damaged, the other slot is automatically switched to start the system, so that the system starting reliability is improved.

Description

Technical Field

[0001] The present invention relates to the field of embedded technology, and in particular to a system startup method and electronic equipment based on dual systems. Background Art

[0002] To improve the reliability of Over-The-Air (OTA) upgrades, the Android system introduces an A / B system. This system creates two partitions in the physical partition table for each upgradeable firmware file (such as boot.img), labeled _a and _b. Furthermore, a dynamic partition, called "super," is used to store system firmware, distinguishing between A and B system firmware using logical A and B partitions. In an A / B system, all A partitions constitute the A-slot system, and all B partitions constitute the B-slot system.

[0003] When performing an OTA upgrade in the A / B system, if the device is currently running on slot A, the firmware to be upgraded will be upgraded to slot B, and vice versa. If the upgrade fails, the operation of the current system will not be affected, that is, the current slot will not be switched to the slot where the upgrade failed. If the upgrade is successful, the system sets the upgraded slot as the boot slot to boot the device system. In the existing Android A / B system, when a slot is upgraded and successfully booted, the upgrade verification service update_verifier will mark the slot as booted successfully. In this case, if the slot that has been marked as successfully booted is damaged or the storage area has an abnormality due to physical aging, the Android A / B system will not be able to automatically switch to another slot. This limitation may cause the device to fail to boot normally because the system cannot automatically load the operating system from the backup slot. Summary of the Invention

[0004] The present invention provides a system startup method based on dual systems and an electronic device, which can automatically switch to another slot to start the system when the firmware of a slot that was originally successfully started is damaged, thereby improving the reliability of system startup.

[0005] In one aspect of the present invention, a dual-system system startup method is provided. The method includes: reading a startup flag corresponding to a boot object of a boot program in a boot communication partition; detecting, based on the startup flag, whether the boot object was normally started the last time it was started; if the boot object was normally started the last time, resetting the startup flag and continuing to boot the boot object through the boot program; if the boot object was normally started, marking the startup flag; and if the boot object was not normally started, switching the current partition system to a backup partition system and resetting the backup partition system to start it.

[0006] In another aspect of the present invention, an electronic device is provided, comprising a memory configured to store a computer program and a processor configured to execute the computer program to perform the above-mentioned dual-system-based system startup method.

[0007] According to the technical solution of the present invention, the existing dual system is utilized to mark the slot as having successfully started after it is upgraded and successfully started in one slot. After determining that the boot object was marked as normally started at the last startup based on the startup mark, the startup mark is first reset. If the boot object still starts normally this time, the startup mark will be marked as normally started. If the boot object is damaged or the storage area becomes abnormal due to physical aging, causing the boot object to be unable to start normally this time, the startup mark cannot be marked and will remain in the reset state. In this way, it is possible to distinguish between a system that has been marked as successfully started but is running abnormally and a system that has been marked as successfully started and is running normally. At the same time, if the boot object's startup mark is not marked, the system will reboot the backup partition system through a reset operation to achieve automatic switching to another slot to start the system when the firmware of the slot that was originally successfully started is damaged, thereby improving the reliability of the system startup. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 Flowchart of a system startup method based on dual systems according to an embodiment of the present invention; Figure 2 A flowchart of a method for initializing a boot communication partition according to an embodiment of the present invention; Figure 3 Flowchart of a method for operating the primary boot program firmware according to an embodiment of the present invention; Figure 4 This is a flowchart of a method for running the Android bootloader firmware according to an embodiment of the present invention; Figure 5 This is a flowchart of a method for operating Android system firmware according to an embodiment of the present invention; Figure 6 The figure is a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0009] To illustrate the technical content, achieved objectives and effects of the present invention in detail, the following description is given in conjunction with the embodiments and accompanying drawings.

[0010] To improve the reliability of over-the-air (OTA) upgrades, the Android system introduced an A / B system. This system creates two partitions in the physical partition table for each upgradeable firmware file (such as boot.img), labeled _a and _b. Furthermore, a dynamic partition, called "super," is used to store system firmware, distinguishing between A and B system firmware using logical A and B partitions. In this A / B system, all A partitions constitute the A-slot system, and all B partitions constitute the B-slot system.

[0011] During an OTA upgrade in the A / B system, if the device is currently running on slot A, the firmware to be upgraded will be upgraded to slot B, and vice versa. If the upgrade fails, the current system will not be affected; the current slot will not be switched to the slot where the upgrade failed. If the upgrade is successful, the system sets the upgraded slot as the boot slot and sets a preset boot count (for example, 7). After the device restarts, the bootloader attempts to boot the system from the upgraded slot and decrements the boot count. If the upgraded slot successfully boots, the update_verifier service marks the upgraded slot as booted successfully. If the upgraded slot fails to boot, the system restarts a preset number of times. When the boot count reaches 0, the bootloader falls back to the previous slot in the A / B system and boots the system based on the previous slot, ensuring upgrade reliability. The Android A / B system falls back to the old system in the event of an upgrade failure, allowing the system to be restored to its pre-upgrade state even if the new system fails to boot. However, in the existing Android A / B system, after a slot is upgraded and successfully boots, the update_verifier service marks the slot as booted successfully. In this case, if the slot marked as successfully booted becomes corrupted or the storage area becomes abnormal due to physical aging, the Android A / B system will not be able to automatically switch to the other slot. This limitation may cause the device to not boot properly because the system cannot automatically load the operating system from the backup slot.

[0012] In order to solve at least the above-mentioned technical problems, the present disclosure provides a system startup method based on a dual system. According to the present disclosure, after the existing dual system is upgraded and successfully started in one slot, the slot will be marked as successfully started. After determining that the boot object was marked as normally started at the last startup based on the startup mark, the startup mark is first reset. If the boot object still starts normally this time, the startup mark will be marked as normally started. If the boot object is damaged or the storage area is abnormal due to physical aging, causing the boot object to be unable to start normally this time, the startup mark cannot be marked and will remain in the reset state. In this way, according to the embodiment of the present disclosure, it is possible to distinguish between a system that has been marked as successfully started but is running abnormally and a system that has been marked as successfully started and is running normally. At the same time, if the boot object's startup mark is not marked, the system will reboot the backup partition system through a reset operation to start the system, so that when the firmware of the slot that was originally successfully started is damaged, it will automatically switch to another slot to start the system, thereby improving the reliability of the system startup.

[0013] According to an embodiment of the present disclosure, if the boot flags of the current Android system's slot A and slot B have been set to boot successfully, and the Android system firmware stored in slot A (or slot B) becomes corrupted due to natural aging (or human damage) of the storage medium, causing the Android system firmware to fail to boot normally, once the Android system firmware in slot A (or slot B) is corrupted, it will be impossible to successfully enter the Android system, and it will be impossible to reset the boot flags that have been restored to their initial reset values to the preset boot magic number.

[0014] The system attempts to boot the Android system firmware in slot A (or slot B) multiple times. Each time the device attempts to boot, the Android system's maximum boot count for the corresponding boot object is reduced by one. After the device has booted a certain number of times, the maximum boot count for the corresponding boot object in the Android system is reduced to the preset minimum. The system recovery flag is then set to the preset magic number, and the current slot's system is switched to the other slot based on the upgrade boot information. For example, if the current boot slot is system A, the Android A / B upgrade boot control information is updated to make system B the current boot slot. If the current boot slot is system B, the Android A / B upgrade boot control information is updated to make system A the current boot slot. Finally, the device is reset and restarted, re-booting the bootloader to automatically switch the Android system to the other slot for boot, improving system startup reliability.

[0015] At the same time, after the Android system firmware is normally started through another slot, the background system recovery service determines whether the system recovery mark is the preset recovery magic number, thereby notifying the firmware upgrade client to communicate with the firmware upgrade server, querying the latest version of the complete upgrade package from the upgrade server, and re-upgrading the damaged slot through A / B upgrade to repair the damaged slot firmware.

[0016] Hereinafter, the technical solutions according to the present disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.

[0017] Figure 1 1 is a flow chart showing a dual-system based system startup method 100 according to an embodiment of the present disclosure. Figure 1 , the method 100 includes the following steps 102 to 110.

[0018] In step 102, a startup flag corresponding to a boot object of a boot program in a boot communication partition is read.

[0019] In some embodiments, reading the boot flag corresponding to the boot object of the boot program in the boot communication partition includes reading anomaly detection metadata from a preset location in the boot communication partition, the anomaly detection metadata including at least one of a maximum number of boot program firmware boots, a boot program firmware boot success flag, a maximum number of system firmware boots, and a system firmware boot success flag. In this embodiment, a boot communication partition is written to a boot communication partition image file, the size of the boot communication partition image file is equal to the size of the boot communication partition, and the boot communication partition image file includes the anomaly detection metadata.

[0020] In step 104, it is detected based on the startup flag whether the guidance object was started normally during the last startup.

[0021] In some embodiments, the boot object is system firmware of the current partition system. In this embodiment, detecting whether the boot object was normally booted the last time it was booted based on the boot flag includes: detecting whether the boot flag has been flagged; if so, determining that the system firmware was normally booted the last time; otherwise, determining that the system firmware was not normally booted the last time.

[0022] In this way, the system firmware's last boot is confirmed by checking whether the boot flag was marked. If the system firmware last booted normally, the boot flag is first reset to remove the marking from the last boot, enabling accurate detection of each boot. If the system firmware did not boot normally, the backup partition system is switched to boot the backup partition system. This ensures accurate determination of the system firmware's normal operation each time it boots, effectively improving system detection efficiency and accuracy.

[0023] In some embodiments, the boot object is the boot program firmware of the current partition system, and the boot program firmware is used to boot the system firmware of the current partition system. In this embodiment, the boot mark includes a program boot mark and a firmware boot mark. Detecting whether the boot object was normally started at the last boot based on the boot mark includes: detecting whether the program boot mark corresponding to the boot program firmware in the boot mark has undergone the marking process; if the program boot mark has undergone the marking process, determining that the boot program firmware was normally started last time, and detecting whether the firmware boot mark corresponding to the system firmware in the boot mark has undergone the marking process; if so, performing the reset process on the boot mark; otherwise, switching the current partition system to the backup partition system, and booting the backup partition system through the reset operation.

[0024] In this way, the introduction of program startup flags and firmware startup flags can detect the startup status of the boot program firmware and system firmware respectively, further refining the startup status detection dimension. When the boot program firmware is booted, the simultaneous detection of the firmware startup flag and the program startup flag can effectively distinguish whether the current system startup failure is caused by the boot program firmware or the system firmware, thereby gaining a more comprehensive understanding of the startup status of the boot object. If either the firmware startup flag or the program startup flag is not marked, the system can promptly detect and take appropriate recovery measures to avoid system resource occupation caused by invalid booting.

[0025] In step 106, if the boot object was started normally last time, the startup flag is reset, and the boot object is continued to be booted through the boot program.

[0026] In step 108, if the guidance object is started normally, the start flag is marked.

[0027] In some embodiments, before reading the boot flag corresponding to the boot object of the boot program in the boot communication partition, method 100 may further include: receiving a meta-image file, wherein the meta-image file stores an initial reset value of the boot flag, and writing the meta-image file to the boot communication partition. In this embodiment, resetting the boot flag includes setting the boot flag to the initial reset value using the meta-image file. Furthermore, marking the boot flag includes setting the boot flag to a preset magic number.

[0028] In this way, by receiving the meta-image file and writing the initial reset value of the boot flag stored therein into the boot communication partition, the boot communication partition can be initialized. When the boot flag needs to be set to the initial reset value, the initial state of the boot flag can be directly restored through the meta-image file, simplifying the reset operation of the boot flag.

[0029] In step 110, if the boot object is not started normally, the current partition system is switched to the backup partition system, and the backup partition system is booted through a reset operation.

[0030] In some embodiments, the method 100 may further include: if the boot target failed to boot normally last time, switching the current partition system to a backup partition system, and booting the backup partition system through a reset operation. In this way, if the boot target failed to boot normally, the backup partition system can be rebooted through a reset operation. This allows the system to automatically switch to another slot to boot if the firmware of the slot that originally successfully booted is corrupted, thereby improving system boot reliability.

[0031] In some embodiments, before switching the current partition system to the backup partition system, the method 100 may further include: reading the boot startup times of the boot object in the boot communication partition; detecting whether the boot startup times have reached a preset limit; if so, resetting the boot startup times, switching the current partition system to the backup partition system, and booting the backup partition system to start through the reset operation; otherwise, updating the boot startup times, and continuing to boot the boot object through the boot program.

[0032] In this way, after determining that the boot object has not started normally, the system checks whether the number of boot attempts has reached a preset limit. If the number of boot attempts has not reached the limit, repeated boot attempts are made to the boot object, thereby avoiding system switching caused by accidental errors and improving system fault tolerance. When the number of boot attempts reaches the limit, the system switches to the backup partition system for booting. This prevents the system from endlessly looping boot attempts if the boot object in the current partition system fails to start. This enables automatic switching and recovery after multiple boot failures of the boot object, further optimizing the system recovery process and improving system reliability.

[0033] In some embodiments, after the number of boot starts reaches a preset limit, the method 100 may further include: marking the recovery flag in the boot communication partition. In this embodiment, the method 100 may further include: after the current partition system is booted, reading the recovery flag in the boot communication partition; if it is detected that the recovery flag has been marked, upgrading the currently inactive partition system.

[0034] In this way, by setting a system recovery mark in the boot communication partition and marking it when the boot object fails to start normally for multiple times, it serves as a trigger signal for partition system upgrade recovery. This allows a partition system to be re-upgraded through another normally started partition system when it fails to start normally for multiple times, so as to repair the damaged firmware and achieve automatic system recovery.

[0035] In some embodiments, upgrading the partition system that is not currently running includes: downloading the latest version of the firmware upgrade package from the upgrade server through the system recovery service; and upgrading the partition system that is not currently running according to the firmware upgrade package.

[0036] In this way, the system can automatically download the latest version of the firmware upgrade package from the upgrade server through the system recovery service and re-upgrade the currently inactive partition system, achieving automated system upgrade and recovery. The system recovery tag can automatically repair a partition system when an anomaly is detected, using another normally running partition system. This enhances the system's self-healing capabilities, reduces downtime caused by system failures, and improves system availability.

[0037] In some embodiments, switching the current system to a backup partition system includes: obtaining first system information of the current partition system from the upgrade startup information; determining second system information of a partition system that is not currently running based on the first system information; and updating the upgrade startup information based on the second system information, so that the partition system that is not currently running becomes the current partition system. In this way, the first system information of the current partition system is obtained from the upgrade startup information, and the second system information of the partition system that is not currently running is determined based on the first system information. Finally, the upgrade startup information is updated based on the second system information, so that the partition system that is not currently running becomes the current partition system, thereby achieving flexible switching of the current partition system. When a startup abnormality occurs in the current partition system, it can quickly switch to another partition system, avoiding downtime caused by system failure, improving system availability, and ensuring continuous operation of the system.

[0038] Hereinafter, the dual-system-based system startup method according to an embodiment of the present invention will be described by way of example in which it is applied to an Android A / B system.

[0039] Figure 2 2 is a flow chart showing a method 200 for initializing a boot communication partition according to an embodiment of the present invention, including steps 202 to 204 .

[0040] Step 202: construct a meta-image file according to the size of the boot communication partition in the primary boot storage medium.

[0041] In some embodiments, constructing a meta-image file specifically includes: constructing a binary image file of the same size as the boot communication partition, writing a boot flag, a boot start count, and a system recovery flag into the image file, and writing initial reset values corresponding to the boot flag, the boot start count, and the system recovery flag, to obtain the meta-image file. The boot flag includes a program boot flag of the Android boot program firmware and a firmware boot flag of the Android system firmware. The boot start count includes the maximum number of boots for the Android boot program firmware and the Android system firmware.

[0042] In a specific application scenario, in the meta-image file, the initial reset values of the program startup flag of the Android boot program firmware and the firmware startup flag of the Android system firmware are all 0, the maximum startup times of the Android boot program firmware and the Android system firmware are preset values greater than 0, and the initial reset value of the system recovery flag is 0.

[0043] Step 204: When the device firmware is flashed and burned, the meta-image file is written into the boot communication partition in the main boot storage medium of the device.

[0044] Device firmware for Android A / B systems includes the first-level bootloader, Android bootloader firmware, and Android system firmware. The first-level bootloader firmware (e.g., loader) is the first-level firmware loaded from the primary boot storage medium after the device powers on. The first-level bootloader firmware is highly coupled to the specific chip and is not part of the AB partition. Android bootloader firmware (e.g., uboot) is used to boot the Android system firmware. In Android A / B systems, the Android bootloader firmware is part of the AB partition (e.g., uboot_a and uboot_b). Android system firmware refers to all other Android firmware besides the first-level bootloader firmware and Android bootloader firmware, such as boot firmware and dynamic partition firmware (super).

[0045] It should be noted that the boot communication partition is a readable and writable raw partition in the Android A / B system, used for communication between the primary bootloader firmware, the Android bootloader firmware, and the Android system firmware. In the Android A / B system, a preset location in the boot communication partition stores Android A / B upgrade startup control information. During the upgrade process, the Android A / B upgrade engine (update_engine) reads and sets the Android A / B upgrade startup control information. After completing the AB upgrade, the Android A / B upgrade engine sets the upgraded slot as the boot slot and sets a preset number of boot attempts (e.g., 7). It then restarts the device to attempt to boot the upgraded slot. After entering the upgraded slot, the Android A / B system's upgrade verification service (update_verifier) sets the boot success flag (e.g., "successful") corresponding to the current boot slot in the Android A / B upgrade startup control information. The bootloader firmware in the Android A / B system is divided into primary bootloader firmware and Android bootloader firmware. The primary bootloader firmware is not part of the AB partition and is therefore not upgraded during an Android A / B system upgrade. The Android bootloader firmware is part of the AB partition and is therefore upgraded by the Android A / B upgrade engine during Android A / B system upgrades. Both the primary bootloader firmware and the Android bootloader firmware can obtain the current boot slot from the Android A / B upgrade launch control information according to the Android A / B specification and determine whether the corresponding slot has the successful launch flag set.

[0046] After the device starts, it runs the first-level bootloader, Android bootloader firmware, and Android system firmware in sequence to start the Android system.

[0047] Figure 3 3 is a flow chart showing a method 300 for running a first-level boot program firmware according to an embodiment of the present invention, including steps 302 to 316 .

[0048] Step 302 : before booting the Android boot program firmware, read the program startup flag of the Android boot program firmware and the firmware startup flag of the Android system firmware from the boot communication partition in the main startup storage medium.

[0049] Step 304 , detecting whether the program startup flag and the firmware startup flag are both preset magic numbers for successful startup, if so, executing step 306 , otherwise executing steps 308 to 310 .

[0050] In step 306, the boot flag, maximum boot times, and system recovery flag stored in the boot communication partition are restored to their initial reset values, and the current boot slot is obtained from the Android A / B upgrade boot control information according to the Android AB specification, and the Android boot program firmware corresponding to the current boot slot is continued to be booted.

[0051] In a specific application scenario, restoring to the initial reset value specifically includes: restoring the program startup flag and the firmware startup flag to all 0, restoring the maximum startup times of the Android boot program firmware and the Android system firmware to a preset value greater than 0, and restoring the system recovery flag to 0.

[0052] Step 308: Read the maximum number of startup times of the Android boot program firmware from the boot communication partition in the main boot storage medium.

[0053] Step 310 , detecting whether the maximum number of startup times is greater than a preset minimum number of times (0 times), if so, executing step 312 , otherwise executing steps 314 to 316 .

[0054] Step 312: After reducing the maximum number of boot times by 1, write it into the boot communication partition, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android boot program firmware corresponding to the current boot slot.

[0055] Step 314 sets the system recovery flag in the boot communication partition to the preset system recovery magic number, restores the boot flag and maximum boot count stored in the boot communication partition to their initial reset values, and retrieves the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification. The current boot slot is then switched to the backup boot slot. Specifically, if the current boot slot is slot A, the Android A / B upgrade boot control information is updated to make slot B the current boot slot; if the current boot slot is slot B, the Android A / B upgrade boot control information is updated to make slot A the current boot slot.

[0056] Step 316: Reset and restart the device to reboot and run the first-level boot program firmware.

[0057] Figure 4 4 is a flow chart showing a method 400 for running an Android bootloader firmware according to an embodiment of the present invention, including steps 402 to 416 .

[0058] Step 402: before booting the Android system firmware, read the program startup flag of the Android boot program firmware from the boot communication partition in the main boot storage medium, set the program startup flag to a preset magic number for successful startup, and then update it to the boot communication partition.

[0059] Step 404, read the firmware startup mark of the Android system firmware from the boot communication partition in the main startup storage medium, and detect whether the firmware startup mark is a preset startup success magic number, if so, execute step 406, otherwise execute steps 408 to 410.

[0060] Step 406: Restore the boot flag, maximum boot times, and system recovery flag stored in the boot communication partition to their initial reset values, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue booting the Android system firmware corresponding to the current boot slot.

[0061] Step 408: Read the maximum number of boot times of the Android system firmware from the boot communication partition in the main boot storage medium.

[0062] Step 410 , detecting whether the maximum number of startup times is greater than a preset minimum number of times (0 times), if so, executing step 412 , otherwise executing steps 414 to 416 .

[0063] Step 412: After reducing the maximum number of boot times by 1, write it into the boot communication partition, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android system firmware corresponding to the current boot slot.

[0064] Step 414: Set the system recovery flag in the boot communication partition to the preset system recovery magic number, restore the boot flag and maximum boot count stored in the boot communication partition to their initial reset values, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and switch the current boot slot to the backup boot slot.

[0065] Step 416: Reset and restart the device to reboot and run the first-level boot program firmware.

[0066] Figure 5 5 is a flow chart showing an operating method 500 of Android system firmware according to an embodiment of the present invention, including the following steps 502 to 506.

[0067] Step 502: After entering the Android system, the firmware startup flag of the Android system firmware is read from the boot communication partition through the upgrade verification service update_verifier in the A / B system, and the firmware startup flag is set to a preset startup success magic number and then updated to the boot communication partition.

[0068] Step 504: read the system recovery mark from the boot communication partition through the background system recovery service in the A / B system, and detect whether the system recovery mark is a preset system recovery magic number. If so, execute step 506; otherwise, exit the system recovery service.

[0069] Step 506: The upgrade client communicates with the upgrade server to query the latest version of the firmware upgrade package from the upgrade server, and re-upgrades the damaged slot through the A / B system upgrade method, thereby repairing the damaged slot firmware.

[0070] Since the boot flag, maximum boot count, and system recovery flag in the meta-image file are always at their initial reset values when the device is first booted after flashing, there is no need to read or check the flags during system boot. At this point, when the primary bootloader firmware is running, steps 308 to 316 are executed. When the Android bootloader firmware is running, steps 402 and 408 to 416 are executed. When the Android system firmware is running, step 502 is executed.

[0071] In another aspect of the present invention, a reliable Android A / B-based system and boot method are proposed to address the issue of automatically switching to another slot when the firmware of a slot that previously successfully booted normally in the basic AB system (without virtual AB enabled) becomes corrupted due to natural physical aging or human damage during normal use of an Android device. The proposed solution automatically switches the Android system to another slot for booting when the firmware of the slot that previously successfully booted normally becomes corrupted due to natural physical aging or human damage, and then recovers the damaged slot firmware using the firmware of the other slot that can boot normally.

[0072] In some embodiments, when the device is first started after flashing, the first-level boot program firmware checks that the maximum number of Android boot program firmware startup times in the abnormality detection metadata is greater than the preset minimum value, thereby reducing the maximum number of Android boot program firmware startup times in the abnormality detection metadata by 1, and continuing to boot the Android boot program firmware corresponding to the current boot slot. In the Android boot program firmware, first set the Android boot program firmware startup success mark in the abnormality detection metadata to the preset Android boot program firmware startup success magic number, indicating that the Android boot program firmware can run normally, and then check that the maximum number of Android system firmware startup times in the abnormality detection metadata is greater than the preset minimum value, thereby reducing the maximum number of Android system firmware startup times in the abnormality detection metadata by 1, and continuing to boot the Android system firmware corresponding to the current boot slot. In the Android system firmware, set the Android system firmware startup success mark in the abnormality detection metadata to the preset Android system firmware startup success magic number, indicating that the Android system firmware can run normally. During the subsequent normal startup process of the device, the first-level boot program firmware is started, and the Android boot program firmware startup success flag and the Android system firmware startup success flag in the abnormal detection metadata are checked to be the preset Android boot program firmware startup success magic number and the Android system firmware startup success magic number respectively. The abnormal detection metadata is set to the corresponding initial reset value, the system recovery flag is set to the corresponding initial reset value, and the Android boot program firmware corresponding to the current startup slot is continued to be booted.

[0073] In addition, in some embodiments, assuming that slot a and slot b of the current slots have been set to the startup success mark, at this time slot a (or slot b) is damaged due to natural aging (or damage) of the storage medium, resulting in the Android system firmware stored in it being unable to start normally. Since slot a (or slot b) is already in the startup success state at this time, the Android A / B system cannot automatically switch the system to another slot. In this solution, once the Android system firmware in slot a (or slot b) is damaged, the Android system cannot be successfully entered, and the Android system firmware startup success mark in the anomaly detection metadata cannot be set to the preset Android system firmware startup success magic number. Each time the device restarts, the maximum number of startups of the Android boot program firmware and the maximum number of startups of the Android system firmware are reduced by 1. After the device restarts a certain number of times, the maximum number of startups of the Android boot program firmware and or the maximum number of startups of the Android system firmware are reduced to the preset minimum value. Therefore, in the first-level boot program firmware, the system recovery mark is set to the preset system recovery mark magic number, and the anomaly detection metadata is set to the corresponding initial reset value. If the current boot slot is a, the Android A / B upgrade startup control information is updated to make slot b the current boot slot; if the current boot slot is b, the Android A / B upgrade startup control information is updated to make slot a the current boot slot. Finally, reset and restart the device, reboot and run the first-level bootloader firmware, and automatically switch the Android system to another slot for startup; after the other slot is started and the Android system firmware is started normally, the background system recovery service determines that the system recovery mark is the preset system recovery mark magic number, thereby notifying the firmware upgrade client to communicate with the firmware upgrade server, query the upgrade server for the latest version of the complete upgrade package, and re-upgrade the damaged slot through A / B upgrade, thereby repairing the damaged slot firmware.

[0074] The technical solution of the present invention can be seamlessly integrated with the existing Android A / B upgrade, and the existing Android A / B upgrade engine does not need to be modified.

[0075] In some embodiments, a binary image file of the same size as the boot communication partition is constructed as the boot communication partition image file. Anomaly detection metadata composed of the maximum number of boot times of the Android boot boot program firmware, the successful boot mark of the Android boot boot program firmware, the maximum number of boot times of the Android system firmware, and the successful boot mark of the Android system firmware is constructed, an initial reset value of the anomaly detection metadata is set, and the initial reset value of the anomaly detection metadata is written to the preset location for storing the anomaly detection metadata in the boot communication partition image file. An initial reset value of the system recovery mark is set, and the initial reset value of the system recovery mark is written to the preset location for storing the system recovery mark in the boot communication partition image file. During the burning process of the device firmware, the boot communication partition image file is written to the boot communication partition in the main boot storage medium.

[0076] Specifically: (1) Construct a binary image file with the same size as the boot communication partition as the boot communication partition image file.

[0077] (2) Construct anomaly detection metadata consisting of the maximum number of boot times of the Android boot program firmware, the successful boot flag of the Android boot program firmware, the maximum number of boot times of the Android system firmware, and the successful boot flag of the Android system firmware, set the initial reset value of the anomaly detection metadata, and write the initial reset value of the anomaly detection metadata into the preset location for storing the anomaly detection metadata in the boot communication partition image file.

[0078] Specifically, (2-1) the anomaly detection metadata consists of the maximum number of bootstrapping the Android bootloader firmware, the successful bootstrapping flag for the Android bootloader firmware, the maximum number of bootstrapping the Android system firmware, and the successful bootstrapping flag for the Android system firmware. (2-2) The initial reset value of the anomaly detection metadata is set. Specifically, the maximum number of bootstrapping the Android bootloader firmware of the anomaly detection metadata is set to a preset maximum number of boots, where the preset maximum number of boots must be greater than a preset minimum value (e.g., 0); the successful bootstrapping flag for the Android bootloader firmware of the anomaly detection metadata is set to all 0s; the maximum number of bootstrapping the Android system firmware of the anomaly detection metadata is set to a preset maximum number of boots, where the preset maximum number of boots must be greater than a preset minimum value (e.g., 0); the successful bootstrapping flag for the Android system firmware of the anomaly detection metadata is set to all 0s; (2-3) the initial reset value of the anomaly detection metadata is written to the preset location for storing the anomaly detection metadata in the boot communication partition image file.

[0079] (3) Set the initial reset value of the system recovery mark (such as 0), and write the initial reset value of the system recovery mark into the preset location for saving the system recovery mark in the boot communication partition image file.

[0080] (4) During the flashing and burning process of the device firmware, the boot communication partition image file is written to the boot communication partition in the main boot storage medium.

[0081] Then, in some embodiments, the first-level boot program firmware runs, reads the anomaly detection metadata from the preset location for storing the anomaly detection metadata in the boot communication partition, and checks whether the Android boot program firmware startup success mark and the Android system firmware startup success mark in the anomaly detection metadata are the preset Android boot program firmware startup success magic number and the Android system firmware startup success magic number respectively. If so, perform the following operation one; otherwise, perform the following operation two.

[0082] Operation 1: Set the anomaly detection metadata to the corresponding initial reset value, and write the initial reset value of the anomaly detection metadata to the preset location for storing the anomaly detection metadata in the boot communication partition; set the system recovery flag to the corresponding initial reset value, and write the initial reset value of the system recovery flag to the preset location for storing the system recovery flag in the boot communication partition; obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android boot loader firmware corresponding to the current boot slot.

[0083] Operation 2: Check whether the maximum number of boots of the Android bootloader firmware in the anomaly detection metadata is greater than the preset minimum value. If not, perform the following step (b); otherwise, perform the following step (a) Step (a): Subtract 1 from the maximum number of boots of the Android bootloader firmware in the anomaly detection metadata, write the updated anomaly detection metadata to the preset location for storing anomaly detection metadata in the boot communication partition, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android bootloader firmware corresponding to the current boot slot.

[0084] Step (b): Write the preset system recovery mark magic number to the preset location for storing the system recovery mark in the boot communication partition. Write the initial reset value of the anomaly detection metadata to the preset location for storing anomaly detection metadata in the boot communication partition. Obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification. If the current boot slot is a, update the Android A / B upgrade boot control information to make slot b the current boot slot. If the current boot slot is b, update the Android A / B upgrade boot control information to make slot a the current boot slot. Finally, reset and restart the device, re-booting and running the first-level bootloader firmware.

[0085] Specifically: (1) The first-level bootloader firmware runs, reads the anomaly detection metadata from the preset location for storing anomaly detection metadata in the boot communication partition, and checks whether the Android bootloader firmware startup success flag and the Android system firmware startup success flag in the anomaly detection metadata are respectively the preset Android bootloader firmware startup success magic number and the Android system firmware startup success magic number (the magic number is a non-zero value). If so, it means that the Android bootloader firmware and the Android system firmware can be started normally during the last startup, and execute the following step (2); otherwise, execute the following step (3).

[0086] (2) Setting the anomaly detection metadata to the corresponding initial reset value, and writing the initial reset value of the anomaly detection metadata to the preset location for storing the anomaly detection metadata in the boot communication partition; setting the system recovery mark to the corresponding initial reset value (such as 0), and writing the initial reset value of the system recovery mark to the preset location for storing the system recovery mark in the boot communication partition; obtaining the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continuing to boot the Android boot boot program firmware corresponding to the current boot slot.

[0087] Set the anomaly detection metadata to the corresponding initial reset value, that is: set the maximum number of startup times of the Android boot program firmware of the anomaly detection metadata to the preset maximum number of startup times, where the preset maximum number of startup times must be greater than the preset minimum value (such as 0); set the Android boot program firmware startup success mark of the anomaly detection metadata to all 0s; set the maximum number of startup times of the Android system firmware of the anomaly detection metadata to the preset maximum number of startup times, where the preset maximum number of startup times must be greater than the preset minimum value (such as 0); set the Android system firmware startup success mark of the anomaly detection metadata to all 0s.

[0088] (3) Check whether the maximum number of boot times of the Android boot program firmware in the anomaly detection metadata is greater than the preset minimum value (such as 0). If not, execute the following step (4); otherwise, reduce the maximum number of boot times of the Android boot program firmware in the anomaly detection metadata by 1, write the updated anomaly detection metadata to the preset location for storing anomaly detection metadata in the boot communication partition, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android boot program firmware corresponding to the current boot slot.

[0089] (4) Write the preset system recovery mark magic number (this magic number can be different from the initial reset value) to the preset location for storing the system recovery mark in the boot communication partition, and write the initial reset value of the anomaly detection metadata to the preset location for storing the anomaly detection metadata in the boot communication partition. Obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification. If the current boot slot is a, update the Android A / B upgrade boot control information so that the b slot is the current boot slot; if the current boot slot is b, update the Android A / B upgrade boot control information so that the a slot is the current boot slot. Finally, reset and restart the device, and reboot the first-level boot program firmware.

[0090] In addition, in some embodiments, the Android boot program firmware runs, and before booting the Android system firmware, the anomaly detection metadata is read from a preset location in the boot communication partition for storing anomaly detection metadata, and the Android boot program firmware startup success mark in the anomaly detection metadata is set to a preset Android boot program firmware startup success magic number, indicating that the Android boot program firmware can run normally, and the updated anomaly detection metadata is written to the preset location in the boot communication partition for storing anomaly detection metadata.

[0091] Check whether the Android system firmware boot success flag in the anomaly detection metadata is the preset Android system firmware boot success magic number. If it is, it means that the Android system firmware can be booted normally during the last boot. Perform the following operation 1; otherwise, perform the following operation 2.

[0092] Operation 1: Set the anomaly detection metadata to the corresponding initial reset value, and write the initial reset value of the anomaly detection metadata to the preset location for storing the anomaly detection metadata in the boot communication partition; set the system recovery mark to the corresponding initial reset value, and write the initial reset value of the system recovery mark to the preset location for storing the system recovery mark in the boot communication partition; obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android system firmware corresponding to the current boot slot.

[0093] Operation 2: Check whether the maximum number of Android system firmware boot times in the anomaly detection metadata is greater than the preset minimum value. If not, perform the following step (b); otherwise, perform the following step (a): (a) Reduce the maximum number of Android system firmware boot times in the anomaly detection metadata by 1, write the updated anomaly detection metadata to the preset location for storing anomaly detection metadata in the boot communication partition, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue booting the Android system firmware corresponding to the current boot slot.

[0094] (b) Write the preset system recovery flag magic number to the preset location in the boot communication partition used to store the system recovery flag. Write the initial reset value of the anomaly detection metadata to the preset location in the boot communication partition used to store the anomaly detection metadata. Obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification. If the current boot slot is a, update the Android A / B upgrade boot control information to make slot b the current boot slot. If the current boot slot is b, update the Android A / B upgrade boot control information to make slot a the current boot slot. Finally, reset and restart the device, re-booting and running the first-level bootloader firmware.

[0095] Specifically: (1) before booting the Android system firmware, read the anomaly detection metadata from the preset location for storing anomaly detection metadata in the boot communication partition, set the Android boot program firmware startup success mark in the anomaly detection metadata to the preset Android boot program firmware startup success magic number, indicating that the Android boot program firmware can run normally, and write the updated anomaly detection metadata to the preset location for storing anomaly detection metadata in the boot communication partition.

[0096] (2) Check whether the Android system firmware startup success mark in the anomaly detection metadata is the preset Android system firmware startup success magic number (the magic number is a non-zero value). If so, it means that the Android system firmware can be started normally during the last startup, and execute the following step (3); otherwise, execute the following step (4).

[0097] (3) Set the anomaly detection metadata to the corresponding initial reset value, and write the initial reset value of the anomaly detection metadata to the preset location for storing the anomaly detection metadata in the boot communication partition; set the system recovery mark to the corresponding initial reset value (such as 0), and write the initial reset value of the system recovery mark to the preset location for storing the system recovery mark in the boot communication partition; obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android system firmware corresponding to the current boot slot.

[0098] Set the anomaly detection metadata to the corresponding initial reset value, that is: set the maximum number of startup times of the Android boot program firmware of the anomaly detection metadata to the preset maximum number of startup times, where the preset maximum number of startup times must be greater than the preset minimum value (such as 0); set the Android boot program firmware startup success mark of the anomaly detection metadata to all 0s; set the maximum number of startup times of the Android system firmware of the anomaly detection metadata to the preset maximum number of startup times, where the preset maximum number of startup times must be greater than the preset minimum value (such as 0); set the Android system firmware startup success mark of the anomaly detection metadata to all 0s.

[0099] (4) Check whether the maximum number of boot times of the Android system firmware in the anomaly detection metadata is greater than the preset minimum value (such as 0). If not, execute the following step (5); otherwise, reduce the maximum number of boot times of the Android system firmware in the anomaly detection metadata by 1, write the updated anomaly detection metadata to the preset location for storing anomaly detection metadata in the boot communication partition, obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification, and continue to boot the Android system firmware corresponding to the current boot slot.

[0100] (5) Write the preset system recovery mark magic number to the preset location for storing the system recovery mark in the boot communication partition, and write the initial reset value of the anomaly detection metadata to the preset location for storing the anomaly detection metadata in the boot communication partition. Obtain the current boot slot from the Android A / B upgrade boot control information according to the Android AB specification. If the current boot slot is a, update the Android A / B upgrade boot control information so that the b slot is the current boot slot; if the current boot slot is b, update the Android A / B upgrade boot control information so that the a slot is the current boot slot. Finally, reset and restart the device, and restart the first-level boot boot program firmware.

[0101] In addition, in some embodiments, the Android system firmware runs: (1) after successfully entering the Android system, the upgrade verification service update_verifier in the A / B system runs, and the upgrade verification service update_verifier in the A / B system reads the abnormality detection metadata from the preset location in the boot communication partition for storing abnormality detection metadata, sets the Android system firmware startup success mark in the abnormality detection metadata to the preset Android system firmware startup success magic number, indicating that the Android system firmware can run normally, and writes the updated abnormality detection metadata to the preset location in the boot communication partition for storing abnormality detection metadata. The upgrade verification service update_verifier in the A / B system runs once each time the device boots and enters the Android system. This is a feature of the existing Android A / B system.

[0102] (2) After the Android system firmware starts normally, the background system recovery service reads the system recovery mark from the preset location for saving the system recovery mark in the boot communication partition, checks whether the read system recovery mark is the preset system recovery mark magic number, and if not, exits the system recovery service; otherwise, notifies the firmware upgrade client to communicate with the firmware upgrade server, queries the latest version of the complete upgrade package from the upgrade server, and re-upgrades the damaged slot through A / B upgrade, thereby repairing the damaged slot firmware.

[0103] According to another aspect of the present invention, Figure 6 FIG. 6 is a schematic diagram showing the structure of an electronic device 600 according to an embodiment of the present invention. Figure 6 The electronic device 600 includes a memory 602, a processor 604, and a computer program stored in the memory 604 and executable on the processor. When the processor 604 executes the computer program, the steps of the dual-system-based system startup method described above are implemented.

[0104] In summary, the present invention provides a system startup method and electronic device based on a dual system, which utilizes the existing dual system to mark the slot as successfully started after it is upgraded and successfully started in one slot. After determining that the boot object was marked as normally started at the last startup based on the startup mark, the startup mark is reset to distinguish between a system that has been marked as successfully started but is running abnormally and a system that has been marked as successfully started and is running normally. If multiple boot firmware startups are unsuccessful, the system will reboot the backup partition system through a reset operation to automatically switch to another slot to start the system when the firmware of the slot that was originally successfully started is damaged, thereby improving the reliability of the system startup. In addition, before switching to the backup partition system startup, a system recovery mark is recorded in the boot communication partition, so that the normally started system is triggered by the system recovery mark to re-upgrade the abnormally started system to repair the damaged firmware of the system, thereby improving the self-healing ability of the system. The present invention utilizes the existing system upgrade mechanism to achieve slot switching, and can be seamlessly coupled with the existing system without modifying the system upgrade mechanism.

[0105] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's description and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A system startup method based on dual systems, characterized in that: include: Reading a boot tag corresponding to a boot object of a boot program in a boot communication partition; Detecting whether the guide object was started normally at the last startup according to the startup mark; If the boot object was started normally last time, resetting the startup flag and continuing to guide the boot object to start through the boot program; If the guidance object is started normally, marking the startup mark; as well as If the boot object fails to start normally, the current partition system is switched to the backup partition system, and the backup partition system is booted through a reset operation.

2. The system startup method according to claim 1, characterized in that: Reading the boot flag corresponding to the boot object of the boot program in the boot communication partition includes: Abnormality detection metadata is read from a preset location in the boot communication partition, wherein the abnormality detection metadata includes at least one of a maximum number of boot times of boot program firmware, a boot program firmware boot success mark, a maximum number of system firmware boot times, and a system firmware boot success mark.

3. The system startup method according to claim 2, characterized in that: A boot communication partition mirror file is written into the boot communication partition, a size of the boot communication partition mirror file is equal to a size of the boot communication partition, and the boot communication partition mirror file includes the abnormality detection metadata.

4. The system startup method according to claim 1, characterized in that: The boot object is the system firmware of the current partition system; Wherein, detecting whether the guide object was started normally at the last startup according to the startup mark includes: detecting whether the start mark is to be processed; If yes, determining that the system firmware last started normally; and Otherwise, it is determined that the system firmware was not started normally last time.

5. The system startup method according to claim 1, characterized in that: The boot object is the boot program firmware of the current partition system, and the boot program firmware is used to boot the system firmware of the current partition system; The startup mark includes a program startup mark and a firmware startup mark; Wherein, detecting whether the guide object was started normally at the last startup according to the startup mark includes: detecting whether a program startup mark corresponding to the boot program firmware in the startup mark has been subjected to the mark processing; If the program startup mark has been marked, determining whether the boot program firmware was normally started last time, and detecting whether the firmware startup mark corresponding to the system firmware in the startup mark has been marked; If yes, performing the reset process on the startup flag; Otherwise, the current partition system is switched to the backup partition system, and the backup partition system is booted up through a reset operation.

6. The system startup method according to claim 1, characterized in that: Also includes: If the boot object was not started normally last time, the current partition system is switched to the backup partition system, and the backup partition system is booted through a reset operation.

7. The system startup method according to claim 5 or 6, characterized in that: Before switching the current partition system to the backup partition system, it also includes: Reading the boot start times of the boot object in the boot communication partition; Detecting whether the number of boot starts reaches a preset limit; If yes, resetting the boot and start times, switching the current partition system to the backup partition system, and booting the backup partition system through the reset operation; and Otherwise, the boot startup times are updated, and the boot object is continued to be booted through the boot program.

8. The system startup method according to claim 7, characterized in that: After the boot-up times reach a preset limit, the method further includes: Marking the recovery mark in the boot communication partition; The method further comprises: After the current partition system is started, reading the recovery flag in the boot communication partition; If it is detected that the recovery mark has been marked, the partition system that is not currently running is upgraded.

9. The system startup method according to claim 8, characterized in that: Upgrading a partitioned system that is not currently running includes: Download the latest version of the firmware upgrade package from the upgrade server through the system recovery service; The non-running partition system is upgraded according to the firmware upgrade package.

10. The system startup method according to claim 1, characterized in that: Before reading the boot tag corresponding to the boot object of the boot program in the boot communication partition, it also includes: receiving a meta-image file, wherein the meta-image file stores an initial reset value of the startup flag, and writing the meta-image file into a boot communication partition; Resetting the startup flag includes: Setting the startup flag to an initial reset value through the meta-image file; and Marking the startup mark includes: The startup mark is set to a preset startup magic number.

11. The system startup method according to claim 1, characterized in that: Switching the current system to the backup partition system includes: Get the first system information of the current partition system from the upgrade startup information; Determining second system information of a partition system that is not currently running according to the first system information; and The upgrade startup information is updated according to the second system information, so that the non-running partition system becomes the current partition system.

12. An electronic device, characterized in that: include: a memory configured to store an executable program; as well as A processor is configured to execute the program to perform the system startup method according to any one of claims 1 to 9.

Images