Firmware starting method and device, electronic equipment and machine readable medium

Abstract

The embodiment of the invention provides a firmware starting method and device, electronic equipment and a machine readable medium, and relates to the technical field of computers, in the method, firmware is started based on an implementation code file corresponding to the firmware in a firmware storage area. If it is monitored that the firmware is not normally started in the target stage, obtaining a target code file corresponding to the target stage from a starting recovery file of a preset storage medium; the startup recovery file comprises an implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized. And continuing to call the target code file from the target stage so as to complete starting of the firmware. Therefore, under the condition of starting abnormity, starting can be recovered by means of the preset storage medium, so that the problem of firmware starting abnormity is solved, operation and maintenance personnel do not need to disassemble a machine for maintenance, the operation is simple, and the working efficiency is high.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a firmware startup method, device, electronic device, and machine-readable medium. Background Art

[0002] Currently, electronic devices use Unified Extensible Firmware Interface (UEFI) firmware to boot the operating system. When using UEFI firmware, UEFI boot anomalies may occur.

[0003] In the prior art, when a UEFI boot anomaly occurs, the UEFI firmware is restored. Specifically, during the restoration, the machine must first be disassembled to locate the UEFI firmware storage area, and then the UEFI firmware must be rewritten into the firmware storage area. This method makes maintenance operations more difficult and inefficient for maintenance personnel. Summary of the Invention

[0004] The embodiments of the present invention provide a firmware startup method, device, electronic device, and machine-readable medium, which can solve the problems of high operational difficulty and low work efficiency.

[0005] In order to solve the above problem, an embodiment of the present invention discloses a method for starting firmware, the method comprising: Starting the firmware based on the implementation code file corresponding to the firmware in the firmware storage area; If it is detected that the firmware does not start normally in the target stage, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium; the startup recovery file includes the implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized; The target code file is continued to be called from the target stage to complete the startup of the firmware.

[0006] On the other hand, an embodiment of the present invention discloses a firmware startup device, the device comprising: A first startup module, configured to start the firmware based on an implementation code file corresponding to the firmware in the firmware storage area; an acquisition module, configured to acquire a target code file corresponding to the target stage from a startup recovery file in a preset storage medium if it is detected that the firmware does not start normally in the target stage; the startup recovery file includes an implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized; The second startup module is used to continue calling the target code file from the target stage to complete the startup of the firmware.

[0007] On the other hand, an embodiment of the present invention discloses an electronic device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the aforementioned method.

[0008] An embodiment of the present invention further discloses a machine-readable medium having instructions stored thereon. When executed by one or more processors, the processors are enabled to execute the method described above.

[0009] The embodiment of the present invention includes the following advantages: the firmware is started based on the implementation code file corresponding to the firmware in the firmware storage area. If it is monitored that the firmware does not start normally in the target stage, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium; the startup recovery file includes the implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized. The target code file is continued to be called from the target stage to complete the startup of the firmware. In this way, in the case of abnormal startup, the startup can be restored with the help of the preset storage medium, thereby solving the problem of abnormal firmware startup. The operation and maintenance personnel do not need to disassemble the machine for maintenance, and the operation is simple and the work efficiency is high. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0011] Figure 1 This is a flowchart of a method for starting firmware provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of a processing process provided by an embodiment of the present invention; Figure 3 This is a block diagram of a firmware startup device provided by an embodiment of the present invention; Figure 4 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0012] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0013] First, let's explain the application scenarios involved in the embodiments of the present invention. UEFI boot is implemented through multiple boot phases, and the boot process is a phased sequential execution process. Each boot phase will load and execute the corresponding implementation code file to complete the tasks of the boot phase and prepare for the next boot phase. Specifically, the UEFI boot process includes the Security Phase (SEC), the Pre-EFI Initialization Phase (PEI), the Driver Execution Environment Phase (DXE), the Boot Device Select Phase (BDS), and the Runtime Phase (RT).

[0014] Among them, the SEC stage is the first boot stage of the UEFI boot process, which is mainly responsible for initializing the processor and basic hardware to provide a secure boot environment for subsequent stages. The PEI stage is the second boot stage of the UEFI boot process, which is mainly responsible for initializing the processor, memory, and other key hardware resources to prepare for the subsequent DXE stage. The DXE stage is mainly responsible for loading and executing drivers. It is the third boot stage of the UEFI boot process, further initializing hardware devices and preparing for the boot of the operating system. The BDS stage is the fourth boot stage of the UEFI boot process, which is mainly responsible for selecting the boot device and starting the operating system. The RT stage is the last boot stage of the UEFI boot process, which is mainly responsible for providing hardware access and management functions when the operating system is running.

[0015] Only after the UEFI firmware boots properly can the operating system on the device run properly. However, sometimes boot anomalies occur. For example, after the user modifies the UEFI configuration or updates the UEFI firmware, the UEFI fails to boot properly. Problems with the operating system boot manager, boot file corruption, or system file loss can also prevent the UEFI from booting properly.

