A boot program updating method and device

Abstract

This application discloses a method and apparatus for updating a boot program. The method is applied to a storage medium including a first bank and a second bank, wherein the first bank is an active, running bank, and the second bank is an inactive, non-running bank. The method first responds to a boot program update command and queries the burning flag bit of the storage medium. This update command instructs the target boot program to be burned to each bank of the storage medium. Subsequently, when the burning flag bit indicates that the program should be burned to the inactive bank, the target boot program is burned to the second bank. Finally, after the target boot program is successfully burned to the second bank, it is copied to the first bank, thus completing the boot program update. By using the burning flag bit as the execution basis, the target boot program is prioritized for burning to the inactive, non-running second bank. After successful burning, the target boot program is copied to the first bank. The entire process does not require direct burning operations on the active bank, avoiding interference with the currently running boot program during the update process.

Description

Technical Field

[0001] This application relates to the field of boot program update technology, and in particular to a boot program update method and device. Background Technology

[0002] With the widespread application of embedded systems in industrial control, automotive electronics and consumer electronics, the Boot program, as the core component for device startup and system initialization, directly affects the reliability and functional upgrade capabilities of the device through its stable operation and version iteration. Boot update technology has become an important support link for the whole life cycle management of embedded devices.

[0003] Most storage media adopt a dual-bank storage architecture, with each bank having a boot partition to store the boot program. Current boot program update technologies require simultaneous updates to the boot programs in both banks to ensure version consistency across the partitions.

[0004] However, the current boot program update process carries the risk of program flashing failure. Once the flashing fails, the storage medium may become unusable, commonly known as "bricked," affecting the normal use of the storage medium. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method and apparatus for updating a Boot program.

[0006] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a method for updating a Boot program, the method comprising: In response to a Boot program update command, the program flashing flag of the storage medium is queried; wherein, the Boot program update command is used to instruct the target Boot program to be flashed to each Bank in the storage medium; the storage medium includes a first Bank and a second Bank; the first Bank is an active Bank that is running, and the second Bank is an inactive Bank that is not running. When the programming flag is used to indicate that the program should be programmed into the inactive BANK, the target boot program is programmed into the second BANK. After the target boot program is successfully burned into the second BANK, the target boot program in the second BANK is copied to the first BANK.

[0007] In one possible implementation, burning the target boot program to the second BANK includes: Run the Boot program in the first BANK to burn the secondary boot loader program SBL to the storage medium; Run the SBL to burn the target Boot program to the second BANK.

[0008] In one possible implementation, after burning the target boot program to the second BANK, the method further includes: Perform an integrity check on the target boot program burned to the second BANK; If the target boot program in the second BANK passes the verification, it is determined that the target boot program in the second BANK has been successfully burned. If the target boot program in the second BANK fails the verification, the current burning flag is maintained, and the target boot program is re-burned to the second BANK.

[0009] In one possible implementation, before copying the target boot program from the second BANK to the first BANK, the method further includes: Execute the BANK switch instruction to switch the second BANK to the active BANK and the first BANK to the inactive BANK.

[0010] In one possible implementation, after copying the target boot program from the second BANK to the first BANK, the method further includes: Perform an integrity check on the target Boot program burned to the first BANK; If the target boot program in the first BANK passes the verification, it is determined that the target boot program in the first BANK has been successfully burned. If the target boot program in the first BANK fails the verification, the current burning flag is maintained, and the target boot program is re-burned to the first BANK.

[0011] In one possible implementation, after copying the target boot program from the second BANK to the first BANK, the method further includes: Execute the BANK switch instruction to switch the first BANK to the active BANK and the second BANK to the inactive BANK.

[0012] In one possible implementation, the method further includes: In response to an application update instruction, when the burning flag indicates that a program should be burned to an inactive BANK, the boot program in the first BANK is run to burn the secondary boot loader SBL to the storage medium; the application update instruction is used to instruct the target application to be burned to each Bank in the storage medium. Run the SBL to burn the target application into the second BANK, thereby updating the application in the second BANK.

[0013] In one possible implementation, the method further includes: After successfully burning the target application to the second BANK, execute the BANK switching command to switch the second BANK to the active BANK and the first BANK to the inactive BANK. Run the Boot program in the second BANK to burn the SBL onto the storage medium; Run the SBL to burn the target application into the first BANK, thereby updating the application in the first BANK.

[0014] Secondly, embodiments of this application disclose a Boot program update apparatus, the apparatus comprising: A query module is used to query the burning flag bit of the storage medium in response to a Boot program update command; wherein, the Boot program update command is used to instruct the target Boot program to be burned to each Bank in the storage medium; the storage medium includes a first BANK and a second BANK; the first BANK is an active BANK that is running, and the second BANK is an inactive BANK that is not running. The programming module is used to program the target boot program to the second BANK when the programming flag indicates that the program should be programmed to the inactive BANK. The copy module is used to copy the target boot program from the second BANK to the first BANK after the target boot program is successfully burned into the second BANK.

