TECHNICAL FIELD

The present disclosure relates generally to power-up routines for computing devices. More particularly, aspects of this disclosure relate to a system that boots from at least one of multiple remote basic input output system (BIOS) images.

BACKGROUND

Servers are employed in large numbers for high demand applications such as network based systems or data centers. The emergence of the cloud for computing applications has increased the demand for data centers. Data centers have numerous servers that store data and run applications accessed by remotely-connected, computer device users. A typical data center has physical chassis structures with attendant power and communication connections. Each rack may hold multiple computing servers and storage servers. Each individual server is typically powered-up with a power-on self-test (POST) routine to begin operation. During a POST routine for a computer system, such as a processor core on a server, the basic input output system (BIOS) is executed by the processor core to initialize the hardware of the server.

BIOS firmware (the BIOS image) is typically stored on a Serial Peripheral Interface (SPI) EEPROM on the motherboard of a server. The available space to store the BIOS image depends on the capacity of an EEPROM as per the hardware design. This limits the BIOS image size by the memory capacity of SPI EEPROM. Such limitations mean that there is a finite capacity to add modules or drivers to the stored BIOS firmware. Thus, the extension of features for BIOS firmware that may be incrementally added is constrained.

In order to increase flexibility, hardware designs may use two SPI EEPROMs to store multiple BIOS images for different situations requiring different features. Such a configuration allows the use of the larger EEPROM of the two EEPROMS to contain the larger BIOS firmware. However, the additional EEPROM will increase the cost of the hardware. Furthermore, the size of EEPROM is still limited for BIOS image storage if more BIOS images are desirable.

Upgrading or downgrading BIOS firmware is a complex process and requires 3 to 6 minutes depending on the size of the EEPROM. For a server system, upgrading BIOS is usually processed via a baseboard management controller (BMC). For such upgrades, the server manager needs to shut down the system; load the upgraded BIOS image into the BMC; erase the BIOS EEPROM; and then write the upgraded BIOS image into the EEPROM. When the upgrade is finished, the server manager needs to power-on the system to confirm if the BIOS upgrade is successful. Since the upgrade of BIOS firmware is complex and inflexible, BIOS upgrades currently only occur when a serious problem occurs. Especially for installations with numerous servers, such as a data center, BIOS firmware updates require significant amounts of time, therefore causing server service to be suspended. Delays in server availability are undesirable, as any delay increases the time a user must wait to complete tasks such as data processing or application execution. Such delays multiplied over the large numbers of servers in a data center can impede overall operation of the data center.

FIG. 1is a prior art structure of a BIOS image stored on an EEPROM of a flash memory12on a motherboard10. The flash memory12is divided into a descriptor region20, a management engine (ME) region22, a 10GBE A region24, and a BIOS region26. The descriptor region20includes description information for the BIOS image. The ME region22stores code for an embedded management controller. The 10 GBE A region24stores code for a 10 GbE controller for a platform control hub (PCH). The BIOS region26stores a BIOS image30.

The BIOS image30includes a non-volatile RAM (NVRAM) region32for storing data. The BIOS image30also includes a driver execution environment/boot device selection (DXE/BDS) area34, a pre-EFI initialization (PEI) area36, and a security (SEC) area38. Each of the areas34,36, and38store code for executing respective different BIOS functions of execution environment/boot device selection, pre-EFI initialization and authentication.

FIG. 2is a prior art hardware diagram of the components used in a boot-up process using the BIOS.FIG. 2thus shows different components of the motherboard10inFIG. 1and the process of booting from the BIOS image in the flash memory12. The motherboard10includes a CPU40, a system memory42, a platform hub controller (PCH)44, and the BIOS flash memory12.

