Baseboard Management Controller Firmware Update

Abstract

A baseboard management controller (BMC) may include a processor, a non-volatile memory, and a volatile memory. The non-volatile memory includes firmware classified into a plurality of independently updateable service modules. Each of the independently updateable service modules is stored on a read-write partition of the non-volatile memory and includes at least one of an application, a library, and a driver. The BMC includes an update agent that performs an update process. During the update process, a BMC update package is stored in the volatile memory, the BMC update package including an update service module for updating an existing service module stored in one of the plurality of RW partitions. The existing service module stored in the RW partition is replaced with the updated service module.

Description

Technical Field

[0001] The present disclosure relates generally to baseboard management controller (BMC) technology, and more particularly to firmware updates for a BMC. Background Art

[0002] Data centers are used around the world to provide large amounts of processing and storage capacity. Data centers typically include multiple server racks, sometimes referred to as "blades." Each of these blades includes one or more processors and memory. A baseboard management controller (BMC) is typically an embedded control device that serves as an interface between system management software and platform hardware. The BMC monitors server operating parameters such as temperature, cooling fan speed, power status, operating system status, etc. The BMC interfaces with other blade components (including hardware and software components, such as the chassis management interface) using the Intelligent Platform Management Interface (IPMI).

[0003] The BMC's firmware includes a boot loader, kernel, configuration data, and root file system stored on partitions in the BMC's flash drive (e.g., a serial peripheral interface (SPI) flash drive). These partitions together constitute the BMC binary ROM image. The BMC's firmware may need to be updated from time to time to address issues related to various functions of the BMC. When updating the BMC's firmware, the firmware is treated as a binary blob, and the entire BMC binary ROM image is written to the BMC's flash memory during the update. Summary of the Invention

[0004] The following is a simplified summary to provide a basic understanding of some aspects described herein. This summary is not an extensive overview of the claimed subject matter. It is not intended to identify key or critical elements of the claimed subject matter, nor is it intended to delineate its scope. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0005] According to one embodiment of the present disclosure, a system includes a baseboard management controller (BMC). The BMC may include a processor and a memory. The memory may include a non-volatile memory and a volatile memory. The non-volatile memory may include firmware classified into a plurality of independently updateable service modules, each of the independently updateable storage modules being stored on a read-write (RW) partition of the non-volatile memory. Each of the independently updateable service modules may include at least one of an application, a library, and a driver. The memory may also include executable code that, when executed at the processor, is configured to perform a firmware update. The firmware update may include: receiving a BMC update package, the BMC update package being used to update an existing service module stored in one of a plurality of RW partitions, wherein the BMC update package includes an updated service module; storing the BMC update package in the volatile memory; and replacing the existing service module stored in the RW partition of the non-volatile memory with the updated service module.

[0006] According to another embodiment of the present invention, a method for updating BMC firmware includes: receiving a BMC update package, the BMC update package including an update service module for updating an existing service module of the BMC, the service module being stored in one of multiple read-write (RW) partitions of the BMC's non-volatile memory, each RW partition including an independently updateable service module, wherein each independently updateable service module includes at least one of an application, a library, and a driver; storing the BMC update package in the BMC's volatile memory; replacing the existing service module stored in the RW partition of the non-volatile memory with the update service module; and restarting the BMC's service associated with the update service module.

[0007] According to another embodiment of the present invention, a method for transferring a file to a baseboard management controller (BMC) includes: receiving a command from a deployment agent that instructs the BMC to enter a transfer mode; identifying a partition of a volatile memory of the BMC and mounting the partition of the volatile memory to a host computing device connected to the BMC via a memory interface as a virtual memory drive; storing the file in the volatile memory by a write operation to the virtual memory drive, and transferring the file from the host computing device to the BMC; and unmounting the partition of the volatile memory from the host computing device. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0009] Figure 1 is a schematic diagram of a computing system for updating firmware of a BMC according to an example embodiment of the present disclosure.

[0010] Figure 2 A flow chart depicting a method for transferring data from a host computing device to a BMC according to an example embodiment of the present disclosure is illustrated.

[0011] Figure 3 A flowchart depicting a method for updating firmware of a BMC according to an example embodiment of the present disclosure is illustrated.

[0012] Figure 4 A flowchart depicting a method for updating firmware of a BMC according to an example embodiment of the present disclosure is illustrated.

[0013] Figure 5 An example computing system suitable for implementing one or more embodiments of the subject matter described herein is shown. DETAILED DESCRIPTION

[0014] In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, and in which are shown by way of illustration of specific embodiments. These embodiments are described in sufficient detail to enable those skilled in the art to practice the technology, and it is understood that other embodiments may be utilized and that structural, logical, and electrical changes may be made without departing from the spirit and scope of the present disclosure. Therefore, the following detailed description should not be understood in a limiting sense, and the scope is limited only by the appended claims and their equivalents. The same reference numerals in the figures refer to the same components, which should be apparent from the context of use.

[0015] Various embodiments of the present disclosure describe techniques for updating the firmware of a BMC and transferring data between the BMC and a host computing device. This subject matter describes a service-based BMC update in which the firmware of the BMC is divided into individually updateable service modules, thereby allowing the BMC to be updated without having to rewrite the entire BMC blob image. For purposes of explanation and not limitation, a service module is a source of services provided by the BMC and may include individual BMC services or applications (e.g., a fan management service / application), drivers, and / or libraries associated with the individual services or applications.

[0016] As mentioned above, the BMC's firmware includes a boot loader, a kernel, configuration data, and a root file system. The root file system is stored in a read-only partition of the BMC's non-volatile memory (e.g., an SPI flash drive). The BMC's root file system includes multiple executable applications and their libraries. When the BMC's firmware is viewed as a monolithic binary blob, updates required by a specific service provided by the firmware require an update of the entire firmware. For example, an update to the configuration of the BMC firmware requires an update to the entire BMC firmware image, including each application / service in the root file system's applications / services.

