CN116860282A

CN116860282A - Firmware refreshing method, device, equipment and storage medium

Info

Publication number: CN116860282A
Application number: CN202310610662.XA
Authority: CN
Inventors: 王学龙
Original assignee: Suzhou Inspur Intelligent Technology Co Ltd
Current assignee: Suzhou Inspur Intelligent Technology Co Ltd
Priority date: 2023-05-26
Filing date: 2023-05-26
Publication date: 2023-10-10

Abstract

The application discloses a firmware refreshing method, a device, equipment and a storage medium, wherein the method comprises the steps of receiving a firmware refreshing request, wherein the firmware refreshing request comprises a target component to be subjected to firmware refreshing, and the firmware in the target component comprises first firmware for direct execution and second firmware for backing up the first firmware; sequentially executing power-down and power-up operations on a server where the target component is located so as to refresh the first firmware; under the condition that the refreshing of the first firmware is completed, setting the value of the starting control identifier as a first value, so that when the baseboard management controller monitors that the value of the starting control identifier is the first value, starting operation is carried out on the server; and refreshing the second firmware under the condition that the starting of the server is completed. The whole firmware refreshing process can be automatically coherent without manual participation.

Description

Firmware refreshing method, device, equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a firmware refreshing method, device, equipment, and storage medium.

Background

PFR (Platform Firmware Resilience, platform firmware elastic) technology is a security technology based on Intel platform, and is mainly used for detecting malicious or erroneous behavior of server firmware and restoring the server firmware to a good state. The PFR technology uses a CPLD (Complex Programmable Logic Device ) chip as a technology core, and functions such as secure boot verification and data management for server firmware are realized through the CPLD chip.

Currently, in some scenarios, when refreshing server firmware based on PFR technology, the refreshing is performed based on a mode of server automation combined with human operation. In short, after the server automatically performs part of the refresh operation, the server can continue to automatically perform the subsequent refresh operation only under the condition of manually participating in performing some operations, and the whole refresh process cannot be automatically coherent.

Disclosure of Invention

In view of the above, the present application provides a firmware refreshing method, a firmware refreshing device, an electronic device, and a computer readable storage medium, where the firmware refreshing process can be automatically performed without human intervention.

In one aspect, the present application provides a firmware refreshing method, including:

receiving a firmware refreshing request, wherein the firmware refreshing request comprises a target component to be subjected to firmware refreshing, and the firmware in the target component comprises first firmware for direct execution and second firmware for backing up the first firmware;

sequentially executing power-down and power-up operations on a server where the target component is located so as to refresh the first firmware;

under the condition that the refreshing of the first firmware is completed, setting the value of the startup control identifier as a first value so that the baseboard management controller can execute startup operation on the server when monitoring that the value of the startup control identifier is the first value;

and refreshing the second firmware under the condition that the starting of the server is completed.

In some embodiments, the method is applied to a platform firmware elastomer for protecting and recovering firmware, the platform firmware elastomer including an instruction register for storing the boot control identification;

the setting the value of the startup control identifier as a first value includes:

writing the first value in the instruction register to set the value of the startup control identifier to the first value.

In some embodiments, in the event that the baseboard management controller has completed reading the first value from the instruction register, the method further comprises:

a second value different from the first value is written in the instruction register to zero-clear the value stored in the instruction register.

In some embodiments, the method is applied to a platform firmware elastic component for protecting and recovering firmware, and the starting control identifier is set in a configuration file allowing the platform firmware elastic component to read and write;

and setting the value of the startup control identifier as the first value in the configuration file.

In some embodiments, in the case that the server is powered on, the method further includes:

and in the configuration file, setting the value of the starting control identifier to be a second value different from the first value so as to carry out zero clearing processing on the value of the starting control identifier.

In some embodiments, the server includes a bios chip that detects whether the server is powered up according to the following method:

receiving a state identifier which is sent by a central processing unit and is related to the running state of the basic input/output system chip;

under the condition that the value of the state identifier is a target state value, determining that the basic input/output system chip runs successfully;

and under the condition that the basic input system chip successfully operates, determining that the starting of the server is completed.

In some embodiments, the firmware refresh request further includes file information of a firmware image file for refreshing firmware of the target component;