[0016] In the existing technology, users can only use an external burner to manually re-flash the UEFI firmware storage area, and then it is possible to boot normally after the refresh. In this way, when re-flashing the UEFI firmware storage area, professional burning tools (for example, a burner) are required, and the machine needs to be disassembled to find the UEFI firmware storage chip. If the firmware storage chip is connected to the board by welding, it is also necessary to use a soldering iron to remove the chip before re-burning, so as to rewrite the UEFI firmware into the firmware storage chip, so that the UEFI firmware can be started normally later. This cannot be achieved when the user lacks professional equipment such as burning tools and soldering irons. The entire process is cumbersome, difficult to implement, and inefficient.

[0017] To this end, an embodiment of the present invention provides a method for starting firmware.

[0018] Figure 1 This is a flowchart of a method for starting a firmware according to an embodiment of the present invention, which is applied to electronic devices such as Figure 1 As shown, the method may include the following steps: Step 101: Start the firmware based on the implementation code file corresponding to the firmware in the firmware storage area.

[0019] Step 102: If it is detected that the firmware does not start normally in the target stage, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium; the startup recovery file includes the implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized.

[0020] Step 103: Continue calling the target code file from the target stage to complete the startup of the firmware.

[0021] In an embodiment of the present invention, the firmware storage area is located in the aforementioned firmware storage chip, which can be a non-volatile memory on a board, such as a flash memory. The firmware storage area stores implementation code files corresponding to the firmware. Specifically, the implementation code files corresponding to the firmware include implementation code files corresponding to all boot phases of the firmware. The implementation code files are executable code, i.e., binary code. For UEFI firmware, implementation code files for the aforementioned six boot phases are included. The implementation code file corresponding to a boot phase is used to implement that boot phase. Accordingly, the boot phase can be implemented by executing the implementation code file corresponding to that boot phase. Firmware startup is achieved by sequentially executing the implementation code files corresponding to each boot phase in the order in which the boot phases are executed.

[0022] However, during the boot process, it is possible that the next boot phase may not be properly entered, which in turn may result in the firmware not being properly booted, causing a UEFI boot anomaly, i.e., a problem occurred during the boot process. Accordingly, the next boot phase is the target phase, and if the firmware does not properly boot in the target phase, it means that the target phase did not properly boot during the boot process.

[0023] The preset storage medium is a storage medium connected to the board, and the preset storage medium is different from the firmware storage area. For example, the preset storage medium can be a Universal Serial Bus (USB) device, a Non-Volatile Memory Express (NVMe) device, or an optical drive (CD / DVD). In an embodiment of the present invention, a boot recovery file can be pre-stored in the preset storage medium, wherein the boot recovery file is used to boot the firmware in the event of a boot anomaly, so that the firmware can boot normally. In this way, the firmware boot anomaly can be resolved without disassembling the device for recovery, ensuring that the firmware boots normally.

[0024] In an embodiment of the present invention, after the startup of the firmware is completed, the firmware storage area can be restored to ensure that the firmware can be normally started based on the firmware storage area later. Specifically, in the event of a startup exception, a preset storage medium can be connected to the board. Then, the startup is restarted, so that in the event that the target stage does not start normally during the startup process, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium. Alternatively, the board is connected to the preset storage medium by default, so that in the event of the first startup exception, the target code file corresponding to the target stage can be obtained from the startup recovery file stored in the preset storage medium, thereby performing startup recovery according to the target code file. Among them, the target code file corresponding to the target stage is the implementation code file corresponding to the target stage.

[0025] In an embodiment of the present invention, the preset storage medium is initialized in the initialization phase, and accordingly, the target phase is after the preset storage medium is initialized. Exemplarily, the initialization phase is the above-mentioned PEI phase. Since the hardware resources will be initialized in the PEI phase, the preset storage medium connected after the PEI phase will complete the initialization, so that the electronic device can recognize the preset storage medium, thereby ensuring that the operation of obtaining the target code file corresponding to the target phase from the startup recovery file of the preset storage medium can be performed normally. That is, after the preset storage medium is initialized, the file can be read from the preset storage medium. Since the startup recovery file includes the implementation code file corresponding to the firmware, the startup can be continued by reading the target code file corresponding to the target phase in the startup recovery file to complete the firmware startup.

[0026] The target phase is after the preset storage medium has been initialized. For example, if the DXE or BDS phases fail to start properly due to issues with driver execution, board Option ROM startup, or setup interface configuration, the target phase can be the DXE or BDS phase after the initialization phase.

[0027] In summary, in the firmware startup method provided by the embodiment of the present invention, the firmware is started based on the implementation code file corresponding to the firmware in the firmware storage area. If it is monitored that the firmware does not start normally in the target stage, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium; the startup recovery file includes the implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized. The target code file is continued to be called from the target stage to complete the startup of the firmware. In this way, in the case of abnormal startup, the startup can be restored with the help of the preset storage medium, thereby solving the problem of abnormal firmware startup. The operation and maintenance personnel do not need to disassemble the machine for maintenance, and the operation is simple and the work efficiency is high.

[0028] Optionally, the embodiment of the present invention further includes the following steps: Step S21: For any stage of the firmware during the startup process, the implementation code file corresponding to each stage is used as a file to be verified, and integrity verification is performed on the files to be verified respectively during the startup process.

[0029] Step S22: If it is detected that the integrity check fails and / or a designated triggering event is detected, it is determined that the firmware is not started normally in the target phase.