[0017] Furthermore, updating the entire BMC firmware requires a complete BMC reboot / restart. This can create availability issues. For example, while the BMC is reset, critical BMC functions are unavailable for fabric management. Therefore, if the network fabric to which the BMC is connected is monitoring BMC health, and the BMC becomes unavailable due to an update or reset, the network fabric may determine that the BMC is unavailable and may place the hardware in an unhealthy state, further impacting availability.

[0018] In one aspect of the present subject matter, the availability of the BMC is increased during BMC updates by partitioning the BMC's non-volatile memory into multiple read-write (RW) partitions that include independently updateable service modules. For example, the services provided by the BMC's root file system can be categorized into separate service modules, each stored on a different RW partition. Different service modules can each include a separate application, a grouping of applications, a library of applications, an application and its library, and the like. Having multiple RW partitions for different service modules allows the services provided by the BMC to be updated independently. Therefore, a full restart of the BMC is not required, and system availability is increased.

[0019] In another aspect of the present subject matter, BMC availability can be increased by providing a high-bandwidth protocol and a high-bandwidth interface from a host computing device to the BMC for updating BMC services. To this end, the BMC can mount a portion of its own volatile memory onto the host computing device as a virtual memory drive to transfer data at the native speed of the host computing device's memory drive, thereby allowing the data transfer of update packages to be completed in a shorter duration.

[0020] While described in detail throughout this disclosure, representative examples of the disclosure have utility over a wide range of applications, and the above discussion is not intended to and should not be construed as limiting but rather is provided as an illustrative discussion of aspects of the disclosure.

[0021] Figure 1 FIG2 illustrates a schematic diagram of a computing system 100 for updating firmware of a BMC according to an example embodiment of the present subject matter. Figure 1, computing system 100 includes a BMC 102 and a host computing device 160. BMC 102 is connected to host computing device 160 via a high-speed in-band interface 150, such as a universal serial bus (USB) interface. In addition, the BMC can be connected to an out-of-band network, such as a trusted LAN network, via an out-of-band interface 140 (e.g., Intelligent Platform Management Interface / IPMI, Redfish host interface), where the out-of-band nature of management traffic is guaranteed. In an exemplary embodiment, BMC 102 can also be connected to computing device 142 via in-band interface 150 and / or out-of-band interface 140. Computing device 142 can be a remote server that provides services for updating BMC 102.

[0022] Host computing device 160 may be a general-purpose computer or a headless computer. Host computing device 160 may include a processor 162, a memory 164, and a communication connection 166. Processor 162, memory 164, and communication connection 166 may reside on a motherboard of the host computing device. In some embodiments, BMC 102 may also be incorporated into the motherboard of host computing device 160.

[0023] Memory 164 of host computing device 160 may store machine-readable instructions that processor 162 may execute. Memory 164 may include a plurality of software applications, including a host operating system (OS). Processor 162 is a host processor configured to control the operation of host computing device 162.

[0024] BMC 102 is a dedicated microcontroller that manages the interface between system management software and platform hardware. Various sensors may be built into computer system 100, and BMC 102 reads these sensors to obtain parameters such as temperature, cooling fan speed, management status, and operating system (OS) status. BMC 102 monitors and manages components of the server hardware. Therefore, the BMC's services are preferably always available while the server is powered on.

[0025] BMC 102 includes a processor 104, non-volatile memory 110, volatile memory 130, and an update agent 180. Processor 104 controls the operation of BMC 102. Processor 104 can execute firmware, such as boot loader 112, kernel 114, configuration 116, and root file system 120, or other code stored in BMC 102. Processor 104 can also execute update agent 180 to update the firmware of the BMC. Update agent 180 can be machine-readable code stored on a memory of the BMC (such as non-volatile memory 110 and / or volatile memory 130) for performing an update of the firmware of BMC 102.

[0026] The volatile memory 130 is configured to store data and information during operation of the BMC 102. In certain embodiments of the present disclosure, the volatile memory 130 may include an update partition 132 for performing updates of the firmware of the BMC 102, as will be described in more detail below. The volatile memory 130 may be random access memory (RAM).

[0027] The non-volatile memory 110 is a non-volatile data storage medium for storing computer executable code and data required for the operation of the BMC 102. The computer executable code and data may include firmware for the BMC 102, such as a boot loader 112, a kernel 114, a configuration 116, and a root file system 120, as well as other necessary firmware or software components of the BMC 102. Examples of non-volatile memory may include flash memory (e.g., a serial peripheral interface (SPI) flash drive), a USB drive, a hard disk drive, or any other type of data storage device.

[0028] The boot loader 112 is a computer program that loads the kernel 114 of the BMC 102. The boot loader 112 is loaded from the non-volatile memory 110 to the volatile memory 130 and performs a process for booting the BMC 102, such as bringing the kernel 114 from the non-volatile memory 110 to the volatile memory 130 and providing the kernel 114 with information necessary for operation. The boot loader 112 may then pass control to the kernel 114.

[0029] Kernel 114 is the operating system (OS) of the BMC. Kernel 114 manages I / O requests from software and converts the requests into data processing instructions for processor 104. Kernel 114 mediates access to BMC 102 resources, including processor 104, non-volatile memory 110, and volatile memory 130.

[0030] Configuration data 116 includes information and data that enables BMC 102 to operate. Configuration data 116 may include the media access control (MAC) address of BMC 102, kernel boot parameters, environment variables, and other user-specific files. The MAC address provides Internet Protocol (IP) information available to BMC 102, which allows network connectivity and network support for BMC 102 to perform remote management. Kernel boot parameters and environment variables allow BMC 102 to properly run kernel 114 and other monitoring and sensing programs.

