Firmware Loading Method, Device, Electronic Device, and Storage Medium

Abstract

The present application discloses a firmware loading method, apparatus, electronic device, and storage medium, relating to the technical field of firmware, including: during the firmware loading process, a verification operation can be performed on the firmware volume that makes up the firmware to obtain a verification result. In the case where the verification result is a verification failure, recovery information in the main storage area can be obtained, and subsequent firmware loading operations can be performed based on the recovery information in the main storage area. During this process, there is no need for an additional component to monitor the firmware loading process. Instead, a verification operation is performed before loading, and subsequent firmware loading operations are executed based on the verification result. In this way, hardware resources can be saved.

Description

Technical Field

[0001] This application relates to the technical field of firmware, and in particular to a firmware loading method, apparatus, electronic device, and storage medium. Background Art

[0002] In a computer device, firmware can be stored in a storage component. The firmware can be used to initialize hardware components, provide an interface between the operating system and the hardware components, etc. However, in the case of damage to the storage component, power failure during the firmware upgrade process, etc., the firmware will be damaged, resulting in the firmware being unable to be loaded and used normally.

[0003] Generally, to avoid the above problems, a backup storage component can be set in the computer device to backup the firmware, and a monitor can be set to monitor the firmware loading process. When the monitor detects an abnormality in the firmware loading process, it switches to the backup storage component and reloads the backup firmware. However, it occupies more hardware resources. Summary of the Invention

[0004] This application provides a firmware loading method, apparatus, electronic device, storage medium, and program product to address the problem of relatively high hardware resource consumption during the firmware loading process.

[0005] This application provides a firmware loading method, which includes:

[0006] When it is determined that the trigger timing of the firmware loading operation corresponding to the target firmware volume is reached, based on the pre-acquired location information of the target firmware volume, read the target firmware volume from the main storage area of the target storage component, where the target firmware volume is any one of the multiple firmware volumes that make up the firmware;

[0007] After performing a verification operation on the target firmware volume, obtain the verification result corresponding to the target firmware volume;

[0008] When it is determined that the verification result corresponding to the target firmware volume is a verification failure, obtain the recovery information of the main storage area;

[0009] According to the recovery information of the main storage area, perform the firmware loading operation corresponding to the recovery information.

[0010] This application also provides a firmware loading apparatus, which includes:

[0011] A reading module, configured to, when it is determined that the trigger timing of the firmware loading operation corresponding to the target firmware volume is reached, based on the pre-acquired location information of the target firmware volume, read the target firmware volume from the main storage area of the target storage component, where the target firmware volume is any one of the multiple firmware volumes that make up the firmware;

[0012] A verification module, configured to perform a verification operation on a target firmware volume and obtain a verification result corresponding to the target firmware volume;

[0013] An acquisition module, configured to obtain recovery information of a main storage area when it is determined that the verification result corresponding to the target firmware volume is a verification failure;

[0014] A loading module, configured to perform a firmware loading operation corresponding to the recovery information according to the recovery information of the main storage area.

[0015] This application also provides an electronic device, including: a memory, configured to store a computer program; a processor, configured to implement the steps of any of the above firmware loading methods when executing the computer program.

[0016] This application also provides a computer-readable storage medium, in which a computer program is stored, and the computer program implements the steps of any of the above firmware loading methods when executed by a processor.

[0017] This application also provides a computer program product, including a computer program, and the computer program implements the steps of any of the above firmware loading methods when executed by a processor.

[0018] Through this application, during the firmware loading process, a verification operation can be performed on the firmware volumes that make up the firmware to obtain a verification result. In the case where the verification result is a verification failure, the recovery information of the main storage area can be obtained, and based on the recovery information of the main storage area, subsequent firmware loading operations can be performed. During this process, there is no need for additional components to monitor the firmware loading process. Instead, a verification operation is performed before loading, and subsequent firmware loading operations are performed based on the verification result. In this way, hardware resources can be saved. In addition, since the recovery information of the main storage area can indicate the reason for the failure of the main memory firmware verification, therefore, performing the corresponding firmware loading operation according to the recovery information of the main storage area can solve the problem of verification failure, so as to complete the firmware loading operation. Description of the Drawings

[0019] To more clearly illustrate the embodiments of this application, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0020] Figure 1 It is a schematic diagram of the architecture of a firmware loading system provided by an embodiment of this application;

[0021] Figure 2 It is a schematic flowchart of a firmware loading method provided by an embodiment of this application;

[0022] Figure 3 A partition diagram of a target storage component provided by an embodiment of the present application;

[0023] Figure 4 A partition diagram of a main storage area and a standby storage area provided by an embodiment of the present application;

[0024] Figure 5 A structural diagram of a firmware loading device provided by an embodiment of the present application;

[0025] Figure 6 A structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0026] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

[0027] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0028] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific implementation manners.