[0015] In one possible implementation, the burning module is specifically used to run the Boot program in the first BANK to burn the secondary bootloader SBL to the storage medium; and to run the SBL to burn the target Boot program to the second BANK.

[0016] In one possible implementation, the device further includes a verification module, which is used to perform an integrity verification on the target boot program burned to the second BANK after the target boot program is burned to the second BANK; if the target boot program in the second BANK passes the verification, it is determined that the target boot program in the second BANK has been successfully burned; if the target boot program in the second BANK fails the verification, the current burning flag is maintained and the target boot program is burned to the second BANK again.

[0017] In one possible implementation, the device further includes a switching module, which is used to execute a switching BANK instruction before copying the target Boot program in the second BANK to the first BANK, switching the second BANK to an active BANK and the first BANK to an inactive BANK.

[0018] In one possible implementation, the device further includes a verification module, which is used to perform an integrity verification on the target boot program burned to the first BANK after copying the target boot program from the second BANK to the first BANK; if the target boot program in the first BANK passes the verification, it is determined that the target boot program in the first BANK has been successfully burned; if the target boot program in the first BANK fails the verification, the current burning flag is maintained, and the target boot program is burned to the first BANK again.

[0019] In one possible implementation, the device further includes a switching module, which is used to execute a switching BANK instruction after copying the target Boot program in the second BANK to the first BANK, to switch the first BANK to an active BANK and the second BANK to an inactive BANK.

[0020] In one possible implementation, the programming module is further configured to, in response to an application update instruction, run the Boot program in the first BANK to program the secondary bootloader SBL to the storage medium when the programming flag indicates that a program should be programmed to an inactive BANK; the application update instruction is configured to indicate that a target application should be programmed to each Bank in the storage medium; and run the SBL to program the target application to the second BANK to update the application in the second BANK.

[0021] In one possible implementation, the switching module is further configured to execute a switching BANK instruction after successfully burning the target application to the second BANK, switching the second BANK to an active BANK and the first BANK to an inactive BANK. The programming module is also used to run the Boot program in the second BANK to program the SBL to the storage medium; and to run the SBL to program the target application to the first BANK to update the application in the first BANK.

[0022] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the Boot program update method as described in any of the first aspects.

[0023] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that it stores a computer program, which is loaded by a processor to execute the Boot program update method as described in any of the first aspects.

[0024] This application provides a method and apparatus for updating a boot program. The method is applied to a storage medium including a first bank and a second bank, wherein the first bank is an active bank that is running, and the second bank is an inactive bank that is not running. The method first responds to a boot program update command and queries the burning flag bit of the storage medium. The update command is used to instruct the target boot program to be burned to each bank of the storage medium. Then, when the burning flag bit indicates that the program should be burned to the inactive bank, the target boot program is burned to the second bank. Finally, after the target boot program is successfully burned to the second bank, the target boot program in the second bank is copied to the first bank, thereby completing the boot program update.

[0025] This method relies on the dual-bank architecture of the storage medium, using a burning flag as the execution criterion. It prioritizes burning the target boot program to the inactive second bank, which is not currently running. After successful burning, the target boot program is copied to the first bank. The entire process eliminates the need to directly perform the burning operation on the active bank, avoiding interference with the currently running boot program during the update process and reducing the risk of device boot failure due to program flashing failure. Furthermore, this embodiment utilizes a dual-bank partitioning design to complete the boot program update, eliminating the need for additional independent backup storage space, effectively saving storage resources and adapting to the hardware specifications of small-capacity storage chips. The entire update process is guided by flags, with simple operation logic and no complex manual intervention, reducing the operational difficulty of boot program updates. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0027] Figure 1 A flowchart illustrating a method for updating a Boot program provided in an embodiment of this application; Figure 2 A schematic diagram of a storage medium provided in an embodiment of this application; Figure 3 A flowchart illustrating another method for updating a Boot program provided in an embodiment of this application; Figure 4 A flowchart illustrating an application update method provided in this application embodiment; Figure 5 This is a schematic diagram of a Boot program update device provided in an embodiment of this application. Detailed Implementation

[0028] As described earlier, existing boot program update solutions are mostly based on a dual-partition backup architecture. Considering the storage characteristics and boot requirements of embedded systems, existing solutions divide the embedded device's storage medium into two independent areas: a primary boot partition and a backup partition. The primary boot partition is the active partition where the device is running normally, containing the currently used boot program. The backup partition is a dedicated program storage partition with no actual running function; it is only used to store the target boot program to be updated or to back up the boot program currently used in the primary partition. Upon receiving a boot program update command, the target boot program must first be burned to the dedicated backup partition. After burning, a synchronous update operation is performed on both the primary and backup partitions, overwriting the target version of the boot program in the primary boot partition.

[0029] Throughout the update process, the backup partition serves only as temporary storage or backup for the program and cannot be used as an independent boot partition to participate in device operation. Furthermore, after the update command is executed, manual intervention is required to confirm key information such as partition status and burning progress. Some steps also require professional personnel to complete parameter configuration and process triggering using specialized tools.