[0031] The root file system 120 is where all applications and services reside. For example, the root file system 120 includes files for executing various services, such as thermal management services, fan speed services, IPMI services, power capping services, media redirection services, etc. The root file system 120 includes applications for executing services, libraries associated with the applications, drivers, etc.

[0032] In an embodiment of the present subject matter, the non-volatile memory 110 of the BMC 102 is separated into a plurality of independently updateable RW partitions 122-1, 122-2, 122-3, ..., 122-N. Each of the RW partitions 122-1, 122-2, 122-3, ..., 122-N includes a service module 124, and the service module 124 includes one or more files related to the services provided by the BMC 102. The applications, libraries, and drivers of the root file system 120 can be categorized into different service modules 124 according to a classification method to allow independent updating of the services. For example, each application of the BMC 102 can be separated into a different service module 124, the libraries associated with the applications can be separated into different service modules 124, and the drivers can be separated into different service modules 124. In another configuration, each application and its one or more libraries can be stored in a separate service module 124, and the drivers can be separated into one or more service modules 124. In another example, applications that are often updated together can be separated into their own service modules 124. A variety of configurations are possible, and the present disclosure is not limited to any particular configuration.

[0033] By separating services into distinct, independently updateable service modules 124 stored on RW partitions 122-1, 122-2, 122-3, ..., 122-N, a single service of BMC 102 can be updated without having to update all of the services in BMC 102 during the update process. Furthermore, a single service can be reset to implement its update without having to update the entire BMC 102. Consider an example where BMC 102 reports a hardware error after diagnosing the hardware, and the error occurs due to the nature of the hardware settings rather than an actual fault. For example, a vulnerability exists in the hardware that causes BMC 102 to see an error at a certain temperature rather than the actual temperature at which the error should be reported. If BMC 102 were treated as a monolithic binary, the entire BMC 102 would need to be updated, resulting in significant, undesirable downtime. By categorizing BMC 102's services into distinct service modules and storing these service modules on separate RW partitions, the error can be fixed by updating a single BMC service module rather than the entire BMC 102. Furthermore, update errors can be reduced because the update is focused only on a single service rather than on the entire BMC 102. Therefore, there is no need to worry about update errors occurring in services residing outside of the service module 124 being updated.

[0034] Despite Figure 1 122-N with respect to the root file system 120, but the RW partitions 122-1, 122-2, 122-3, ..., 122-N and the service modules 124 contained therein are not limited to the root file system 120 of the BMC 102 firmware. The RW partitions 122-1, 122-2, 122-3, ..., 122-N and the service modules 124 contained therein are also applicable to other aspects of the BMC 102 firmware. For example, the configuration data 116 of the BMC 102 firmware can also advantageously be its own service module 124 within the RW partition 122-N, or can be divided into multiple service modules / RW partitions. For example, if a feature is disabled in the configuration data 116, the configuration data 116 itself can be updated by providing the configuration data 116 as its own RW partition 122-N, without having to update the entire BMC 102.

[0035] Update agent 180 performs the update process on the updated service module 124. Update agent 180 may be machine-readable code stored on BMC 102. In embodiments of the present disclosure, the update process may differ depending on whether the update is in-band or out-of-band. For in-band updates, the update package is forwarded through host computing device 160. For out-of-band updates, the update package is forwarded through secure out-of-band connection 140, which is not exposed to host computing device 160.

[0036] For in-band communication, the BMC typically uses a protocol such as IPMI to communicate with the host computing device. However, this protocol introduces protocol latency because the protocol adds a certain amount of overhead. This is detrimental to updates because the protocol latency increases the amount of time it takes to implement the update. Embodiments of the present disclosure bypass this protocol overhead by leveraging the host computing device OS's native support for USB drivers. In embodiments of the present disclosure, the update agent 180 implements a special update mode process in which the BMC 102 enumerates the temporary update partition 132 on the host computing device OS as a virtual memory driver 165 (such as a virtual USB hard drive), thereby providing a high-bandwidth protocol and high-bandwidth interface from the host computing device 160 to the BMC 102 for updating BMC 102 services.

[0037] During the update process performed by update agent 180, update agent 180 may first receive a command from update deployment agent 144 of computing device 142 instructing BMC 102 to enter a special firmware update mode. Upon receiving the command, update agent 180 mounts update partition 132 of volatile memory 130 onto host computing device 160 as a virtual storage drive 165. Mounting update partition 132 of volatile memory 130 onto the host computing device may involve the BMC using its virtual storage service (e.g., IPMI virtual storage service) to mount the update partition onto host computing device 160 as a USB key so that data can be written directly to update partition 132. After update partition 132 is mounted onto host computing device 160, update deployment agent 144 may navigate to virtual storage drive 165 and write an update package including an update service module to virtual storage drive 165. Thus, the BMC 102 receives the BMC update package, and the update package is stored in the volatile memory 130 via a write operation performed by the update deployment agent 144 .

[0038] After update deployment agent 144 has completed writing the update package to virtual storage 165, update deployment agent 144 may transmit a command to update agent 180 indicating the completion of the write operation. After receiving the command, update agent 180 may then unmount update partition 132 from host computing device 160. The update agent may unmount update partition 132 by, for example, using its virtual storage service to unmount the update partition from host computing device 160. Update agent 180 may then replace the existing service module in the corresponding RW partition 122-N of non-volatile memory with the update service module included in the BMC update package.

[0039] In certain embodiments of the present subject matter, BMC update packages received from update deployment agent 144 may include a signed update service module. For example, update deployment agent 144 may implement authentication techniques, such as signature verification, key matching, and other such techniques. Authentication can help determine valid update packages and, therefore, protect BMC 102 from security attacks. When using such authentication techniques, update agent 180 can authenticate update packages written to update partition 132 of volatile memory 130 before replacing the corresponding existing service module in non-volatile memory 110 with the update service module.