The boot process begins when the system is powered on. The PCH44maps the security and pre-EFI initialization (SEC/PEI) code from the BIOS image on the flash memory12to an internal cache60of the CPU40. The CPU40uses the internal cache60as random access memory (RAM) to execute the SEC/PEI code. The BIOS loads the remaining code (DXE/BDS) from the SPI EEPROM of the flash memory12into the system memory42. The CPU40then executes the remaining BIOS code on the system memory42until the power on self-test (POST) routines ends and the BIOS boots to the operating system (OS). The BIOS code for such prior art systems is constrained by the size of the EEPROM on the flash memory12. Thus, updates for the BIOS code cannot be readily adopted. Further, other BIOS images cannot be used because of space constraints.

Thus, there is a need for a system that includes a motherboard that may be used in a series of products, with no need to update the BIOS on the motherboard. There is a need for a system that does not require a larger EEPROM as the firmware of the BIOS increases in size. There is also a need for unified control of the BIOS firmware version via a baseboard management controller regardless of the BIOS version on the motherboard. There is a further need for a system that allows different BIOS images to be used.

SUMMARY

One disclosed example is a system including an electrically erasable programmable read-only memory (EEPROM) storing a minor BIOS image. The system includes a system memory and a central processing unit having a cache. The central processing unit is operable to execute code from the minor BIOS image on the cache to initialize the system memory. A remote site stores a major BIOS image. A controller loads code from the major BIOS image to the system memory. The central processing unit executes the code from the major BIOS image to boot an operating system.

A further implementation of the example system is where the controller is a baseboard management controller. Another implementation is where the major BIOS image is selected from one of a plurality of major BIOS images stored at the remote site. Another implementation is where the remote site is a controller accessible memory. Another implementation is where the remote site is a network accessible device coupled via a network to the controller. Another implementation is where the minor BIOS image supports one of a plurality of different modes that boot the operating system if communication to the controller is not established. Another implementation is where the minor BIOS image includes a driver execution environment/boot device selection (DXE/BDS) area, and the central processing unit is operable to load code from the DXE/BDS area of the minor BIOS image if communication to the controller is not established. Another implementation is where the minor BIOS image includes a non-volatile random access memory area, a pre-EFI initialization (PEI) area, and a security area. Another implementation is where the major BIOS image includes a driver execution environment/boot device selection (DXE/BDS) area. Another implementation is where the major BIOS image is one of a BIOS version for a generation of the CPU, a debug BIOS version, a test BIOS version, a special BIOS version, or a BIOS patch.

Another disclosed example is a method for booting a computer system is disclosed. Code is loaded from a minor BIOS image stored on an electrically erasable programmable read-only memory (EEPROM) to a cache of a central processing unit. The central processing unit executes the code from the minor BIOS image to initialize a system memory. A major BIOS image is accessed from a remote site via a controller. Code from the major BIOS image is loaded to the system memory. The code from the major BIOS image is executed via the central processing unit to boot an operating system.

Another implementation of the example method is where the controller is a baseboard management controller. Another implementation includes selecting the major BIOS image from one of a plurality of major BIOS images stored at the remote site. Another implementation is where the remote site is a controller accessible memory. Another implementation is where the remote site is a network accessible device coupled via a network to the controller. Another implementation is where the minor BIOS image supports a mode to boot the operating system if loading the code from the major BIOS image fails. Another implementation includes determining if communication to the controller is not established; and executing driver execution environment/boot device selection (DXE/BDS) from a DXE/BDS area of the minor BIOS image. Another implementation is where the minor BIOS image includes a non-volatile random access memory area, a pre-EFI initialization (PEI) area, and a security area. Another implementation is where the major BIOS image includes a driver execution environment/boot device selection (DXE/BDS) area. Another implementation is where the major BIOS image is one of a BIOS version for a generation of the CPU, a debug BIOS version, a test BIOS version, a special BIOS version, or a BIOS patch.

The above summary is not intended to represent each embodiment or every aspect of the present disclosure. Rather, the foregoing summary merely provides an example of some of the novel aspects and features set forth herein. The above features and advantages, and other features and advantages of the present disclosure, will be readily apparent from the following detailed description of representative embodiments and modes for carrying out the present invention, when taken in connection with the accompanying drawings and the appended claims.