[0030] In an embodiment of the present invention, the stage of the firmware during the startup process is the above-mentioned startup stage. During the startup process, the integrity of the startup binary in the firmware storage area will be judged, that is, the integrity check of the implementation code file will be performed. Specifically, if the implementation code file passes the integrity check, it means that the startup stage corresponding to the implementation code file can be executed normally. Otherwise, it means that the startup stage corresponding to the file to be verified cannot be executed normally. Therefore, it can be determined that the target stage that did not start normally occurred during the startup process. In this scenario, the startup stage corresponding to the file to be verified is the target stage.

[0031] In the embodiment of the present invention, the boot recovery file can be read from the preset storage medium only after the initialization phase. Therefore, in any boot phase after the preset storage medium is initialized, if the file to be verified is the implementation code file corresponding to the boot phase, and the file to be verified fails the integrity check, then the boot phase is used as the target phase, and the situation in which the firmware fails to start normally in the target phase during the boot process is determined to trigger the recovery boot process. For example, assuming that the implementation code file corresponding to the DXE phase fails the integrity check when used as the file to be verified, the DXE phase is used as the target phase. Accordingly, the implementation code file corresponding to the DXE phase can be obtained from the boot recovery file of the preset storage medium as the target code file corresponding to the DXE phase, and the boot can continue from the DXE phase according to the target code file.

[0032] Furthermore, the designated trigger event may be predefined. For example, the designated trigger event may be an event triggered by hardware. The designated trigger event may be a power failure of the timing module of the board, or a short circuit of a reserved circuit in the board, i.e., a hardware trip. The designated trigger event may be triggered by the user. In actual application scenarios, the user may manually trigger the designated trigger event upon observing a startup anomaly, for example, by cutting off the power supply to the timing module, causing the timing module to lose power. Alternatively, the reserved circuit in the board may be short-circuited. In an embodiment of the present invention, if a designated trigger event is detected in any startup phase after the initialization phase, the startup phase may be used as the target phase.

[0033] For example, the event signals corresponding to each designated trigger event can be pre-stored in a designated non-volatile storage area. The event signals corresponding to designated trigger events are pre-defined by the developer. For example, the event signal corresponding to a designated trigger event, such as a power failure of the timing module of a board, is a timing module power failure signal, and the event signal corresponding to a designated trigger event, such as a short circuit of a reserved line, is a reserved line overcurrent signal. If a pre-stored event signal is detected on the board, it is determined that a designated trigger event has been detected.

[0034] In this embodiment of the present invention, the implementation code files corresponding to the startup phase are each treated as files to be verified, and integrity verification is performed on the files to be verified during the startup process. After the initialization phase is completed, if the integrity check fails and / or a specified trigger event is detected, it can be determined that the firmware did not boot normally in the target phase, thus conveniently triggering the subsequent startup recovery process.

[0035] Optionally, the step of performing integrity verification on the files to be verified during the startup process may specifically include: Step S21a: Load the file to be verified from the firmware storage area and write it into the first memory area.

[0036] Step S21b: perform integrity verification based on the files to be verified in the first memory area and the files to be verified in the firmware storage area.

[0037] Correspondingly, the above-mentioned step of starting the firmware based on the implementation code file corresponding to the firmware in the firmware storage area specifically includes: step 1011, executing the file to be checked in the first memory area when the integrity check passes, and clearing the first memory area after execution to start the firmware.

[0038] In an embodiment of the present invention, for any stage, when the implementation code file corresponding to the startup stage is used as the file to be verified, the implementation code file corresponding to the startup stage stored in the firmware storage area (i.e., the file to be verified in the firmware storage area) is first copied to the first memory area. After the copying is complete, the implementation code file corresponding to the startup stage (i.e., the file to be verified in the first memory area) exists in the first memory area, and the file to be verified is also stored in the firmware storage area. Integrity verification is performed by comparing the file to be verified copied to the first memory area with the file to be verified in the firmware storage area to determine whether they are consistent. If the two are consistent, it can be determined that the implementation code file for that stage has passed the integrity verification. If they are inconsistent, it can be determined that the implementation code file for that stage has failed the integrity verification. Specifically, in an embodiment of the present invention, the same hash algorithm can be used to calculate a hash value of the file to be verified copied to the first memory area as a first hash value, and a hash value of the file to be verified in the firmware storage area as a second hash value. If the first hash value and the second hash value are consistent, it can be determined that the contents of the two are consistent, and the implementation code file for that stage has passed the integrity verification. If the first hash value and the second hash value are inconsistent, it can be determined that the contents of the two are inconsistent, and the implementation code file for that stage has failed the integrity verification. The hash algorithm can be predefined. For example, the MD5 (Message-Digest Algorithm 5) hash algorithm can be used. Accordingly, the first hash value and the second hash value are MD5 values. The first hash value and the second hash value can be stored in a preset cache area. After the comparison is completed, the first hash value and the second hash value in the preset cache area can be cleared to avoid unnecessary cache usage.