[0040] In certain embodiments of the present disclosure, the update agent 180 may include a timer 182. The timer 182 may determine whether the time taken to write the update package to the update partition 132 exceeds a predetermined time. If the time taken exceeds the predetermined time, the update agent 180 may unmount the update partition 132 from the host computing device 160 and discard the update package for security purposes. For example, in the case of a compromised host computing device 160, a bad actor may attempt to install large malware. Implementing the timer 182 prevents such malware from being installed on the non-volatile memory 110 of the BMC 102. In addition to the timer 182, or in lieu of the timer 182, the update agent 180 may also enforce a size constraint on the size of any file written to the BMC 102 via the virtual memory driver 165.

[0041] Unlike the in-band update process performed by the update agent 180, for out-of-band updates, the update package proceeds over the secure out-of-band connection 140, which is not exposed to the host computing device 160. In this case, the update deployment agent 144 can write the update package directly to the update partition 132. To write the package directly to the update partition 132, a secure file transfer protocol (SFTP) can be implemented and used to transfer the update package to the update partition 132. After the update deployment agent 144 completes the write process, the update deployment agent 144 can send a command to the update agent 180 indicating the completion of the write process.

[0042] Similar to the in-band update process, in the out-of-band process, the update deployment agent 144 may implement authentication techniques on the update packages written to the update partition 132. In this case, the update agent 180 may authenticate the update packages written to the update partition 132 before replacing the corresponding existing service modules in the non-volatile memory 110 with the updated service modules.

[0043] In an embodiment of the present subject matter, during the update process described above, existing service modules can be run from volatile memory 130 while the update process is being performed. For example, when a service associated with service module 124 is to be executed by BMC 102, service module 124 can be transferred from its RW partition 122-N in non-volatile memory 110 to a portion of volatile memory 130 other than update partition 132. Thus, service module 124 can be executed from volatile memory 130 while the update process is being performed.

[0044] Figure 2 A flow chart depicting a method for transferring data from a host computing device 160 to a BMC 102 is illustrated, according to an example embodiment of the present disclosure.

[0045] refer to Figure 2 At block 201, BMC 102 receives a command to enter a special transfer mode so that data can be transferred to BMC 102. For example, the command may be sent by deployment agent 144 of a remote computing device, such as computing device 142, or by host computing device 160. For example, the command may be sent to BMC 102 using the IPMI protocol for in-band or the Redfish protocol for out-of-band.

[0046] Typically, data is transferred between the host computing device 160 and the BMC 102, or between the computing device 142 and the BMC 102, using protocols such as IPMI for in-band communication or Redfish for out-of-band communication. Data transfer using these protocols has a certain amount of protocol overhead, which increases the time it takes to transfer data. Special transfer mode is a mode in which the computer system 100 utilizes the native speed of the host computing device 160's memory drive to transfer data between the host computing device 160 and the BMC 102. For example, the host computing device 160 may have the ability to mount a remote drive as a USB hard drive, and the BMC 102 may control this mounting operation. In special transfer mode, the BMC 102 mounts its own volatile memory 130 to the host computing device 160, thereby facilitating data transfer between the host computing device 160 and the BMC 102.

[0047] In an embodiment of the present subject matter, the command received by BMC 102 to enter special pass-through mode may include information in addition to an indication that BMC 102 should mount a partition of its volatile memory 130 onto host computing device 160. For example, the command may also include the size of a file to be written to volatile memory 130 so that BMC 102 can allocate an appropriate amount of volatile memory to mount to host computing device 160.

[0048] At block 202, the BMC 102 identifies a partition 132 in the volatile memory 130 of the BMC 102 to mount to the host computing device 160 as a virtual memory drive 165. In an embodiment of the present subject matter, the partition 132 may be pre-reserved for use in the data transfer mode, or the partition 132 may be a dynamically allocated memory partition. At block 203, the BMC 102 mounts the partition 132 on the host computing device 160 as a virtual memory drive 165 (e.g., a virtual USB hard drive).

[0049] At block 204, the data is stored in the volatile memory 130 of the BMC 102 via a write operation to the virtual memory drive 165. For example, the virtual memory drive 165 may appear as a USB hard drive to the remote computing device 142 and / or the host computing device 160. To transfer the data to the BMC 102, the host computing device 160 or the remote computing device 142 may write the data to the virtual memory drive 165, which in turn stores the data on the volatile memory 130 of the BMC.

[0050] After the write operation is complete, at block 205, BMC 102 unmounts partition 132 from host computing device 160. In some implementations of the present subject matter, BMC 102 may receive a command from host computing device 160 or remote computing device 142 indicating that the write operation is complete and BMC 102 may unmount virtual memory driver 165.

[0051] In the embodiments of the present subject matter, reference is made to Figure 2 The described data transfer method can be useful in a variety of situations. For example, the data transfer mode can be useful when transferring telemetry data from the host computing device 160 to the BMC 102. In addition, the data transfer mode can be useful when updating the firmware of the BMC 102, which will be referred to as Figure 3 An embodiment of updating the firmware of the BMC 102 is described.

[0052] Figure 3 FIG2 illustrates a flow chart depicting a method for updating firmware of a BMC according to an example embodiment of the present disclosure. Figure 3 The illustrated process may be referred to as an inbound process because the data is passed through host computing device 160 .

[0053] refer to Figure 3At block 301, the BMC 102 receives an update command from the update deployment agent 144 of the computing device 142, the update command instructing the BMC 102 to enter a special firmware update mode. For example, the command may be sent to the BMC 102 using the IPMI protocol for in-band, the Redfish protocol for out-of-band, or other applicable protocols. In embodiments of the present subject matter, the special update mode is a mode in which the BMC 102 mounts a partition of its volatile memory 130 on the host computing device 160 as a virtual memory drive 165.