[0029] The firmware loading method provided by the present application can be implemented by a firmware loading system, such as Figure 1As shown, the firmware loading system may include a Central Processing Unit (CPU), a Baseboard Management Controller (BMC), a Complex Programmable Logic Device (CPLD), memory, a Platform Controller Hub (PCH), flash memory, a Peripheral Component Interconnect Express (PCIe) device, etc. Among them, the memory may be a Dual Inline Memory Module (DIMM). The flash memory may be the flash memory that stores the Basic Input / Output System (BIOS) firmware.

[0030] The central processor is electrically connected to the memory through the I2C or I3C bus, electrically connected to the PCIe device and the baseboard management controller respectively through the PCIe bus, and electrically connected to the platform controller hub through the Direct Media Interface (DMI). The baseboard management controller is electrically connected to the platform controller hub through the Low Pin Count (LPC) interface, and electrically connected to the complex programmable logic controller device through the I2C bus or I3C. The platform controller hub is electrically connected to the complex programmable logic controller device through the I2C or I3C bus, and electrically connected to the flash memory through the Serial Peripheral Interface (SPI).

[0031] Each of the above components may be a component included in a computer device, for example, a server, a computer, etc.

[0032] After the central processor is powered on and starts running, it can directly access the firmware stored in the flash memory, or indirectly access the firmware stored in the flash memory through the platform controller hub. In this way, the central processor can load the firmware stored in the flash memory for subsequent data processing. For example, in Figure 1 , the central processor first communicates with the platform controller hub through the direct media interface, and then the platform controller hub communicates with the flash memory through the serial peripheral interface.

[0033] The firmware stored in the flash memory may be abnormal due to various reasons. For example, it may include the following situations:

[0034] First, some memory particles in the flash memory are physically damaged, resulting in the inability to access the data in this area.

[0035] Second, during the in-band upgrade of the firmware by the operating system (OS), power failure or restart and downtime occur, resulting in the interruption of the upgrade and partial erasure of the firmware.

[0036] Third, on certain types of servers, when an error is detected during the operation of the operating system, this error is recorded in the flash memory. If an abnormal power failure occurs during the process of recording the error, it will cause the firmware to be abnormal. For example, the BIOS based on the Unified Extensible Firmware Interface (UEFI) usually provides an interface for flash memory access for the operating system to use. It can be the Windows Hardware Error Architecture Error Record Serialization Table (WHEA ERST) table function. WHEA ERST can be a firmware volume in the flash memory, specifically used to record errors. Under this function, when a Reliability Availability and Serviceability (RAS) error is detected during the operation of the operating system, this error is recorded in the WHEA ERST table. During the process of recording the error, it is generally to erase first and then write. After an abnormal power failure occurs during this process, this section of the firmware will be abnormal.

[0037] Fourth, when the out-of-band upgrade of the firmware is interrupted due to power failure or restart by the baseboard management controller, the firmware becomes incomplete.

[0038] Therefore, to solve the above problems, a computer device generally sets up a monitor to monitor the firmware loading process. When it is detected that the firmware loading process is abnormal, it switches to the backup flash memory and loads the backup firmware stored in the backup flash memory after restarting the firmware loading process. However, a monitor and a backup flash memory need to be set up in the computer device, which requires a large amount of hardware resources and high costs.

[0039] Embodiments of the present application provide a firmware loading method, which can be executed by the above computer device, such as Figure 2 shown, the specific processing steps of the firmware loading method may include:

[0040] Step S201, when it is determined that the trigger timing of the firmware loading operation corresponding to the target firmware volume is reached, based on the pre-acquired position information of the target firmware volume, read the target firmware volume from the main storage area of the target storage component.

[0041] Among them, the target firmware volume can be any one of the multiple firmware volumes (Firm Volume, FV) that make up the firmware. The target storage component can be Figure 1 the flash memory in. The location information can include the start address information and length of the firmware volume in the flash memory.

[0042] Such as Figure 3 shown, the target storage component can be divided into multiple partitions such as a Boot Loader Block partition, a Run Block partition, and a Backup Block partition. Among them, the Boot Loader Block partition can be used to store the boot loader and the recovery information of the Run Block partition. The firmware stored in the Backup Block partition and the Run Block partition can be the same or different, that is, when the firmware versions are the same and no abnormalities occur, the firmware stored in the two partitions is the same. When the firmware versions are different, or when the firmware in any one of the partitions is abnormal, the firmware stored in the two partitions is different. The firmware can be the firmware burned at the factory or the firmware updated subsequently through out-of-band or in-band methods.

[0043] Such as Figure 4 shown, the Run Block partition and the Backup Block partition can both be divided into a Central Processing Unit partition, a Code partition, and a Data partition according to the type of firmware volume. Among them, the Central Processing Unit partition can store the firmware volume of the central processing unit (CPU FV), the Code partition can store at least one code firmware volume (Code FV), and the Data partition can store at least one data firmware volume (Data FV). All the firmware volumes stored in the Code partition and the Data partition can form the complete firmware file of the BIOS. The firmware volume of the central processing unit can include the firmware and check information of the central processing unit. For example, the firmware of the central processing unit can be the Management Engine (ME) firmware, the Platform Initialization (PI) firmware, etc. The Code firmware volume and the Data firmware volume can both include a Header, body information, check information, etc. The Header is used to indicate the data structure of the body information. The body information of the Code firmware volume includes the execution code, and the body information of the Data firmware volume includes the data required for the execution code. The above various check information can all be Cyclic Redundancy Check (CRC) information.

