Patent Description:
Data centers are used all over the world to provide massive amounts of processing and storage capacity. Data centers typically include multiple racks of servers, sometimes referred to as "blades. " These blades each include one or more processors and memory. A baseboard management controller (BMC) is generally 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 a chassis management interface) according to the Intelligent Platform Management Interface (IPMI).

The firmware of a BMC includes a boot loader, a kernel, configuration data, and a root file system stored on partitions in a flash drive (e.g., a serial peripheral interface (SPI) flash drive) of the BMC. These partitions together constitute a BMC binary ROM image. The BMC's firmware may need to be updated from time to time to address issues relating 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 flash memory of the BMC in an update. <CIT> relates to methods of managing and delivering digital media content data. A management device is in communication to a computing device via a universal serial bus (USB) connector. The management device has a processor, a volatile memory and a non-volatile memory. The non-volatile memory includes a first partition storing a firmware and a second partition. The firmware emulates an emulated bootable storage device for the computing device at the USB connector. In response to an access instruction from the computing device to access data stored at an emulated address of the emulated bootable storage device, the management device converts the emulated address to a physical address of the second partition, and accesses the data at the physical address. The data includes digital media content data and a control module configured to play the content data. <CIT> relates to technologies for running multiple firmware instances in a board management controller (BMC). A BMC is configured to execute a first BMC firmware natively and to execute a virtualized second BMC firmware in an emulator. The virtualized second BMC firmware can be an instance of an older BMC firmware, and the first BMC firmware can be an instance of a newer BMC firmware configured to use the emulator to delegate control of hardware components it does not support to the instance of the older firmware. As the newer firmware is updated to support additional hardware components, the instance of the older firmware's control of those components is disabled. BMC commands are received and routed to the multiple firmware instances that support them for processing. <CIT> system includes a baseboard management controller (BMC), capable of online update of the BMC without shutting down any services. The BMC includes a processor, a volatile memory configured to perform multiple service instances, and a non-volatile memory storing a computer executable code and a root file system. The root file system includes multiple service modules as origin of the service instances. The computer executable code, when executed at the processor, is configured to: receive an update command and perform an update process based on the update command. The update process includes: copying the root file system from the non-volatile memory to the volatile memory; switching the origin of the service instances to the copy of the root file system; receiving an update root file system code; and writing the update root file system code to the non-volatile memory to obtain an updated root file system.

The object of the invention is to provide enhanced firmware updating for a baseboard management controller.

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

Accordingly to one implementation of the present disclosure, a system comprises a baseboard management controller (BMC). The BMC may comprise a processor and memory. The memory may include a non-volatile memory and a volatile memory. The non-volatile memory may comprise firmware categorized into a plurality of independently updatable service modules, each of the independently updatable storage modules being stored on a read-write (RW) partition of the non-volatile memory. Each of the independently updatable service modules may comprise at least one of an application, a library, and a driver. The memory may further comprise executable code that, when executed at the processor, is configured to perform a firmware update. The firmware update may include: receive a BMC update package for updating an existing service module stored in one of the plurality of RW partitions, where the BMC update package comprises an update service module; store the BMC update package in the volatile memory; and replace the existing service module stored in the RW partition of the non-volatile memory with the update service module.

According to another implementation of the present disclosure, a method of updating firmware of a BMC comprises: receiving a BMC update package comprising an update service module for updating an existing service module of the BMC, the service module being stored in one of a plurality of read-write (RW) partitions of a non-volatile memory of the BMC, each RW partition comprising an independently updatable service module, wherein each of the independently updatable service modules comprises 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 update service module; and restarting a service of the BMC associated with the update service module.

According to another implementation of the present disclosure, a method for transferring files to a baseboard management controller (BMC) comprises: receiving a command from a deployment agent instructing the BMC to enter into transfer mode; identifying a partition of volatile memory of the BMC and mounting the partition of the volatile memory to a host computing device connected to the BMC through a memory interface as a virtual memory drive; transferring a file from a host computing device to the BMC by storing the file in the volatile memory by way of a write operation to the virtual memory drive; and unmounting the partition of the volatile memory from the host computing device.