[0054] In some implementations of the present subject matter, the command received by BMC 102 to enter the special update mode may include information in addition to an indication that BMC 102 should mount a partition of its volatile memory 130 onto host computing device 160. For example, the command may also include the size of the update package to be written to volatile memory 130 so that BMC 102 can allocate an appropriate amount of volatile memory to mount to host computing device 160.

[0055] At block 302, the BMC 102 mounts the update partition 132 of its volatile memory 130 to the host computing device 160 as a virtual memory drive 165. The virtual memory drive 165 may appear to the computing device 142 as a virtual USB hard drive.

[0056] In certain embodiments of the present subject matter, when mounting the update partition 132 onto the host computing device 160, the BMC 102 may assign an identifier to the virtual memory driver 165 that is the same as the BMC's globally unique identifier (GUID). The use of the GUID provides an additional layer of security for the update process. In such embodiments, the host computing device 160 may obtain the BMC's GUID via the IPMI protocol prior to any mounting operation. Thus, the host computing device 160 may match the GUID obtained via the IPMI protocol with the identifier of the virtual memory driver 165 to ensure that the virtual memory driver 165 is authentic.

[0057] At block 303, the BMC 102 receives a BMC update package for updating an existing service module from the update deployment agent 144. The BMC update package may include an updated service module for replacing the existing service module. The BMC update package may be received via a high-bandwidth protocol and a high-bandwidth channel because mounting the update partition 132 to the host computing device 160 eliminates protocol overhead and instead utilizes the native speed of the host computing device's 160 memory drive.

[0058] In certain embodiments of the present subject matter, the BMC package received from the update deployment agent 144 may include an update service module that employs authentication techniques thereon. For example, the update deployment agent 144 may implement authentication techniques such as signature verification, key matching, and other such techniques. Authentication may help determine valid update packages and, therefore, may protect the BMC 102 from security attacks.

[0059] At block 304 , the BMC update package is stored in the update partition 132 of the BMC's volatile memory 130 .

[0060] Receiving the update package and storing it in the update partition 132 can be accomplished by writing to the virtual storage driver 165. For example, before sending the update package, the update deployment agent 144 of the computing device 142 can obtain the BMC's GUID. The GUID can be obtained by the update deployment agent 144, for example, via the IPMI protocol for in-band transmission and via the Redfish protocol for out-of-band transmission. Therefore, the update deployment agent 144 can navigate to the virtual storage driver 165 with the same identifier as the BMC 102's GUID. The update deployment agent 144 can then write the update package to the virtual storage driver 165, which in turn transmits and stores the update package in the update partition 132 of the volatile memory 130.

[0061] At block 305, in response to the BMC update package being stored in the update partition 132 of the volatile memory 130, the BMC 102 may unmount the update partition 132 from the host computing device 160. In some implementations of the present subject matter, the BMC 102 may unmount the update partition 132 in response to a command from the update deployment agent 144. For example, the update deployment agent 144 may send a control packet over an in-band or out-of-band channel indicating that its write operation is complete, which in turn signals to the BMC 102 that it should unmount its update partition 132 from the host computing device 160.

[0062] If the BMC update package received from the update deployment agent 144 is a BMC update package for which authentication technology is employed, at block 306, the BMC update package is authenticated before the update service module is used to replace the existing update service module. Authentication ensures that the update package is valid and, therefore, protects the BMC 102 from security attacks. To this end, the BMC 102 may employ various authentication technologies, such as a public-private key pair, to verify the authenticity of the update package. If the BMC 102 determines that the BMC update package is valid, the process proceeds to block 307. If the BMC 102 determines that the BMC update package is invalid, the BMC update package is discarded.

[0063] At block 307 , the BMC 102 replaces the existing service module in the corresponding RW partition 122 -N of the non-volatile memory 110 with the updated service module included in the firmware update package.

[0064] In some embodiments, the RW partition 122-N including the existing service module may be one of a plurality of independently updateable RW partitions. That is, the non-volatile memory 110 of the BMC 102 may be separated into a plurality of independently updateable RW partitions 122-1, 122-2, 122-3, ..., 122-N. Each of the RW partitions 122-1, 122-2, 122-3, ..., 122-N includes a service module 124, and the service module 124 is one or more files related to the services provided by the BMC 102. For example, according to a classification method, the applications, libraries, and drivers of the root file system 120 may be classified into different service modules 124 to allow independent updating of the services.

[0065] In some embodiments, while the existing service module 124 is being updated, the services associated with the existing service module 124 can be running in the BMC 102. For example, the existing service module 124 can be loaded into a portion of the volatile memory 130 other than the update partition 132, and during the update process, the processor 104 can execute the service module 124 from the volatile memory 130 to perform the service. Thus, while the update is being performed in the background, the current services are not interrupted.

[0066] At block 308, BMC 102 restarts the services associated with the updated service module, thereby executing the new applications and / or libraries or drivers included in the updated service module. At this point, only the updated services are restarted, and all other services are unaffected.

[0067] Figure 4 A flow chart depicting a method for updating the firmware of the BMC 102 according to an example embodiment of the present disclosure is illustrated. Figure 4 The flowchart illustrated in FIG. 1 shows an out-of-band method for updating BMC firmware.

[0068] At block 401, the BMC 102 receives a BMC update package for updating an existing service module from the update deployment agent 144. For an out-of-band process, the BMC 102 receives the BMC update package by enabling SFTP. In this case, the update deployment agent 144 connects to the BMC 102 using SFTP, which initiates a connection to the volatile memory 130 of the BMC 102.

[0069] Similar to the inbound process, in some embodiments of the present subject matter, the BMC update package received from the update deployment agent 144 may include an update service module that applies authentication techniques to it. For example, the update deployment agent 144 may implement authentication techniques such as signature verification, key matching, and other such techniques.

[0070] At block 402 , a BMC update package is stored in the update partition 132 of the volatile memory 130 of the BMC 102 . The BMC update package may be stored in the update partition 132 of the volatile memory 130 by a write operation performed by the update deployment agent 144 .