[0044] The code firmware volume can be a firmware volume generated based on the UEFI specification. For example, it can be different types of code firmware volumes such as a BootBlock firmware volume, a Main firmware volume, an Authenticated Code Module (ACM) firmware volume, a Microcode firmware volume, a Bin firmware volume, etc. Among them, the BootBlock firmware volume can generally be represented as FV_BB, including the firmware volume in the Security (Sec) phase and the Pre-EFI Initialization phase, and can also be the Main firmware volume. The Main firmware volume can generally be represented as FV_Main, including the firmware volume in the Driver Execution Environment (DXE) phase and the Boot Device Selection (BDS) phase. The Authenticated Code Module firmware volume can generally be represented as FV_ACM. The Microcode firmware volume can generally be represented as FV_MICROCODE. The Bin firmware volume can generally be represented as FV_Bin.

[0045] The data firmware volume can also be a firmware volume generated based on the UEFI specification. For example, firmware volumes with file types such as "Raw" and "File" like the Non-Volatile Random Access Memory (NVRAM) firmware volume, the WHEA firmware volume, the Vital Product Data (VPD) firmware volume, the Firmware Support Package for Silicon (FSPS) firmware volume, etc. Among them, the WHEA firmware volume can generally be represented as FV_WHEA, the Vital Product Data firmware volume can generally be represented as FV_VPD, and the Firmware Support Package for Silicon firmware volume can generally be represented as FV_Fsps.

[0046] In the above partition mode, the main storage area can be the above-mentioned firmware operation data block partition.

[0047] The triggering times of the firmware loading operations corresponding to different types of firmware volumes are different, and specifically can include the following multiple situations:

[0048] First, when the target firmware volume is the firmware volume of the central processing unit, the completion moment of the operation of reading the boot loader is used as the triggering time.

[0049] Second, when the target firmware volume is a code firmware volume, when the verification result corresponding to the second firmware volume is obtained and it is determined that the verification result corresponding to the second firmware volume is successful, the moment when it is determined that the verification result corresponding to the second firmware volume is successful is used as the trigger timing, where the second firmware volume is the previous firmware volume with a loading order before the target firmware volume. When the target firmware volume is the code firmware volume with the first loading order among at least one firmware volume, the second firmware volume is the firmware volume of the central processing unit, or when the target firmware volume is the code firmware volume with a loading order other than the first among at least one firmware volume, the second firmware volume is a code firmware volume.

[0050] Third, when the target firmware volume is the above-mentioned data firmware volume, the moment of obtaining the data firmware volume corresponding to the first firmware volume during the running of the first firmware volume can be used as the trigger timing. Among them, the first firmware volume is the code firmware volume corresponding to the target firmware volume among multiple firmware volumes.

[0051] In this way, by setting the trigger timing for different types of firmware volumes, it can be ensured that the firmware can complete the loading process in the correct order, improving the probability of successful loading.

[0052] Specifically, after the central processing unit in the computer device is powered on, it can jump to the bootloader data block partition according to the pre-configured address information to read the bootloader and run the bootloader, so that the central processing unit can use the verification rules included in the bootloader to perform verification operations on the read firmware volume. And it can also read the location information of each firmware volume from the bootloader data block partition.

[0053] After the central processing unit finishes reading the bootloader, it can extract the location information of the firmware volume of the central processing unit from the bootloader, or determine the location information of the firmware volume of the central processing unit from the location information of the firmware volumes pre-read from the bootloader data block partition. Furthermore, according to the location information of the firmware volume of the central processing unit, it can read the firmware volume of the central processing unit from the target storage component and perform subsequent verification operations on the firmware volume of the central processing unit.

[0054] When the verification result of the firmware volume of the central processing unit is successful, it can extract the location information of the code firmware volume with the first loading order from the bootloader, or determine the location information of the code firmware volume with the first loading order from the location information of the firmware volumes pre-read from the bootloader data block partition. Furthermore, according to the location information of the code firmware volume with the first loading order, it can determine the code firmware volume with the first loading order from the location information of the firmware volumes pre-read from the target storage component and perform subsequent verification operations on the code firmware volume with the first loading order.

[0055] When the verification result of the code firmware volume with the first loading order is successful, the central processing unit can load the code firmware volume and run the execution code included in the main information of the code firmware volume. During the process of running the code, when it is necessary to obtain the data firmware volume corresponding to the code firmware volume, the location information of the data firmware volume can be extracted from the boot loader, or the location information of the data firmware volume can be determined from the location information of the firmware volume read from the boot loading data block partition. Furthermore, according to the location information of the data firmware volume, the data firmware volume can be read from the target storage component, and a verification operation can be performed on the data firmware volume.