In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which are shown by way of illustration specific embodiments. These embodiments are described in sufficient detail to enable those skilled in the art to practice the technology, and it is to be understood that other embodiments may be utilized and that structural, logical and electrical changes may be made without departing from the scope of the disclosure. The following detailed description is therefore not to be taken in a limiting sense, and the scope is defined only by the appended claims. Like numbers in the figures refer to like components, which should be apparent from the context of use.

Various implementations of the present disclosure describe techniques for updating firmware of a BMC and transferring data between the BMC and a host computing device. The present subject matter describes a service-based update of a BMC in which the firmware of the BMC is partitioned into individually updatable service modules, allowing the BMC to be updated without having to rewrite an entire BMC blob image. For the purposes of explanation and not as a limitation, a service module is the origin of a service provided by the BMC and may include an individual BMC service or application (e.g., fan management service/application), drivers, and/or the library associated with the individual service or application.

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., SPI flash drive). The root file system of the BMC includes a plurality of executable applications and their libraries. When the BMC's firmware is treated as a monolithic binary blob, an update needed for a particular service provided by the firmware requires updating the entire firmware. For example, an update to the configuration of the BMC's firmware necessitates an update of the entire BMC firmware image, including each of the applications/services of the root file system.

Furthermore, an update to the entire BMC firmware requires a full BMC reboot/restart. This creates issues with respect to availability. For example, when the BMC resets, the BMC's critical functionality is not available for fabric management. Thus, if the network fabric to which the BMC is connected is monitoring BMC health status, and the BMC is not available because of an update or reset, the network fabric may determine that the BMC is unavailable and may put the hardware into an unhealthy state, further impacting availability.

In an aspect of the present subject matter, BMC availability is increased during a BMC update by dividing a non-volatile memory of the BMC into a plurality of read-write (RW) partitions that include independently updatable service modules. For example, the services provided by the root file system of the BMC may be categorized into individual service modules each stored on a different RW partition. The different service modules may each include an individual application, a grouping of applications, an application's libraries, an application and its libraries, etc. Having a plurality of RW partitions for different service modules allows independent updates to the services that the BMC provides. Thus, an entire restart of the BMC is not necessary, and system availability is increased.

In another aspect of the present subject matter, BMC availability may be increased by providing a high bandwidth protocol and a high bandwidth interface from a host computing device to the BMC to update BMC services. To do so, the BMC may mount a portion of its own volatile memory onto the host computing device as a virtual memory drive in order to transfer data at the native speed of the host computing device's memory drive, thus allowing data transfer of an update package to be completed in a shorter duration of time.

<FIG> illustrates a schematic of a computing system <NUM> for updating firmware of a BMC, in accordance with an example implementation of the present subject matter. Referring to <FIG>, the computing system <NUM> comprises a BMC <NUM> and a host computing device <NUM>. The BMC <NUM> is connected to the host computing device <NUM> via a high speed in-band interface <NUM> such as a universal serial bus (USB) interface. In addition, the BMC may be connected to an out-of-band network, such as a trusted LAN network in which the out-of-band nature of management traffic is ensured, via out-of-bound interface <NUM> (e.g., Intelligent Platform Management Interface/IPMI, Redfish Host Interface). In exemplary implementations, the BMC <NUM> may be further connected to computing device <NUM> through the in-band interface <NUM> and/or out-of-band interface <NUM>. Computing device <NUM> may be a remote server providing services for updating the BMC <NUM>.

The host computing device <NUM> may be a general purpose computer or a headless computer. Host computing device <NUM> may include a processor <NUM>, a memory <NUM> and communications connections <NUM>. The processor <NUM>, memory <NUM> and communications connections <NUM> may reside on a motherboard of the host computing device. In certain implementations, the BMC <NUM> may also be incorporated onto the motherboard of the host computing device <NUM>.

The memory <NUM> of the host computing device <NUM> may store machine readable instructions that the processor <NUM> may execute. The memory <NUM> may include a plurality of software applications including a host operating system (OS). The processor <NUM> is a host processor configured to control the operation of the host computing device <NUM>.

The BMC <NUM> is a specialized microcontroller that manages the interface between system management software and platform hardware. Different types of sensors may be built into the computer system <NUM>, and the BMC <NUM> reads these sensors to obtain parameters such as temperature, cooling fan speeds, power status, operating system (OS) status, etc. BMC <NUM> monitors and manages components of server hardware. Thus, it is preferable for the BMC's services to be available during the entire time the server is powered up.

