Controller firmware double-backup self-upgrading method and system, electronic equipment and medium

Abstract

The invention provides a controller firmware double-backup self-upgrading method and system, electronic equipment and a medium, controller firmware comprises an address loading partition, a main partition and a backup area, and the method comprises the steps of obtaining an upgrading instruction; in response to the upgrading instruction, determining that the upgrading instruction is a bootstrap program upgrading instruction; backing up the current firmware data in the main partition to the backup area; performing integrity verification based on the backup data in the backup area; if the integrity verification is successful, erasing the main partition and writing new firmware data into the main partition; writing state flag information of upgrading completion in the main partition, and obtaining upgraded controller firmware; and controlling the upgraded controller firmware to load an initial address from the address loading partition for restarting. According to the method and the device, the flashing upgrade of Boot is supported, the data can be successfully recovered from the backup area B when the upgrade fails, and the possibility of brick change due to flashing failure is completely eradicated.

Description

Technical Field

[0001] This application belongs to the field of automotive controller security technology, and relates to a controller firmware dual backup self-upgrade method, system, electronic device and medium. Background Technology

[0002] In recent years, with the rapid development of cutting-edge technologies such as artificial intelligence and the Internet of Things, and the rapid expansion of the market, intelligent driving has become an important direction for the evolution of the automotive industry, especially the new energy vehicle sector. As a core component for vehicle environmental perception, the performance and reliability of onboard radar (such as millimeter-wave radar and lidar) directly determine the safety and sophistication of advanced driver assistance systems (ADAS) and even autonomous driving systems. Therefore, the development of the supporting onboard controllers and their software programs is crucial.

[0003] In the software development process of radar controllers, software version iteration and program upgrades are commonplace. Currently, the industry generally uses a Boot Loader as a fundamental software component to manage application updates. The Boot Loader is the first program to run after the controller is powered on. It is responsible for initializing the hardware and boots the main application. More importantly, it provides a standard interface that enables reliable updates and upgrades to the application via network or bus without relying on dedicated hardware debugging tools.

[0004] However, existing upgrade solutions based on Boot Loader have significant limitations. In actual product development and lifecycle, not only does the main application need to be upgraded, but the Boot Loader itself may also need to be updated to fix vulnerabilities, add new features, or improve compatibility. In the early stages of product development, engineers can usually easily burn or upgrade the Boot Loader program directly through reserved debugging interfaces such as serial ports.

[0005] The problem is that once a product has completed development and entered the mass production and vehicle installation stage, radar equipment is typically subjected to rigorous laser welding encapsulation due to considerations of cost, structural sealing, and electromagnetic compatibility. After this, the casing is no longer opened, and physical interfaces such as serial port pins used for debugging are hidden and inaccessible. This leads to a serious technical challenge: once the radar is installed and encapsulated, its built-in boot loader program loses its effective upgrade path.

[0006] Currently, some tentative solutions exist to address this issue, but these solutions carry extremely high risks. For example, forcibly implementing online upgrades of the Boot Loader through limited external communication channels (such as the CAN bus). However, the Boot Loader is the cornerstone of the entire system's startup and upgrade. If any error occurs during the upgrade process due to power fluctuations, signal interference, or data packet loss, the entire bootloader will be corrupted. In this situation, the controller will be unable to load any valid program (including the Boot Loader itself and the application program), thus rendering the radar module completely unusable, commonly known as "bricked." Because the physical interface is blocked, once the device is "bricked," it cannot be recovered through conventional means and must be replaced entirely. This not only provides users with a terrible user experience but also incurs high after-sales maintenance costs and reputational damage for the manufacturer.

[0007] Therefore, there is an urgent need in this field for a solution that can safely and reliably upgrade the Boot Loader in a closed environment, in order to solve the fundamental problem of high upgrade risk or even inability to upgrade in the existing technology, and to ensure the continuous optimization and stable operation of key components of intelligent driving throughout the entire product life cycle. Summary of the Invention

[0008] This application provides a controller firmware dual-backup self-upgrade method, system, electronic device, and medium to solve the problem of high upgrade risk or even bricking during the upgrade process of the Boot Loader in the prior art.