[0056] After running the code firmware volume with the first loading order, regardless of whether a data firmware volume is required during subsequent running or whether the required data firmware volume passes verification, the location information of the code firmware volume with the second loading order can be extracted from the boot loader first, or the location information of the code firmware volume with the second loading order can be determined from the location information of the firmware volume pre-read from the boot loading data block partition. Furthermore, according to the location information of the code firmware volume with the second loading order, the code firmware volume with the second loading order can be read from the target storage component, and a verification operation can be performed on the code firmware volume with the second loading order. And so on, until all code firmware volume loading operations are completed.

[0057] Step S202, after performing a verification operation on the target firmware volume, obtain the verification result corresponding to the target firmware volume.

[0058] Specifically, since the structures of different types of firmware volumes are different, different verification operations need to be performed on different types of firmware volumes, which can include the following two cases.

[0059] Case 1, when the target firmware volume is a data firmware volume or a code firmware volume, the verification operation can include the following specific steps:

[0060] Step 1, according to the preset header information format and the header information included in the target firmware volume, determine the sub-verification result corresponding to the header information.

[0061] Step 2, when it is determined that the sub-verification result corresponding to the header information indicates verification failure, determine the verification failure as the verification result corresponding to the target firmware volume.

[0062] Step 3, when it is determined that the sub-verification result corresponding to the header information indicates verification success, determine whether the verification information included in the target firmware volume is damaged.

[0063] Step 4, when it is determined that the verification information included in the target firmware volume is damaged, determine the verification failure as the verification result corresponding to the target firmware volume.

[0064] Step Five: When it is determined that the verification information included in the target firmware volume is not damaged, use the verification information included in the target firmware volume to verify the main body information, and obtain a sub-verification result corresponding to the main body information.

[0065] Step Six: Determine the sub-verification result corresponding to the main body information as the verification result corresponding to the target firmware volume.

[0066] Specifically, the central processing unit can compare the preset header information format with the header information included in the target firmware volume to determine whether some fields are missing from the header information included in the target firmware volume. If so, determine the verification failure as the sub-verification result corresponding to the header information, and also determine the verification failure as the verification result corresponding to the target firmware volume. If not, determine the verification success as the sub-verification result corresponding to the header information, and perform the next verification operation, that is, determine whether the verification information included in the target firmware volume is damaged. When it is determined that the verification information included in the target firmware volume is damaged, the verification failure can be determined as the sub-verification result corresponding to the verification information, and also the verification failure can be determined as the verification result corresponding to the target firmware volume. Or, when it is determined that the verification information included in the target firmware volume is not damaged, the verification success can be determined as the sub-verification result corresponding to the verification information, and perform the next verification operation, that is, use the verification information included in the target firmware volume to verify the main body information, obtain a sub-verification result corresponding to the main body information, and determine the sub-verification result corresponding to the main body information as the verification result corresponding to the target firmware volume. For example, when the verification information is CRC verification information, through the CRC verification method, use the verification information included in the target firmware volume to perform CRC verification on the main body information to determine whether the main body information is damaged.

[0067] Case Two: When the target firmware volume is the firmware volume of the central processing unit, the central processing unit can use the verification information included in the firmware volume of the central processing unit to verify the firmware of the central processing unit, and obtain a verification result corresponding to the target firmware volume. For example, when the verification information is CRC verification information, through the CRC verification method, use the verification information included in the firmware volume of the central processing unit to perform CRC verification on the firmware of the central processing unit to determine whether the main body information is damaged.

[0068] Step S203: When it is determined that the verification result corresponding to the target firmware volume is a verification failure, obtain the recovery information in the main storage area.

[0069] Among them, the recovery information may include the number of recovery times. [[ID=!7]]

[0070] Specifically, when the central processing unit determines that the verification result of the target firmware volume is a verification failure, it can read the recovery information of the main storage area corresponding to the type of the target firmware volume from the boot load data block partition. For example, when the target firmware volume is a code firmware volume or the firmware volume of the central processing unit, the total number of recoveries of these two types of firmware volumes can be obtained. Or, when the target firmware volume is a data firmware volume, the cumulative value of the recovery times of the target firmware volume can be obtained. Or, the total number of recoveries of all firmware volumes of all types can be obtained.

[0071] In some alternative ways, when it is determined that the verification result corresponding to the target firmware volume is a verification success, the target firmware volume can be loaded. When the target firmware volume is the firmware volume of the central processing unit, the loading of the code firmware volume can be started. Or, when the target firmware volume is a code firmware volume, the code firmware volume can be run. When the corresponding data firmware volume is needed during the running of the code firmware volume, the loading operation of this data firmware volume can be performed. For a detailed description, refer to step S201 and will not be elaborated here.

