CN115421762A

CN115421762A - BMC (baseboard management controller) firmware upgrading method, device, equipment and medium

Info

Publication number: CN115421762A
Application number: CN202211207632.6A
Authority: CN
Inventors: 高明; 刘宝阳
Original assignee: Shandong Yunhai Guochuang Cloud Computing Equipment Industry Innovation Center Co Ltd
Current assignee: Shandong Yunhai Guochuang Cloud Computing Equipment Industry Innovation Center Co Ltd
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2022-12-02

Abstract

The application discloses a BMC firmware upgrading method, device, equipment and medium, and relates to the technical field of computers. Creating a patch partition in the BMC firmware image; creating a target directory in a patch partition and mounting an Overlayfs file system; acquiring a patch file; wherein, the patch file comprises a plurality of executable programs; uploading each executable program to a target directory; and restarting a target executable program in each executable program to realize upgrading of the BMC firmware. Therefore, according to the scheme, the patch partition and the target directory are created and used for storing the hot patch file of the BMC, the target directory is mounted with the Overlayfs file system, the executable program in the read-only partition is replaced, the hot patch function is further achieved, the BMC firmware is enabled to be light and fast in upgrading, problem repair and function updating can be conducted without restarting the BMC, and upgrading efficiency is improved.

Description

BMC (baseboard management controller) firmware upgrading method, device, equipment and medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a medium for upgrading a BMC firmware.

Background

A Baseboard Management Controller (Baseboard Management Controller) is a Controller that performs remote Management of a server, and can perform operations such as firmware upgrade and checking of a machine device and information thereof on the machine in a state where the machine is not powered on. Current server products implement problem repair and function upgrade through Firmware (Firmware) upgrade of a Baseboard Management Controller (BMC). However, the existing BMC firmware upgrading process is relatively time-consuming, the firmware content in the flash must be completely refreshed, and the BMC needs to be restarted to enable the new firmware version to take effect, which is not light and fast enough.

In view of the above problems, a problem to be solved by those skilled in the art is how to implement BMC firmware upgrade in a light weight and fast manner.

Disclosure of Invention

The application aims to provide a BMC firmware upgrading method, device, equipment and medium, so that upgrading of BMC firmware is achieved in a light and fast mode.

In order to solve the above technical problem, the present application provides a BMC firmware upgrading method, including:

creating a patch partition in a BMC firmware image;

creating a target directory in the patch partition and mounting an Overlayfs file system;

acquiring a patch file; wherein the patch file comprises a plurality of executable programs;

uploading each executable program to the target directory;

and restarting a target executable program in the executable programs to realize BMC firmware upgrading.

Preferably, the creating a patch partition in the BMC firmware image includes:

creating the patch partition according to the mkfs.jffs2-d/patch-o patch.img command by using the mkfs.jffs2 tool.

Preferably, the obtaining the patch file includes:

acquiring the patch file through a web service managed by BMC firmware;

and uploading the patch file to a/var path.

Preferably, before the uploading each executable program to the target directory, the method further includes:

judging whether the patch file supports hot patching or not according to the name of the patch file and configuration options in a hot patching verification configuration file;

if yes, entering the step of uploading each executable program to the target directory;

if not, the process is ended.

Preferably, the restarting the target executable program in each of the executable programs includes:

respectively judging whether each executable program needs to reside;

if yes, the resident executable program is taken as the target executable program to be restarted.

Preferably, if it is determined that the executable program does not need to be resident, further comprising:

and actively running the executable program which does not need to be resident so as to realize the upgrading of the executable program.

Preferably, the method further comprises the following steps:

and checking the hot patching result of the patch file through the hot patching result checking configuration file.

In order to solve the above technical problem, the present application further provides a BMC firmware upgrading apparatus, including:

the creating module is used for creating a patch partition in the BMC firmware image;

the mounting module is used for creating a target directory in the patch partition and mounting an Overlayfs file system;

the obtaining module is used for obtaining the patch file; wherein the patch file comprises a plurality of executable programs;

the uploading module is used for uploading each executable program to the target directory;

and the restarting module is used for restarting the target executable program in each executable program so as to realize upgrading of the BMC firmware.

Preferably, the creating module creates the patch partition according to an mkfs.jffss 2-d/patch-o patch.img command, specifically using an mkfs.jffss 2 tool.

Preferably, the obtaining module includes:

the patch file acquisition module is used for acquiring the patch file through a web service managed by BMC firmware;