refreshing the firmware of the target component, including:

based on the file information, acquiring a firmware image file for refreshing the firmware of the target component;

and refreshing the firmware of the target component according to the firmware image file.

The application also provides a firmware refreshing device, which comprises:

the device comprises a request receiving module, a request updating module and a processing module, wherein the request receiving module is used for receiving a firmware updating request, the firmware updating request comprises a target component to be subjected to firmware updating, and firmware in the target component comprises first firmware for direct execution and second firmware for backing up the first firmware;

the first refreshing module is used for sequentially executing power-down and power-up operations on the server where the target component is located so as to refresh the first firmware;

the device comprises an identifier setting module, a boot control identifier, a base plate management controller and a server, wherein the identifier setting module is used for setting the value of the boot control identifier to be a first value under the condition that refreshing of the first firmware is completed, so that when the base plate management controller monitors that the value of the boot control identifier is the first value, the boot operation is executed on the server;

and the second refreshing module is used for refreshing the second firmware under the condition that the starting of the server is completed.

In a further aspect the application provides an electronic device comprising a processor and a memory for storing a computer program which, when executed by the processor, implements a method as described above.

In a further aspect the application provides a computer readable storage medium for storing a computer program which, when executed by a processor, implements a method as described above.

In some embodiments of the present application, when a firmware refresh request is received, a power-down operation and a power-up operation are sequentially performed on a server where a target component is located, so as to refresh a first firmware. After the first firmware refreshing is completed, the value of the startup control identifier is set to be a first value, so that the baseboard management controller can execute startup operation on the server when monitoring that the value of the startup control identifier is the first value. And refreshing the second firmware under the condition that the starting of the server is completed. The startup control identifier is set to indicate whether to execute startup operation, and the baseboard management controller determines whether to execute startup operation based on the startup control identifier, so that the whole firmware refreshing process can be automatically coherent without manual participation, and the operation of technicians can be simplified.

Drawings

The features and advantages of the present application will be more clearly understood by reference to the accompanying drawings, which are illustrative and should not be construed as limiting the application in any way, in which:

FIG. 1 illustrates a schematic architecture of a server provided by one embodiment of the present application;

FIG. 2 is a flow chart of a firmware refreshing method according to an embodiment of the present application;

FIG. 3 is an interactive schematic diagram of a firmware refreshing method according to an embodiment of the present application;

FIG. 4 is a block diagram of a firmware refreshing apparatus according to an embodiment of the present application;

fig. 5 shows a schematic diagram of an electronic device according to an embodiment of the application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the technical solutions in the present application will be clearly and completely described below with reference to the accompanying drawings in the present application, and it is apparent that the described embodiments are some embodiments of the present application, not all embodiments of the present application. All other embodiments, based on the embodiments of the application, which are available to the person skilled in the art without any inventive effort, are within the scope of the application.

In the present application, firmware refers to a software program that is solidified in a server. Such as a central processing unit (Central Processing Unit, CPU) of the server, a baseboard management controller (Baseboard Management Controller, BMC), a BIOS (Basic Input Output System ) chip, and a CPLD (Complex Programmable Logic Device, complex programmable logic device) chip, which are all burned with software programs. These software programs may be referred to as firmware.

Referring to fig. 1, a schematic architecture of a server 100 according to an embodiment of the application is shown. In fig. 1, a server 100 includes an FPR chip 11 and a plurality of components 12 that require firmware protection and restoration. The FPR chip 11 is communicatively connected to the various components 12. The FPR chip 11 protects and restores the firmware in the component 12. Component 12 illustratively includes a central processor, a baseboard management controller, a BIOS chip, a CPLD chip. It should be noted that, all components 12 in the server 100 that need firmware protection and recovery may be connected to the FPR chip 11, and the components 12 shown in fig. 1 do not limit the present application.

The FPR chip 11 may be a CPLD chip. In brief, the server 100 may include a plurality of CPLD chips, one CPLD chip for implementing FPR functions, and other CPLD chips for implementing other server management functions. In the illustrated embodiment of the present application, a CPLD chip that implements the FPR function is used as the FPR chip 11, and a CPLD chip that implements other server management functions is used as the component 12 that is communicatively connected to the FPR chip 11.