The BMC <NUM> comprises a processor <NUM>, non-volatile memory <NUM>, volatile memory <NUM>, and update agent <NUM>. The processor <NUM> controls the operations of the BMC <NUM>. The processor <NUM> may execute firmware, such as boot loader <NUM>, kernel <NUM>, configuration <NUM> and root file system <NUM>, or other code stored in the BMC <NUM>. The processor <NUM> may also execute the update agent <NUM> for updating the firmware of the BMC. The update agent <NUM> may be machine readable code stored on the BMC's memory, such as the nonvolatile memory <NUM> and/or the volatile memory <NUM>, for performing an update of the firmware of the BMC <NUM>.

The volatile memory <NUM> is configured to store the data and information during the operation of the BMC <NUM>. In certain implementations of the present disclosure, the volatile memory <NUM> may include an update partition <NUM> used to perform an update of the firmware of the BMC <NUM>, which is described in more detail below. The volatile memory <NUM> may be random access memory (RAM).

The non-volatile memory <NUM> is a non-volatile data storage media for storing computer executable code and data required for the operation of the BMC <NUM>. The computer executable code and data may include firmware of the BMC <NUM>, such as boot loader <NUM>, kernel <NUM>, configuration <NUM> and root file system <NUM>, and other necessary firmware or software components of the BMC <NUM>. Examples of non-volatile memory may include flash memory (e.g., a serial peripheral interface (SPI) flash drive), USB drives, hard drives, or any other type of data storage device.

The boot loader <NUM> is a computer program that loads the kernel <NUM> of the BMC <NUM>. The boot loader <NUM> is loaded onto the volatile memory <NUM> from the non-volatile memory <NUM> and performs processes for booting up the BMC <NUM>, such as bringing the kernel <NUM> from the non-volatile memory <NUM> to the volatile memory <NUM> and providing the kernel <NUM> with information needed to operate. The boot loader <NUM> may then transfer control to the kernel <NUM>.

The kernel <NUM> is the operating system (OS) for the BMC. The kernel <NUM> manages I/O requests from software, and translates the requests into data processing instructions for the processor <NUM>. The kernel <NUM> mediates access to the BMC's <NUM> resources, including the processor <NUM>, non-volatile memory <NUM> and volatile memory <NUM>.

The configuration data <NUM> includes information and data that enables the BMC <NUM> to operate. The configuration data <NUM> may include the media access control (MAC) address of the BMC <NUM>, kernel boot parameters, environmental variables and other user specific files. The MAC address provides internet protocol (IP) information available for the BMC <NUM>, which allows network connectivity and network support of the BMC <NUM> to perform remote management. The kernel boot parameters and environmental variables allow the BMC <NUM> to properly run the kernel <NUM> and other monitoring and sensing programs.

The root file system <NUM> is where all of the applications/services reside. For example, the root file system <NUM> includes files for executing a plurality of services, such as a thermal management service, a fan speed service, IPMI service, power capping service, media redirection service, etc. The root file system <NUM> includes applications for performing services, libraries associated with the applications, drivers, etc..

In implementations of the present subject matter, the non-volatile memory <NUM> of the BMC <NUM> is separated into a plurality of independently updatable RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. Each of the RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N comprises a service module <NUM>, and the service module <NUM> comprises one or more files related to a service that is provided by the BMC <NUM>. The applications, libraries, and drivers of the root file system <NUM> may be categorized into different service modules <NUM> to allow independent updates of services according to the method of categorization. For example, each application of the BMC <NUM> may be separated into a different service module <NUM>, the libraries associated with the applications may be separated into different service modules <NUM>, and the drivers may be separated into different service modules <NUM>. In another configuration, each application and its library/libraries may be stored in a separate service module <NUM>, and the drivers may be separated into one or more service modules <NUM>. In another example, applications that are commonly updated together may be separated into their own service module <NUM>. Multiple configurations are possible, and the present disclosure is not limited to any particular configuration.