[0039] Furthermore, if the file to be verified in the first memory area passes the integrity check, the file to be verified in the first memory area can be executed to perform the startup phase, thereby realizing firmware startup. That is to say, in the embodiment of the present invention, when the firmware is started based on the implementation code file in the firmware storage area, the implementation code file corresponding to the startup phase in the firmware storage area will be written into the first memory area for storage. If the execution passes the integrity verification, the implementation code file in the first memory area will be directly executed. After each execution of the implementation code file in the first memory area, the first memory area can be cleared first to facilitate the subsequent writing of the implementation code file corresponding to the next startup phase into the first memory area when continuing to use the implementation code file in the firmware storage area to start, thereby avoiding unnecessary memory usage. Otherwise, the startup recovery file can be obtained to perform the startup recovery process, that is, enter the above-mentioned step 102. In this way, unnecessary code file execution operations can be avoided, thereby saving processing resources.

[0040] Optionally, the embodiment of the present invention may further include: Step S31: Identify a file with a specified name from a specified directory of the preset storage medium to obtain the startup recovery file.

[0041] Correspondingly, the above-mentioned step of continuing to call the target code file from the target stage to complete the startup of the firmware specifically includes: step 1031, writing the target code file corresponding to the target stage into the second memory area, executing the target code file in the second memory area, and clearing the second memory area after execution.

[0042] In an embodiment of the present invention, the designated directory can be predefined as needed. For example, the designated directory can be the root directory, which facilitates searching and ensures search efficiency to a certain extent. The designated name is a predefined fixed name. For example, the designated name can be recovering files, but this is not limited in the embodiment of the present invention. The designated name can be used as a keyword in a keyword matching manner. For any file in the designated directory, the keyword is used to perform keyword matching on the file name of the file, and the successfully matched file is used as the startup recovery file.

[0043] If, during the boot process, it is detected that the firmware does not boot normally at the target stage, it can be determined that the boot mode should be switched to the recovery mode to activate the recovery function. Accordingly, a designated directory in the preset storage medium can be automatically scanned for the boot recovery file. For example, the designated name can be used as a keyword to perform a keyword match against the file names of each file in the root directory. If a match is found for any file, the found file is determined to be the boot recovery file.

[0044] During the startup phase of the boot process, the startup phase is achieved by executing the startup task for that phase, followed by the preparation task. The preparation task is used to complete the preparatory operations required to enter the next startup phase. The implementation code file corresponding to the startup phase includes binary code for implementing the startup and preparation tasks. Thus, executing the implementation code file implements the startup and preparation tasks. Exemplarily, completing the preparation task creates an operating environment for the next startup phase. For example, the preparation operations in the DXE phase may include launching the operating system loader to facilitate the next phase, which boots the operating system based on the operating system loader. Accordingly, for the target phase, under normal circumstances, the preparatory operations required to enter the target phase are completed during the implementation of the previous startup phase. Accordingly, in embodiments of the present invention, the target code file corresponding to the target phase can be searched and written to the second memory area. Since the central processing unit can directly access memory, writing the target code file to the second memory area facilitates execution. Accordingly, if the target phase was not launched normally during the current startup process, resulting in a startup anomaly, the target phase can be resumed by executing the target code file corresponding to the target phase in the second memory area. For example, assuming that the target stage is the DXE stage and the target code file corresponding to the DXE stage is DXE.bin, then the copy command can be used to write DXE.bin into the second memory area. By executing DXE.bin in the second memory area, the DXE stage is completed, and then the startup from the DXE stage can be continued.

[0045] In an embodiment of the present invention, it is monitored that the firmware does not start normally in the target stage. It may be that the firmware does not execute the startup task corresponding to the target stage, or it may be that the firmware executes part of the startup task corresponding to the target stage. For example, when a part of the startup task of the target stage is executed, the user monitors the startup termination through a monitoring device, such as an oscilloscope, and can trigger a specified trigger event to enable the electronic device to start executing the operation of obtaining the target code file corresponding to the target stage from the startup recovery file of the preset storage medium.

[0046] Accordingly, the implementation code file corresponding to the target stage can be searched from the preset storage medium and written into the second memory area to realize continued booting from the target stage. The second memory area is a memory area used to store binary code. The second memory area and the above-mentioned first memory area can be the same memory area, or they can be different memory areas. The second memory area can adopt a specific data structure. For example, the second memory area is divided into logical segments, and each segment is responsible for storing different types of data, such as code segments, data segments, and so on. In an embodiment of the present invention, the boot recovery file can be identified by identifying a file with a specified name from a specified directory of the preset storage medium, and further, the target code file corresponding to the target stage is written into the second memory area. By executing the implementation code file in the second memory area, it is possible to realize continued booting from the target stage, and then by using the boot recovery file in the preset storage medium, it is possible to realize continued booting from the target stage that has never been entered normally, so that the abnormally interrupted boot process is restored, thereby ensuring that the firmware can be started normally.

[0047] Optionally, the embodiment of the present invention further includes: Step S41: Take the next stage of the target stage as the stage to be executed, search for the target code file corresponding to the stage to be executed from the startup recovery file, write it into the second memory area, and continue to execute the target code file in the second memory area until the target code files corresponding to each stage are executed.

[0048] In this embodiment of the present invention, after the next stage of the target phase is designated as the new stage to be executed, the target code file corresponding to the stage to be executed is searched from the startup recovery file and written into the second memory area. At this point, the target code file in the second memory area is the implementation code file corresponding to the next stage of the target phase. Next, the target code file in the second memory area can be executed again, and after execution is complete, the second memory area is cleared. This cycle repeats until all startup phases have been executed.