Each component 12 includes FLASH memory 121. The FLASH memory 121 includes a first memory area 1211 and a second memory area 1212. The first storage area 1211 may also be referred to as an active storage area for storing uncompressed, directly executable first firmware. The first firmware may also be referred to as active firmware. During operation of component 12, the first firmware may be executed to implement the corresponding functions. The second storage area 1212 may also be referred to as a recovery storage area for storing compressed second firmware that backs up the first firmware. The second firmware may also be referred to as recovery firmware. Upon boot-up of the component 12, the FPR chip 11 may verify the first firmware of the first storage 1211, and in the event that the verification passes, the component 12 boots up from the first storage 1211. In the event that the verification is not passed, the FPR chip 11 may restore the second firmware in the second storage area 1212 to the first storage area 1211, and then the unit 12 may restart.

In some embodiments, FLASH memory 121 may also include a third storage area 1213. The third storage area 1213 may also be referred to as a starting storage area. Upon refreshing the firmware in the part 12 (i.e., upgrading the firmware in the part 12), the FPR chip 11 may first write the firmware for refreshing into the third storage area 1213. During a restart of the server 100, the FPR chip 11 may further write the firmware in the third storage 1213 into the first storage 1211 and/or the second storage 1212 to refresh the firmware in the first storage 1211 and/or the second storage 1212.

Specifically, when firmware in the component 12 is refreshed, two modes, namely active refresh and recovery refresh, may be specifically included. The active refresh is to refresh only the first firmware in the first storage area 1211. The recovery refresh is to refresh the second firmware in the second storage area 1212 after the first firmware in the first storage area 1211 is refreshed. The technical scheme of the application is mainly aimed at the technical improvement of recovery refreshing.

Currently, in the recovery refresh mode, when the first firmware in the first storage area 1211 is refreshed, the FPR chip 11 requests the CPLD chip to perform the power-down and power-up operations on the server 100 in sequence, so as to refresh the first firmware. After the first firmware refreshing is completed, the FPR chip 11 will refresh the second firmware only when detecting that the CPLD chip, the baseboard management controller, and the BIOS chip all operate normally. Typically, most components 12 (e.g., cpu, baseboard management controller) will automatically resume operation after the server 100 is powered up, but the BIOS chip will need to be operated after the server 100 is powered up. In this case, when the power-on policy of the server 100 is that the FPR chip 11 is powered on and not powered on, it is required to manually execute the power-on action after the FPR chip 11 completes the refreshing of the first firmware, so that the BIOS chip resumes operation, so that the FPR chip 11 continues to refresh the second firmware. The firmware refreshing method needs to be manually participated, cannot achieve automatic continuity, and brings a plurality of inconveniences to technicians who execute firmware refreshing. For example, in the recovery refresh mode, the technician may need to check the refresh progress in real time, and go to the machine room to manually start the server 100 when checking that the refresh of the first firmware is completed, so that the BIOS chip resumes operation, so that the FPR chip 11 continues to refresh the second firmware. This process is cumbersome.

In view of this, the present application provides a firmware refreshing method, in which the firmware refreshing process can be automatically continued in the recovery refreshing mode, without human participation, and simplifying the operation of technicians. The firmware refreshing method can be applied to a platform firmware elastic component, namely an FPR chip, for protecting and recovering the firmware. Referring to fig. 2, a flowchart of a firmware refreshing method according to an embodiment of the application is shown. In fig. 2, the firmware refreshing method includes the following steps:

in step S21, a firmware refreshing request is received, where the firmware refreshing request includes a target component to be subjected to firmware refreshing, and the firmware in the target component includes a first firmware for direct execution and a second firmware for backing up the first firmware.

The first firmware and the second firmware may be referred to in fig. 1 for description, which is not repeated here.

In some embodiments, a technician may specify a target component that needs to be firmware refreshed, and a firmware image of the firmware refreshed target component, through a management interface of the baseboard management controller. In particular, the target component may include, but is not limited to, one or more of a central processing unit, a baseboard management controller, a BIOS chip, a CPLD chip. The firmware image file may include content required for refreshing the firmware in the target component, such as new firmware to be refreshed into the target component. The file format of the firmware image file may include, but is not limited to, the following:

.iso、.bin、.nrg、.vcd、.cif、.fcd、.img、.ccd、.c2d、.dfi、.tao、.dao。

for example, when a technician needs to refresh the firmware in the CPLD chip, the CPLD chip may be designated as a target component to be used in the management interface of the baseboard management controller, and a firmware image file for refreshing the firmware in the CPLD chip may be uploaded.

In some embodiments, after receiving the firmware image file uploaded by the technician through the management interface, the baseboard control manager may save the firmware image file to a designated storage location accessible to the FPR chip, so that when the FPR chip performs firmware refreshing, the firmware image file may be obtained from the designated storage location.

After the technician completes the specification of the target component and the uploading of the firmware image, the baseboard control manager may send a firmware refresh request to the FPR chip to request the FPR chip to refresh the firmware in the target component.

In some embodiments, the firmware refreshing request may further include file information of a firmware image file for refreshing the firmware in the target component, so that the FPR chip obtains the firmware image file for refreshing the firmware of the target component based on the file information, and refreshes the firmware of the target component according to the firmware image file. In particular, the file information includes, but is not limited to, information such as a storage address, a file name, a file size, a file format, and the like of the firmware image file. Based on the file information, the FPR chip can acquire a specified firmware image file from a specified storage address, and refresh the firmware in the target component according to the acquired firmware image file. By sending the storage address of the firmware file to the FPR chip, the firmware mirror image file does not need to be sent when the firmware refreshing request is sent, and the data transmission quantity is reduced.

In other embodiments, the file information may be preset in the FPR chip. Under the condition that the FPR chip receives the firmware refreshing request, a firmware image file is obtained according to preset file information. In these embodiments, the firmware refresh request may not need to include file information for the firmware image file. Thus, the data transmission amount is further reduced.

Step S22, power-down and power-up operations are sequentially executed on the server where the target component is located, so as to refresh the first firmware.

Specifically, the FPR chip may send a request to the CPLD chip, and the CPLD chip sequentially performs power-down and power-up operations on the server. And in the power-down and power-up processes of the server, the FPR chip completes refreshing of the first firmware. Specifically, the FPR chip may obtain a new firmware for refreshing the firmware in the target component from the firmware image file, and write the new firmware into the first storage area of the FLASH memory of the target component during the power-down and power-up processes of the server, so as to complete the refreshing of the first firmware.

Step S23, under the condition that the refreshing of the first firmware is completed, the value of the startup control identifier is set to be a first value, so that the baseboard management controller can execute startup operation on the server when monitoring that the value of the startup control identifier is the first value.

In some embodiments, the power-on control identifier may be used to characterize whether a power-on operation is performed on the server where the target component is located. The power-on control flag may have different values. Under the condition that the value of the starting control identifier is a first value, the starting operation of the server can be represented; in the case that the value of the power-on control identifier is the second value, it may indicate that the power-on operation is not performed on the server. The first value and the second value are different. For example, the first value may be 1 and the second value may be 0. After the FPR chip completes the refreshing of the first firmware, the value of the boot control identifier may be set to a first value, so as to indicate that the boot operation needs to be performed on the server where the target component is located.

In this embodiment, the boot control identifier is stored in the FPR chip. The FPR chip may store the boot control identification in a number of different storage ways. Two of these storage modes are described below as examples.

In some embodiments, the FPR chip may include an instruction register for storing a boot control identification. Setting the value of the startup control identifier as a first value includes:

and writing a first value into the instruction register to set the value of the startup control identifier as the first value.

In short, the FPR chip in these embodiments has one more instruction register for storing the boot control identifier, compared to the FPR chip in some technologies. The value in the instruction register is used for representing whether to execute the startup operation on the server where the target component is located. After the FPR chip completes the refresh of the first firmware, the value in the instruction register may be set to a first value to indicate that a boot operation needs to be performed on the server where the target component is located.

In other embodiments, the FPR chip may include a configuration file that allows the FPR chip to read and write. The power-on control identifier may be set in the configuration file. For example, assuming that the startup control identifier is represented by a character string ST, the configuration file may include at least the following:

ST＝X

wherein X represents the value of the startup control identifier. The FPR chip can modify this value. After the FPR chip completes the refresh of the first firmware, X may be modified to a first value to indicate that a boot operation needs to be performed on the server where the target component is located.

The above describes the case where the boot control flag is stored in the FPR chip. In other embodiments, the power-on control identification may also be stored off the FPR chip, such as in a configuration file off the FPR chip. The FPR chip has the authority of reading and writing the configuration file so as to modify the value of the startup control identifier.

It should be noted that the foregoing is merely an exemplary storage manner of the startup control identifier, and is not meant to limit the present application. One server may be capable of supporting one of the storage modes. For example, in the case where the FPR chip has an instruction register for storing the boot control identification, it may not be necessary to have a configuration file for storing the boot control identification. Of course, the FPR chip may also have an instruction register for storing the boot control identifier and a configuration file for storing the boot control identifier at the same time, which is not limited in the present application.

In some embodiments, the baseboard management controller may query the value of the power-on control identifier in a polling manner. Specifically, the baseboard management controller may query the numerical value stored in the instruction register once every preset time period, or query the value of the startup control identifier in the configuration file once every preset time period. And under the condition that the numerical value stored in the instruction register is queried to be a first value or the numerical value of the startup control identifier in the configuration file is queried to be the first value, executing startup operation on the server where the target component is located so as to enable the BIOS chip to resume operation.

In the above embodiment, the baseboard management controller queries the value of the startup control identifier in a polling manner, and after the value of the startup control identifier is modified to the first value, if the baseboard management controller reads the first value every time it polls, the startup operation may be repeatedly executed on the server. For example, suppose that the FPR chip modifies the value of the boot control flag to the first value at time 1. The baseboard management controller reads the first value in the first polling performed after the time 1, performs the startup operation on the server, reads the first value in the second polling performed after the time 1, further performs the startup operation on the server, and so on, and the baseboard management controller repeatedly performs the startup operation on the server.

To avoid this, in some embodiments, in a case where the baseboard management controller has completed reading the first value from the instruction register, the FPR chip may write a second value different from the first value in the instruction register to perform the zero clearing process on the value stored in the instruction register, or set the value of the startup control identifier to a second value different from the first value in the configuration file to perform the zero clearing process on the value of the startup control identifier. Therefore, the baseboard management controller can be prevented from continuously and repeatedly reading the first value from the instruction register or the configuration file, and further repeatedly executing the starting operation on the server.

Specifically, for the case where the boot control identifier is stored in the instruction register, the first value in the instruction register may be read and detected for the first time by using a function of the FPR chip itself. In short, the FPR chip may detect this action when the baseboard management controller reads the first value in the instruction register for the first time, and then modify the first value in the instruction register to the second value. Thus, when the baseboard management controller reads the value in the instruction register for the second time, the value in the instruction register is changed to the second value, and the baseboard management controller can not execute the starting operation on the server.

For the situation that the starting control identifier is stored in the configuration file, the characteristics that the BIOS chip does not operate when the server is powered off and the BIOS chip starts to operate when the server is powered on can be utilized to detect whether the server is powered on or not. In short, whether the server is started up is detected by detecting whether the BIOS chip is running or not. In some embodiments, considering that the cpu outputs a status identifier related to the running status of the bios chip, when the value of the status identifier is a target status value (e.g., 1), it indicates that the bios chip is in the running status, and when the value of the status identifier is another value (e.g., 0) other than the target status value, it indicates that the bios chip is in the non-running status. Therefore, whether the server is started up or not can be detected by detecting the value of the state identifier of the central processing unit. Specifically, when detecting whether the server is started up, the state identifier, which is sent by the central processing unit and is related to the running state of the basic input/output system chip, can be received; under the condition that the value of the first state identifier is a target state value, determining that the basic input/output system chip runs successfully; and under the condition that the basic input system chip successfully operates, determining that the starting-up of the server is completed. Therefore, after the completion of the startup of the server is detected, the startup control identifier of the configuration file is set to a second value, so that the baseboard management controller is prevented from repeatedly executing startup operation on the server.