[0009] In a first aspect, this application provides a controller firmware dual-backup self-upgrade method, wherein the controller firmware includes an address loading partition, a main partition, and a backup partition, comprising: obtaining an upgrade command; responding to the upgrade command, confirming that the upgrade command is a bootloader upgrade command; backing up the current firmware data in the main partition to the backup partition; performing an integrity check based on the backup data in the backup partition; if the integrity check is successful, erasing the main partition and writing new firmware data therein; writing upgrade completion status flag information into the main partition, obtaining the upgraded controller firmware; controlling the upgraded controller firmware to load the starting address from the address loading partition for restart; the address loading partition includes the starting address information of the main partition and the backup partition.

[0010] In one implementation of the first aspect, controlling the upgraded controller firmware to load the starting address from the address loading partition for reboot includes: during the power-on initialization phase of the upgraded controller firmware, detecting the status flag information; if the status flag information is not detected, performing an integrity check on the current bootloader in the main partition; if the integrity check is successful, writing an upgrade-complete status flag information into the main partition; if the integrity check fails, restoring the backup data in the backup area to the main partition, and after successful restoration, writing an upgrade-complete status flag information into the main partition; if the status flag information is detected, controlling the upgraded controller firmware to load the starting address from the address loading partition for reboot.

[0011] In one implementation of the first aspect, restoring backup data in the backup area to the primary partition includes: performing an integrity check on the backup data in the backup area; if the integrity check is successful, restoring the backup data in the backup area to the primary partition.

[0012] In one implementation of the first aspect, performing integrity verification on the current bootloader in the main partition includes: calculating and obtaining a corresponding hash value based on the current firmware data in the main partition; obtaining a check value at the end of the current firmware data in the main partition; the check value being a hash value calculated before the current firmware data in the main partition is written; performing integrity verification based on the hash value and the check value; if the hash value and the check value are consistent, the integrity verification is successful; if the hash value and the check value are inconsistent, the integrity verification is unsuccessful.

[0013] In one implementation of the first aspect, integrity verification based on backup data in the backup area includes: calculating and obtaining a corresponding hash value based on the backup data in the backup area; obtaining a check value at the end of the backup data in the backup area; the check value is a hash value calculated before backing up the current firmware data in the main partition; performing integrity verification based on the hash value and the check value; if the hash value and the check value are consistent, the integrity verification is successful; if the hash value and the check value are inconsistent, the integrity verification is unsuccessful.

[0014] In one implementation of the first aspect, backing up the current firmware data in the main partition to the backup area includes: clearing the status flag information in the main partition before performing the backup; and backing up the current firmware data in the main partition to the backup area.

[0015] In one implementation of the first aspect, the integrity verification is a hash operation verification.

[0016] Secondly, this application provides a controller firmware dual-backup self-upgrade system. The controller firmware includes an address loading partition, a main partition, and a backup partition. The system includes: an acquisition module configured to acquire an upgrade command; a confirmation module configured to confirm, in response to the upgrade command, that the upgrade command is a bootloader upgrade command; a backup module configured to back up the current firmware data in the main partition to the backup partition; a verification module configured to perform integrity verification based on the backup data in the backup partition; an upgrade module configured to erase the main partition and write new firmware data therein if the integrity verification is successful; a writing module configured to write upgrade completion status flag information into the main partition and acquire the upgraded controller firmware; and a restart module configured to control the upgraded controller firmware to load a starting address from the address loading partition for restarting. The address loading partition includes the starting address information of the main partition and the backup partition.

[0017] Thirdly, this application provides an electronic device, characterized in that it includes: at least one processor; and a memory communicatively connected to the at least one processor, the memory including an address loading partition, a main partition, and a backup partition; wherein the memory stores computer program instructions executable by the at least one processor, the computer program instructions being executed by the at least one processor to enable the at least one processor to execute the controller firmware dual backup self-upgrade method as described above.

[0018] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the controller firmware dual backup self-upgrade method as described above.

[0019] As described above, the controller firmware dual backup self-upgrade method, system, electronic device, and medium described in this application have the following beneficial effects:

[0020] This application provides a controller firmware dual-backup self-upgrade method. The controller firmware includes an address loading partition, a main partition, and a backup partition. The method involves: acquiring an upgrade command; confirming the upgrade command as a bootloader upgrade command; backing up the current firmware data in the main partition to the backup partition; performing an integrity check on the backup data in the backup partition; if the integrity check is successful, erasing the main partition and writing new firmware data therein; writing an upgrade completion status flag to the main partition to obtain the upgraded controller firmware; and controlling the upgraded controller firmware to load the starting address from the address loading partition for reboot. The address loading partition includes the starting address information of the main partition and the backup partition. This application, by completely backing up data to backup partition B before upgrading the main partition A, supports the flashing and upgrading of the Bootloader itself. Furthermore, in the event of an upgrade failure, data can be successfully restored from backup partition B, eliminating the possibility of bricking the device due to flashing failure. This solves the problem of high upgrade risk and even bricking due to upgrade failure in the BootLoader upgrade process in the prior art. Attached Figure Description