[0049] In an embodiment of the present invention, the boot process can be terminated without the existence of a next boot phase. This is equivalent to sequentially searching the boot recovery file for the implementation code file corresponding to the next boot phase of the currently completed boot phase, writing the implementation code file to the second memory area, and executing the implementation code file in the second memory area until all boot phases are completed. Each time the implementation code file in the second memory area is executed, the second memory area can be cleared to facilitate subsequent writing of code files to the second memory area, thereby avoiding unnecessary memory usage.

[0050] For example, assuming the second memory area is 0x0010-0x9010, and the implementation code files corresponding to the DXE, BDS, and RT stages are DXE.bin, BDS.bin, and RT.bin, respectively, and the target stage is the DXE stage, then the implementation code file DXE.bin corresponding to the DXE stage can be searched first and written to 0x0010-0x9010. After executing DXE.bin in 0x0010-0x9010, the 0x0010-0x9010 range is cleared. Next, the implementation code file BDS.bin corresponding to the BDS stage is searched from the boot recovery file and written to 0x0010-0x9010. After executing BDS.bin in 0x0010-0x9010, the 0x0010-0x9010 range is cleared. Next, the implementation code file RT.bin corresponding to the RT stage is searched from the boot recovery file and written to 0x0010~0x9010. After executing RT.bin in 0x0010~0x9010, 0x0010~0x9010 is cleared to end the boot process.

[0051] In this embodiment of the present invention, by cyclically searching for target code files corresponding to the boot phase after the target phase in the boot recovery file and executing these target code files, in the event of a boot anomaly, the remaining boot process is directly implemented based on the boot recovery file in the preset storage medium, ensuring normal firmware boot. This method eliminates the need to repeatedly switch back and forth between the fixed storage area and the preset storage medium to read code files, thus ensuring processing efficiency to a certain extent.

[0052] Of course, the implementation code files corresponding to other startup phases after the target phase may also be obtained from the fixed storage area for startup, and this embodiment of the present invention does not impose any limitation on this.

[0053] Optionally, the above-mentioned startup recovery file also includes header information and a real signature value of an implementation code file corresponding to the startup phase of the firmware, and the startup recovery file is stored in the format of a firmware volume.

[0054] The step of obtaining the target code file corresponding to the target stage may specifically include: Step 1021: Determine the firmware volume whose identifier in the startup recovery file matches the identifier of the target stage as the target firmware volume.

[0055] Step 1022: Obtain the binary file recorded in the target firmware volume to obtain the target code file corresponding to the target stage.

[0056] The step of writing the target code file corresponding to the target stage into the second memory area includes: sequentially loading the binary files recorded in the target firmware volume into the second memory area according to a preset loading order.

[0057] The preset loading order is consistent with the order in which the implementation code files corresponding to the target stage are loaded from the firmware storage area. For example, the target firmware volume containing the core components is loaded first in the preset loading order. That is, the target firmware volume containing the core components of the current stage can be loaded first, and then the target firmware volumes required later can be loaded. For example, if the target stage is the DXE stage, the binary file recorded in the FV where the DXECORE is located can be loaded first, and then the binary file recorded in the FV required later can be loaded.

[0058] In this embodiment of the present invention, the boot recovery file is a recovery package containing binary files and header information for each firmware boot phase. These binary files are known as the recovery image. The boot recovery file is generated along with the firmware during compilation. When the firmware is released, it can be included simultaneously, allowing users to easily access the boot recovery file and import it for recovery in the event of a problem.

[0059] Specifically, the boot recovery file is stored in the format of a firmware volume (FV). The boot recovery file includes multiple FVs, which are stored continuously. The multiple FVs are packaged to obtain the boot recovery file. FV is a data structure defined in the UEFI specification, which is used to organize and store firmware components. The data structure of FV consists of two parts: an FV header and FV data. Among them, the FV data part of an FV stores part or all of the implementation files in the implementation code file corresponding to a boot phase, that is, the implementation code file corresponding to a boot phase is recorded with the FV in a one-to-one or one-to-many relationship. And, the real signature value of the code file stored in the FV data part is a real signature value pre-generated for the code file stored in the FV data part using a preset signature algorithm. Correspondingly, the header information is stored in the FV header, and the header information includes the startup phase identifier, signature algorithm information and real signature value information corresponding to the code file stored in the FV data part. Exemplarily, the data structure of the header information can be expressed as: startup phase identifier-signature algorithm information-real signature value information, and the data structure of the FV data can be expressed as: implementation code file-real signature value.

[0060] The signature algorithm information is used to identify the signature algorithm used when generating the true signature value for the code file stored in the FV data portion. That is, the signature algorithm information is used to identify the aforementioned preset signature algorithm. The true signature value information is the information required to obtain the true signature value stored in the FV data portion. For example, the true signature value stored in the FV data portion may be stored at the end of the FV data. The true signature value information may represent the length of the true signature value stored in the FV data portion, that is, the length occupied by the true signature value, for example, 1 byte. Accordingly, one byte at the end of the FV data portion may be obtained to obtain the true signature value.