and the patch file uploading module is used for uploading the patch file to the/var path.

Preferably, the method further comprises the following steps:

a first determining module, configured to determine whether the patch file supports a hot patch according to a name of the patch file and a configuration option in a hot patch verification configuration file before each executable program is uploaded to the target directory; if yes, triggering the uploading module; if not, the process is ended.

Preferably, the restart module comprises:

the second judgment module is used for respectively judging whether each executable program needs to reside;

if yes, triggering a target executable program to restart the module;

and the target executable program restarting module is used for restarting the resident executable program as the target executable program.

Preferably, the method further comprises the following steps:

and the executable program running module is used for actively running the executable program which does not need to be resident when the executable program does not need to be resident so as to realize the upgrading of the executable program.

Preferably, the method further comprises the following steps:

and the checking module is used for checking the hot patching result of the patch file through the hot patching result checking configuration file.

In order to solve the above technical problem, the present application further provides a BMC firmware upgrading device, including:

a memory for storing a computer program;

and the processor is used for realizing the steps of the BMC firmware upgrading method when executing the computer program.

In order to solve the above technical problem, the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the BMC firmware upgrading method are implemented.

According to the BMC firmware upgrading method, a patch partition is established in a BMC firmware image; creating a target directory in a patch partition and mounting an Overlayfs file system; acquiring a patch file; wherein, the patch file comprises a plurality of executable programs; uploading each executable program to a target directory; and restarting a target executable program in each executable program to realize upgrading of the BMC firmware. Therefore, according to the scheme, the patch partition and the target directory are created and used for storing the hot patch file of the BMC, the target directory is mounted with the Overlayfs file system, the executable program in the read-only partition is replaced, the hot patch function is further achieved, the BMC firmware is enabled to be light and fast in upgrading, problem repair and function updating can be conducted without restarting the BMC, and upgrading efficiency is improved.

In addition, the embodiment of the application also provides a BMC firmware upgrading device, equipment and medium, and the effect is the same as the above.

Drawings

In order to more clearly illustrate the embodiments of the present application, the drawings needed for the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained by those skilled in the art without inventive effort.

Fig. 1 is a flowchart of a BMC firmware upgrading method according to an embodiment of the present disclosure;

fig. 2 is a schematic diagram of a BMC firmware partitioning condition according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of an Overlayfs file system according to an embodiment of the present application;

fig. 4 is a schematic diagram of a BMC firmware upgrading apparatus according to an embodiment of the present disclosure;

fig. 5 is a schematic diagram of a BMC firmware upgrade device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without any creative effort belong to the protection scope of the present application.

The core of the application is to provide a BMC firmware upgrading method, device, equipment and medium.

In order that those skilled in the art will better understand the disclosure, the following detailed description will be given with reference to the accompanying drawings.

The current server products realize problem repair and function upgrade through firmware upgrade of the BMC. However, the traditional firmware upgrading process is relatively time-consuming, the firmware content in the flash must be completely refreshed, and the BMC needs to be restarted to enable the new firmware version to take effect, which is not light and fast enough. Hot patching of firmware is a perfect solution to this problem. The hot patch is also called patch, which means that some codes capable of repairing software bugs are a way to repair the version defects of the product software quickly and at low cost. The function upgrading and problem repairing of the BMC firmware with high speed and light weight can be realized through the hot patch. In addition, the hot patch of the firmware also provides a faster and more convenient method for research and development engineers of the BMC, and the specific executable program in the BMC firmware is updated, so that the research and development efficiency can be greatly improved. Therefore, the embodiment of the application provides a BMC firmware upgrading method based on the hot patch. Fig. 1 is a flowchart of a BMC firmware upgrading method according to an embodiment of the present disclosure. As shown in fig. 1, the BMC firmware upgrading method includes:

s10: a patch partition is created in the BMC firmware image.

It is understood that there are multiple partitions in the BMC firmware image. Fig. 2 is a schematic diagram of a BMC firmware partitioning condition according to an embodiment of the present disclosure. As shown in fig. 2, the BMC firmware partition includes an uboot partition, a kernel partition, a Log partition, a conf partition, a root partition, a media partition, and the like. Wherein the uboot partition is used for storing binary uboot; the kernel partition is used for storing compressed files of the kernel; the Log partition adopts a 2 nd Version (JFFS 2, journal Flash System Version 2) File System of a Flash memory journal type File System, and is mainly used for storing journals; the root partition adopts a Squashfs file system and is mainly used for storing a library function, a file system and most executable programs; the media partition employs the JFFS2 file system for media service related. In a specific implementation, in order to implement hot patch upgrade of the BMC firmware, a patch partition is first created in the BMC firmware image to store a hot patch file required by the firmware upgrade.