[0021] Figure 1 The diagram shown is a schematic representation of the structure of the memory partition of the radar device described in this application embodiment.

[0022] Figure 2 The diagram shown is a flowchart illustrating the controller firmware dual backup self-upgrade method described in this application embodiment.

[0023] Figure 3 The diagram shows a schematic representation of the Boot backup and upgrade process described in this application embodiment.

[0024] Figure 4 The diagram illustrates the process of controlling the upgraded controller firmware to load the starting address from the address loading partition and restart, as described in this embodiment of the application.

[0025] Figure 5 The diagram shows a flowchart illustrating the process of performing integrity verification on the current firmware data in the main partition as described in an embodiment of this application.

[0026] Figure 6 The diagram shows a flowchart illustrating the integrity verification process based on backup data in the backup area as described in this application embodiment.

[0027] Figure 7 The diagram shows the complete process of the controller firmware dual backup self-upgrade method described in this application embodiment.

[0028] Figure 8 The diagram shown is a structural schematic of the controller firmware dual backup self-upgrade system described in this application embodiment.

[0029] Figure 9 The diagram shown is a structural schematic of the electronic device described in an embodiment of this application.

[0030] Component designation explanation

[0031] 800 Controller firmware dual backup self-upgrade system 900 electronic devices 801 Get Module 901 processor 802 Confirmation module 902 memory 803 Backup module S201~S207 step 804 Verification module S401~S405 step 805 Upgrade module S501~S505 step 806 Write module S601~S605 step 807 Restart module Detailed Implementation

[0032] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0033] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0034] BOOT update refers to updating the bootloader of a vehicle's controller. In the automotive industry, the primary function of the bootloader is to update applications. By updating the bootloader, software can be updated without opening the controller, thereby enabling upgrades and maintenance of the vehicle's control system. This update process typically involves updating both the bootloader itself and the applications loaded through it. Updating the bootloader can be viewed as a way to upgrade and maintain the vehicle's control system software, ensuring continuous optimization of system safety, performance, and functionality.

[0035] Since the entire radar controller cannot start or update if the boot loader is corrupted, upgrades are usually not supported. To solve the problem of bricking the system due to upgrade failures, this application implements a backup upgrade solution.

[0036] The following embodiments of this application provide a controller firmware dual-backup self-upgrade method, system, electronic device, and medium, which solves the problem of high upgrade risk or even bricking due to upgrade failure in the Boot Loader upgrade process in the prior art.

[0037] The following embodiments of this application provide a controller firmware dual-backup self-upgrade method, system, electronic device and medium that support the flashing and upgrading of the boot itself, and support dual backup. After the main partition software flashing fails, it can be restored from the backup area to prevent the radar from becoming bricked due to flashing failure.

[0038] Figure 1 The diagram shown illustrates the hardware structure of the controller firmware dual backup self-upgrade method described in this application embodiment. Figure 1 As shown, the memory partitions of the radar equipment are first determined. These partitions include the payload vector table (PVT partition), the primary partition (partition A), and the backup partition (partition B). The PVT partition contains the starting address information for partitions A and B, i.e., the address loading partition. Partition A is the software runtime area, and partition B is the backup area, used to store the boot backup program. During the startup phase, the Boot ROM selects the loading partition based on the PVT address. First, it checks if partition A is complete; if it is, partition A is loaded. If partition A is incomplete, partition B is checked; if partition B is complete, partition B is loaded.

[0039] This application uses a car radar device as an example for illustration, but this application is not limited to this. Any flashing or upgrading of controller firmware can be done using the controller firmware dual backup self-upgrade method described in this application.

[0040] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0041] like Figure 2 As shown, this embodiment provides a controller firmware dual-backup self-upgrade method, wherein the controller firmware includes an address loading partition, a main partition and a backup partition, and includes the following steps S201 to S207.

[0042] Step S201: Obtain upgrade instructions.

[0043] Step S202: In response to the upgrade instruction, confirm that the upgrade instruction is a bootloader upgrade instruction.