[0030] However, the current boot program update process carries the risk of program flashing failure. Once the flashing fails, the storage medium may become unusable, commonly known as "bricked," which not only affects the normal use of the device but also causes unnecessary losses to the user.

[0031] To address this technical problem, this application provides a method and apparatus for updating a boot program. The method is applied to a storage medium including a first bank and a second bank, where the first bank is an active, running bank and the second bank is an inactive, non-running bank. The method first responds to a boot program update command and queries the burning flag bit of the storage medium. This update command instructs the target boot program to be burned to each bank of the storage medium. Subsequently, when the burning flag bit indicates that the program should be burned to an inactive bank, the target boot program is burned to the second bank. Finally, after the target boot program is successfully burned to the second bank, the target boot program in the second bank is copied to the first bank, thereby completing the boot program update.

[0032] This method relies on the dual-bank architecture of the storage medium, using a burning flag as the execution criterion. It prioritizes burning the target boot program to the inactive second bank, which is not currently running. After successful burning, the target boot program is copied to the first bank. The entire process eliminates the need to directly perform the burning operation on the active bank, avoiding interference with the currently running boot program during the update process and reducing the risk of device boot failure due to program flashing failure. Furthermore, this embodiment utilizes a dual-bank partitioning design to complete the boot program update, eliminating the need for additional independent backup storage space, effectively saving storage resources and adapting to the hardware specifications of small-capacity storage chips. The entire update process is guided by flags, with simple operation logic and no complex manual intervention, reducing the operational difficulty of boot program updates.

[0033] The method provided in this application is applicable to various hardware devices equipped with dual-BANK architecture embedded storage chips, especially suitable for automotive electronic devices such as Body Control Modules (BCMs), Engine Control Units (ECUs), and domain controllers; industrial control devices such as Programmable Logic Controllers (PLCs), smart sensors, and IoT edge gateways; and consumer embedded devices with small storage capacity such as portable testing terminals and smart wearable devices. These hardware devices all have physically partitioned active and inactive BANK dual storage areas, and often feature limited storage space, uninterrupted device operation, and simple on-site maintenance requirements. They do not require additional backup storage hardware and can directly rely on their own dual-BANK architecture to complete boot program self-updates.

[0034] In practical applications, vehicle-mounted electronic devices can complete secure updates of the boot program through the embodiments of this application when the vehicle is stopped or in a low-power state, avoiding the failure of the update that would prevent the vehicle control module from starting. Industrial control equipment can quickly perform boot program upgrades on the production line without requiring professional personnel to carry special tools for complex operations, adapting to the rapid maintenance needs of industrial sites. Consumer embedded devices with small storage capacity can achieve boot program iteration through the embodiments of this application while saving storage resources, balancing the storage utilization of the device and the security of updates.

[0035] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0036] See Figure 1 , Figure 1 This is a flowchart illustrating a method for updating a boot program according to an embodiment of this application. The executing entity of this method can be a device capable of performing computational functions. The following description uses a controller as the executing entity, and the method includes: S101: The controller responds to the Boot program update command by querying the burning flag bit of the storage medium.

[0037] The Boot program update command is a trigger command that initiates the Boot program self-update process. It instructs the controller to burn the target Boot program to each bank of the storage medium. The burning flag is a status indicator stored in a specified storage area of ​​the storage medium.

[0038] The storage medium is the program storage medium for embedded devices. As an example, such as... Figure 2 The storage medium shown in this embodiment adopts a dual-BANK architecture, physically divided into two independent partitions: a first BANK and a second BANK. Each BANK is further divided into a Boot program area and an APP application area. Both BANKs have independent program storage and execution capabilities, enabling program updates and version management without the need for an additional dedicated backup partition.

[0039] For ease of explanation, this application embodiment uses the first BANK as the currently running active BANK and the second BANK as the inactive BANK that is not running as an example. The active BANK is the storage partition that the device is currently running, and the boot program of the active BANK is the core program that the device is currently starting and running; the inactive BANK is the storage partition that the device is not currently running, and no program is running in it, so it can be used as the target partition for program burning.

[0040] In this embodiment, the controller of the embedded device is in a real-time command listening state, capable of receiving Boot program update commands from the local operation module or an external host computer. When the controller receives a Boot program update command, it initiates the Boot program update process. The controller accesses a partition in the storage medium specifically designated for storing programming flags according to a preset storage address, and reads the programming flags within that partition. These programming flags indicate the target partition for subsequent program programming. The controller can temporarily store the read programming flag status in a local cache, providing a basis for determining the execution of subsequent steps.

[0041] Throughout the process, the Boot program update command acts as a process trigger signal, causing the controller to burn the target Boot program to each bank on the storage medium. It does not directly interfere with the selection of the burning partition; the determination of the burning partition relies entirely on the burning flag bit. The Boot program update command can carry the target Boot program or indicate the storage address of the target Boot program, which the controller then reads based on the storage address. Furthermore, the controller's querying of the burning flag bit will not cause any data writing or operational interference to the first bank currently in operation, ensuring the normal operation of the device in the initial stage of the update process.