By separating the services into independently updatable different service modules <NUM> stored on RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N, it is possible to update a single service of the BMC <NUM> without having to update all of the BMC's <NUM> services during the update process. Furthermore, it is possible to reset a single service to implement its update without having to update the entire BMC <NUM>. Consider an example in which the BMC <NUM> reports a hardware error after diagnosing the hardware, and the error occurs because of the nature of the setup of the hardware rather than actual failure. For example, there is a bug in the hardware that causes the BMC <NUM> to see an error at a certain temperature rather than the actual temperature at which the error should be reported. When the BMC <NUM> is treated as a monolithic binary, the entire BMC <NUM> would need to be updated, which results in substantial unwanted downtime. By categorizing the services of the BMC <NUM> into different service modules and storing these service modules on separate RW partitions, the bug can be fixed by updating a single BMC service module rather than the entire BMC <NUM>. Furthermore, update errors may be reduced because the update is focused only on a single service rather than on the entire BMC <NUM>. Thus, one need not worry about an update error occurring in a service residing outside of the service module <NUM> that is being updated.

Although the RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N are shown in <FIG> with respect to the root file system <NUM>, the RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N and service modules <NUM> contained therein are not limited to the root file system <NUM> of the BMC's <NUM> firmware. The RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N and service modules <NUM> may also apply to other aspects of the BMC <NUM> firmware. For example, the configuration data <NUM> of the BMC's <NUM> firmware may also advantageously be its own service module <NUM> within an RW partition <NUM>-N, or may be divided into multiple service modules / RW partitions. For example, if a feature is disabled in the configuration data <NUM>, the configuration data <NUM> can be updated itself without having to update the entire BMC <NUM> by providing the configuration data <NUM> as its own RW partition <NUM>-N.

The update agent <NUM> performs an update process for the service module <NUM> being updated. The update agent <NUM> may be machine readable code stored on the BMC <NUM>. In implementations of the present disclosure, the update process may differ depending on whether the update is in-band or out-of-band. For the in-band update, the update package proceeds through the host computing device <NUM>. For the out-of-band update, the update package proceeds through a secure out-of-band connection <NUM> that is not exposed to the host computing device <NUM>.

For in-band communication, a BMC generally communicates with a host computing device using a protocol such as IPMI. However, such a protocol introduces protocol latency, as there is a certain amount of overhead added by the protocol. This is disadvantageous for updates, as the protocol latency increases the amount of time it takes to implement an update. Implementations of the present disclosure bypass this protocol overhead by taking advantage of the host computing device OS's native support for USB drives. In implementations of the present disclosure, the update agent <NUM> implements a special update mode process in which the BMC <NUM> enumerates a temporary update partition <NUM> onto the host computing device OS as a virtual memory drive <NUM>, such as a virtual USB hard disk drive, thereby providing a high bandwidth protocol and a high bandwidth interface from the host computing device <NUM> to the BMC <NUM> to update BMC <NUM> services.

In the update process performed by the update agent <NUM>, the update agent <NUM> may first receive a command from the update deployment agent <NUM> of the computing device <NUM> instructing the BMC <NUM> to enter into a special firmware update mode. When the update agent <NUM> receives the command, the update agent <NUM> mounts an update partition <NUM> of volatile memory <NUM> onto the host computing device <NUM> as a virtual memory drive <NUM>. Mounting the update partition <NUM> of volatile memory <NUM> onto the host computing device may involve the BMC using its virtual memory service (e.g., an IPMI virtual memory service) to mount the update partition to the host computing device <NUM> as a USB key so that data may be directly written to the update partition <NUM>. Once the update partition <NUM> is mounted onto the host computing device <NUM>, the update deployment agent <NUM> may navigate to the virtual memory drive <NUM> and write an update package that comprises an update service module to the virtual memory drive <NUM>. The BMC <NUM> thus receives the BMC update package and the update package is stored in the volatile memory <NUM> via the write operation performed by the update deployment agent <NUM>.

Once the update deployment agent <NUM> has completed writing the update package to the virtual memory <NUM> device, the update deployment agent <NUM> may transmit a command to the update agent <NUM> to indicate completion of the write operation. Upon receipt of the command, the update agent <NUM> may then unmount the update partition <NUM> from the host computing device <NUM>. The update agent may unmount the update partition <NUM> by, e.g., using its virtual memory service to unmount the update partition from the host computing device <NUM>. The update agent <NUM> may then replace an existing service module in the corresponding RW partition <NUM>-N of the non-volatile memory with the update service module included in the BMC update package.