[0044] In some embodiments, when the lower-level device receives an upgrade command, it determines whether the upgrade command is a Boot Loader based on the upgrade address to be written. If it is not a Boot Loader, the process ends and the backup operation is not performed; if it is a Boot Loader, the Boot backup operation is performed.

[0045] Step S203: Back up the current firmware data in the main partition to the backup area.

[0046] In some embodiments, the current firmware data includes bootloader and software data.

[0047] Step S204: Perform integrity verification based on the backup data in the backup area.

[0048] In some embodiments, after the current firmware data of the main partition is backed up to the backup area, an integrity verification needs to be performed first. If the integrity verification is successful, it means that the current firmware data of the main partition has been completely backed up to the backup area.

[0049] In some embodiments, the integrity verification is a hash operation verification, and preferably, the integrity verification is a SHA256 verification.

[0050] Step S205: If the integrity verification is successful, the main partition is erased and new firmware data is written into it.

[0051] In some embodiments, if the integrity verification is successful, it means that the current firmware data of the main partition has been completely backed up to the backup area. At this time, the main partition can be flashed and upgraded by erasing the main partition and writing the new firmware data into it.

[0052] Step S206: Write the upgrade completion status flag information into the main partition and obtain the upgraded controller firmware.

[0053] In some embodiments, after the main partition completes the flashing and upgrade operation, upgrade completion status flag information is written into the main partition, and the upgraded controller firmware is obtained based on the main partition, backup partition, and address loading partition where the upgrade completion status flag information is written.

[0054] Step S207: Control the upgraded controller firmware to load the starting address from the address loading partition and restart; the address loading partition includes the starting address information of the main partition and the backup partition.

[0055] In some embodiments, after the main partition is upgraded and backed up, the controller firmware restarts and powers on. During the next power-on process after the restart, the Boot Loader can read the status flag information to confirm that the upgrade process has been completed normally.

[0056] Figure 3 This diagram illustrates the Boot backup and upgrade process described in an embodiment of this application. Figure 3As shown, when the software running area A (main partition) receives the erase command, it is confirmed to be a Boot program upgrade according to the erase command. First, the software of the current main partition A is completely backed up to the backup area B. After the backup is completed, it is verified by SHA256. After the verification is successful, the erase and upgrade operations begin. After the upgrade is completed, the write completion flag is written, and then the radar is restarted and powered on.

[0057] During the power-on initialization phase, first check if the flash success flag is set. If not, check if the main partition A is complete. If the main partition A is incomplete, it means that the main partition A has been corrupted. Copy the backup partition B to the current main partition A and set the flash success flag.

[0058] This application enables the Boot itself to be flashed and upgraded by backing up the data completely to the backup area B before upgrading the main partition A. In the event of an upgrade failure, the data can be successfully restored from the backup area B, eliminating the possibility of bricking the device due to a flash failure. This solves the problem of high upgrade risk or even bricking due to upgrade failure in the Boot Loader upgrade process in the prior art.

[0059] like Figure 4 As shown, in one embodiment of this application, controlling the upgraded controller firmware to load the starting address from the address loading partition for restart includes the following steps S401 to S405.

[0060] Step S401: During the power-on initialization phase of the upgraded controller firmware, the status flag information is detected.

[0061] Step S402: If the status flag information is not detected, perform an integrity check on the current boot program in the main partition.

[0062] Step S403: If the integrity verification is successful, write the upgrade completion status flag information into the main partition.

[0063] Step S404: If the integrity verification fails, restore the backup data in the backup area to the main partition. After successful restoration, write the upgrade completion status flag information into the main partition.

[0064] Step S405: If the status flag information is detected, control the upgraded controller firmware to load the starting address from the address loading partition and restart.

[0065] In some embodiments, during the power-on initialization phase, the system first checks whether the flashing success flag is set. If not, it verifies whether the main partition A is complete. If the main partition A is incomplete, it indicates that the main partition A has been corrupted. The backup partition B is then copied to the current main partition A, and the flashing success flag is set.

[0066] In one embodiment of this application, restoring backup data in the backup area to the main partition includes the following steps S4041 to S4042.

[0067] Step S4041: Perform integrity verification on the backup data in the backup area.

[0068] Step S4042: If the integrity verification is successful, restore the backup data in the backup area to the main partition.