Step S24, under the condition that the starting of the server is completed, refreshing the second firmware.

In some embodiments, it is contemplated that the various components do not necessarily operate properly after the server is powered on. Therefore, before the second firmware is refreshed, the FPR chip can detect whether components such as the baseboard management controller, the CPLD chip, the BIOS chip and the like are normally operated, and the second firmware is refreshed again under the condition that the components are normally operated. The detection of whether the BIOS chip is operating normally may refer to the description related to step S23, which is not repeated here. For the components of the baseboard management controller and the CPLD chip, the components can send an identification representing the running state to the FPR chip in normal operation, so that the FPR chip can determine whether the components run normally or not. In this way, the FPR chip can determine whether these components are operating properly.

In summary, in the technical solutions of some embodiments of the present application, when a firmware refresh request is received, a power-down operation and a power-up operation are sequentially performed on a server where a target component is located, so as to refresh a first firmware. After the first firmware refreshing is completed, the value of the startup control identifier is set to be a first value, so that the baseboard management controller can execute startup operation on the server when monitoring that the value of the startup control identifier is the first value. And refreshing the second firmware under the condition that the starting of the server is completed. The startup control identifier is set to indicate whether to execute startup operation, and the baseboard management controller determines whether to execute startup operation based on the startup control identifier, so that the whole firmware refreshing process can be automatically coherent without manual participation, and the operation of technicians can be simplified.

Referring to fig. 3, an interactive schematic diagram of a firmware refreshing method according to an embodiment of the application is shown. In fig. 3, the firmware refreshing method includes the following steps:

in step S31, the technician designates the target component requiring firmware refreshing and the firmware image file for firmware refreshing the target component through the management interface of the baseboard management controller.

In step S32, after the technician finishes the assignment of the target component and the uploading of the firmware image file, the baseboard management controller sends a firmware refreshing request to the FPR chip.

In step S33, the FPR chip sends a request to the CPLD chip to sequentially perform power-down and power-up operations on the server.

In step S34, the CPLD chip sequentially performs power-down and power-up operations on the server. In the process of performing a power-down and power-up operation on the server, the FPR chip performs step S35.

In step S35, the FPR chip refreshes the first firmware of the target component based on the firmware image file.

In step S36, after the first firmware refresh is completed, the FPR chip sets the value of the boot control flag to the first value.

Specifically, in some embodiments, the boot control flag may be set in an instruction register of the FPR chip. The FPR chip sets the value of the startup control identifier to a first value by setting the value in the instruction register to the first value.

In other embodiments, the boot control identifier may be provided in a configuration file of the FPR chip. The FPR updates the value of the startup control identifier in the configuration file to set the value of the startup control identifier to a first value.

In step S37, the baseboard management controller queries the value of the startup control identifier by means of polling.

Specifically, when the baseboard management controller queries that the value of the startup control identifier is the first value, step S38 is executed. And when the baseboard management controller inquires that the value of the startup control identifier is a second value different from the first value, continuing to execute the polling operation.

Step S38, the starting operation is sequentially executed on the server where the target component is located.

In step S39, the second firmware of the target component is refreshed when the FPR chip detects that the server is powered on.

Compared with some technologies, in the technical solution shown in fig. 3, a boot control identifier for indicating whether to execute a boot operation is added, and the FPR chip may modify the value of the identifier, and the baseboard management controller may poll the value of the identifier. In this way, under the condition that the first firmware of the target component is refreshed, the FPR chip can set the value of the boot control identifier to be a first value representing execution of boot operation, and when the baseboard management controller inquires that the value of the boot control identifier is the first value, the baseboard management controller executes the boot operation on the server where the target component is located, so that the FPR chip refreshes the second firmware of the target component after the server is booted. The whole firmware refreshing process can be automatically and continuously performed without manual participation, and the operation of technicians can be simplified.

Referring to fig. 4, a block diagram of a firmware refreshing apparatus according to an embodiment of the application is shown. In fig. 4, the firmware refreshing apparatus includes:

the system comprises a request receiving module, a request updating module and a processing module, wherein the request receiving module is used for receiving a firmware updating request, the firmware updating request comprises a target component to be subjected to firmware updating, and the firmware in the target component comprises first firmware for direct execution and second firmware for backing up the first firmware;

