A boot program rollback method and chip
By adjusting the boot order and partition binding, the automatic rollback problem in case of FSBL anomalies was resolved, ensuring stable chip startup under abnormal conditions and enabling automatic system recovery.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING SEMIDRIVE TECHNOLOGY LTD
- Filing Date
- 2026-05-19
- Publication Date
- 2026-06-16
AI Technical Summary
In the AB system, when the FSBL malfunctions, it cannot automatically roll back to the normal version, causing the chip to get stuck in an infinite reboot loop or become unusable. Existing technology cannot solve this problem.
By starting a read-only memory program to obtain status indicators, adjusting the FSBL boot order and partition binding, automatic rollback to the backup FSBL is achieved, ensuring that the correct partition and FSBL version are matched on the next boot.
Automatic rollback is implemented when the FSBL malfunctions, preventing the chip from restarting indefinitely or becoming unusable, thus ensuring system stability and reliability.
Smart Images
Figure CN122220147A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip technology, and in particular to a bootloader rollback method and a chip. Background Technology
[0002] With the increasing demands for system reliability and OTA (Over-the-Air) upgrades in fields such as automotive electronics and the Internet of Things, chips are widely adopting AB partitioning architecture to achieve redundant backup of system images and wireless upgrades. In an AB system, the storage space is typically divided into two partitions (Slot A and Slot B), and each partition can independently store the boot image.
[0003] When the First Stage Boot Loader (FSBL) itself needs to be upgraded via OTA, for example to fix boot defects or add support for new hardware, existing technologies have the following problems: After the chip powers on, the boot ROM program (found in the boot ROM) is responsible for loading and verifying the FSBL from the external storage device. Once the verification passes, the FSBL is considered valid and execution is initiated; however, if a new version of the FSBL passes the verification but encounters errors during actual operation, such as initialization freezes, critical peripheral configuration errors, or memory access anomalies, the chip will fail to boot normally; since the FSBL cannot actively notify the boot ROM program when it malfunctions, after the chip restarts, the boot ROM program will repeatedly load the same faulty FSBL, causing the chip to get stuck in an infinite reboot loop or become completely unusable, unable to automatically roll back to the normal version before the FSBL upgrade. Summary of the Invention
[0004] This application is made in view of at least one of the above-mentioned technical problems existing in the prior art, and this application can realize automatic rollback when the FSBL is abnormal.
[0005] In a first aspect, embodiments of this application provide a bootloader rollback method applied to a chip, the method comprising: Start the read-only memory program to obtain the status flag; If the status indicator indicates that the preset conditions are not met, the boot read-only memory program verifies the boot loader that is first in the boot order among multiple boot loader programs. If the verification passes, the status indicator is adjusted to meet the preset conditions. The boot loader programs that are first or second in the boot order are bound to the two partitions one by one. When the status indicator indicates that the preset condition is met, the boot read-only memory program verifies the boot boot program that is second in the boot order among the plurality of boot boot programs; After the status indicator is changed from not meeting the preset conditions to meeting the preset conditions, or after the status indicator is changed from meeting the preset conditions and the verification passes: The target bootloader among the plurality of bootloaders determines the target partition with an activity identifier from the two partitions; wherein, the activity identifier indicates the partition used for this boot; when the status identifier does not meet the preset conditions, the target bootloader is the bootloader with the first boot order; when the status identifier meets the preset conditions, the target bootloader is the bootloader with the second boot order. The target bootloader determines whether the image in the target partition has been successfully booted. If not, it adjusts the boot order of the top two bootloaders, switches the target partition to the other of the two partitions, adjusts the status flag to indicate that the preset condition is not met, and triggers the chip to restart.
[0006] Secondly, embodiments of this application provide a chip, including: a processor; wherein the processor is configured to execute a boot read-only memory program and a target boot program; The boot read-only memory program is configured to acquire a status identifier; if the status identifier indicates that a preset condition is not met, the boot read-only memory program verifies the boot loader that is first in the boot order among multiple boot loader programs; if the verification passes, the status identifier is adjusted to meet the preset condition; wherein, the boot loader programs that are first or second in the boot order are bound to two partitions one by one; if the status identifier indicates that the preset condition is met, the boot read-only memory program verifies the boot loader that is second in the boot order among the multiple boot loader programs; After the status indicator is changed from not meeting the preset conditions to meeting the preset conditions, or after the status indicator is met and the verification passes, the target bootloader is configured to determine the target partition with an activity indicator from the two partitions; wherein, the activity indicator indicates the partition used for this boot, and when the status indicator is not meeting the preset conditions, the target bootloader is the bootloader ranked first in the boot order, and when the status indicator is met, the target bootloader is the bootloader ranked second in the boot order; it is determined whether the image in the target partition has been successfully booted. If not, the boot order of the top two bootloaders is adjusted, the target partition is switched to the other partition among the two partitions, the status indicator is changed to not meeting the preset conditions, and the chip is restarted.
[0007] Thirdly, embodiments of this application provide a vehicle, including the chip described above.
[0008] This application provides a bootloader rollback method and chip. When the image in the target partition has not been successfully booted (i.e., OTA fails), it not only switches the active partition but also adjusts the boot order of the two FSBLs to ensure that the FSBL matches the partition on the next boot, avoiding boot anomalies caused by mismatch. Through status flag verification, even if an FSBL passes verification but crashes during runtime, the system can automatically roll back to the other FSBL after a reset. Attached Figure Description
[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0010] Figure 1 This is a flowchart illustrating a bootloader rollback method provided in one embodiment of this application; Figure 2 This is a flowchart of a bootloader rollback method provided in another embodiment of this application; Figure 3 This is a schematic diagram of a chip provided in one embodiment of this application. Detailed Implementation
[0011] To enable those skilled in the art to better understand the technical solutions of the embodiments of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0012] like Figure 1 As shown, this application embodiment provides a bootloader rollback method applied to a chip, including: Step 101: Start the read-only memory program to obtain the status flag. If the status flag indicates that the preset conditions are not met, proceed to step 102; otherwise, proceed to step 103.
[0013] After the chip powers on, the boot read-only memory program embedded within the chip is executed first. This program first reads a status flag stored in a predefined memory location, which can be a general-purpose register, a non-volatile register, or a specific memory cell. This status flag indicates whether an exception occurred during the previous boot process or whether a rollback operation is required. For example, 0 can represent that the preset conditions are not met, and 1 can represent that the preset conditions are met. When the status flag meets the preset conditions, a rollback is executed; otherwise, the normal upgrade path is executed.
[0014] Step 102: Start the read-only memory program to verify the boot loader that is first in the boot order among multiple boot loader programs. If the verification is successful, adjust the status flag to meet the preset conditions and execute step 104; wherein, the boot loader programs that are first or second in the boot order are bound to the two partitions one by one.
[0015] For ease of description, the first-stage bootloader will be simply referred to as the bootloader. The boot order refers to the order in which the ROM program attempts to boot the FSBL (FSupported File System Bootloader) under normal circumstances. This order can be determined by the FSBL's serial number, with larger serial numbers booting first, representing newer versions, and smaller serial numbers booting second. Alternatively, it can be determined by a fixed address order, such as booting from address 0 first.
[0016] The first two bootloaders are bound to the two partitions one by one. For example, for two partitions, Slot A and Slot B, FSBL1 corresponds to partition A and FSBL2 corresponds to partition B.
[0017] Verification of the FSBL can include any one of signature verification, CRC verification, and hash verification.
[0018] Before jumping to the first-order FSBL for execution, the status flag is first adjusted to meet the preset conditions, that is, set to indicate rollback. If the subsequent FSBL or operating system fails to start and causes a reset, the read-only memory program will see the status flag that meets the preset conditions when it is restarted, thereby triggering the rollback path.
[0019] Step 103: Start the read-only memory program to verify the boot loader that is second in the boot order among the multiple boot loader programs. If the verification passes, proceed to step 104.
[0020] When the status indicator suggests a rollback is needed, the read-only memory startup program no longer attempts to start the first-priority FSBL, but instead directly selects the second-priority FSBL for verification, typically an older version or a backup FSBL, thus achieving a rollback at the FSBL level. In practical applications, if the second-priority verification also fails, the system may enter burning mode or report an error.
[0021] Step 104: The target boot loader among multiple boot loader programs determines the target partition with an active identifier from two partitions; wherein, the active identifier indicates the partition used for this boot. If the status identifier indicates that the preset conditions are not met, the target boot loader is the boot loader with the first boot order. If the status identifier indicates that the preset conditions are met, the target boot loader is the boot loader with the second boot order.
[0022] In two scenarios, (1) after the status indicator does not meet the preset conditions and the verification is passed, and (2) after the status indicator meets the preset conditions and the verification is passed, the target starts the boot program to execute the subsequent steps.
[0023] Scenario (1): Target bootloader = first priority FSBL.
[0024] Scenario (2): Target bootloader = second priority FSBL.
[0025] In the AB system, the partition table maintains a set of attributes for each partition, including the Active attribute. The Active attribute is exclusive and indicates which partition the system should boot from. The FSBL reads the partition table and finds the partition with Active=1, which is the target partition. The active identifier can also be stored in a separate storage area or indicated via hardware registers.
[0026] Step 105: The target bootloader determines whether the image in the target partition has been successfully booted. If not, it adjusts the boot order of the top two bootloaders, switches the target partition to the other partition of the two partitions, adjusts the status flag to "not meeting the preset conditions", and triggers the chip to restart.
[0027] Determining whether a partition has been successfully booted can be done by reading the `Successful` attribute in the partition table. If this attribute is true, it means that the partition successfully reached the operating system layer in a past boot; if it is false, it means that this is a newly upgraded partition that has not yet been verified as successful. Besides the `Successful` attribute, a separate boot counter can also be used.
[0028] If the target partition has not been successfully booted, the currently failed FSBL is downgraded, for example, by changing its sequence number to 0, or by other means ensuring that the FSBL is no longer the first priority when the read-only memory program boots next time. Typically, the priority of the currently used FSBL is lowered, thus rolling back to another FSBL. Partition switching can be achieved by modifying the partition table, that is, changing the Active attribute from the current target partition to another partition, thus achieving a rollback at the AB system level.
[0029] After restarting, the read-only memory program reads the status flag and finds that the preset conditions are not met. Therefore, it selects a new first-priority FSBL. At this time, the first-priority FSBL is the adjusted FSBL corresponding to another partition. At the same time, the new active partition is the old version, and the system is restored to the state before the upgrade.
[0030] When the image in the target partition has not been successfully booted (i.e., OTA fails), this embodiment not only switches the active partition but also adjusts the boot order of the two FSBLs to ensure that the FSBL matches the partition on the next boot, avoiding boot anomalies caused by mismatch. Through status flag verification, even if an FSBL passes verification but crashes during runtime, the system can automatically roll back to the other FSBL after a reset.
[0031] In one embodiment of this application, the method further includes: If the bootloader that is first in the boot order fails the verification, the boot ROM program will adjust the status flag to meet the preset conditions, trigger the chip to restart, and execute the boot ROM program to obtain the status flag.
[0032] Possible reasons for verification failure include: signature mismatch, incorrect hash value, corrupted image data, invalid image format, or image length exceeding expectations. Verification failure means that the FSBL is untrusted and cannot be executed securely. When launching a read-only memory program, jumping to this FSBL must be avoided, otherwise it may lead to system hang or security risks.
[0033] After the read-only memory program reads the verification failure, it actively modifies the status flag to meet the preset conditions, such as setting it to 1. The purpose is to indicate that this startup attempt failed because the FSBL is invalid and it is necessary to enter the rollback path.
[0034] After setting the status flag, a global reset of the chip is actively triggered, such as writing to the reset register, executing a watchdog reset, or jumping to the reset vector. After restarting, the read-only memory program will begin execution from step 101. When the newly upgraded FSBL fails the verification, this embodiment can automatically detect and trigger a rollback, avoiding the system getting stuck in a loop of repeated attempts.
[0035] In one embodiment of this application, after the target bootloader among a plurality of bootloaders determines the target partition with an active identifier from two partitions, the method further includes: The target bootloader determines whether the partition it is bound to is the target partition; If the target bootloader is bound to the target partition and the image in the target partition has not been successfully booted, the target bootloader determines whether the image in the target partition meets the preset boot conditions. If not, it adjusts the boot order of the first two bootloaders. If the partition to which the target bootloader is bound is not the target partition, or if the image in the target partition has not been successfully booted, the boot order of the first two bootloaders will be adjusted.
[0036] Each FSBL is bound to a fixed partition at the factory or during upgrade; for example, FSBL1 is bound to Slot A, and FSBL2 is bound to Slot B. The target bootloader (target FSBL) reads the partition identifier it is bound to and then compares it with the target partition. The binding relationship can be stored in a special field in the partition table or in a dedicated binding register.
[0037] When the FSBL matches the active partition, but that active partition has not yet been successfully booted, this means that the first boot attempt after an OTA is in progress. At this time, the FSBL will not roll back immediately, but will further check whether the image in the partition meets the preset boot conditions. If it does, booting is allowed to continue; otherwise, a rollback is triggered.
[0038] The activation conditions can be set according to specific business needs, such as the remaining number of retries being greater than a preset threshold, or the retry duration being less than a preset duration threshold.
[0039] When the FSBL does not match the active partition, it indicates that the system is in an abnormal state. At this point, regardless of the remaining retries for the target partition, no further attempts to boot from that partition will be made. Therefore, triggering a rollback directly improves system determinism. When the FSBL matches the active partition and the boot conditions are met, the system is allowed to continue attempting to boot instead of immediately rolling back, avoiding misjudging a failure and rolling back due to a brief boot delay.
[0040] In one embodiment of this application, the method further includes: if the partition bound to the target bootloader is the target partition and the image in the target partition has been successfully booted, the target bootloader adjusts the status flag to indicate that the preset conditions are not met and boots the image in the target partition.
[0041] The status flag is promptly adjusted to indicate that the preset conditions are not met, preventing the read-only memory program from being incorrectly identified as needing a rollback during the next cold start or restart, thus ensuring a smooth normal startup path.
[0042] In one embodiment of this application, the method further includes: If the partition bound to the target bootloader is not the target partition, or if the image in the target partition has already been successfully booted, the target bootloader will adjust the boot order of the top two bootloaders, change the status flag to "not meeting the preset conditions", and trigger a chip restart.
[0043] The image was previously running in Slot B, and Slot B had been successfully started. However, some anomalies may have occurred later, causing the currently running target FSBL to mismatch with the active partition. Ideally, the FSBL should clear the status flags after each successful boot, leaving no unnecessary markers. However, if the hardware reset results in the loss of some status, or if the OTA process is abnormally interrupted and then manually resumed, or if the partition table is manually modified during the debugging phase, this mismatched state may occur.
[0044] The purpose of adjusting the boot order is to ensure that the FSBL bound to this target partition is selected when the read-only memory program starts up next time. In other words, it downgrades currently mismatched FSBLs, making the other FSBL bound to the target partition the first priority.
[0045] When the FSBL and partition do not match but the image has already been successfully booted, traditional AB systems typically either deadlock outright or rely on watchdog timer resets, failing to provide accurate repair. This application's embodiment autonomously adjusts the FSBL boot order instead of switching partitions, achieving a more intelligent recovery strategy.
[0046] In one embodiment of this application, the method further includes: If the image in the target partition meets the boot conditions, the target boot loader will adjust the status flag to indicate that the preset conditions are not met and then start the image in the target partition.
[0047] If the startup conditions are not checked, all matching cases that have not been successfully started will be rolled back according to the branch indicating that the startup conditions are not met. OTA upgrades will fail because the new partition will never have a chance to be attempted. Therefore, the embodiments of this application represent a necessary channel for enabling OTA upgrades to proceed normally.
[0048] After adjusting the status flag in the FSBL, the system follows the normal boot process, loading and jumping to the operating system image in the target partition to attempt to boot the system. If the boot is successful, the operating system will mark the target partition as successfully booted. If the boot fails, the system may crash, time out, or trigger a watchdog reset during the boot process. After the reset, the chip re-executes the boot ROM program. Because the status flag adjustment no longer meets the preset conditions, the boot ROM program will not directly roll back the FSBL. Instead, it will select the same FSBL again.
[0049] The upgraded partition has not yet been successfully booted, but this embodiment of the application allows the system to attempt to boot normally when the boot conditions are met, instead of rolling back immediately.
[0050] In one embodiment of this application, the startup condition includes: whether the remaining number of restarts is greater than 0; If the image in the target partition meets the boot conditions, before adjusting the status flag to indicate that the preset conditions are not met, the method further includes: The target bootloader will decrement the remaining reboot count by 1.
[0051] In the AB system, the remaining reboot count is a field in the partition table attributes that records the number of times a current partition can be attempted to boot before it is deemed unbootable. When the remaining reboot count is greater than 0, it means that the system still has a chance to try booting from that partition. When the remaining reboot count is equal to 0, it means that the partition has tried enough times but all attempts have failed, and a rollback should be triggered.
[0052] If the newly upgraded partition has problems, the system will not attempt to boot indefinitely, ensuring that the system eventually converges to a stable state.
[0053] In one embodiment of this application, the target bootloader determines whether the image in the target partition has been successfully booted, including: The target bootloader obtains the boot identifier of the target partition and determines whether the boot identifier indicates that the image in the target partition has been successfully booted.
[0054] The target bootloader needs to determine whether the operating system image in the target partition has been successfully booted before. To make this determination, the FSBL reads a boot flag associated with that partition. The boot flag is a flag or field stored in non-volatile storage media specifically used to record the boot status of the partition. In AB systems, this flag is often called the "successful" flag. This flag can be stored in a partition attribute field in the partition table or in a separate dedicated storage area. For example, `successful=true` indicates that the image in the partition has been successfully booted, while `successful=false` indicates that it has not been successfully booted.
[0055] This application's embodiments introduce a boot identifier, transforming the abstract concept of whether a partition image has successfully booted into a storable and readable concrete data field. FSBL does not need to analyze boot logs or wait for external signals; it can quickly and deterministically make a determination simply by reading the partition table.
[0056] like Figure 2As shown in the figure, this application embodiment provides a bootloader rollback method, including the following steps: After the chip is powered on, the read-only memory program executes the boot process, first obtaining the status flag rollbackflag. The read-only memory program is located in the Boot ROM.
[0057] Depending on whether the status flag is set, proceed to different branches: Branch 1: Rollback flag not set The read-only memory program is started to verify FSBL2, which is the first boot loader in the boot order among multiple boot loader programs.
[0058] If the verification passes: then jump to FSBL2 for execution.
[0059] If the verification fails: Start the read-only memory program to directly set the rollback flag, trigger the chip to restart, and reacquire the rollback flag.
[0060] Branch 2: Set the rollback flag The read-only memory program verifies FSBL1, which is the second boot loader in the boot order among multiple boot loader programs.
[0061] If the verification passes: Set the rollback flag and jump to FSBL1 for execution.
[0062] If the verification fails: the system will enter a restart waiting process, prompting that it needs to be re-burned.
[0063] In the following two scenarios, the program will jump to the target bootloader for execution: If the rollback flag is not set, and the verification passes and the rollback flag is set, then jump to FSBL2; After the rollback flag is set and the verification passes, jump to FSBL1.
[0064] The target bootloader reads the partition with the active identifier from the two partitions and determines the active slot of the target partition for this boot.
[0065] The target bootloader determines whether the partition it is bound to is the target partition.
[0066] The target bootloader obtains the "successful" boot flag from the target partition, determines whether the image in the target partition has already been successfully booted (i.e., whether the "successful" flag is set), and then proceeds to different branches: Branch A: The target partition has been successfully booted. Sub-branch A1: The partition to which the target bootloader is bound is the target partition. The target bootloader clears the rollback flag and starts the image in the target partition.
[0067] Sub-branch A2: The partition to which the target bootloader is bound is not the target partition. The target bootloader adjusts the boot order of the first two bootloaders, such as changing the FSBL2 serial number to 0, so that its priority is lower than FSBL1; Clear the rollback flag; The chip was triggered to restart.
[0068] Branch B: The target partition has not been successfully booted. Sub-branch B1: The partition to which the target bootloader is bound is the target partition. The target bootloader determines whether the target partition image meets the preset boot conditions: The startup condition is whether the remaining retry count for the target partition is greater than 0; If the boot conditions are not met: perform a rollback operation; specifically, adjust the boot order, switch partitions, clear the rollback flag, and restart.
[0069] If the startup conditions are met: Decrement the remaining number of restarts for the target partition by 1; Clear the rollback flag; Start the image in the target partition.
[0070] Sub-branch B2: The partition to which the target bootloader is bound is not the target partition. The target bootloader adjusts the boot order of the first two bootloaders, such as changing the FSBL2 serial number to 0, so that its priority is lower than FSBL1; Switch the active slot from partition B to partition A; Clear the rollback flag.
[0071] If the target partition image boots successfully, the system continues to boot and enters the subsequent boot process; if the entire system boots successfully, the successful attribute of the target partition is marked as true, and the current boot process is completed; if the system boots unsuccessfully, the chip is triggered to restart.
[0072] The following will explain rollback in four different scenarios.
[0073] Abnormal rollback scenario 1: First-priority bootloader verification failed.
[0074] Scenario: The FSBL2 in the upgrade package is incomplete or invalid and cannot pass the verification of starting the read-only memory program.
[0075] After the chip powers on, the read-only memory (ROM) program retrieves the status flag. If the status flag indicates that the preset conditions are not met, the ROM program verifies the bootloader FSBL2, which is the first boot program in the boot sequence. If the verification fails, the ROM program adjusts the status flag to meet the preset conditions, triggering a chip restart. The process then returns to retrieving the status flag from the ROM program.
[0076] After restarting, the read-only memory program is started to obtain the status flag. If the status flag is found to meet the preset conditions, the boot loader FSBL1, which is the second in the boot order, is verified and the verification is successful.
[0077] The read-only memory program is started to adjust the status flag to meet the preset conditions and then jumps to FSBL1 for execution.
[0078] FSBL1 identifies the target partition Slot B with an active identifier from the two partitions and checks whether its own bound partition Slot A is the target partition. The result is a mismatch, and the image in the target partition has not been successfully booted.
[0079] FSBL1 adjusts the boot order of the first two boot loader programs, changes the serial number of FSBL2 to 0, switches the target partition to the other partition of the two partitions, adjusts the status flag to indicate that the preset conditions are not met, and triggers the chip to restart.
[0080] After restarting, the read-only memory program obtains a status flag indicating that the preset conditions are not met. It then verifies and starts the bootloader FSBL1, which is the first bootloader in the boot order, and starts normally. The system then starts from FSBL1 and Slot A and rolls back to the state before the upgrade.
[0081] Abnormal rollback scenario 2: The first-priority bootloader verification passes but an error occurs during runtime.
[0082] Scenario: The first-priority bootloader FSBL2 in the upgrade package passes the verification of the boot ROM program, but an exception occurs during runtime.
[0083] After the chip is powered on, the read-only memory program obtains the status flag as not meeting the preset conditions, verifies the boot loader FSBL2 which is the first in the boot sequence, and the verification passes; the read-only memory program then adjusts the status flag to meet the preset conditions and jumps to FSBL2 for execution.
[0084] FSBL2 malfunctioned and failed to reach the stage of clearing the status flag or the normal boot partition image, resulting in a system reset.
[0085] After restarting, the read-only memory program is started to obtain the status flag. It is determined that the preset conditions are met, so the boot loader FSBL1, which is the second in the boot order, is verified and the verification is successful.
[0086] The read-only memory program is started to adjust the status flag to meet the preset conditions and then jumps to FSBL1 for execution.
[0087] FSBL1 identifies the target partition Slot B with an active identifier, checks whether its bound partition Slot A is the target partition, and finds that it does not match, and that the image in the target partition has not been successfully started.
[0088] FSBL1 adjusts the boot order of the top two boot loader programs, switches the target partition to another partition, adjusts the status flag to indicate that the preset conditions are not met, and triggers a chip restart.
[0089] After restarting, the read-only memory program obtains a status flag indicating that the preset conditions are not met. It then verifies and starts the bootloader FSBL1, which is the first bootloader in the boot order, and starts normally. The system then starts from FSBL1 and Slot A and rolls back to the state before the upgrade.
[0090] Abnormal rollback scenario 3: The first-order bootloader verification passes and the binding matches, but the target partition image runs abnormally, causing the number of retries to be exhausted.
[0091] Scenario: The first-priority bootloader FSBL2 in the upgrade package passes verification and matches the active partition Slot B, but the operating system image in the active partition repeatedly fails to boot, causing the remaining reboot count to reach zero.
[0092] After the chip is powered on, the read-only memory program obtains the status flag as not meeting the preset conditions, verifies the boot loader FSBL2 which is the first in the boot sequence, and the verification passes; the read-only memory program then adjusts the status flag to meet the preset conditions and jumps to FSBL2 for execution.
[0093] FSBL2 determines that the target partition Slot B has an active identifier, determines that the partition it is bound to is Slot B, and that the image in the target partition has not been successfully started.
[0094] FSBL2 checks if the remaining restart count is greater than 0. Since the current remaining restart count is greater than 0, it decrements the remaining restart count by 1, adjusts the status flag to indicate that the preset conditions are not met, and attempts to start the image in the target partition.
[0095] The image in the target partition failed to boot, and the system was reset. After a reset, FSBL2 checks the remaining reboot count again and finds it has reached zero. FSBL2 then adjusts the boot order of the top two boot loader programs, switches the target partition to another partition, adjusts the status flag to indicate that the preset conditions are not met, and triggers a chip reboot.
[0096] After restarting, the read-only memory program obtains a status flag indicating that the preset conditions are not met. It then verifies and starts the bootloader FSBL1, which is the first bootloader in the boot order, and starts normally. The system then starts from FSBL1 and Slot A and rolls back to the state before the upgrade.
[0097] Abnormal rollback scenario 4: The first-priority bootloader has been upgraded, but the target partition has not been switched or the image has not been completed.
[0098] Scenario: During an OTA upgrade, the first-priority bootloader FSBL2 has been successfully written, but the active partition is still the old partition Slot A, or the image of the new partition Slot B has not been written or its attributes have not been switched.
[0099] After the chip is powered on, the read-only memory program obtains the status flag as not meeting the preset conditions, verifies the boot loader FSBL2 which is the first in the boot sequence, and the verification passes; the read-only memory program then adjusts the status flag to meet the preset conditions and jumps to FSBL2 for execution.
[0100] FSBL2 identifies the target partition Slot A with an active identifier, and checks whether the partition Slot B bound to it is the target partition. The result is a mismatch.
[0101] FSBL2 obtains the boot identifier of Slot A and determines that the identifier indicates that the image in the target partition has been successfully booted.
[0102] FSBL2 adjusts the boot order of the first two bootloaders, changes the status flag to indicate that the preset conditions are not met, and triggers a chip restart.
[0103] After restarting, the read-only memory program obtains a status flag indicating that the preset conditions are not met. It then verifies and starts the bootloader FSBL1, which is the first bootloader in the boot order, and starts normally. The system then starts from FSBL1 and Slot A and rolls back to the state before the upgrade.
[0104] like Figure 3 As shown, this application embodiment provides a chip, including: a processor; wherein the processor is used to execute a boot read-only memory program and a target boot program; The read-only memory program is started and configured to acquire a status flag. If the status flag indicates that the preset conditions are not met, the read-only memory program is started to verify the boot loader that is ranked first in the boot order among multiple boot loader programs. If the verification passes, the status flag is adjusted to meet the preset conditions. The first two boot loader programs in the boot order are bound to the two partitions one by one. If the status flag indicates that the preset conditions are met, the read-only memory program is started to verify the boot loader that is ranked second in the boot order among multiple boot loader programs. After the status indicator is changed from "not meeting the preset conditions" to "meeting the preset conditions," or if the status indicator is "meeting the preset conditions" and the verification passes, the target bootloader is configured to determine the target partition with an active identifier from the two partitions. The active identifier indicates the partition used for this boot. If the status indicator is "not meeting the preset conditions," the target bootloader is the first bootloader in the boot order; if the status indicator is "meeting the preset conditions," the target bootloader is the second bootloader in the boot order. It is then determined whether the image in the target partition has been successfully booted. If not, the boot order of the top two bootloaders is adjusted, the target partition is switched to the other partition among the two partitions, the status indicator is changed back to "not meeting the preset conditions," and the chip is restarted.
[0105] In one embodiment of this application, the read-only memory program is configured to adjust the status flag to meet preset conditions and trigger the chip to restart if the bootloader that is first in the boot order fails the verification, and then execute the acquisition of the status flag.
[0106] In one embodiment of this application, the target bootloader is configured to, after determining the target partition with an active identifier from two partitions among multiple bootloaders, determine whether the partition it is bound to is the target partition; if the partition bound to the target bootloader is the target partition and the image in the target partition has not been successfully booted, the target bootloader determines whether the image in the target partition meets the preset boot conditions; if not, it adjusts the boot order of the top two bootloaders; if the partition bound to the target bootloader is not the target partition and the image in the target partition has not been successfully booted, it adjusts the boot order of the top two bootloaders.
[0107] In one embodiment of this application, the target bootloader is configured to adjust the status flag to indicate that the preset conditions are not met and start the image in the target partition when the partition to which the target bootloader is bound is the target partition and the image in the target partition has been successfully started.
[0108] In one embodiment of this application, the target bootloader is configured to adjust the boot order of the top two bootloaders and set the status flag to indicate that the preset conditions are not met when the partition to which the target bootloader is bound is not the target partition or the image in the target partition has been successfully booted. This triggers a chip restart.
[0109] In one embodiment of this application, the target bootloader is configured to adjust the status flag to indicate that the preset conditions are not met, and then start the image in the target partition if the image in the target partition meets the boot conditions.
[0110] In one embodiment of this application, the startup condition includes: whether the remaining number of restarts is greater than 0; the target bootloader is configured to decrement the remaining number of restarts by 1 before adjusting the status flag to indicate that the preset condition is not met, provided that the image in the target partition meets the startup condition.
[0111] In one embodiment of this application, the target bootloader is configured to obtain the boot identifier of the target partition and determine whether the boot identifier indicates that the image in the target partition has been successfully booted.
[0112] This application provides a vehicle, including the chip described in the above embodiment.
[0113] In this application, "vehicle" can refer to "automobile," "vehicle," or "complete vehicle," or other similar terms, including general motor vehicles such as sedans, SUVs, MPVs, buses, trucks, and other freight or passenger vehicles; water transport vehicles including various boats and vessels; and aircraft, including hybrid vehicles, electric vehicles, gasoline vehicles, plug-in hybrid vehicles, fuel cell vehicles, and other alternative fuel vehicles. Hybrid vehicles refer to vehicles with two or more power sources, and electric vehicles include pure electric vehicles and range-extended electric vehicles; this application does not specifically limit their use.
[0114] It should be understood that in the embodiments of this application, the processor may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
[0115] It should also be understood that the memory mentioned in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).
[0116] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor.
[0117] It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.
[0118] In addition to the data bus, this bus may also include a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled "bus" in the diagram.
[0119] It should also be understood that the first, second, third, fourth and various numerical designations used herein are merely for descriptive convenience and are not intended to limit the scope of this application.
[0120] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.
[0121] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.
[0122] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0123] Those skilled in the art will recognize that the various illustrative logical blocks (ILBs) and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.
[0124] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0126] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0127] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.
[0128] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for rolling back a bootloader, characterized in that, Applied to chips, including: Start the read-only memory program to obtain the status flag; If the status indicator indicates that the preset conditions are not met, the boot read-only memory program verifies the boot loader that is first in the boot order among multiple boot loader programs. If the verification passes, the status indicator is adjusted to meet the preset conditions. The boot loader programs that are first or second in the boot order are bound to the two partitions one by one. When the status indicator indicates that the preset condition is met, the boot read-only memory program verifies the boot boot program that is second in the boot order among the plurality of boot boot programs; After the status indicator is changed from not meeting the preset conditions to meeting the preset conditions, or after the status indicator is changed from meeting the preset conditions and the verification passes: The target bootloader among the plurality of bootloaders determines the target partition with an activity identifier from the two partitions; wherein, the activity identifier indicates the partition used for this boot; when the status identifier does not meet the preset conditions, the target bootloader is the bootloader with the first boot order; when the status identifier meets the preset conditions, the target bootloader is the bootloader with the second boot order. The target bootloader determines whether the image in the target partition has been successfully booted. If not, it adjusts the boot order of the top two bootloaders, switches the target partition to the other of the two partitions, adjusts the status flag to indicate that the preset condition is not met, and triggers the chip to restart.
2. The method as described in claim 1, characterized in that, Also includes: If the bootloader that is first in the boot order fails the verification, the boot read-only memory program adjusts the status flag to meet the preset conditions, triggers the chip to restart, and executes the boot read-only memory program to obtain the status flag.
3. The method as described in claim 1, characterized in that, After the target bootloader among the plurality of bootloaders determines the target partition with an active identifier from the two partitions, the method further includes: The target bootloader determines whether the partition it is bound to is the target partition; If the partition to which the target bootloader is bound is the target partition and the image in the target partition has not been successfully booted, the target bootloader determines whether the image in the target partition meets the preset boot conditions. If not, it performs the adjustment of the boot order of the first two bootloaders. If the partition to which the target bootloader is bound is not the target partition, or if the image in the target partition has not been successfully booted, the boot order of the first two bootloaders will be adjusted.
4. The method as described in claim 3, characterized in that, Also includes: If the partition to which the target bootloader is bound is the target partition, and the image in the target partition has been successfully booted, the target bootloader will adjust the status flag to indicate that the preset conditions are not met, and then boot the image in the target partition.
5. The method as described in claim 3, characterized in that, Also includes: If the partition bound to the target bootloader is not the target partition, or if the image in the target partition has been successfully booted, the target bootloader adjusts the boot order of the top two bootloaders, changes the status flag to indicate that the preset condition is not met, and triggers the chip to restart.
6. The method as described in claim 3, characterized in that, Also includes: If the image in the target partition meets the boot conditions, the target bootloader adjusts the status flag to indicate that the preset conditions are not met and then starts the image in the target partition.
7. The method as described in claim 6, Its features are, The startup conditions include: whether the remaining number of restarts is greater than 0; If the image in the target partition meets the boot conditions, before adjusting the status flag to indicate that the preset conditions are not met, the method further includes: The target startup bootloader will decrement the remaining number of restarts by 1.
8. The method as described in claim 1, characterized in that, The target bootloader determines whether the image in the target partition has been successfully booted, including: The target bootloader obtains the boot identifier of the target partition and determines whether the boot identifier indicates that the image in the target partition has been successfully booted.
9. A chip, characterized in that, include: A processor; wherein the processor is configured to execute a boot read-only memory program and a target boot loader; The boot read-only memory program is configured to acquire a status identifier; if the status identifier does not meet the preset conditions, the boot read-only memory program verifies the boot loader that is ranked first in the boot order among multiple boot loader programs; if the verification passes, the status identifier is adjusted to meet the preset conditions; wherein, the boot loader programs ranked first and second in the boot order are bound to two partitions one by one; if the status identifier meets the preset conditions, the boot read-only memory program verifies the boot loader that is ranked second in the boot order among the multiple boot loader programs; After the status indicator is changed from not meeting the preset conditions to meeting the preset conditions, or after the status indicator is met and the verification passes, the target bootloader is configured to determine the target partition with an activity indicator from the two partitions; wherein, the activity indicator indicates the partition used for this boot, and when the status indicator is not meeting the preset conditions, the target bootloader is the bootloader ranked first in the boot order, and when the status indicator is met, the target bootloader is the bootloader ranked second in the boot order; it is determined whether the image in the target partition has been successfully booted. If not, the boot order of the top two bootloaders is adjusted, the target partition is switched to the other partition among the two partitions, the status indicator is changed to not meeting the preset conditions, and the chip is restarted.
10. A vehicle, characterized in that, include: The chip according to claim 9.