[0069] In some embodiments, before the Boot data recovery operation, it is necessary to perform an integrity verification on the backup data in the backup area. The verification will definitely succeed because the software in the main partition has been corrupted, and the software currently being executed is definitely the software in the backup area. The fact that it can be executed normally indicates that the software in the backup area is intact. After the integrity verification is successful, the backup data is restored to the main partition.

[0070] like Figure 5 As shown, in one embodiment of this application, the integrity verification of the current firmware data in the main partition includes the following steps S501 to S505.

[0071] Step S501: Calculate and obtain the corresponding hash value based on the current firmware data in the main partition;

[0072] Step S502: Obtain the checksum of the end of the current firmware data in the main partition; the checksum is the hash value calculated before the current firmware data is written to the main partition.

[0073] Step S503: Perform integrity verification based on the hash value and the check value;

[0074] Step S504: If the hash value matches the verification value, the integrity verification is successful;

[0075] Step S505: If the hash value and the verification value are inconsistent, the integrity verification fails.

[0076] In some embodiments, this application utilizes SHA256 checksum to perform integrity verification on the current firmware data in the main partition. First, the hash value of the current firmware data in the main partition is calculated. Then, the checksum value at the end of the current firmware data in the main partition is read. This checksum value is the hash value calculated before the current firmware data is written to the main partition. The hash value and the checksum value are compared. If they match, the integrity verification is successful; otherwise, the integrity verification is unsuccessful.

[0077] like Figure 6As shown, in one embodiment of this application, integrity verification based on backup data in the backup area includes the following steps S601 to S605.

[0078] Step S601: Calculate and obtain the corresponding hash value based on the backup data in the backup area;

[0079] Step S602: Obtain the checksum at the end of the backup data in the backup area; the checksum is the hash value calculated before backing up the current firmware data in the main partition.

[0080] Step S603: Perform integrity verification based on the hash value and the check value;

[0081] Step S604: If the hash value matches the verification value, the integrity verification is successful;

[0082] Step S605: If the hash value and the verification value are inconsistent, the integrity verification fails.

[0083] In some embodiments, this application utilizes SHA256 checksum to perform integrity verification on the backup data in the backup area. First, the hash value of the backup data in the backup area is calculated. Then, the checksum at the end of the backup data in the backup area is read. This checksum is the hash value calculated before backing up the current firmware data in the main partition. The hash value and the checksum are compared. If they match, the integrity verification is successful; otherwise, the integrity verification is unsuccessful.

[0084] In one embodiment of this application, backing up the current firmware data in the main partition to the backup area includes the following steps S2031 to S2032.

[0085] Step S2031: Clear the status flag information in the primary partition before performing the backup.

[0086] Step S2032: Back up the current firmware data in the main partition to the backup area.

[0087] In some embodiments, when performing a Boot backup operation, it is first necessary to clear the status flag information in the primary partition. The purpose of this is to prevent the primary partition from having upgrade completion status flag information after the backup upgrade, so that even if the upgrade fails, the problem of upgrade failure cannot be detected in time because this status flag information can be read.

[0088] In one embodiment of this application, the integrity verification is a hash operation verification, such as SHA256 verification.

[0089] Figure 7This diagram illustrates the complete process of the controller firmware dual backup self-upgrade method described in this application embodiment. Figure 7 As shown, when the lower-level machine (controller firmware) receives the upgrade command, it determines whether it is the BootLoader based on the flashing upgrade address. If it is not the BootLoader, the process ends and the backup operation is not performed; if it is the BootLoader, the Boot backup operation is performed.