In certain implementations of the present subject matter, the BMC update package received from the update deployment agent <NUM> may comprise a signed update service module. For example, the update deployment agent <NUM> may implement authentication techniques such as, for example, signature verification, key matching, and other such techniques. The authentication may aid in determining a valid update package and may thus protect the BMC <NUM> from security attacks. When such authentication techniques are used, the update agent <NUM> may authenticate the update package written to the update partition <NUM> of the volatile memory <NUM> prior to replacing the corresponding existing service module in the non-volatile memory <NUM> with the update service module.

In certain implementations of the present disclosure, the update agent <NUM> may include a timer <NUM>. The timer <NUM> may determine whether the time taken to write the update package to the update partition <NUM> exceeds a predetermined time. If the time taken exceeds the predetermined time, the update agent <NUM> may unmount the update partition <NUM> from the host computing device <NUM> and discard the update package for security purposes. For example, in the case of a compromised host computing device <NUM>, a bad actor may try to install malware of a large size. Implementing a timer <NUM> prevents such malware from being installed on the non-volatile memory <NUM> of the BMC <NUM>. In addition to, or instead of, timer <NUM>, the update agent <NUM> may also implement a size restriction on the size of any file being written to the BMC <NUM> by way of the virtual memory drive <NUM>.

Different from the in-band update process performed by the update agent <NUM>, for an out-of-band update, the update package proceeds through a secure out-of-band connection <NUM> that is not exposed to the host computing device <NUM>. In such a situation, the update deployment agent <NUM> may write the update package directly to the update partition <NUM>. In order to write the package directly to the update partition <NUM>, secure file transfer protocol (SFTP) may be implemented and used to transfer the update package to the update partition <NUM>. Once the update deployment agent <NUM> has completed the write process, the update deployment agent <NUM> may send a command to the update agent <NUM> indicating completion of the write process.

Similar to the in-band update process, in the out-of-band process the update deployment agent <NUM> may implement an authentication technique on the update package written to the update partition <NUM>. In this case, the update agent <NUM> may authenticate the update package written to the update partition <NUM> prior to replacing the corresponding existing service module in the non-volatile memory <NUM> with the update service module.

In implementations of the present subject matter, during the update processes described above, the existing service module may run from the volatile memory <NUM> while the update process is being performed. For example, when a service associated with a service module <NUM> is to be performed by the BMC <NUM>, the service module <NUM> may be transferred from its RW partition <NUM>-N in the non-volatile memory <NUM> to a portion of the volatile memory <NUM> other than the update partition <NUM>. The service module <NUM> may thus be executed from the volatile memory <NUM> while the update process is being performed.

<FIG> illustrates a flowchart depicting a method for transferring data from a host computing device <NUM> to a BMC <NUM>, in accordance with an example implementation of the present disclosure.

Referring to <FIG>, at block <NUM>, the BMC <NUM> receives a command to enter into a special transfer mode so that data may be transferred to the BMC <NUM>. The command may, for example, be sent by a deployment agent <NUM> of a remote computing device, such as computing device <NUM>, or by the host computing device <NUM>. The command may, for example, be sent to the BMC <NUM> using the IPMI protocol for in-band or the redfish protocol for out-of-band.

In general, data is transferred between the host computing device <NUM> and the BMC <NUM>, or between computing device <NUM> and the BMC <NUM> 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 the data. The special transfer mode is a mode in which the computer system <NUM> takes advantage of the native speed of a host computing device's <NUM> memory drive to transfer data between the host computing device <NUM> and the BMC <NUM>. For example, the host computing device <NUM> has the capability to mount a remote drive as a USB hard disk drive, and the BMC <NUM> may control this mounting operation. In the special transfer mode, the BMC <NUM> mounts its own volatile memory <NUM> to the host computing device <NUM>, thus facilitating the transfer of data between the host computing device <NUM> and BMC <NUM>.

In implementations of the present subject matter, the command to enter into a special transfer mode received by the BMC <NUM> may include information in addition to an indication that the BMC <NUM> should mount a partition of its volatile memory <NUM> onto the host computing device <NUM>. For example, the command may also include the size of the file that is to be written to the volatile memory <NUM>, so that the BMC <NUM> can allocate the proper amount of volatile memory to be mounted to the host computing device <NUM>.