[0072] In some alternative embodiments, when it is determined that the verification result corresponding to the target firmware volume is a verification failure, the firmware version of the main storage area and the firmware version of the backup storage area are obtained. When it is determined that the firmware version of the main storage area and the firmware version of the backup storage area are the same, directly switch to the backup storage area. According to the main location information of the target firmware volume, obtain the backup location information corresponding to the target firmware volume, and use the backup location information as the starting load location information to continue the subsequent loading process. Or, when it is determined that the firmware version of the backup storage area is different from the firmware version of the main storage area, the recovery information of the main storage area can be obtained according to the original process, and the subsequent firmware loading operation can be performed.

[0073] Specifically, when the central processing unit determines that the verification result corresponding to the target firmware volume is a verification failure, it can first obtain the firmware version of the main storage area and the firmware version of the backup storage area respectively. If the two firmware versions are the same, it can directly switch from the main storage area to the backup storage area, and according to the main location information of the target firmware volume, obtain the backup location information corresponding to the main location information of the target firmware volume, read the backup firmware volume corresponding to the target firmware volume from the storage location corresponding to the backup location information, and perform a verification operation to obtain the verification result corresponding to the backup firmware volume. When the verification result is a verification success, the target firmware volume can be loaded. When the target firmware volume is not the last code firmware volume in the loading order, the next firmware volume after the backup firmware volume can be read from the backup storage area, and so on until the loading of all code firmware volumes is completed. Or, when it is determined that the firmware version of the backup storage area is different from the firmware version of the main storage area, then obtain the recovery information of the main storage area and perform the subsequent firmware loading operation.

[0074] When the firmware versions of the primary storage area and the secondary storage area are inconsistent, it indicates that there are some differences between the data stored in the primary storage area and the data stored in the secondary storage area. After switching to the secondary storage area, it is necessary to restart the backup process of all firmware volumes. However, if the firmware versions of the primary storage area and the secondary storage area are the same, it means that the data stored in the primary storage area and the data stored in the secondary storage area are consistent under normal circumstances. In the case where a certain firmware volume verification fails, the firmware loading operation of the subsequent firmware volumes can be continued instead of restarting the firmware volume loading operation, which can improve the firmware loading efficiency.

[0075] Step S204: According to the recovery information of the primary storage area, perform a firmware loading operation corresponding to the recovery information.

[0076] Specifically, since the recovery information can indicate the abnormal type of the firmware, after the central processing unit obtains the recovery information of the primary storage area, it can perform a corresponding firmware loading operation based on the recovery information. Among them, the abnormal type can be physical damage to the storage area or damage caused by an abnormal event. For example, the abnormal event can be a power failure event during the upgrade process or the process of modifying the data firmware volume. Correspondingly, step S204 can include the following two situations:

[0077] Situation 1: When it is determined that the number of recoveries is less than the preset number of recoveries, at least one firmware volume in the primary storage area is erased, and at least one firmware volume in the secondary storage area of the target storage component is restored to the primary storage area. Based on the recovered firmware volume read from the primary storage area, perform a firmware loading operation.

[0078] Among them, the recovered firmware volume includes the target firmware volume. The secondary storage area can be the above-mentioned firmware backup data block partition. The preset number of recoveries can be the preset number of recoveries corresponding to the type of the target file volume. The preset number of recoveries of the firmware volume of the central processing unit or the code firmware volume can be less than the preset number of recoveries of the data firmware volume. For example, when the target file volume is the firmware volume of the central processing unit or the code firmware volume, the preset number of recoveries can be 3, or when the target file volume is the data firmware volume, the preset number of recoveries can be 10. Since the data firmware volume will be modified and erased during the firmware operation, the probability of the data firmware volume encountering an abnormal event is higher. A larger preset number of recoveries needs to be set for it to accurately judge the abnormal type of the firmware, so as to perform a correct firmware loading operation and avoid the problem of wasted storage space caused by misjudgment.

[0079] Specifically, when it is determined that the number of recoveries is less than the preset number of recoveries, it indicates that the abnormal type of the firmware can be damage caused by an abnormal event. Therefore, the backup firmware volume can be read from the secondary storage area and restored to the primary storage area. Generally, the central processing unit can perform the above-mentioned erasing and restoring operations in the following two ways:

[0080] In Method 1, all the firmware volumes stored in the main storage area are erased, and all the firmware volumes stored in the backup storage area are restored to the main storage area.

[0081] Through Method 1, during the firmware loading process, the central processing unit (CPU) does not need to perform complicated analysis operations. It can directly erase all the firmware volumes stored in the main storage area and restore all the firmware volumes stored in the backup storage area to the main storage area. In this way, the error probability is relatively small and the operation is simple.

[0082] After the restoration operation is completed, the CPU can restart the loading process of each firmware volume, start loading the firmware volume again according to the above steps, and update the corresponding number of restoration times.

[0083] In Method 2, according to the main position information of the target firmware volume in the main storage area, the corresponding backup position information of the target firmware volume is obtained. The target firmware volume stored in the main storage area is erased. Based on the backup position information, the backup firmware volume corresponding to the target firmware volume is read from the backup storage area. Based on the main position information, the backup firmware volume is restored to the main storage area.