It is noted that the JFFS2 file system functions to manage a journaled file system implemented on a Memory Technology Device (MTD). It is commonly used in embedded systems, using a very wide read/write file system on flash memory. The Squashfs file system is a set of compressed read-only file system used based on a Linux kernel, and can compress the whole file system or a single directory together and store the compressed file system or the single directory in a certain device, a certain partition or a common file.

It should be noted that the Squashfs file system is a read-only file system, and has the main advantages of compressing the image file, reducing the occupation of the storage space, and thus, the content in the partition cannot be modified. The JFFS2 file system is a readable and writable file system and does not compress the contents of the partition. Therefore, in the specific creation process of the patch partition, in order to realize the replacement of the executable program in the BMC firmware upgrade process, a readable and writable JFFS2 file system should be used to create the patch partition for storing the hot patch file required by the firmware upgrade, so as to facilitate the subsequent BMC firmware upgrade. The creating process of the patch partition in this embodiment is not limited, and is determined according to a specific implementation situation.

S11: create a target directory in the patch partition and mount the Overlayfs file system.

Further, a target directory is created in the patch partition and the Overlayfs file system is mounted for the directory. The Overlayfs file system is a Linux-oriented file system service, is a stacked file system, depends on and is established on other file systems, does not directly participate in the division of a disk space structure, only carries out 'merging' on different directories in the original bottom file system, and then presents the merged directories to a user.

Fig. 3 is a schematic diagram of an Overlayfs file system according to an embodiment of the present application. As shown in FIG. 3, the Overlayfs file system mainly contains three roles: lowerdir, upperdir, and merged. Wherein, lowerdir is a read-only layer, and the user can not modify the file of the layer; the upperdir is a readable and writable layer, and a user can modify the file of the layer; and merge is a merge layer, which can merge and display the files of the lowerdir layer and the upperdir layer. When the two directories of the upperdir layer and the lowerdir layer have the same-name file, the file of the lowerdir layer is hidden, and the user can only see the file from the upperdir layer.

It can be understood that the root partition of the BMC firmware image contains most of executable programs in the BMC firmware, but the root partition uses a Squashfs file system, and cannot achieve the function of hot patching by replacing the programs therein. Therefore, a patch partition is created using the readable and writable JFFS2 file system, and a target directory is created in the partition for use by the Overlayfs file system. Specifically, the overlay file system is mounted through the following Linux command: mount-t overlay overlay-o lowerdir =/usr, upperdir =/patch/upper, and workdir =/patch/work/usr.

It should be noted that in the implementation, two directories, namely, a "patch/upper directory" and a "patch/work directory" may be created in a patch partition, where an original executable program to be updated or replaced is mainly stored in a "usr directory" corresponding to lowerdir in fig. 3; the updated new executable file with the same name is mainly stored in the/patch/upper directory corresponding to the upperdir, so that the/patch/upper directory is the target directory; the main function of the/patch/work directory corresponding to the workdir is that an Overlayfs file system is used for storing temporary files.

S12: and obtaining a patch file, wherein the patch file comprises a plurality of executable programs.

After creating the patch partition and mounting the Overlayfs file system for the directory in the patch partition, the patch file is further obtained. It will be appreciated that the patch file contains a plurality of upgraded executables such as IPMIMain, libuss.

In this embodiment, the obtaining manner of the patch file is not limited, and is determined according to a specific implementation situation.

S13: and uploading each executable program to the target directory.

S14: and restarting a target executable program in each executable program to realize upgrading of the BMC firmware.

Furthermore, each executable program of the patch file is uploaded to the target directory, and the target executable program in each executable program is restarted, so that upgrading of the BMC firmware is achieved. It should be noted that, in the patch file, part of each executable program does not need to replace the original corresponding executable program immediately, and the user can select the starting time to complete the upgrade. Therefore, the executable program for performing restart replacement in this embodiment is a target executable program in all executable programs, and the target executable program generally refers to an executable program that needs to be continuously run and must be immediately upgraded; the target executable program in this embodiment is not limited, and is determined according to specific implementation situations.