[0071] If the BMC update package received from the update deployment agent 144 is a BMC update package for which authentication technology has been applied, at block 403, the BMC update package is authenticated before the update service module is used to replace the existing update service module. Authentication can ensure that the update package is valid and thus protect the BMC 102 from security attacks. Similar to the inbound process, the BMC 102 can use various authentication technologies, such as a public-private key pair, to verify the authenticity of the update package. If the BMC 102 determines that the BMC update package is valid, the process proceeds to block 404. If the BMC 102 determines that the BMC update package is invalid, the BMC update package is discarded.

[0072] At block 404, the BMC 102 replaces the existing service module stored in the RW partition 122-N of the non-volatile memory 110 with the updated service module included in the BMC update package. Similar to the inbound process, in some embodiments, the RW partition 122-N including the existing service module may be one of a plurality of independently updateable RW partitions 122-1, 122-2, 122-3, ..., 122-N, each having a service module 124 stored therein.

[0073] At block 405 , BMC 102 restarts the services associated with the updated service module, thereby executing the new applications and / or libraries or drivers included in the updated service module. At this point, only the updated services are restarted, and all other services are not affected.

[0074] Similar to the inbound process, in some embodiments, services associated with an existing service module may be run in the BMC 102 while the existing service module is being updated.

[0075] Figure 5 A non-limiting embodiment of a computing system 500 is schematically shown that can perform one or more of the above methods and processes. The computing system 500 is shown in simplified form. The computing system 500 can implement Figure 1The BMC 102 or computer system 100 of the present invention may be a computer system 500. The computing system 500 may take the form of one or more personal computers, server computers, tablet computers, home entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smartphones), and / or other computing devices, as well as wearable computing devices (such as smart watches and head-mounted augmented reality devices).

[0076] The computing system 500 includes a logic processor 502, a volatile memory 503, and a non-volatile storage device 504. The computing system 500 may optionally include a display subsystem 506, an input subsystem 508, a communication subsystem 510, and / or Figure 5 Other components not shown.

[0077] Logical processor 502 includes one or more physical devices configured to execute instructions. For example, a logical processor may be configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more components, achieve a technical effect, or otherwise achieve a desired result. For example, a logical processor may implement Figure 1 BMC processor 104.

[0078] The logical processor 502 may include one or more physical processors (hardware) configured to execute software instructions. Additionally or alternatively, the logical processor 502 may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions. The processor of the logical processor 502 may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel and / or distributed processing. The various components of the logical processor may optionally be distributed in two or more separate devices that may be remotely located and / or configured for collaborative processing. Various aspects of the logical processor may be virtualized and executed by a remotely accessible networked computing device configured in a cloud computing configuration. It should be understood that in this case, these virtualized aspects run on different physical logical processors of various different machines.

[0079] The non-volatile storage device 504 includes one or more physical devices that are configured to hold instructions executable by a logical processor to implement the methods and processes described herein. When implementing such methods and processes, the state of the non-volatile storage device 504 may be changed, for example, to hold different data. The non-volatile storage device 504 may be implemented, for example, in Figure 1 The non-volatile memory 110 is shown in FIG.

[0080] The non-volatile storage device 504 may include a removable and / or built-in physical device. The non-volatile storage device 504 may include optical memory (e.g., CD, DVD, HD-DVD, Blu-ray disc, etc.), semiconductor memory (e.g., ROM, EPROM, EEPROM, FLASH memory, etc.), and / or magnetic memory (e.g., hard disk drive, floppy disk drive, tape drive, MRAM, etc.) or other mass storage device technology. The non-volatile storage device 504 may include a non-volatile, dynamic, static, read / write, read-only, sequential access, location addressable, file addressable, and / or content addressable device. It should be understood that the non-volatile storage device 504 is configured to retain instructions even when power to the non-volatile storage device 504 is cut off.

[0081] Volatile memory 503 may include physical devices that include random access memory. Logical processor 502 typically utilizes volatile memory 503 to temporarily store information during the processing of software instructions. It should be understood that when power to volatile memory 503 is cut off, volatile memory 503 typically does not continue to store instructions. Volatile memory 503 may be implemented, for example, in Figure 1 The volatile memory 130 is depicted in FIG.

[0082] Aspects of the logic processor 502, volatile memory 503, and non-volatile storage device 504 may be integrated together into one or more hardware logic components. For example, such hardware logic components may include field programmable gate arrays (FPGAs), program and application specific integrated circuits (PASIC / ASICs), program and application specific standard products (PSSP / ASSPs), systems on chips (SOCs), and complex programmable logic devices (CPLDs).

[0083] The terms "module," "program," "mechanism," and "engine" may be used to describe aspects of computing system 500 that are typically implemented in software by a processor to perform a specific function using portions of volatile memory, which involves transformative processing specifically configuring the processor to perform that function. Thus, a module, program, or engine may be instantiated by executing instructions held by non-volatile storage device 504 via logical processor 502 using portions of volatile memory 503. It should be understood that different modules, programs, mechanisms, and / or engines may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Similarly, the same module, program, mechanism, and / or engine may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module," "program," "mechanism," and "engine" may encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc.

[0084] When included, the display subsystem 506 can be used to present a visual representation of the data held by the non-volatile storage device 504. The visual representation can take the form of a graphical user interface (GUI). Since the methods and processes described herein change the data held by the non-volatile storage device and thus transform the state of the non-volatile storage device, the state of the display subsystem 506 can also be transformed to visually represent the changes in the underlying data. The display subsystem 506 can include one or more display devices utilizing virtually any type of technology. Such a display device can be combined with the logical processor 502, volatile memory 503, and / or non-volatile storage device 504 in a shared package, or such a display device can be a peripheral display device.