[0042] This application embodiment uses a Boot program update command as the trigger signal for Boot program updates, achieving precise triggering of the programming flag query. This programming flag then serves as the basis for determining the programming partition, clarifying the execution direction of subsequent program programming and laying a foundation for the orderly progress of the entire update process, avoiding programming errors caused by chaotic partition selection. Simultaneously, the controller only performs read operations on the programming flag, without affecting the program data and operating status of the currently running first BANK, reducing interference with the device's normal operation and ensuring the device's operational stability during the update process. Furthermore, the clear definition and functional division of each core term makes the execution logic of the entire process clear and the division of labor well-defined, reducing the probability of errors in process execution.

[0043] S102: When the programming flag is used to indicate that the program is to be programmed to the inactive BANK, the controller programs the target boot program to the second BANK.

[0044] After querying the programming flag, the controller determines whether the flag indicates that the program should be programmed into an inactive BANK. If so, the second BANK is identified as the target partition for this programming. The controller reads the binary data of the target boot program from a specified storage location or external transmission channel, interacts with the storage medium via a preset communication protocol, and writes the target boot program segment by segment into the boot program partition of the second BANK according to the address mapping relationship. During the writing process, the controller can monitor the data transmission status in real time to ensure that each segment of data is accurately written to the corresponding address.

[0045] During the flashing process to the second bank, the second bank, being an inactive bank, does not participate in the current device operation. Therefore, the flashing operation only affects the stored data in the second bank and will not interfere with the Boot program and APP application running in the first bank. The device can maintain normal operation until the flashing is complete. After flashing, the controller will perform a preliminary verification of the Boot program partition of the second bank to confirm that the target Boot program has been completely written and no data has been lost.

[0046] In one possible implementation, the programming flag can be 0, 1, 2, or 3. When the programming flag is 0, it indicates that the current storage medium is in a normal state; when the programming flag is 1, it indicates that the boot program of the inactive BANK has been successfully programmed; when the programming flag is 2, it indicates that the boot program of each BANK in the storage medium has been successfully programmed; and when the programming flag is 3, it indicates that programming has started.

[0047] In this embodiment of the application, when the programming flag is 0, 2 or 3, the programming flag is used to indicate programming the program to the inactive BANK.

[0048] This application embodiment avoids directly writing to the running active BANK by burning the target boot program to the inactive second BANK, thus preventing interference with the normal operation of the device during the update process and reducing the risk of the device becoming "bricked" due to program flashing failure. At the same time, relying on the dual-BANK architecture, the new version of the program can be written without reserving an additional independent backup partition, effectively saving storage space of the storage medium and adapting to the hardware specifications of small-capacity storage chips.

[0049] S103: After the target boot program is successfully burned into the second BANK, the controller copies the target boot program from the second BANK to the first BANK.

[0050] After confirming successful burning of the target boot program to the second bank, the controller initiates the copying process. The controller reads the binary data of the target boot program segment by segment from the boot program partition of the second bank, temporarily stores it in an internal cache, and then writes the data from the cache to the boot program partition of the first bank according to the address mapping relationship, overwriting the original boot program. During the copying process, the controller monitors the data transmission status in real time to ensure that each segment of data is accurately written to the corresponding address, avoiding data loss or misalignment.

[0051] After the copy is complete, the controller performs an integrity check on the Boot program partition of the first BANK, compares the written data with the target Boot program in the second BANK, and determines that the copy operation is successful once the two are confirmed to be completely identical. Throughout the copy process, the device can maintain normal operation until the copy is completed and the version switch is finished, ensuring that the update process does not interrupt device services.

[0052] To more clearly illustrate the specific implementation process of the Boot program update method provided in this application embodiment, the method will be described in detail below through a complete embodiment, combined with a dual-BANK storage media architecture. This embodiment will further refine the execution details, interaction logic, and security mechanisms of each step to fully demonstrate the feasibility and reliability of this solution in practical applications. Figure 3 As shown, Figure 3 This is a flowchart illustrating another method for updating a Boot program provided in an embodiment of this application.

[0053] In this embodiment, the initial state is illustrated by taking the first BANK as the running active BANK and the second BANK as the non-running inactive BANK.

[0054] S301: The controller responds to the Boot program update command by querying the burning flag bit of the storage medium.

[0055] The controller is in a continuous listening state. Upon receiving a Boot program update command from either the local or external source, it immediately initiates the update process. The controller accesses the fixed address storing the programming flag in the storage medium, reads the current programming flag status, and temporarily stores this status in an internal cache as the basis for subsequent steps. The entire query process is a read operation only and does not affect the running status of the first BANK.

[0056] S302: When the programming flag is used to indicate that a program is to be programmed into an inactive BANK, the controller runs the Boot program in the first BANK and programs the secondary boot loader SBL into the storage medium.

[0057] The Secondary Bootloader (SBL) is a dedicated bootloader used only during the boot program's self-update phase. It provides a stable operating environment for subsequent program burning operations, completing low-level driver adaptation and data transmission control related to the burning process. The ROM partition is a partition in the storage medium used to temporarily store the SBL. When the device restarts and switches banks, the ROM partition is automatically cleared, leaving no residual data.