In this embodiment, a patch partition is created in the BMC firmware image; creating a target directory in a patch partition and mounting an Overlayfs file system; acquiring a patch file; wherein, the patch file comprises a plurality of executable programs; uploading each executable program to a target directory; and restarting a target executable program in each executable program to realize upgrading of the BMC firmware. Therefore, according to the scheme, the patch partition and the target directory are created and used for storing the hot patch file of the BMC, the target directory is mounted with the Overlayfs file system, the executable program in the read-only partition is replaced, the hot patch function is further achieved, the BMC firmware is enabled to be light and fast in upgrading, problem repair and function updating can be conducted without restarting the BMC, and upgrading efficiency is improved.

On the basis of the foregoing embodiment, as a preferred embodiment, creating a patch partition in the BMC firmware image includes:

creating a patch partition according to the mkfs.jffs2-d/patch-o patch.img command using the mkfs.jffs2 tool.

In a specific implementation, creation of a patch partition in a BMC firmware image is specifically realized by an mkfs.jffs2 tool.

JFFS. JFFSs 2 is a common tool for making JFFS2 file system partition images. Based on the mkfs.jffss 2 tool, the creation of a patch partition in the BMC firmware image is realized through the mkfs.jffss 2-d/patch-o patch.img command, so that the executable program which needs to be replaced and updated and the subsequent BMC firmware upgrade are stored conveniently.

On the basis of the above embodiment, as a preferred embodiment, the obtaining the patch file includes:

acquiring a patch file through a web service managed by BMC firmware;

and uploading the patch file to the/var path.

In a specific implementation, to obtain a patch file for updating the BMC firmware, as a preferred embodiment, the patch file is specifically obtained through a web service managed by the BMC firmware. The patch file required by upgrading can be acquired very quickly through the web service managed by the BMC firmware.

In addition, the patch file is uploaded into the/var path. The/var path is a common directory for storing temporary files, and the patch files can be cached through the/var path, so that executable programs in the patch files can be uploaded to a target directory on the basis of the/var path in the subsequent process.

As a preferred embodiment, before uploading each executable program to the target directory, in order to determine that the obtained patch file can support hot patching, the method further includes:

judging whether the patch file supports hot patching or not according to the name of the patch file and configuration options in the hot patching verification configuration file;

if yes, entering a step of uploading each executable program to a target directory;

if not, the process is ended.

In specific implementation, whether the patch file supports hot patching is judged according to the name of the patch file and configuration options in the hot patching verification configuration file. Wherein, the hot patch check configuration file comprises the related information of each executable program; specifically, in the hot patch check configuration file, compName represents the name of the executable program, supportportPatch represents whether patching is supported, and demamon represents whether the executable program is resident. When the patch file supports the hot patch according to the name of the patch file and the configuration options in the hot patch verification configuration file, uploading each executable program to a target directory, and specifically moving the patch file under the/var path to the target directory, namely, under the/patch/upper directory. And if the patch file does not support the hot patch, ending the process.

In the embodiment, whether the patch file supports the hot patch is judged according to the name of the patch file and the configuration options in the hot patch check configuration file; if yes, uploading each executable program to a target directory; if not, ending, and realizing the judgment of whether the patch file supports the hot patch.

On the basis of the above embodiment, as a preferred embodiment, the restarting the target executable program in the executable programs includes:

respectively judging whether each executable program needs to reside;

and if so, restarting the resident executable program serving as the target executable program.

Further, after determining whether or not the hot patch is supported, when restarting the target executable program in each executable program, it is necessary to determine whether or not each executable program needs to be resident. Resident is the executable program needs to run continuously. The resident process may execute, for example, IPMIMain. And when the executable program needs to be resident, the executable program is the target executable program and is restarted, so that the patch is effective.

On the basis of the above embodiments, as a preferred embodiment, if it is determined that the executable program does not need to be resident, the method further includes:

the active running does not need resident executable program to realize the upgrade of the executable program.

In a specific implementation, when it is determined that the executable program does not need to be resident, for example, the executable program cpldflash, the user is required to actively run the executable program which does not need to be resident, and the patch is enabled to take effect by writing the version number of the user into the configuration file during the running process.

In this embodiment, whether each executable program needs to be resident is respectively determined, the resident executable program is used as a target executable program to restart, the resident executable program is not needed to be actively run, and finally, the executable program is upgraded.

On the basis of the above embodiment, as a preferred embodiment, the method further includes:

It can be understood that, during the restart of the resident executable program as the target executable program, the version number of the current service process is written into the configuration file by means of writing the configuration file. For example, the version number written in the initial version of IPMIMain is 1.2, when the patch file of IPMIMain is run, the hot patch result check configuration file is modified, and a new version number 1.3 is written in the file, so that the result of patch execution can be known by checking the record in the configuration. In the hot patch result check configuration file, originVersion represents the original version, and patchVersion represents the version of the patch.

Further, for an executable program which is not a resident type, such as the executable program cpldflash, the executable program can be actively run once, during the running process, the version number of the executable program is written into the configuration file, for example, the original version number of the cpldflash is 3.1, and if the patch is not patched, the patch version number in the configuration file is NA; if the patch is patched, the patch version number in the configuration file is changed to a new version number 3.2. Therefore, in order to realize the hot-patch result check, it is possible to select the hot-patch result of checking the patch file by the hot-patch result check configuration file.

In the foregoing embodiment, a detailed description is given of the BMC firmware upgrading method, and the present application also provides an embodiment corresponding to the BMC firmware upgrading apparatus.

Fig. 4 is a schematic diagram of a BMC firmware upgrading device according to an embodiment of the present disclosure. As shown in fig. 4, the BMC firmware upgrading apparatus includes:

a creating module 10, configured to create a patch partition in the BMC firmware image.

And the mounting module 11 is configured to create a target directory in the patch partition and mount the Overlayfs file system.

An obtaining module 12, configured to obtain a patch file; wherein the patch file includes a plurality of executable programs.

And an uploading module 13, configured to upload each executable program to the target directory.

And the restarting module 14 is used for restarting a target executable program in the executable programs so as to realize the upgrading of the BMC firmware.

As a preferred embodiment, the creation module creates the patch partition according to the mkfs.jffss 2-d/patch-o patch.img command, in particular using the mkfs.jffss 2 tool.

As a preferred embodiment, the obtaining module includes:

the patch file acquisition module is used for acquiring a patch file through a web service managed by BMC firmware;

As a preferred embodiment, the method further comprises the following steps:

the first judgment module is used for judging whether the patch file supports hot patching or not according to the name of the patch file and the configuration options in the hot patching check configuration file before each executable program is uploaded to the target directory; if yes, triggering an uploading module; if not, ending.

As a preferred embodiment, the restart module includes:

if yes, triggering a target executable program to restart the module;

As a preferred embodiment, further comprising:

As a preferred embodiment, the method further comprises the following steps:

In this embodiment, the BMC firmware upgrading apparatus includes a creation module, a mount module, an acquisition module, an upload module, and a restart module. Creating a patch partition in a BMC firmware image; creating a target directory in a patch partition and mounting an Overlayfs file system; acquiring a patch file; wherein, the patch file comprises a plurality of executable programs; uploading each executable program to a target directory; and restarting a target executable program in each executable program to realize upgrading of the BMC firmware. Therefore, according to the scheme, the patch partition and the target directory are created and used for storing the hot patch file of the BMC, the target directory is mounted with the Overlayfs file system, the executable program in the read-only partition is replaced, the hot patch function is further achieved, the BMC firmware is enabled to be light and fast in upgrading, problem repair and function updating can be conducted without restarting the BMC, and upgrading efficiency is improved.

Fig. 5 is a schematic diagram of a BMC firmware upgrading device according to an embodiment of the present application. As shown in fig. 5, the BMC firmware upgrade apparatus includes:

a memory 20 for storing a computer program.

A processor 21, configured to execute the computer program to implement the steps of the BMC firmware upgrade method as mentioned in the above embodiments.

The BMC firmware upgrading device provided in this embodiment may include, but is not limited to, a smart phone, a tablet computer, a notebook computer, or a desktop computer.

The processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and the like. The Processor 21 may be implemented in at least one hardware form of a Digital Signal Processor (DSP), a Field-Programmable Gate Array (FPGA), and a Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor, where the main processor is a processor for Processing data in a wake state, and is also called a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 21 may be integrated with a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content required to be displayed on the display screen. In some embodiments, the processor 21 may further include an Artificial Intelligence (AI) processor for processing computational operations related to machine learning.

The memory 20 may include one or more computer-readable storage media, which may be non-transitory. Memory 20 may also include high speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In this embodiment, the memory 20 is at least used for storing the following computer program 201, wherein after being loaded and executed by the processor 21, the computer program can implement the relevant steps of the BMC firmware upgrade method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202, data 203, and the like, and the storage manner may be a transient storage manner or a permanent storage manner. Operating system 202 may include, among others, windows, unix, linux, and the like. Data 203 may include, but is not limited to, data involved in a BMC firmware upgrade method.