[0085] When included, the input subsystem 508 may include or interface with one or more user input devices (such as a keyboard, mouse, touch screen, or game controller). In some embodiments, the input subsystem may include or interface with selected natural user input (NUI) components. Such components may be integrated or peripheral, and the conversion and / or processing of input actions may be handled on-board or off-board. Example NUI components may include a microphone for speech and / or voice identification; an infrared, color, stereo, and / or depth camera for machine vision and / or gesture identification; a head tracker, eye tracker, accelerometer, and / or gyroscope for motion detection and / or intent identification; and an electric field sensing component for assessing brain activity; and / or any other suitable sensor.

[0086] When included, the communication subsystem 510 can be configured to communicatively couple the various computing devices described herein to each other and to communicatively couple to other devices. The communication subsystem 510 may include wired and / or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem can be configured for communication via a wireless telephone network, or a wired or wireless local area network or wide area network (such as HDMI over a Wi-Fi connection). In some embodiments, the communication subsystem can allow the computing system 500 to send messages to and / or receive messages from other devices via a network such as the Internet.

[0087] The terms used herein are for the purpose of describing specific embodiments only and are not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when used in this specification, the terms "comprises," "comprising," and "having" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0088] The corresponding structures, materials, acts, and equivalents of all parts or step plus function elements (if any) in the appended claims are intended to include any structure, material, or act for performing the function in combination with other claimed elements for which protection is specifically claimed. This description is presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the present disclosure. The embodiments are selected and described in order to best explain the principles and practical applications of the present disclosure and to enable those skilled in the art to understand the present disclosure to obtain various embodiments with various modifications suitable for the intended specific use.

[0089] Although specific embodiments have been described, it will be appreciated by those skilled in the art that there are other embodiments that are equivalent to the described embodiments. Therefore, it should be understood that the present disclosure is not limited to the specific embodiments described, but only to the scope of the appended claims.

[0090] According to one aspect of the present disclosure, a system includes a BMC, which includes a process and a memory. The memory may include a non-volatile memory and a volatile memory. The non-volatile memory may include firmware classified into a plurality of independently updateable service modules, each of the independently updateable storage modules being stored on a read-write (RW) partition of the non-volatile memory. Each independently updateable service module may include at least one of an application, a library, and a driver. The memory may also include executable code that, when executed at a processor, is configured to perform a firmware update. The firmware update may include: receiving a BMC update package for updating an existing service module stored in one of a plurality of RW partitions, wherein the BMC update package includes an updated service module; storing the BMC update package in the volatile memory; and replacing the existing service module stored in the RW partition of the non-volatile memory with the updated service module.

[0091] In this aspect, existing service modules may be run from volatile memory when performing a firmware update.

[0092] In this aspect, the BMC update package may include a signed update service module, and after storing the BMC update package in the volatile memory, the firmware update may further include authenticating the BMC update package before replacing the existing service module stored in the RW partition of the non-volatile memory with the update service module.

[0093] In this aspect, the BMC may be connected to the host computing device via a memory interface, and the firmware update may further include: before receiving the BMC update, receiving an update command from an update deployment agent, the update command instructing the BMC to enter a firmware update mode; and mounting a partition of the volatile memory onto the host computing device as a virtual memory drive, wherein the BMC update package is stored in the volatile memory via a write operation to the virtual memory drive.

[0094] In this aspect, the memory bus may include a universal serial bus (USB), and the virtual memory drive may include a virtual USB hard drive.

[0095] In this aspect, the firmware update may further include: determining whether the time taken to write the BMC update package to the volatile memory exceeds a predetermined time; when the time taken to write the BMC exceeds the predetermined time, unmounting the partition of the volatile memory and discarding the BMC update package.

[0096] In this aspect, the firmware update may further include: receiving a command from the update deployment agent indicating completion of the write operation; and unmounting the partition of the volatile memory from the host computing device.

[0097] In this regard, the BMC may connect to the update deployment agent through an out-of-band interface.

[0098] In this aspect, the out-of-band interface may be a local area network (LAN) interface.

[0099] In this regard, the BMC may receive the update package via Secure File Transfer Protocol (SFTP).

[0100] According to another aspect of the present disclosure, a method for updating the firmware of a baseboard management controller (BMC) may include: receiving a BMC update package, the BMC update package including an update service module for updating an existing service module of the BMC, the existing service module being stored in one of multiple read-write (RW) partitions of a non-volatile memory of the BMC, each RW partition including an independently updateable service module, wherein each independently updateable service module includes at least one of an application, a library, and a driver; storing the BMC update package in the volatile memory of the BMC; replacing the existing service module stored in the RW partition of the non-volatile memory with the update service module; and restarting the service of the BMC associated with the update service module.

[0101] In this aspect, the BMC update package may include a signed update service module, and the method may further include authenticating the signed update service module after storing the BMC update package in a volatile memory of the BMC.

[0102] In this aspect, the method may further include: before receiving the BMC update package, receiving an update command from an update deployment agent, the update command instructing the BMC to enter a firmware update mode; mounting a partition of the volatile memory onto a host computing device connected to the BMC via a memory interface as a virtual memory drive; wherein the BMC update package is stored in the volatile memory via a write operation to the virtual memory drive.

[0103] In this aspect, the memory interface may include a universal serial bus (USB), and the virtual memory drive may include a virtual USB hard drive.

[0104] In this aspect, the method may further include: receiving a command from the update deployment agent indicating completion of the write operation; and unmounting the partition of the volatile memory from the host computing device.

[0105] In this regard, the BMC may connect to the update deployment agent through an out-of-band interface.

[0106] In this aspect, the out-of-band interface may be a local area network (LAN) interface.

[0107] In this regard, the BMC may receive the update package via Secure File Transfer Protocol (SFTP).