[0090] During boot backup, you first need to clear the boot flash success flag (e.g., Figure 7 The program (using the magic word in the image) is then copied from the main partition to the backup area. The program's hash value is stored at the end of the backup area. The program in the B partition of the Flash memory is read and its SHA256 checksum is obtained. The checksum is compared with the hash at the end of the program for integrity verification. If the integrity verification fails, it means that the backup has failed, so the boot flashing is stopped and the system waits for a re-upgrade. If the integrity verification is successful, the boot flashing process continues until the flashing is successful. The boot flashing success flag is written, and a reset and restart operation is performed.

[0091] During the power-on initialization phase of reboot and reset, the Boot is first verified by reading the Boot successful flash flag in the Flash. If the Boot successful flash flag exists, it means that the Boot flash was successful. Then the process ends and other operations continue.

[0092] If the Boot flash success flag is not present, it means the flashing process was incomplete. The Boot on the main partition needs to be verified for integrity. If the integrity verification is successful, it means the software on the main partition is intact. The Boot flash success flag is then written, and the process ends to continue with other operations.

[0093] If the primary partition integrity check fails, it means that the primary partition software is corrupted, and a boot recovery operation needs to be performed.

[0094] The boot recovery operation first performs an integrity check on the software in the backup partition. This integrity check will definitely succeed because the software on the main partition has been corrupted, and the software currently being executed is definitely the software in the backup partition. If it can be executed normally, it means that the software in the backup partition is intact. After the integrity check is successful, the software in the backup partition is restored to the main partition, and the Boot flash success flag is written. Then the process ends and other operations continue.

[0095] This application achieves support for flashing and upgrading the Boot itself by backing up the data completely to backup area B before upgrading the main partition A, and by successfully restoring the data from backup area B in case of upgrade failure. This dual backup method, which includes both pre-upgrade and upgrade failure backups, also eliminates the possibility of bricking the device due to flashing failure. It solves the problem of high upgrade risk or even bricking due to upgrade failure in the Boot Loader upgrade process in the prior art.

[0096] The scope of protection of the controller firmware dual backup self-upgrade method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, deleting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0097] This application also provides a controller firmware dual backup self-upgrade system, which can implement the controller firmware dual backup self-upgrade method described in this application. However, the implementation device of the controller firmware dual backup self-upgrade method described in this application includes, but is not limited to, the structure of the controller firmware dual backup self-upgrade system listed in this embodiment. All structural modifications and substitutions of the prior art made based on the principles of this application are included within the protection scope of this application.

[0098] like Figure 8 As shown, this embodiment provides a controller firmware dual-backup self-upgrade system. The controller firmware includes an address loading partition, a main partition, and a backup partition. The system 800 includes: an acquisition module 801, a confirmation module 802, a backup module 803, a verification module 804, an upgrade module 805, a writing module 806, and a restart module 807.

[0099] Module 801 is configured to retrieve upgrade instructions.

[0100] The confirmation module 802 is configured to respond to the upgrade instruction and confirm that the upgrade instruction is a bootloader upgrade instruction.

[0101] Backup module 803 is configured to back up the current firmware data in the main partition to the backup area.

[0102] The verification module 804 is configured to perform integrity verification based on the backup data in the backup area.

[0103] Upgrade module 805 is configured to erase the main partition and write new firmware data into it if the integrity verification is successful.

[0104] The writing module 806 is configured to write upgrade completion status flag information into the main partition and obtain the upgraded controller firmware.

[0105] The restart module 807 is configured to control the upgraded controller firmware to load the starting address from the address loading partition for restarting; the address loading partition includes the starting address information of the main partition and the backup partition.

[0106] It should be noted that the functions or operations of the acquisition module 801, confirmation module 802, backup module 803, verification module 804, upgrade module 805, writing module 806 and restart module 807 described in this embodiment correspond one-to-one with the steps in the controller firmware dual backup self-upgrade method described above, so they will not be repeated here.

[0107] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units 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 of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0108] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0109] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 implementation should not be considered beyond the scope of this application.

[0110] like Figure 9 As shown, this embodiment provides an electronic device, which includes:

[0111] At least one processor 901; and

[0112] A memory 902 communicatively connected to the at least one processor 901, the memory including an address loading partition, a primary partition, and a backup partition;

[0113] The memory 902 stores computer program instructions that can be executed by the at least one processor, which enable the at least one processor to execute the controller firmware dual backup self-upgrade method as described above.

[0114] This application also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer 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., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0115] This application embodiment may also provide a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application embodiment are generated. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0116] When the computer program product is executed by a computer, the computer performs the method described in the foregoing method embodiments. The computer program product can be a software installation package; when the foregoing method is required, the computer program product can be downloaded and executed on the computer.

[0117] In summary, the controller firmware dual backup self-upgrade method, system, electronic device, and medium described in this application have the following beneficial effects:

[0118] This application provides a controller firmware dual-backup self-upgrade method. The controller firmware includes an address loading partition, a main partition, and a backup partition. The method involves: acquiring an upgrade command; confirming the upgrade command as a bootloader upgrade command; backing up the current firmware data in the main partition to the backup partition; performing an integrity check on the backup data in the backup partition; if the integrity check is successful, erasing the main partition and writing new firmware data therein; writing an upgrade completion status flag to the main partition to obtain the upgraded controller firmware; and controlling the upgraded controller firmware to load the starting address from the address loading partition for reboot. The address loading partition includes the starting address information of the main partition and the backup partition. This application, by completely backing up data to backup partition B before upgrading the main partition A, supports the flashing and upgrading of the Bootloader itself. Furthermore, in the event of an upgrade failure, data can be successfully restored from backup partition B, eliminating the possibility of bricking the device due to flashing failure. This solves the problem of high upgrade risk and even bricking due to upgrade failure in the BootLoader upgrade process in the prior art.