[0061] It should be noted that the FV header may also include an FV index for managing FVs, and the FV header may also include an FV length field, which is used to characterize the total length of the FV. Starting from the starting position of the startup recovery file in the preset storage medium, according to the FV length field in the FV header, the sum of the starting position and the FV length field is determined as the end position of the first FV, and the files between the starting position and the end position are taken as one FV. Then, the next storage of the end position of the FV is used as the starting position of the next FV, and then the FV length field is searched from the starting position, and the sum of the starting position and the FV length field is determined as the end position of the FV, and the files between the starting position and the end position are taken as one FV. Repeat the above process until the end position of the startup recovery file is reached.

[0062] For each FV found, the identifier in the FV header information of the FV is matched with the identifier of the target stage. For example, a comparison instruction is used to compare the identifier in the FV header information with the identifier of the target stage. If the two are consistent, it can be determined that the two match, and accordingly, the FV can be used as the target firmware volume. In actual application scenarios, the implementation code file corresponding to a startup stage may be stored in multiple FVs. Therefore, there are multiple FVs with the same identifier in the FV header information. Accordingly, the target firmware volumes found may be multiple. Among them, the identifier can be a GUID, and different startup stages have different GUIDs. For example, assuming that the startup recovery file includes 20 FVs: FV1~FV20, the identifier of the target stage is "dxe", and the identifier in FV7~FV12 is "dxe", then FV7~FV12 can be used as the target firmware volume.

[0063] Assuming the binary files stored in the FV data of FV7 to FV12 are: DXE-part1.bin, DXE-part2.bin, DXE-part3.bin, DXE-part4.bin, DXE-part5.bin, and DXE-part6.bin, respectively, then DXE-part1.bin, DXE-part2.bin, DXE-part3.bin, DXE-part4.bin, DXE-part5.bin, and DXE-part6.bin can be used as the target code files corresponding to the target stage. The binary files recorded in FV7 to FV10: DXE-part1.bin, DXE-part2.bin, DXE-part3.bin, DXE-part4.bin, DXE-part5.bin, and DXE-part6.bin can be loaded into the second memory area in ascending order of serial numbers.

[0064] Of course, the FV header may also include other information, such as the file type. For any target firmware volume, the target firmware volume representing the core component of the file type in the FV header is identified, and the binary files recorded in these target firmware volumes are first loaded into the second memory area.

[0065] In this embodiment of the present invention, a firmware volume whose identifier matches the identifier of the target stage is identified as the target firmware volume. The binary file recorded in the target firmware volume is retrieved to obtain the target code file corresponding to the target stage. This ensures that all firmware volumes of the target stage can be found, thereby ensuring the integrity of the found implementation code files.

[0066] The embodiment of the present invention further includes: Step S51: Use any firmware volume in the boot recovery file as the firmware volume to be verified, and obtain signature algorithm information and real signature value information in header information of the firmware volume to be verified.

[0067] Step S52: Based on the real signature value information, obtain the real signature value of the firmware volume to be verified, and generate a verification signature value for the firmware volume to be verified based on the signature algorithm information.

[0068] Step S53: When the verification signature value matches the real signature value, execute the step of obtaining the target code file corresponding to the target stage.

[0069] In the embodiment of the present invention, since the startup recovery file is an external uncertain file, after the startup recovery file is found, a processing operation may be performed on the startup recovery file: signature verification.

[0070] Specifically, for any FV found in the boot recovery file, the signature algorithm represented by the signature algorithm information in the FV header information of the FV can be used to generate a signature value for the binary file recorded in the data portion of the FV, which serves as the verification signature value. For example, the signature algorithm represented by the signature algorithm information can be a hash algorithm, such as SHA-256. SHA-256 is a one-way encryption algorithm that accepts input data of any length and outputs a fixed-length hash value of 256 bits (32 bytes). This hash value serves as the verification signature value. The implementation method for obtaining the true signature value based on the true signature value information can be referred to in the previous description and will not be repeated here.

[0071] If the verification signature value of the FV matches the true signature value, the verification is determined to match the true signature value, meaning the verification has passed. For example, assuming the FV7 header is: dxe-SHA-256-32byte, indicating that the FV stores the implementation code file corresponding to the DXE stage, uses the SHA-256 signature algorithm, and the true signature value carried in the FV data portion is the last 32 bytes. The FV7 data portion is: DXE1.bin-SHA-256 value 1, where DXE1.bin is a portion of the implementation code file corresponding to the DXE stage, and SHA-256 value 1 represents the true signature value carried. Assuming the verification signature value generated using the SHA-256 algorithm for DXE-part.bin is: SHA-256 value 2, SHA-256 value 2 can be compared bit by bit with the last 32 bytes of the FV7 data portion: SHA-256 value 1. If every bit is identical, the verification is determined to have passed. Otherwise, the verification is determined to have failed.

[0072] Furthermore, if the verification signature values of all firmware volumes to be verified match the true signature values, the step of searching the boot recovery file for the target code file corresponding to the target stage is performed. If there is a firmware volume whose verification signature value does not match the true signature value, a verification failure reminder is displayed. This allows the user to promptly disassemble the device for recovery.

[0073] In an embodiment of the present invention, by generating a verification signature value and comparing the verification signature value with the real signature value, verification of an external startup recovery file can be achieved, ensuring that the target code file is completely matched with the target stage, thereby ensuring the security of startup recovery.

[0074] Optionally, the step of performing firmware recovery on the firmware storage area specifically includes: Step S61: displaying the firmware setting interface, and updating the firmware in the firmware storage area in response to a triggering operation on an update option in the setting interface.