At block <NUM>, the BMC <NUM> identifies a partition <NUM> in the BMC's <NUM> volatile memory <NUM> to mount to the host computing device <NUM> as a virtual memory drive <NUM>. In implementations of the present subject matter, the partition <NUM> may be reserved in advance for the data transfer mode, or the partition <NUM> may be a dynamically allocated memory partition. At block <NUM>, the BMC <NUM> mounts this partition <NUM> onto the host computing device <NUM> as a virtual memory drive <NUM> (e.g., a virtual USB hard disk drive).

At block <NUM>, data is stored in the volatile memory <NUM> of the BMC <NUM> by way of a write operation to the virtual memory drive <NUM>. For example, the virtual memory drive <NUM> may appear as a USB hard disk drive to the remote computing device <NUM> and/or the host computing device <NUM>. In order to transfer data to the BMC <NUM>, the host computing device <NUM> or the remote computing device <NUM> may write data to the virtual memory drive <NUM>, which in turn stores the data on the BMC's volatile memory <NUM>.

Once the write operation is completed, at block <NUM>, the BMC <NUM> unmounts the partition <NUM> from the host computing device <NUM>. In certain implementations of the present subject matter, the BMC <NUM> may receive a command from the host computing device <NUM> or the remote computing device <NUM> signaling that the write operation is complete and that the BMC <NUM> may unmount the virtual memory drive <NUM>.

In implementations of the present subject matter, the data transfer method described with reference to <FIG> can be useful in a variety of cases. For example, the data transfer mode may be useful in transferring telemetry data from the host computing device <NUM> to the BMC <NUM>. Furthermore, the data transfer mode may be useful in updating the firmware of the BMC <NUM>, an implementation of which will be described with reference to <FIG>.

<FIG> illustrates a flowchart depicting a method for updating firmware of a BMC, in accordance with an example implementation of the present disclosure. The process illustrated with reference to <FIG> may be referred to as an in-bound process, as data is transferred through the host computing device <NUM>.

Referring to <FIG>, at block <NUM> the BMC <NUM> receives an update command from the update deployment agent <NUM> of computing device <NUM> instructing the BMC <NUM> to enter into a special firmware update mode. The command may, for example, be sent to the BMC <NUM> using the IPMI protocol for in-band, the redfish protocol for out-of-band, or other applicable protocols. In implementations of the present subject matter, the special update mode is a mode in which the BMC <NUM> mounts a partition of its volatile memory <NUM> onto the host computing device <NUM> as a virtual memory drive <NUM>.

In certain implementations of the present subject matter, the command to enter into a special update mode received by the BMC <NUM> may include information in addition to an indication that the BMC <NUM> should mount a partition of its volatile memory <NUM> onto the host computing device <NUM>. For example, the command may also include the size of the update package that is to be written to the volatile memory <NUM>, so that the BMC <NUM> can allocate the proper amount of volatile memory to be mounted to the host computing device <NUM>.

At block <NUM>, the BMC <NUM> mounts an update partition <NUM> of its volatile memory <NUM> to the host computing device <NUM> as a virtual memory drive <NUM>. The virtual memory drive <NUM> may appear to the computing device <NUM> as a virtual USB hard disc drive.

In certain implementations of the present subject matter, when mounting the update partition <NUM> onto the host computing device <NUM>, the BMC <NUM> may assign the virtual memory drive <NUM> an identifier that is the same as the BMC's global unique identifier (GUID). The use of the GUID provides an additional layer of security to the update process. In such an implementation, the host computing device <NUM> may obtain the BMC's GUID prior to any mounting operation by way of the IPMI protocol. Thus, the host computing device <NUM> can match the GUID obtained by way of the IPMI protocol with the identifier of the virtual memory drive <NUM> to ensure that the virtual memory drive <NUM> is authentic.

At block <NUM>, the BMC <NUM> receives a BMC update package for updating an existing service module from the update deployment agent <NUM>. The BMC update package may include an update service module for replacing the existing service module. The BMC update package may be received through a high bandwidth protocol and high bandwidth channel, because the operation of mounting the update partition <NUM> to the host computing device <NUM> eliminates protocol overhead and instead utilizes the native speed of the host computing device's <NUM> memory drive.