[0084] Through Method 2, the CPU can determine the target backup position information corresponding to the main position information of the target firmware volume in the mapping relationship table in the boot loader, and determine the target backup position information as the backup position information of the target firmware volume. Furthermore, the CPU erases the data stored in the storage position corresponding to the main position information of the target firmware volume in the target storage component, that is, erases the target firmware volume. And, based on the backup position information, the backup firmware volume is read from the storage position corresponding to the target backup position information in the target storage component and restored to the storage position corresponding to the main position information of the target firmware volume in the target storage component. In this way, by performing targeted erase and restore operations, the amount of data transmitted is relatively small, and the restoration efficiency can be improved.

[0085] After the restoration operation is completed, the CPU can re-perform the firmware loading operation on the target firmware volume and update the corresponding number of restoration times.

[0086] In some optional implementation manners, when the CPU determines that the number of restoration times is less than the preset number of restoration times, it can also select different methods to perform the firmware restoration operation according to the type of the target firmware volume. Specifically, when the target firmware volume is the firmware volume or code firmware volume of the CPU, Method 1 can be used to perform the firmware restoration operation and the firmware loading operation. When the target firmware volume is a data firmware volume, Method 2 can be used to perform the firmware restoration operation and the firmware loading operation.

[0087] Since the firmware volume and the code firmware volume of the central processing unit cannot be modified during the operation of the firmware, the firmware cannot run when the code firmware volume is damaged or modified. The data firmware volume can be read, erased, and written during operation. That is to say, the security requirements for the code firmware volume and the firmware volume of the central processing unit are higher. For such firmware volumes, to avoid problems introduced by complex processes during subsequent recovery, a simple operation method 1 can be used for firmware recovery operations. For firmware volumes with low security requirements such as the data firmware volume, the firmware recovery operation can be specifically performed only on the firmware volume with verification failure to improve the firmware loading efficiency.

[0088] In Case 2, when it is determined that the recovery count is equal to the preset recovery count, all the firmware in the main storage area is erased, and the main storage area is switched to the backup storage area. After restarting the firmware loading process, the firmware loading operation is performed based on the firmware volume read from the backup storage area.

[0089] Specifically, when it is determined that the recovery count is equal to the preset recovery count, it indicates that the abnormal type of the firmware is physical damage to the storage area and cannot be normally recovered. For this situation, all the firmware in the main storage area can be erased, and the main storage area is switched to the backup storage area. After restarting the firmware loading process, the firmware loading operation for each firmware volume is restarted.

[0090] In the firmware loading method according to the embodiments of the present application, during the firmware loading process, verification operations can be performed on the firmware volumes that make up the firmware to obtain verification results. In the case where the verification result is verification failure, the recovery information of the main storage area can be obtained, and subsequent firmware loading operations are performed based on the recovery information of the main storage area. During this process, there is no need for additional components to monitor the firmware loading process. Instead, verification operations are performed before loading, and subsequent firmware loading operations are performed based on the verification results. In this way, hardware resources can be saved. In addition, since the recovery information of the main storage area can indicate the reason for the failure of the main memory firmware verification, therefore, performing corresponding firmware loading operations according to the recovery information of the main storage area can solve the problem of verification failure to complete the firmware loading operation.

[0091] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0092] The embodiments of the present application also provide a firmware loading device, as Figure 5 shown, including:

[0093] A reading module 510, configured to, when determining that a trigger time for a firmware loading operation corresponding to a target firmware volume is reached, read the target firmware volume from a main storage area of a target storage component based on pre-acquired location information of the target firmware volume, where the target firmware volume is any one of multiple firmware volumes constituting the firmware;

[0094] A verification module 520, configured to, after performing a verification operation on the target firmware volume, obtain a verification result corresponding to the target firmware volume;

[0095] An obtaining module 530, configured to, when determining that the verification result corresponding to the target firmware volume indicates verification failure, obtain recovery information of the main storage area;

[0096] A loading module 540, configured to perform a firmware loading operation corresponding to the recovery information according to the recovery information of the main storage area.

[0097] In some optional implementation manners, when the target firmware volume is a data firmware volume, the trigger time for the firmware loading operation corresponding to the target firmware volume includes:

[0098] During the process of running a first firmware volume, taking the moment of obtaining the data firmware volume corresponding to the first firmware volume as the trigger time, where the first firmware volume is a code firmware volume corresponding to the target firmware volume among the multiple firmware volumes.

[0099] In some optional implementation manners, when the target firmware volume is a code firmware volume, the trigger time for the firmware loading operation corresponding to the target firmware volume includes:

[0100] When obtaining the verification result corresponding to a second firmware volume and determining that the verification result corresponding to the second firmware volume indicates verification success, taking the moment of determining that the verification result corresponding to the second firmware volume indicates verification success as the trigger time, where the second firmware volume is the previous firmware volume in the loading order before the target firmware volume.