[0119] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0120] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A controller firmware dual-backup self-upgrade method, characterized in that, The controller firmware includes an address loading partition, a primary partition, and a backup partition, comprising: Obtain upgrade instructions; In response to the upgrade command, confirm that the upgrade command is a bootloader upgrade command; Back up the current firmware data in the main partition to the backup area; Integrity verification is performed based on the backup data in the backup area; If the integrity verification is successful, the main partition will be erased and new firmware data will be written into it; Write the upgrade completion status flag information into the main partition and obtain the upgraded controller firmware; The upgraded controller firmware is controlled to load the starting address from the address loading partition and reboot; the address loading partition includes the starting address information of the main partition and the backup partition.

2. The controller firmware dual backup self-upgrade method according to claim 1, characterized in that, Controlling the upgraded controller firmware to load the starting address from the address loading partition and reboot includes: During the power-on initialization phase of the upgraded controller firmware, the status flag information is detected. If the status flag information is not detected, then the integrity of the current boot program in the main partition is checked; If the integrity verification is successful, an upgrade completion status flag is written to the main partition; If the integrity check fails, the backup data in the backup area will be restored to the main partition. After successful restoration, an upgrade completion status flag will be written to the main partition. If the status flag information is detected, the upgraded controller firmware is controlled to load the starting address from the address loading partition and restart.

3. The controller firmware dual backup self-upgrade method according to claim 2, characterized in that, Restoring backup data from the backup area to the primary partition includes: Perform integrity verification on the backup data in the backup area; If the integrity verification is successful, the backup data in the backup area will be restored to the primary partition.

4. The controller firmware dual backup self-upgrade method according to claim 2, characterized in that, Performing an integrity check on the current bootloader in the primary partition includes: The corresponding hash value is calculated and obtained based on the current firmware data in the main partition; Obtain the checksum value at the end of the current firmware data in the main partition; the checksum value is the hash value calculated before the current firmware data is written to the main partition. Integrity verification is performed based on the hash value and the check value; If the hash value matches the check value, the integrity check is successful. If the hash value does not match the check value, the integrity check will fail.

5. The controller firmware dual backup self-upgrade method according to claim 1 or 3, characterized in that, Integrity verification based on backup data in the backup area includes: The corresponding hash value is calculated and obtained based on the backup data in the backup area; Obtain the checksum value at the end of the backup data in the backup area; the checksum value is the hash value calculated before backing up the current firmware data in the main partition. Integrity verification is performed based on the hash value and the check value; If the hash value matches the check value, the integrity check is successful. If the hash value does not match the check value, the integrity check will fail.

6. The controller firmware dual backup self-upgrade method according to claim 1, characterized in that, Backing up the current firmware data in the main partition to the backup area includes: Clear the status flag information in the primary partition before performing the backup; Back up the current firmware data in the main partition to the backup area.

7. The controller firmware dual backup self-upgrade method according to claim 1 or 2, characterized in that, The integrity verification is a hash operation verification.

8. A controller firmware dual-backup self-upgrade system, characterized in that, The controller firmware includes an address loading partition, a primary partition, and a backup partition, comprising: The acquisition module is configured to acquire upgrade instructions; The confirmation module is configured to, in response to the upgrade instruction, confirm that the upgrade instruction is a bootloader upgrade instruction; The backup module is configured to back up the current firmware data in the main partition to the backup area; The verification module is configured to perform integrity verification based on the backup data in the backup area. The upgrade module is configured to erase the main partition and write new firmware data into it if the integrity check is successful. The writing module is configured to write upgrade completion status flag information into the main partition and obtain the upgraded controller firmware. The restart module is configured to control the upgraded controller firmware to load the starting address from the address loading partition for restarting; the address loading partition includes the starting address information of the main partition and the backup partition.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor, the memory including an address loading partition, a primary partition, and a backup partition; The memory stores computer program instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the controller firmware dual backup self-upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the controller firmware dual backup self-upgrade method as described in any one of claims 1 to 7.

Images