[0058] In this embodiment, the controller determines the programming flag. When it is confirmed that the programming flag indicates that the programming program should be programmed to an inactive BANK, it directly calls the Boot program in the currently running first BANK. Based on this Boot program, the binary data of the SBL is accurately programmed into the ROM partition of the storage medium. The SBL only takes effect during this Boot program self-update process and has no other business functions. Due to the unique characteristics of the ROM partition, the SBL in the ROM partition will be automatically cleared when the device performs a subsequent BANK switching operation. This will not generate redundant data occupying storage medium space, nor will it affect the normal operation of the device in any way.

[0059] This embodiment relies on the Boot program in the currently running first BANK to complete the SBL burning, ensuring the stability of the environment for SBL loading and operation, and providing reliable support for subsequent burning operations. Simultaneously, the SBL is temporarily stored in the ROM partition, utilizing partition characteristics to automatically clear the SBL after an update, avoiding redundant data occupying storage space and improving the security and cleanliness of the entire update scheme.

[0060] S303: The controller runs SBL to burn the target boot program to the second BANK.

[0061] After completing the SBL (System Boot Recorder) programming, the controller runs the SBL in the ROM partition to program the device. The controller reads the complete binary data of the target boot program from the device's local storage or an external transmission channel according to a preset address. Communication with the storage medium is achieved through low-level driver adaptation. The target boot program data is then precisely written segment by segment to the boot program's dedicated partition in the second bank according to the address mapping. Throughout the programming process, the SBL monitors the data transmission and writing status in real time, ensuring that each segment of data is accurately written to the corresponding storage address. Because the second bank is an inactive bank, the programming operation only changes the data stored there and does not interfere with the programs running in the first bank or the normal operation of the device.

[0062] This application embodiment provides a professional and stable programming environment through SBL, effectively improving the reliability of the target boot program programming process and reducing the probability of data writing errors. The target boot program is programmed first to the inactive second bank, avoiding direct writing operations to the running active bank, thus reducing the risk of interruption of the device's current operation due to programming operations.

[0063] S304: The controller performs an integrity check on the target boot program burned into the second BANK.

[0064] After the target boot program is burned, the controller immediately performs an integrity verification operation on the boot program partition of the second BANK. The controller reads all the data of the target boot program that has been burned in the second BANK, calculates the data feature values ​​through a preset verification algorithm, and compares them precisely with the feature values ​​of the original target boot program.

[0065] If the two characteristic values ​​are consistent, the target Boot program in the second BANK is determined to have passed the integrity check, and the burning process is confirmed to be successful. The subsequent step S205 is then executed. If the two characteristic values ​​are inconsistent, the check is determined to have failed, and the burning process is confirmed to have failed. At this time, the controller maintains the current burning flag state unchanged, re-triggers the burning process, returns to step S303, and burns the target Boot program to the second BANK again until the check is successful.

[0066] Integrity checks are performed to verify the burning results of the second BANK, improving the correctness and integrity of the target boot program burned to the inactive BANK and providing a reliable program foundation for subsequent copying operations. Simultaneously, a retry mechanism is implemented after verification failure, effectively enhancing the fault tolerance of the entire update process and preventing the termination of the entire self-update process due to accidental failure of a single burning attempt, thus ensuring the continuity of the process.

[0067] S305: The controller executes a BANK switching instruction to switch the second BANK to an active BANK and the first BANK to an inactive BANK.

[0068] The Switch BANK command is used to modify the activation status flag of the storage medium. The activated BANK after the switch is the partition that will be loaded and run first during subsequent device startup, while the inactive BANK will remain inactive. After the switch, the second BANK is set as the new activated BANK, and the first BANK becomes the inactive BANK.

[0069] After confirming that the target boot program in the second bank has been successfully burned and passed integrity verification, the controller immediately sends a bank switch command to the storage medium, triggering a partition state switch. Upon receiving the command, the storage medium modifies its own activation status flag, switching the previously inactive second bank to the new active bank, and simultaneously switching the previously active first bank to the inactive bank, completing the reverse partition state switch. After the state switch, the device performs a reboot operation, prioritizing loading the updated target boot program from the second bank, which then becomes the active bank, maintaining normal device operation. After the device reboots, the data in the ROM partition is cleared.

[0070] This application embodiment switches the BANK state, making the second BANK where the successfully verified target Boot program is located the new active BANK, improving the availability of the updated target Boot program, and providing a safe operating environment for subsequent copy operations to the original active BANK (now inactive BANK), avoiding interference with the program currently running on the device during the copy process.

[0071] This application embodiment switches the BANK, making the successfully verified target boot program the new activated program, thus ensuring the availability of the updated program. Simultaneously, it converts the original activated BANK to inactive, providing a secure target partition for subsequent copy operations.

[0072] S306: The controller copies the target boot program from the second BANK to the first BANK.

[0073] The first BANK is currently an inactive BANK and will be used as the target partition for this copy.