[0108] In another aspect of the present disclosure, a method for delivering a file to a baseboard management controller (BMC) may include: receiving a command from a deployment agent instructing the BMC to enter a delivery mode; identifying a partition of volatile memory of the BMC and mounting the partition of volatile memory to a host computing device connected to the BMC via a memory interface as a virtual memory drive; delivering the file from the host computing device to the BMC by storing the file in the volatile memory through a write operation to the virtual memory drive; and unmounting the partition of volatile memory from the host computing device.

[0109] In this aspect, the memory bus may include a universal serial bus (USB), and the virtual memory drive may include a virtual USB hard drive.

Claims

1. A system comprising: Baseboard Management Controller (BMC), including: A processor and a memory, the memory including a non-volatile memory and a volatile memory, the non-volatile memory including firmware classified into a plurality of independently updateable service modules, the non-volatile memory being divided into at least a plurality of read-write (RW) partitions, the plurality of RW partitions respectively storing the plurality of independently updateable service modules, wherein each independently updateable service module includes at least one of the following: an application, a library, and a driver, the memory further including executable code, which, when executed by the processor, is configured to: Perform a firmware update, including: receiving a BMC update package, the BMC update package being used to update an existing service module stored in one of the multiple RW partitions, the BMC update package including an updated service module; Storing the BMC update package in the volatile memory; replacing the existing service module stored in the RW partition of the non-volatile memory with the updated service module without replacing at least one other service module stored in at least one other RW partition of the non-volatile memory; and The service of the BMC associated with the update service module is restarted without affecting other service modules stored in other RW partitions of the non-volatile memory. 2 . The system of claim 1 , wherein the existing service module is run from the volatile memory when the firmware update is performed.

3. The system of claim 1 , wherein the BMC update package includes a signed update service module, and after storing the BMC update package in the volatile memory and before replacing the existing service module stored in the RW partition of the non-volatile memory with the update service module, performing the firmware update further comprises authenticating the BMC update package.

4. The system of claim 1 , wherein the BMC is connected to a host computing device via a memory interface, and wherein performing the firmware update further comprises: Before receiving the BMC update, receiving an update command from an update deployment agent, the update command instructing the BMC to enter a firmware update mode; as well as Mounting the partition of the volatile memory on the host computing device as a virtual memory drive, The BMC update package is stored in the volatile memory by means of a write operation to the virtual memory driver.

5. The system of claim 4, wherein the memory interface comprises a universal serial bus (USB), and the virtual memory drive comprises a virtual USB hard drive.

6. The system of claim 4, wherein performing the firmware update further comprises: determining whether a time taken to write the BMC update package into the volatile memory exceeds a predetermined time; as well as When the time taken to write the BMC update package exceeds the predetermined time, the partition of the volatile memory is unmounted and the BMC update package is discarded.

7. The system of claim 4, wherein performing the firmware update further comprises: receiving a command from the update deployment agent indicating completion of the write operation; as well as The partition of the volatile memory is unmounted from the host computing device.

8. The system of claim 1, wherein the BMC is connected to the update deployment agent through an out-of-band interface. 9 . The system according to claim 6 , wherein the BMC receives the BMC update package via Secure File Transfer Protocol (SFTP).

10. A method for updating firmware of a baseboard management controller (BMC), comprising: receiving a BMC update package, the BMC update package including an update service module for updating an existing service module of the BMC, the existing service module being stored in one of a plurality of read-write (RW) partitions included in a non-volatile memory of the BMC, each RW partition including an independently updateable service module, wherein each independently updateable service module includes at least one of an application, a library, and a driver; Storing the BMC update package in a volatile memory of the BMC; replacing the existing service module stored in the RW partition of the non-volatile memory with the updated service module without replacing at least one other service module stored in at least one other RW partition of the non-volatile memory; as well as The service of the BMC associated with the update service module is restarted without affecting other service modules stored in other RW partitions of the non-volatile memory.

11. The method according to claim 10, wherein the BMC update package includes a signed update service module, and the method further comprises: After storing the BMC update package in the volatile memory of the BMC, authenticating the signed update service module.

12. The method according to claim 10, further comprising: Before receiving the BMC update package, receiving an update command from an update deployment agent, wherein the update command instructs the BMC to enter a firmware update mode; as well as Mounting the partition of the volatile memory onto a host computing device connected to the BMC via a memory interface as a virtual memory drive; The BMC update package is stored in the volatile memory by performing a write operation on the virtual memory driver.

13. The method of claim 12, wherein the memory interface comprises a Universal Serial Bus (USB), and the virtual memory drive comprises a virtual USB hard drive.

14. The method according to claim 12, further comprising: receiving a command from the update deployment agent indicating completion of the write operation; as well as The partition of the volatile memory is unmounted from the host computing device.

15. The method of claim 10, wherein the BMC is connected to the update deployment agent through an out-of-band interface.

16. The method of claim 15, wherein the out-of-band interface is a local area network (LAN) interface. 17 . The method according to claim 10 , wherein the BMC receives the BMC update package via Secure File Transfer Protocol (SFTP).

18. A baseboard management controller (BMC), comprising: one or more processors; Volatile memory; non-volatile memory including a plurality of read-write (RW) partitions; Firmware stored in the non-volatile memory; a plurality of independently updateable service modules in the firmware, each of the plurality of independently updateable service modules being stored in one of the plurality of RW partitions included in the non-volatile memory, each of the plurality of independently updateable service modules comprising at least one of the following: an application, a library, and a driver; and Instructions in the firmware, the instructions executable by the one or more processors to: receiving a BMC update package, the BMC update package being configured to update an existing service module stored in one of the plurality of RW partitions, the BMC update package including an updated service module; replacing the existing service module stored in the RW partition of the non-volatile memory with the updated service module without replacing multiple other service modules stored in multiple other RW partitions of the non-volatile memory; as well as Restart the BMC service associated with the update service module, Without restarting the multiple other service modules stored in the multiple other RW partitions of the non-volatile memory.

Images