[0101] In some optional implementation manners, the target firmware volume includes header information;

[0102] The verification module 520 is specifically configured to:

[0103] Determine a sub-verification result corresponding to the header information according to a preset header information format and the header information included in the target firmware volume;

[0104] When determining that the sub-verification result corresponding to the header information is used to indicate verification failure, determine verification failure as the verification result corresponding to the target firmware volume.

[0105] In some optional implementation manners, the target firmware volume further includes verification information; the verification module 520 is specifically configured to:

[0106] When it is determined that the sub - verification result corresponding to the header information is used to indicate successful verification, determine whether the verification information included in the target firmware volume is damaged;

[0107] When it is determined that the verification information included in the target firmware volume is damaged, determine the verification failure as the verification result corresponding to the target firmware volume.

[0108] In some alternative embodiments, the target firmware volume further includes body information; the verification module 520 is specifically configured to:

[0109] When it is determined that the verification information included in the target firmware volume is not damaged, use the verification information included in the target firmware volume to verify the body information, and obtain a sub - verification result corresponding to the body information;

[0110] Determine the sub - verification result corresponding to the body information as the verification result corresponding to the target firmware volume.

[0111] In some alternative embodiments, when the target firmware volume is the firmware volume of the central processing unit, the triggering timing of the firmware loading operation corresponding to the target firmware volume includes:

[0112] Take the completion moment of the operation of reading the bootloader as the triggering timing.

[0113] In some alternative embodiments, the firmware volume of the central processing unit includes the firmware of the central processing unit and verification information;

[0114] The verification module 520 is specifically configured to:

[0115] Use the verification information included in the firmware volume of the central processing unit to verify the firmware of the central processing unit, and obtain the verification result corresponding to the target firmware volume.

[0116] In some alternative embodiments, the recovery information includes the number of recoveries;

[0117] The loading module 540 is specifically configured to:

[0118] When it is determined that the number of recoveries is less than the preset number of recoveries, erase at least one firmware volume in the main storage area, and restore at least one firmware volume in the backup storage area of the target storage component to the main storage area, wherein the restored firmware volume includes the target firmware volume;

[0119] Based on the restored firmware volume read from the main storage area, perform the firmware loading operation.

[0120] In some alternative embodiments, the loading module 540 is specifically configured to:

[0121] Erase all the firmware volumes stored in the main storage area, and restore all the firmware volumes stored in the backup storage area to the main storage area.

[0122] In some alternative embodiments, the loading module 540 is specifically configured to:

[0123] Obtain backup location information corresponding to the target firmware volume according to the main location information of the target firmware volume in the main storage area;

[0124] Erase the target firmware volume stored in the main storage area;

[0125] Read the backup firmware volume corresponding to the target firmware volume from the backup storage area based on the backup location information;

[0126] Restore the backup firmware volume to the main storage area based on the main location information.

[0127] In some alternative embodiments, the loading module 540 is specifically configured to:

[0128] When it is determined that the number of restoration times is equal to the preset number of restoration times, erase all the firmware in the main storage area and switch from the main storage area to the backup storage area;

[0129] After restarting the firmware loading process, perform the firmware loading operation based on the firmware volume read from the backup storage area.

[0130] For the description of the features in the embodiments corresponding to the firmware loading device, reference can be made to the relevant description in the embodiments corresponding to the firmware loading method, which will not be elaborated here one by one.

[0131] An embodiment of the present application further provides an electronic device, as Figure 6 shown, including a memory 10 and a processor 20. A computer program is stored in the memory 10, and the processor 20 is configured to run the computer program to execute the steps in any of the above embodiments of the firmware loading method. The electronic device may be the above computer device.

[0132] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above embodiments of the firmware loading method when running.

[0133] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), external hard drives, magnetic disks, or optical discs and other media that can store computer programs.

[0134] Embodiments of the present application further provide a computer program product. The computer program product includes a computer program which, when executed by a processor, implements the steps in any of the above-described embodiments of the firmware loading method.

[0135] Embodiments of the present application further provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program which, when executed by a processor, implements the steps in any of the above-described embodiments of the firmware loading method.

[0136] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner 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 to exceed the scope of the present application.

[0137] The above has introduced in detail a firmware loading method, apparatus, electronic device, storage medium, and program product provided by the present application. Specific examples are used herein to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the present application.

Claims

1. A firmware loading method, characterized in that, Including: When it is determined that the trigger timing of the firmware loading operation corresponding to the target firmware volume is reached, based on the pre-acquired position information of the target firmware volume, read the target firmware volume from the main storage area of the target storage component, where the target firmware volume is any one of the multiple firmware volumes that make up the firmware; After performing a verification operation on the target firmware volume, obtain a verification result corresponding to the target firmware volume; When it is determined that the verification result corresponding to the target firmware volume is a verification failure, obtain the number of recovery times corresponding to the type of the target firmware volume; When it is determined that the number of recovery times is less than the preset number of recovery times corresponding to the type of the target firmware volume, select a firmware recovery method corresponding to the type of the target firmware volume according to the type of the target firmware volume; Based on the firmware recovery method, erase a preset number of firmware volumes corresponding to the firmware recovery method in the main storage area, and restore a preset number of firmware volumes corresponding to the firmware recovery method in the backup storage area of the target storage component to the main storage area, where the restored firmware volumes include the target firmware volume; Execute the firmware loading operation based on the restored firmware volume read from the main storage area.