[0074] After completing the BANK state switch, the controller initiates the program copying process. First, it runs the target Boot program in the currently active second BANK. Using this updated Boot program as the basis, the SBL is re-burned to the ROM partition of the storage medium, completing the environment setup for the copying operation. Subsequently, the controller starts and runs the SBL in the ROM partition. The controller reads the complete binary data of the target Boot program segment by segment from the Boot program partition of the second BANK, temporarily stores it, and then writes the data segment by segment precisely to the Boot program partition of the currently inactive first BANK according to the address mapping relationship, completing the overwriting of the original old version Boot program of the first BANK. During the copying process, the controller monitors the data reading, transmission, and writing status in real time to ensure that each segment of data accurately corresponds to the storage address, with no data misalignment, loss, or tampering. Furthermore, because the first BANK is inactive, the entire copying operation will not interfere with the normal operation of the device.

[0075] This application embodiment establishes a stable and reliable execution environment for the copy operation by running the target Boot program in the verified second BANK to burn the SBL. Relying on the SBL, professional data copying operations are completed, significantly improving the accuracy and stability of the copying process. Simultaneously, performing the copy operation on the inactive first BANK avoids interference with the currently running programs on the device, ensuring the continuity of device services. Furthermore, the copy operation synchronizes the Boot program versions of both BANKs, effectively avoiding device compatibility issues caused by inconsistencies in program versions between different BANKs.

[0076] S307: The controller performs an integrity check on the target boot program burned into the first BANK.

[0077] The integrity check in step S307 is consistent with the check logic in step S304. It is used to verify whether the target boot program data copied to the first BANK is completely consistent with the target boot program data in the second BANK, to ensure the accuracy of the copy operation and avoid incomplete or unusable program data in the first BANK due to copying errors.

[0078] In this embodiment, after the copy operation in step S306 is completed, the controller immediately performs an integrity verification operation on the Boot program partition of the first BANK. The controller reads all the data of the target Boot program that has been copied in the first BANK, calculates the data feature value using the same preset verification algorithm as in step S304, and accurately compares the feature value with the feature value of the target Boot program in the second BANK.

[0079] If the two feature values ​​are consistent, the target Boot program in the first BANK is determined to have passed the integrity check, and the copy is confirmed to be successful. Step S308 is then executed. If the two feature values ​​are inconsistent, the check is determined to have failed, and the copy is confirmed to have failed. At this time, the controller maintains the current burning flag state and re-triggers the copy process, returning to step S306 to copy the target Boot program in the second BANK to the first BANK again, until the check is successful.

[0080] This application embodiment further ensures the consistency and correctness of the Boot program data in both banks by performing a second integrity check on the copied first bank, thus avoiding program version anomalies caused by copy operation errors. At the same time, it continues the retry mechanism after verification failure, further improving the reliability and fault tolerance of the entire self-update process.

[0081] S308: The controller executes a BANK switching instruction to switch the first BANK to an active BANK and the second BANK to an inactive BANK.

[0082] After confirming that the target Boot program in the first BANK has been successfully copied and passed integrity verification, the controller immediately sends a BANK switch command to the storage medium, triggering a secondary switch of the storage medium's partition status. Upon receiving the command, the storage medium modifies its own activation status flag, switching the currently active second BANK to an inactive BANK, and simultaneously switching the currently inactive first BANK to an active BANK, restoring the storage medium's dual BANKs to their initial state before the start of this self-update process. After the state is restored, both BANKs have been successfully updated to the target Boot program, and the device continues to load and run the updated Boot program from the first BANK, thus completing the entire Boot program self-update process.

[0083] This application embodiment restores the initial partition state of the storage medium, ensuring that the device's operating logic remains consistent with that before the update. No additional adjustments to the device's operating configuration are required, enhancing the practicality and convenience of the solution. Simultaneously, both banks are synchronized to the target boot program version, achieving a full partition program update and completely avoiding the problem of program version fragmentation between partitions, providing a solid guarantee for the subsequent stable operation of the device.

[0084] In addition to the above-described Boot program self-update method, this application embodiment further provides an application update method adapted to the Boot program update logic. This method is based on the state of the dual-BANK storage medium after the Boot program update is completed, and must be executed after the entire Boot program update process is completed to ensure the stability of the storage medium's boot environment during the application update process. The specific implementation steps of this application update method are described in detail below. Figure 4 As shown, Figure 4 A flowchart illustrating an application update method provided in this application embodiment. The method includes: S401: In response to an application update command, when the burning flag indicates that a program is to be burned to an inactive BANK, the controller runs the Boot program in the first BANK and burns the secondary boot loader SBL to the storage medium.

[0085] The application update command is a signal used to trigger the application self-update process, instructing the controller to burn the target application to each BANK of the storage medium. The application update command must be issued after the boot program update is completed.