[0075] Alternatively, in step S62, the firmware in the firmware storage area is updated using a firmware update tool installed in the operating system.

[0076] In the embodiment of the present invention, after completing the firmware startup, the user can use the electronic device normally. Therefore, the firmware in the firmware storage area can be updated with the help of the established setting interface and firmware update tool, so that subsequent startup can be based on the firmware in the firmware storage area.

[0077] That is, in an embodiment of the present invention, after starting based on the startup recovery file, the repair operation is performed. In one implementation method, the user can click a button to trigger the entry into the UEFI firmware setting interface to enter the setting interface. Among them, the setting interface is an established setting interface in the electronic device in the prior art, and the electronic device displays the setting interface in response to the user's triggering operation of the button to enter the UEFI firmware setting interface. Then, click the update option in the setting interface, so that the electronic device detects the triggering operation and updates the UEFI firmware in the firmware storage area. For example, the latest firmware implementation code file is downloaded from the official firmware website, and the downloaded firmware implementation code file is written into the firmware storage area to implement the firmware update. Assuming that the latest firmware implementation code file is version 3.0 of UEFI.bin, then version 3.0 of UEFI.bin can be written into the firmware storage area. Alternatively, in another way, the update can be performed with the help of an installed firmware update tool. Exemplarily, the firmware update tool can be a fwupdate tool, and the firmware update tool can be pre-installed for the electronic device. After the system is restored and the operating system is normally entered, the firmware update tool can be launched. Accordingly, the firmware update tool will update the UEFI firmware in the firmware storage area. For example, the latest firmware implementation code file can be downloaded from the official firmware website and written to the firmware storage area to implement the firmware update.

[0078] In an embodiment of the present invention, a setting interface for UEFI firmware is displayed, and in response to a triggering operation on an update option in the setting interface, the UEFI firmware in the firmware storage area is updated. Alternatively, a firmware update tool installed in the operating system is used to update the UEFI firmware in the firmware storage area. In this way, after startup recovery, that is, after resolving the problem of startup failure in the UEFI environment, the UEFI firmware in the firmware storage area can be updated with the help of an existing setting interface or firmware update tool, so that subsequent startup can be completed normally based on the UEFI firmware in the firmware storage area, which can simplify the recovery process and improve the reliability of the system.

[0079] The firmware startup method provided in the embodiment of the present invention can be implemented in the form of a recovery tool. The recovery tool can be built into an electronic device. By running the recovery tool, each step in the firmware startup method is implemented. Each step in the firmware startup method can be implemented by corresponding driver software. If there is reusable existing driver software, the existing driver software can be reused, for example, a signature verification driver can be reused. If it does not exist, corresponding driver software can be developed for the recovery tool.

[0080] Figure 2 This is a schematic diagram of a processing process provided in an embodiment of the present invention. Figure 2 As shown, when the firmware is started, after the initialization phase, it is determined whether to enter the recovery mode, that is, whether the firmware fails to start the target phase normally. If not, continue to start normally. If so, enter the recovery mode based on the startup recovery file in the preset storage medium. Specifically, in the recovery mode, the startup recovery file can be obtained, and then the signature is verified based on the verification signature value and the real signature value. If the signature verification passes, loading and starting are performed, that is, based on the target code file corresponding to the target phase, the startup continues from the target phase, and the firmware storage area is restored after startup. In this way, users can quickly restore the startup state without an external burning device, which has high practical value and prospects.

[0081] Reference Figure 3 , shows a block diagram of a firmware startup device provided by an embodiment of the present invention, such as Figure 3 As shown, the device may specifically include: A first startup module 201, configured to start the firmware based on an implementation code file corresponding to the firmware in the firmware storage area; The acquisition module 202 is configured to acquire a target code file corresponding to the target stage from a startup recovery file in a preset storage medium if it is detected that the firmware does not start normally in the target stage; the startup recovery file includes an implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized; The second startup module 203 is used to continue calling the target code file from the target stage to complete the startup of the firmware.

[0082] Optionally, the device further comprises: A verification module is used to use the implementation code files corresponding to each stage as files to be verified at any stage of the firmware during the startup process, and to perform integrity verification on the files to be verified during the startup process; The determination module is configured to determine that the firmware is not normally started in the target phase if it is detected that the integrity check fails and / or a designated triggering event is triggered.

[0083] Optionally, the verification module is specifically configured to: Loading the file to be verified from the firmware storage area and writing it into the first memory area; Performing integrity verification based on the file to be verified in the first memory area and the file to be verified in the firmware storage area; The first startup module 201 is specifically configured to: execute the file to be verified in the first memory area if the integrity check passes, and clear the first memory area after the execution is completed to start the firmware.

[0084] Optionally, the device further comprises: an identification module, configured to identify a file with a specified name from a specified directory of the preset storage medium as the startup recovery file; The second starting module 203 is specifically configured to write the target code file corresponding to the target stage into the second memory area, execute the target code file in the second memory area, and clear the second memory area after execution.

[0085] Optionally, the device further comprises: The first processing module is used to take the next stage of the target stage as the to-be-executed stage, search for the target code file corresponding to the to-be-executed stage from the startup recovery file, write it into the second memory area, and continue to execute the target code file in the second memory area until the target code files corresponding to each stage are executed.