In some embodiments, the BMC firmware upgrade device may further include a display 22, an input/output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

Those skilled in the art will appreciate that the architecture shown in FIG. 5 does not constitute a limitation of a BMC firmware upgrade device and may include more or fewer components than those shown.

In this embodiment, the BMC firmware upgrade device includes a memory and a processor. The memory is used for storing a computer program; the processor, when executing the computer program, implements the steps of the BMC firmware upgrade method as mentioned in the above embodiments. Creating a patch partition in the BMC firmware image; creating a target directory in a patch partition and mounting an Overlayfs file system; acquiring a patch file; wherein, the patch file comprises a plurality of executable programs; uploading each executable program to a target directory; and restarting a target executable program in each executable program to realize upgrading of the BMC firmware. Therefore, according to the scheme, the patch partition and the target directory are created and used for storing the hot patch file of the BMC, the target directory is mounted with the Overlayfs file system, the executable program in the read-only partition is replaced, the hot patch function is further achieved, the BMC firmware is enabled to be light and fast in upgrading, problem repair and function updating can be conducted without restarting the BMC, and upgrading efficiency is improved.

Finally, the application also provides a corresponding embodiment of the computer readable storage medium. The computer-readable storage medium has stored thereon a computer program which, when being executed by a processor, carries out the steps as set forth in the above-mentioned method embodiments.

It is to be understood that if the method in the above embodiments is implemented in the form of software functional units and sold or used as a stand-alone product, it can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application, which are essential or part of the prior art, or all or part of the technical solutions may be embodied in the form of a software product, which is stored in a storage medium and executes all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, an optical disk, or other various media capable of storing program codes.

In this embodiment, a computer program is stored on a computer-readable storage medium, and when executed by a processor, the computer program implements the steps described in the above method embodiments. Creating a patch partition in a BMC firmware image; creating a target directory in a patch partition and mounting an Overlayfs file system; acquiring a patch file; wherein, the patch file comprises a plurality of executable programs; uploading each executable program to a target directory; and restarting a target executable program in each executable program to realize upgrading of the BMC firmware. Therefore, according to the scheme, the patch partition and the target directory are created and used for storing the hot patch file of the BMC, the target directory is mounted with the Overlayfs file system, the executable program in the read-only partition is replaced, the hot patch function is further achieved, the BMC firmware is enabled to be light and fast in upgrading, problem repair and function updating can be conducted without restarting the BMC, and upgrading efficiency is improved.

The method, the device, the equipment and the medium for upgrading the BMC firmware provided by the present application are described in detail above. The embodiments are described in a progressive mode in the specification, the emphasis of each embodiment is on the difference from the other embodiments, and the same and similar parts among the embodiments can be referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description. It should be noted that, for those skilled in the art, it is possible to make several improvements and modifications to the present application without departing from the principle of the present application, and such improvements and modifications also fall within the scope of the claims of the present application.

It is further noted that, in the present specification, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.

Claims

1. A BMC firmware upgrade method is characterized by comprising the following steps:

creating a patch partition in a BMC firmware image;

uploading each executable program to the target directory;

2. The BMC firmware upgrade method of claim 1, wherein the creating a patch partition in the BMC firmware image comprises:

3. The BMC firmware upgrade method of claim 1, wherein the obtaining the patch file comprises:

acquiring the patch file through a web service managed by BMC firmware;

and uploading the patch file to a/var path.

4. The BMC firmware upgrade method of claim 1, further comprising, before said uploading each of said executable programs into said target directory:

if not, the process is ended.

5. The BMC firmware upgrade method of claim 4, wherein the restarting a target executable program of the executable programs comprises:

respectively judging whether each executable program needs to reside;

6. The BMC firmware upgrade method of claim 5, wherein if it is determined that the executable program does not need to be resident, further comprising:

7. The BMC firmware upgrade method of claim 5 or 6, further comprising:

8. A BMC firmware upgrade apparatus, comprising:

9. A BMC firmware upgrade device, comprising:

a memory for storing a computer program;

a processor for implementing the steps of the BMC firmware upgrade method as claimed in any one of claims 1 to 7 when said computer program is executed.

10. A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor, carries out the steps of the BMC firmware upgrade method according to any one of claims 1 to 7.