In certain implementations of the present subject matter, the BMC package received from the update deployment agent <NUM> may include an update service module on which an authentication technique is employed. For example, the update deployment agent <NUM> may implement authentication techniques such as signature verification, key matching, and other such techniques. The authentication may aid in determining a valid update package and may thus protect the BMC <NUM> from security attacks.

At block <NUM>, the BMC update package is stored in the update partition <NUM> of the BMC's volatile memory <NUM>.

Receiving the update package and storing the update package in the update partition <NUM> may be accomplished by way of a write operation to the virtual memory drive <NUM>. For example, the update deployment agent <NUM> of the computing device <NUM> may have the BMC's GUID in advance of sending the update package. The GUID may, for example, be obtained by the update deployment agent <NUM> through the IPMI protocol in the case of in-band transmission and through the redfish protocol in the case of out-of-band transmission. The update deployment agent <NUM> may thus navigate to the virtual memory drive <NUM> having the same identifier as the BMC's <NUM> GUID. The update deployment agent <NUM> may then write the update package to the virtual memory drive <NUM>, which in turn transmits and stores the update package in the update partition <NUM> of the volatile memory <NUM>.

At block <NUM>, once the BMC update package is stored in the update partition <NUM> of the volatile memory <NUM>, the BMC <NUM> may unmount the update partition <NUM> from the host computing device <NUM>. In certain implementations of the present subject matter, the BMC <NUM> may unmount the update partition <NUM> in response to a command from the update deployment agent <NUM>. For example, the update deployment agent <NUM> may send a control packet through the in-band or out-of-band channel indicating that its write operation is complete, which in turn signals that the BMC <NUM> should unmount its update partition <NUM> from the host computing device <NUM>.

When the BMC update package received from the update deployment agent <NUM> is a BMC update package on which an authentication technique is employed, at block <NUM>, the BMC update package is authenticated prior to replacing the existing update service module with the update service module. The authentication may ensure that the update package is valid and may thus protect the BMC <NUM> from security attacks. To do so, the BMC <NUM> may employ various authentication techniques such as, for example, a public-private key pair to verify the authenticity of the update package. If the BMC <NUM> determines that the BMC update package is a valid package, the process proceeds to block <NUM>. If the BMC <NUM> determines that the BMC update package is invalid, the BMC update package is discarded.

At block <NUM>, the BMC <NUM> replaces an existing service module in the corresponding RW partition <NUM>-N of the non-volatile memory <NUM> with the update service module included in the firmware update package.

In certain implementations, the RW partition <NUM>-N that includes the existing service module may be one of a plurality of independently updateable RW partitions. That is, the non-volatile memory <NUM> of the BMC <NUM> may be separated into a plurality of independently updatable RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. Each of the RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N comprises a service module <NUM>, and the service module <NUM> is one or more files related to a service that is provided by the BMC <NUM>. For example, the applications, libraries, and drivers of the root file system <NUM> may be categorized into different service modules <NUM> to allow independent updates of services according to the method of categorization.

In certain implementations, the service associated with the existing service module <NUM> may be running in the BMC <NUM> while the existing service module <NUM> is being updated. For example, the existing service module <NUM> may be loaded into a portion of the volatile memory <NUM> other than the update partition <NUM>, and the processor <NUM> may execute the service module <NUM> from the volatile memory <NUM> during the update process to perform the service. Thus, there is no interruption to the current service while the update is going on in the background.

At block <NUM> the BMC <NUM> restarts the service associated with the updated service module, thereby executing the new application and/or libraries or drivers included in the updated service module. At this time, only the updated service is restarted, and all other services remain unaffected.

<FIG> illustrates a flowchart depicting a method for updating firmware of a BMC <NUM>, in accordance with an example implementation of the present disclosure. The flowchart illustrated in <FIG> shows an out-of-band method of updating the BMC firmware.

At block <NUM>, the BMC <NUM> receives a BMC update package for updating an existing service module from the update deployment agent <NUM>. For the out-of-band process, the BMC <NUM> receives the BMC update package by enabling SFTP. In this case, the update deployment agent <NUM> connects to the BMC <NUM> using SFTP, which initiates a connection to the BMC's <NUM> volatile memory <NUM>.

Similar to the in-bound process, in certain implementations of the present subject matter, the BMC update package received from the update deployment agent <NUM> may comprise an update service module on which an authentication technique is employed. For example, the update deployment agent <NUM> may implement authentication techniques such as, for example, signature verification, key matching, and other such techniques.