[0086] After confirming the completion of the Boot program update process, the controller enters the application update command listening state. Upon receiving an application update command from either the local or external source, it first reads the burning flag bit of the storage medium. If the burning flag bit indicates that the program should be burned to the inactive BANK (second BANK) (burning flag bit is 0, 2, or 3), the controller then runs the stable Boot program that has already been updated in the first BANK. Using this Boot program as the basis for execution, the binary data of the SBL is accurately burned to the ROM partition of the storage medium, establishing a dedicated execution environment for subsequent application burning. The entire process relies on the updated Boot program to complete the SBL burning, ensuring the stability of SBL loading, and only performing operations when the burning flag bit meets the requirements, avoiding incorrect partition selection.

[0087] S402: The controller runs SBL to burn the target application to the second BANK in order to update the application in the second BANK.

[0088] After completing the SBL programming, the controller immediately starts and runs the SBL in the ROM partition to program the application. The controller reads the complete binary data of the target application from the preset storage location, establishes communication with the storage medium through the underlying driver adaptation, and writes the target application data segment by segment into the APP program's dedicated partition in the second BANK according to the address mapping relationship, overwriting the original old version of the application. During the programming process, the SBL monitors the data transmission and writing status in real time to ensure that each segment of data accurately corresponds to the storage address. Since the second BANK is an inactive partition, the programming operation will not interfere with the Boot program and device services running in the first BANK.

[0089] S403: The controller performs an integrity check on the target application program burned into the second BANK.

[0090] After the flashing is complete, the controller immediately performs an integrity check on the APP program partition of the second BANK. Using methods such as checksums and hash algorithms, it compares the target application data flashed to the second BANK with the original data to verify data integrity and the absence of loss or tampering. The controller reads all the flashed target application data from the second BANK, calculates data feature values, and precisely compares them with the feature values ​​of the original target application. If the feature values ​​match, the check passes, the application flashing to the second BANK is successful, and the subsequent step S404 continues. If the feature values ​​do not match, the check fails. The controller maintains the current flashing flag state, re-triggers the flashing process, returns to step S402, and flashes the target application to the second BANK again until the check passes.

[0091] S404: The controller executes a BANK switching instruction to switch the second BANK to an active BANK and the first BANK to an inactive BANK.

[0092] After confirming that the application has been successfully burned into the second bank and passed verification, the controller sends a bank switch command to the storage medium. Upon receiving the command, the storage medium modifies the activation status flag, switching the second bank to the active bank (running the updated boot program and target application), while simultaneously switching the first bank to the inactive bank, completing the reverse switch of partition status. After the status switch, the device continues to operate normally relying on the second bank, providing a secure operating environment for subsequent copying of applications to the first bank.

[0093] S405: The controller runs the Boot program in the second BANK to burn the SBL to the storage medium.

[0094] After completing the BANK state switch, the controller runs the Boot program in the currently active BANK. Based on this stable Boot program, the SBL is re-burned to the ROM partition of the storage medium. The SBL burned this time is only used for subsequent application burning operations of the first BANK, and due to the characteristics of the ROM partition, it will be automatically cleared when the device restarts and switches BANKs, leaving no redundant data.

[0095] S406: The controller runs SBL to burn the target application to the first BANK in order to update the application in the first BANK.

[0096] The controller starts and runs the re-flashed SBL in the ROM partition, continuing the application flashing process for the first BANK. The controller reads the complete, verified target application data from the APP program partition of the second BANK, temporarily stores it, and then writes it segment by segment to the APP program partition of the first BANK according to the address mapping relationship, overwriting the original old version of the application. During the flashing process, the controller monitors the data read, transmission, and write status in real time to ensure no data misalignment or loss. Furthermore, because the first BANK is an inactive partition, the flashing operation will not affect the current normal operation of the device.

[0097] Based on the above embodiments, this application also provides a boot program update device, such as... Figure 5 As shown, the device includes: The query module 501 is used to query the burning flag bit of the storage medium in response to the Boot program update command; wherein, the Boot program update command is used to instruct the target Boot program to be burned to each Bank in the storage medium; the storage medium includes a first BANK and a second BANK; the first BANK is an active BANK that is running, and the second BANK is an inactive BANK that is not running. The programming module 502 is used to program the target boot program to the second BANK when the programming flag bit indicates that the program should be programmed to the inactive BANK. Copy module 503 is used to copy the target boot program from the second BANK to the first BANK after the target boot program is successfully burned into the second BANK. In one possible implementation, the programming module 502 is specifically used to run the Boot program in the first BANK to program the secondary bootloader SBL to the storage medium; and to run the SBL to program the target Boot program to the second BANK.

[0098] In one possible implementation, the device further includes a verification module, which is used to perform an integrity verification on the target boot program burned to the second BANK after the target boot program is burned to the second BANK; if the target boot program in the second BANK passes the verification, it is determined that the target boot program in the second BANK has been successfully burned; if the target boot program in the second BANK fails the verification, the current burning flag is maintained and the target boot program is burned to the second BANK again.

[0099] In one possible implementation, the device further includes a switching module, which is used to execute a switching BANK instruction before copying the target Boot program in the second BANK to the first BANK, switching the second BANK to an active BANK and the first BANK to an inactive BANK.