2. The firmware loading method according to claim 1, wherein When the target firmware volume is a data firmware volume, the trigger timing of the firmware loading operation corresponding to the target firmware volume includes: During the running of the first firmware volume, use the moment of obtaining the data firmware volume corresponding to the first firmware volume as the trigger timing, where the first firmware volume is the code firmware volume corresponding to the target firmware volume among the multiple firmware volumes.

3. The firmware loading method according to claim 1, wherein When the target firmware volume is a code firmware volume, the trigger timing of the firmware loading operation corresponding to the target firmware volume includes: When the verification result corresponding to the second firmware volume is obtained and it is determined that the verification result corresponding to the second firmware volume is a verification success, use the moment of determining that the verification result corresponding to the second firmware volume is a verification success as the trigger timing, where the second firmware volume is the previous firmware volume in the loading order before the target firmware volume.

4. The firmware loading method according to claim 2 or 3, characterized in that The target firmware volume includes header information; After verifying the target firmware volume, obtaining the verification result corresponding to the target firmware volume includes: According to the preset header information format and the header information included in the target firmware volume, determine the sub-verification result corresponding to the header information; When it is determined that the sub-verification result corresponding to the header information is used to indicate a verification failure, determine the verification failure as the verification result corresponding to the target firmware volume.

5. The firmware loading method according to claim 4, wherein The target firmware volume further includes verification information; the method further includes: When it is determined that the sub-verification result corresponding to the header information is used to indicate a verification success, determine whether the verification information included in the target firmware volume is damaged; When it is determined that the verification information included in the target firmware volume is damaged, determine the verification failure as the verification result corresponding to the target firmware volume.

6. The firmware loading method according to claim 5, wherein The target firmware volume further includes body information; the method further includes: When it is determined that the verification information included in the target firmware volume is not damaged, the main body information is verified by using the verification information included in the target firmware volume to obtain a sub-verification result corresponding to the main body information; The sub-verification result corresponding to the main body information is determined as the verification result corresponding to the target firmware volume.

7. The firmware loading method according to claim 1, wherein When the target firmware volume is the firmware volume of the central processing unit, the triggering timing of the firmware loading operation corresponding to the target firmware volume includes: Taking the completion moment of the operation of reading the boot loader as the triggering timing.

8. The firmware loading method according to claim 7, wherein The firmware volume of the central processing unit includes the firmware of the central processing unit and verification information; After verifying the target firmware volume, obtaining the verification result corresponding to the target firmware volume includes: Verifying the firmware of the central processing unit by using the verification information included in the firmware volume of the central processing unit to obtain the verification result corresponding to the target firmware volume.

9. The firmware loading method according to claim 1, wherein When the target firmware volume is the code firmware volume or the firmware volume of the central processing unit, based on the firmware recovery method, erasing the firmware volume corresponding to the firmware recovery method in the main storage area, and restoring the firmware volume corresponding to the firmware recovery method in the backup storage area of the target storage component to the main storage area, includes: Erasing all the firmware volumes stored in the main storage area, and restoring all the firmware volumes stored in the backup storage area to the main storage area.

10. The firmware loading method according to claim 1, wherein When the target firmware volume is the data firmware volume, based on the firmware recovery method, erasing the firmware volume corresponding to the firmware recovery method in the main storage area, and restoring the firmware volume corresponding to the firmware recovery method in the backup storage area of the target storage component to the main storage area, includes: According to the main position information of the target firmware volume in the main storage area, obtaining the backup position information corresponding to the target firmware volume; Erasing the target firmware volume stored in the main storage area; Based on the backup position information, reading the backup firmware volume corresponding to the target firmware volume from the backup storage area; Based on the main position information, restoring the backup firmware volume to the main storage area.

11. The firmware loading method according to claim 10, wherein The method further includes: When it is determined that the number of recovery times is equal to the preset number of recovery times, erasing all the firmware in the main storage area, and switching from the main storage area to the backup storage area; After restarting the firmware loading process, performing the firmware loading operation based on the firmware volume read from the backup storage area.

12. An electronic device, characterized in that, Includes: A memory for storing a computer program; A processor for implementing the steps of the firmware loading method according to any one of claims 1-11 when executing the computer program.

13. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the firmware loading method according to any one of claims 1-11 when executed by a processor.

14. A computer program product, characterized in that, The computer program product includes a computer program, wherein the computer program implements the steps of the firmware loading method according to any one of claims 1-11 when executed by a processor.

Images