At block <NUM>, the BMC update package is stored in the update partition <NUM> of the volatile memory <NUM> of the BMC <NUM>. The BMC update package may be stored in the update partition <NUM> by way of a write operation performed by the update deployment agent <NUM> to the update partition <NUM> of the volatile memory <NUM>.

When the BMC update package received from the update deployment agent <NUM> is a BMC update package on which an authentication technique has been employed, at block <NUM>, the BMC update package is authenticated prior to replacing the existing update service module with the update service module. The authentication may ensure that the update package is valid and may thus protect the BMC <NUM> from security attacks. Similar to the in-bound process, the BMC <NUM> may employ various authentication techniques such as, for example, a public-private key pair to verify the authenticity of the update package. If the BMC <NUM> determines that the BMC update package is a valid package, the process proceeds to block <NUM>. If the BMC <NUM> determines that the BMC update package is invalid, the BMC update package is discarded.

At block <NUM>, the BMC <NUM> replaces an existing service module stored in a RW partition <NUM>-N of the non-volatile memory <NUM> with an update service module included in the BMC update package. Similar to the in-bound process, in certain implementations, the RW partition <NUM>-N that comprises the existing service module may be one of a plurality of independently updateable RW partitions <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N each having a service module <NUM> stored therein.

At block <NUM>, the BMC <NUM> restarts the service associated with the updated service module, thereby executing the new application and/or libraries or drivers included in the updated service module. At this time, only the updated service is restarted, and all other services remain unaffected.

Similar to the in-bound process, in certain implementations, the service associated with the existing service module may be running in the BMC <NUM> while the existing service module is being updated.

Computing system <NUM> may embody the BMC <NUM> or the computer system <NUM> of <FIG>. Computing system <NUM> 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., smart phone), and/or other computing devices, and wearable computing devices such as smart wristwatches and head mounted augmented reality devices.

Logic processor may, for example, embody the BMC processor <NUM> of <FIG>.

The logic processor <NUM> may include one or more physical processors (hardware) configured to execute software instructions. Additionally or alternatively, the logic processor <NUM> may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions.

Non-volatile storage device <NUM> may, for example, embody the non-volatile memory <NUM> shown in <FIG>.

Volatile memory <NUM> may, for example, embody the volatile memory <NUM> depicted in <FIG>.

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), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

The terms "module," "program," "mechanism," and "engine" may be used to describe an aspect of computing system <NUM> typically implemented in software by a processor to perform a particular function using portions of volatile memory, which function involves transformative processing that specially configures the processor to perform the function. It will 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. Likewise, 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..

It will be further understood that the terms "comprises," "includes," "has," "comprising," "including" and/or "having," when used in this specification, 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.

The corresponding structures, materials, acts, or step plus function elements, if any, in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. This description has been presented for purposes of illustration and description, but is not intended to be exhaustive or limiting in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the present disclosure. The embodiment was chosen and described in order to best explain the principles of the present disclosure and the practical application, and to enable others of ordinary skill in the art to understand the present disclosure for various embodiments with various modifications as are suited to the particular use contemplated.

Claim 1:
A system, comprising:
a baseboard management controller, BMC, (<NUM>) comprising:
a processor (<NUM>) and memory comprising a non-volatile memory (<NUM>) and a volatile memory (<NUM>), the non-volatile memory comprising firmware of the BMC, the firmware being partitioned into a plurality of independently updatable service modules (<NUM>) and the non-volatile memory being separated into a plurality of independently updateable read-write, RW, partitions (<NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-N), wherein each of the independently updateable RW partitions comprise a service module of the plurality of independently updateable service modules, wherein each independently updatable service module comprises at least one of an application, a library, and a driver, the memory further comprising executable code that, when executed at the processor, is configured to:
perform a firmware update comprising:
receive (<NUM>) a BMC update package for updating an existing service module of the plurality of independently updateable service modules, the existing service module being stored in one of the plurality of independently updateable RW partitions, the BMC update package comprising an update service module;
store (<NUM>) the BMC update package in the volatile memory;
replace (<NUM>) the existing service module stored in the RW partition of the non-volatile memory with the update service module; and
restart (<NUM>) a service of the BMC associated with the update service module.