[0100] In one possible implementation, the device further includes a verification module, which is used to perform an integrity verification on the target boot program burned to the first BANK after copying the target boot program from the second BANK to the first BANK; if the target boot program in the first BANK passes the verification, it is determined that the target boot program in the first BANK has been successfully burned; if the target boot program in the first BANK fails the verification, the current burning flag is maintained, and the target boot program is burned to the first BANK again.

[0101] In one possible implementation, the device further includes a switching module, which is used to execute a switching BANK instruction after copying the target Boot program in the second BANK to the first BANK, to switch the first BANK to an active BANK and the second BANK to an inactive BANK.

[0102] In one possible implementation, the programming module 502 is further configured to, in response to an application update instruction, run the Boot program in the first BANK and program the secondary boot loader SBL to the storage medium when the programming flag indicates that a program should be programmed to an inactive BANK; the application update instruction is configured to indicate that a target application should be programmed to each Bank in the storage medium; and run the SBL to program the target application to the second BANK to update the application in the second BANK.

[0103] In one possible implementation, the switching module is further configured to execute a switching BANK instruction after successfully burning the target application to the second BANK, switching the second BANK to an active BANK and the first BANK to an inactive BANK. The programming module 502 is also used to run the Boot program in the second BANK to program the SBL to the storage medium; and to run the SBL to program the target application to the first BANK to update the application in the first BANK.

[0104] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the boot program update method described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0105] Memory can store computer instructions. When these instructions are executed by the processor, the processor can use them to execute update methods for the boot program. Memory can also store data.

[0106] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A 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 flow or function according to the embodiments of this application is 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, 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 (DSL)) 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) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0107] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0108] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0109] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0110] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for updating a boot program, characterized in that, The method includes: In response to a Boot program update command, the program flashing flag of the storage medium is queried; wherein, the Boot program update command is used to instruct the target Boot program to be flashed to each Bank in the storage medium; the storage medium includes a first Bank and a second Bank; the first Bank is an active Bank that is running, and the second Bank is an inactive Bank that is not running. When the programming flag is used to indicate that the program should be programmed into the inactive BANK, the target boot program is programmed into the second BANK. After the target boot program is successfully burned into the second BANK, the target boot program in the second BANK is copied to the first BANK.

2. The method according to claim 1, characterized in that, The step of burning the target boot program to the second BANK includes: Run the Boot program in the first BANK to burn the secondary boot loader program SBL to the storage medium; Run the SBL to burn the target Boot program to the second BANK.

3. The method according to claim 1, characterized in that, After burning the target boot program to the second BANK, the method further includes: Perform an integrity check on the target boot program burned to the second BANK; If the target boot program in the second BANK passes the verification, it is determined that the target boot program in the second BANK has been successfully burned. If the target boot program in the second BANK fails the verification, the current burning flag is maintained, and the target boot program is re-burned to the second BANK.

4. The method according to claim 1, characterized in that, Before copying the target boot program from the second BANK to the first BANK, the method further includes: Execute the BANK switch instruction to switch the second BANK to the active BANK and the first BANK to the inactive BANK.

5. The method according to claim 4, characterized in that, After copying the target boot program from the second BANK to the first BANK, the method further includes: Perform an integrity check on the target Boot program burned to the first BANK; If the target boot program in the first BANK passes the verification, it is determined that the target boot program in the first BANK has been successfully burned. If the target boot program in the first BANK fails the verification, the current burning flag is maintained, and the target boot program is re-burned to the first BANK.

6. The method according to claim 5, characterized in that, After copying the target boot program from the second BANK to the first BANK, the method further includes: Execute the BANK switch instruction to switch the first BANK to the active BANK and the second BANK to the inactive BANK.

7. The method according to claim 1, characterized in that, The method further includes: In response to an application update instruction, when the burning flag indicates that a program should be burned to an inactive BANK, the boot program in the first BANK is run to burn the secondary boot loader SBL to the storage medium; the application update instruction is used to instruct the target application to be burned to each Bank in the storage medium. Run the SBL to burn the target application into the second BANK, thereby updating the application in the second BANK.

8. The method according to claim 7, characterized in that, The method further includes: After successfully burning the target application to the second BANK, execute the BANK switching command to switch the second BANK to the active BANK and the first BANK to the inactive BANK. Run the Boot program in the second BANK to burn the SBL onto the storage medium; Run the SBL to burn the target application into the first BANK, thereby updating the application in the first BANK.

9. A boot program update device, characterized in that, The device includes: A query module is used to query the burning flag bit of the storage medium in response to a Boot program update command; wherein, the Boot program update command is used to instruct the target Boot program to be burned to each Bank in the storage medium; the storage medium includes a first BANK and a second BANK; the first BANK is an active BANK that is running, and the second BANK is an inactive BANK that is not running. The programming module is used to program the target boot program to the second BANK when the programming flag indicates that the program should be programmed to the inactive BANK. The copy module is used to copy the target boot program from the second BANK to the first BANK after the target boot program is successfully burned into the second BANK.

10. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to perform the method for updating the Boot program as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the method for updating the Boot program as described in any one of claims 1-8.

Images