the device comprises an identifier setting module, a power-on control module and a power-on control module, wherein the identifier setting module is used for setting the value of the power-on control identifier to be a first value under the condition that refreshing of the first firmware is completed, so that when the substrate management controller monitors that the value of the power-on control identifier is the first value, the power-on operation is executed on the server;

In some embodiments, the identification setting module includes an instruction register for storing a boot control identification; the identification setting module is specifically configured to write a first value into the instruction register, so as to set the value of the startup control identification to the first value.

In some embodiments, in the case where the baseboard management controller has completed reading the first value from the instruction register, the identifier setting module is specifically configured to write a second value different from the first value in the instruction register, so as to perform a zero clearing process on the value stored in the instruction register.

In some embodiments, the startup control identifier is set in a configuration file allowing the identifier setting module to read and write; the identifier setting module is specifically configured to set a value of the startup control identifier to a first value in the configuration file.

In some embodiments, when the startup of the server is completed, the identifier setting module is specifically configured to set, in the configuration file, a value of the startup control identifier to a second value different from the first value, so as to zero-clearing the value of the startup control identifier.

In some embodiments, the server includes a bios chip, and the identifier setting module detects whether the server is powered on according to the following method:

receiving a state identifier which is sent by a central processing unit and is related to the running state of a basic input/output system chip;

under the condition that the value of the state identifier is a target state value, the successful operation of the basic input/output system chip is determined;

and under the condition that the basic input system chip successfully operates, determining that the starting-up of the server is completed.

In some embodiments, the firmware refresh request further includes file information of a firmware image file for refreshing firmware of the target component; the first refreshing module and the second refreshing module are specifically configured to obtain a firmware image file for refreshing the firmware of the target component based on the file information, and refresh the firmware of the target component according to the firmware image file.

Referring to fig. 5, a schematic diagram of an electronic device according to an embodiment of the application is provided. The electronic device comprises a processor and a memory for storing a computer program which, when executed by the processor, implements the firmware refresh method described above.

The processor may be a central processing unit (Central Processing Unit, CPU). The processor may also be any other general purpose processor, digital signal processor (Digital Signal Processor, DSP), application specific integrated circuit (Application Specific Integrated Circuit, ASIC), field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof.

The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions/modules, corresponding to the methods in embodiments of the present application. The processor executes various functional applications of the processor and data processing, i.e., implements the methods of the method embodiments described above, by running non-transitory software programs, instructions, and modules stored in memory.

The memory may include a memory program area and a memory data area, wherein the memory program area may store an operating system, at least one application program required for a function; the storage data area may store data created by the processor, etc. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some implementations, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

An embodiment of the present application also provides a computer readable storage medium storing a computer program, where the computer program is executed by a processor to implement the firmware refreshing method described above.

The application also provides a computer program product, which comprises a computer program, wherein the computer program realizes the firmware refreshing method when being executed by a processor.

Although the method of practicing the application has been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the application, and such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A firmware refreshing method, the method comprising:

2. The method of claim 1, wherein the method is applied to a platform firmware elastomer that protects and restores firmware, the platform firmware elastomer including an instruction register for storing the boot control identification;

3. The method of claim 2, wherein in the event that the baseboard management controller has completed reading the first value from the instruction register, the method further comprises:

4. The method of claim 1, wherein the method is applied to a platform firmware elastomer for protecting and recovering firmware, and the boot control identifier is set in a configuration file allowing the platform firmware elastomer to read and write;

5. The method of claim 4, wherein in the event that the server power up is complete, the method further comprises:

6. The method of claim 1, wherein the server includes a bios chip that detects whether the server is powered up according to the following method:

7. The method of claim 1, wherein the firmware refresh request further includes file information of a firmware image file for refreshing firmware of the target component;

refreshing the firmware of the target component, including:

8. A firmware refreshing apparatus, the apparatus comprising:

9. A computer readable storage medium for storing a computer program which, when executed by a processor, implements the method of any one of claims 1 to 7.

10. An electronic device comprising a processor and a memory for storing a computer program which, when executed by the processor, implements the method of any of claims 1 to 7.