[0086] Optionally, the boot recovery file is stored in a firmware volume format; the acquisition module 202 is specifically configured to: Determine the corresponding firmware volume whose identifier in the startup recovery file matches the identifier of the target stage as the target firmware volume; Obtain the binary file recorded in the target firmware volume to obtain the target code file corresponding to the target stage.

[0087] Optionally, the device further comprises: A recovery module is used to: display the setting interface of the firmware, and update the firmware in the firmware storage area in response to a triggering operation of an update option in the setting interface; or use a firmware update tool installed in the operating system to update the firmware in the firmware storage area.

[0088] In summary, in the firmware startup device provided by the embodiment of the present invention, the firmware is started based on the implementation code file corresponding to the firmware in the firmware storage area. If it is monitored that the firmware does not start normally in the target stage, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium; the startup recovery file includes the implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized. The target code file is continued to be called from the target stage to complete the startup of the firmware. In this way, in the case of abnormal startup, the startup can be restored with the help of the preset storage medium, thereby solving the problem of abnormal firmware startup. The operation and maintenance personnel do not need to disassemble the machine for maintenance, and the operation is simple and the work efficiency is high.

[0089] Reference Figure 4 , is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 4 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus.

[0090] The processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, which enables the processor to execute the firmware startup method of the above embodiment. The executable instructions can form a program.

[0091] An embodiment of the present invention provides a machine-readable medium having instructions stored thereon. When executed by one or more processors, the processors are enabled to execute the firmware startup method of the aforementioned embodiment. The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0092] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatus, or computer program products. Thus, embodiments of the present invention may take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] It should be noted that all actions of acquiring signals, information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located and with the authorization given by the owner of the corresponding device.

[0094] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0095] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0096] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0097] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0098] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0099] Moreover, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or terminal device that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not preclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0100] The above describes in detail a firmware startup method, device, electronic device, and one or more readable media provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the contents of this specification should not be understood as limiting the present invention.

Claims

1. A method for starting a firmware, characterized in that: The method comprises: Starting the firmware based on the implementation code file corresponding to the firmware in the firmware storage area; If it is detected that the firmware does not start normally in the target stage, the target code file corresponding to the target stage is obtained from the startup recovery file of the preset storage medium; the startup recovery file includes the implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized; The target code file is continued to be called from the target stage to complete the startup of the firmware.

2. The method according to claim 1, characterized in that The method further comprises: For any stage of the firmware during the startup process, the implementation code files corresponding to each stage are used as files to be verified, and integrity verification is performed on the files to be verified respectively during the startup process; If it is detected that the integrity check fails and / or a specified trigger event is detected to be triggered, it is determined that the firmware is not normally started in the target stage.

3. The method according to claim 2, characterized in that The performing integrity check on the files to be checked respectively during the startup process includes: Loading the file to be verified from the firmware storage area and writing it into the first memory area; Performing integrity verification based on the file to be verified in the first memory area and the file to be verified in the firmware storage area; The firmware is started based on the implementation code file corresponding to the firmware in the firmware storage area, including: executing the file to be checked in the first memory area when the integrity check passes, and clearing the first memory area after execution to start the firmware.

4. The method according to claim 1, wherein The method further comprises: Identifying a file with a specified name from a specified directory of the preset storage medium as the startup recovery file; Continuing to call the target code file from the target stage to complete the startup of the firmware includes: writing the target code file corresponding to the target stage into a second memory area, executing the target code file in the second memory area, and clearing the second memory area after execution is completed.

5. The method according to claim 4, characterized in that The method further comprises: The next stage of the target stage is taken as the stage to be executed, the target code file corresponding to the stage to be executed is searched from the startup recovery file, and written into the second memory area, and the target code file in the second memory area is continued to be executed until the target code files corresponding to each stage are all executed.

6. The method according to claim 1, characterized in that The boot recovery file is stored in a firmware volume format; and obtaining the target code file corresponding to the target stage includes: Determine the corresponding firmware volume whose identifier in the startup recovery file matches the identifier of the target stage as the target firmware volume; Obtain the binary file recorded in the target firmware volume to obtain the target code file corresponding to the target stage.

7. The method according to any one of claims 1 to 6, characterized in that: After completing the startup of the firmware, the method further includes: displaying a setting interface for the firmware, and updating the firmware in the firmware storage area in response to a triggering operation on an update option in the setting interface; Alternatively, a firmware update tool installed in the operating system is used to update the firmware in the firmware storage area.

8. A firmware startup device, characterized in that: The device comprises: A first startup module, configured to start the firmware based on an implementation code file corresponding to the firmware in the firmware storage area; an acquisition module, configured to acquire a target code file corresponding to the target stage from a startup recovery file in a preset storage medium if it is detected that the firmware does not start normally in the target stage; the startup recovery file includes an implementation code file corresponding to the firmware, and the target stage is after the preset storage medium is initialized; The second startup module is used to continue calling the target code file from the target stage to complete the startup of the firmware.

9. An electronic device, characterized in that: include: A processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; The memory is used to store executable instructions, and the executable instructions enable the processor to execute the method according to any one of claims 1 to 7.

10. A machine-readable medium, characterized in that Instructions are stored thereon, which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 7.

Images