TWI754317B - Method and system for optimal boot path for a network device - Google Patents

Abstract

A system and method for providing multiple options for booting-up a remote computing device is disclosed. The system has a remote management station, in network communication with a computing device. The computing device has hardware components and a Unified Extensible Firmware Interface (UEFI) basic input output system (BIOS), including multiple power-on self-test (POST) routines. A controller is in communication with the UEFI BIOS and in network communication with the remote management station. The controller receives a selection of one of the plurality of POST routines from the management station. The controller boots up the computing device with the selected POST routine. The POST routines include a normal POST and other specialized routines such as a fast boot option, a safety boot option, a diagnostic boot option and a factory boot option.

Description

Method and system for optimal boot paths for network devices

The present invention relates to a startup program for a computing device. More particularly, the present invention relates to a system that includes a plurality of boot options to bypass selected modules to facilitate fast booting of network devices.

Servers are heavily used in high-demand applications such as web-based systems or data centers. The advent of cloud applications for computing applications has increased the demand for data centers. A data center has many servers that store data and run applications that are accessed by users of computing devices over remote connections. A typical data center has a physical rack structure with corresponding power and communication connections. Each rack can hold multiple compute and storage servers.

Servers in data centers provide businesses with many services, including executing applications, providing virtualization services, and facilitating Internet commerce. As companies increasingly rely on these services from data center servers, stable uptime becomes increasingly important and valuable. When servers are down, productivity is reduced or stopped altogether, reducing the profitability of the business. Although data center administrators take all precautions to prevent Failure to interrupt service, but the problem of server downtime is difficult to completely eliminate. The main reasons for server downtime may include server hardware failures, hardware upgrades, software upgrades, and incidents or server maintenance caused by cyber attacks. Considering the potentially high and disruptive cost of mass downtime, data center management often develops plans to deal with server downtime and tailors different contingencies to the cause of the downtime. However, when restoring servers, each server must be restarted. Typically, each server is powered on through a power-on self-test (POST) procedure to begin operation. During the POST procedure of a computer system (eg, a processor core on a server), the processor core executes a basic input output system (BIOS) to initialize the server's hardware. The process of restarting can take a lot of time, especially when multiple servers are down for reasons such as software or hardware upgrades.

Therefore, there is a need for a system that includes a boot option to eliminate certain unnecessary processes to speed up the POST procedure of the boot path. There is also a need for an enable option that allows diagnostics for the server both in-band and out-of-band. There is also a need to provide different startup options for scenarios commonly found in data centers, factories, or service centers.

According to one embodiment of the present invention, a system and method for enabling a remote computing device to provide multiple options is disclosed. The system has a remote management station, a network and a computing device. The network communicates with the remote management station. The computing device has multiple hardware components and a unified extensible firmware interface (unified extensible firmware interface, UEFI) Basic Input Output System (BIOS). UEFI BIOS includes several power-on self-test (POST) procedures. The controller communicates with UEFI BIOS and network communication with remote management station. The controller is used to receive a selection of one of a plurality of POST procedures from the management station. The controller is used to start the computing device using the selected POST procedure. The POST procedure includes a general POST procedure, a pre-extensible firmware interface (pre-EFI) initialization environment stage, a driver execution environment stage, a boot device selection stage, and a transient system loading stage . A typical POST procedure has a security phase. The pre-EFI initialization environment phase is used to initialize and configure the hardware components of the computing device. The POST procedure further includes a second different POST procedure.

In one embodiment, the controller is a baseboard management controller. In another embodiment, the computing device is a server. In another embodiment, the management station sends the selection of the POST procedure via in-band communication of the computing device. In another embodiment, the management station sends the selection of the POST procedure via out-of-band communication from the computing device. In another embodiment, selection is made through UEFI variables. In another embodiment, the second POST procedure is a fast boot that includes bypassing initialization and configuration of at least some hardware components of the computing device and using data structures stored in persistent memory from the normal POST procedure to Restore the scratchpad of the computing device. In another embodiment, the second POST procedure is a secure boot that includes reading the evaluation report of the failed hardware component to determine a functional hardware component, disabling the failed hardware component, and initializing a functional hardware component. hardware components. In another embodiment, the second POST procedure is a factory provisioning start, which includes loading a firmware configuration, disabling an error correction mechanism, and performing a stress test on hardware components. In another embodiment, the second POST procedure is a diagnostic option that includes collecting debug messages from a security test of the computing device, and Collects hardware error status data for hardware components. In another embodiment, the debug messages are generated by a JTAG host connected to a joint test action group (JTAG) scan chain.

According to another embodiment of the present invention, a method for selecting a startup program for a computer device is provided. A selection of one of a plurality of power-on self-test (POST) procedures is transmitted over a network from a remote management station to a computing device. The computing device includes a controller, a plurality of hardware components, and a Unified Extensible Firmware Interface (UEFI) Basic Input Output System (BIOS). The UEFI BIOS includes a plurality of POST programs. Receive a selection of one of several POST procedures from a remote management station on the controller. The computing device is powered on using the POST procedure of choice. The plurality of POST procedures include a general POST procedure, a pre-EFI initialization environment stage, a driver execution environment stage, a boot device selection stage, and a transient system loading stage. A typical POST procedure has a security phase. The pre-EFI initialization environment phase is used to initialize and configure the hardware components of the computing device. The plurality of POST procedures further includes a second different POST procedure.

In one embodiment, the controller is a baseboard management controller and the computing device is a server. In another embodiment, the selection of the POST procedure is sent via in-band communication with one of the computing devices. In another embodiment, the selection of the POST procedure is sent via out-of-band communication of the computing device. In another embodiment, the selection is made by setting a UEFI variable. In another embodiment, the second POST procedure is a fast boot that includes bypassing initialization and configuration of at least some hardware components of the computing device and using data structures stored in persistent memory from the normal POST procedure to Restore the scratchpad of the computing device. In another embodiment, the second POST procedure is a secure boot that includes a hard drive to read the failure. evaluation reports of the hardware components to determine functional hardware components, disable faulty hardware components, and initialize functional hardware components. In another embodiment, the second POST procedure is a factory supply start, which includes loading a firmware configuration, disabling an error correction mechanism, and performing a stress test on hardware components. In another embodiment, the second POST procedure is a diagnostic option that includes collecting debug messages from security testing of the computing device and collecting hardware error status data for hardware components.

The above summary is not intended to represent each embodiment or every aspect of the present invention. Rather, the foregoing summary provides examples of some of the novel aspects and features set forth herein. In order to have a better understanding of the above-mentioned features, advantages and other features and advantages of the present invention, embodiments are given below and described in detail with the accompanying drawings as follows.

100: Start the system

102: Remote Server Management and Service Station

104: Internet

106: Server

110: Baseboard Management Controller (BMC)

112: Web Interface Controller

120: Unified Extensible Firmware Interface (UEFI) Basic Input Output System (BIOS)

130, 132, 134: Hardware Components

136: Persistent memory

140: Operating System (OS)

142: Universal Serial Bus (USB) port

200: Schematic

210: Security Phase

212: PEI stage

214: DXE stage

216: BDS Stage

218:TSL Stage

220: Pre-validator

222: Ucode Patching

224: Silicon Security Program

230:UPI/XGMI topology discovery process

232: Start memory reference code process

234: Initial Platform Porting Process

240: Device, bus or service driver

242: PCI scan and resource allocation process

244: Create startup and runtime service procedures

246: Publish ACPI and SMBIOS table procedures

250: Start the dispenser process

252: Scan bootloader process

260: Transient operating system boot loader process

262: Operating system switching process

300: BMC system error log file

302 Memory Error Correction Code (ECC)

304: CPU machine check exception error (MCERR)

306: PCIe uncorrectable

308: high temperature

400: table

410: BIOS attribute registration request

420: Description

500: RESTful or IPMI channel

510: Turn on standby power

512: BMC start

518:POST start

524: POST end

514,516,520,522,526,528,610,612,614,616,618,620,622,624,626,628,630,632,634,640,644,646,648,650,652,710,712,714,716,718,720,722,724,726,728,730,732,734,736,738,740,810,812,814,816,818,820,822,824,826,828,910,912,914,916,918,920,922,924,930,932,934,936,938,940,942,944,946: Step

600,700,800,900: Flowchart

For a better understanding of various aspects of the present invention, the following detailed description will be provided with the accompanying drawings. It is to be noted that these drawings depict only exemplary embodiments and are therefore not to be considered limiting of the scope of the various embodiments or claims.

Figure 1 shows a block diagram of a system with an activation optimization procedure in accordance with an aspect of the present invention.

FIG. 2 illustrates a schematic diagram of different functions accessed through different activation paths in accordance with an aspect of the present invention.

FIG. 3 illustrates a schematic diagram of the functionality of the BMC and UEFI BIOS during a diagnostic boot procedure according to an aspect of the present invention.

Figure 4 shows Redfish JSON for boot path options according to an aspect of the present invention data table.

FIG. 5 shows a schematic diagram of the communication flow of the POST procedure for the selected startup path according to an aspect of the present invention.

Figure 6 illustrates a flow diagram of general and quick start POST program options in accordance with an aspect of the present invention.

Figure 7 illustrates a flow diagram of a secure boot POST program option in accordance with an aspect of the present invention.

Figure 8 illustrates a flow diagram of a factory-supplied POST program option in accordance with an aspect of the present invention.

Figure 9 illustrates a flow diagram of a diagnostic launch POST program option in accordance with an aspect of the present invention.

The present invention is capable of various modifications and alternative forms. Some representative embodiments of this invention have been shown by way of example in the accompanying drawings and will now be described in detail. It should be understood, however, that the invention is not limited to the specific forms disclosed. On the contrary, this invention covers all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

The present invention may be embodied in many different forms. Representative embodiments are shown in the accompanying drawings and will be described in detail herein. This disclosure is intended to illustrate or illustrate principles, and not to limit the disclosure to the embodiments shown. Elements and limitations, such as those disclosed in the Abstract, SUMMARY, and EMBODIMENT sections but not expressly set forth in the scope of the claims, should not be incorporated into the scope of the claims, either individually or collectively, by implication, inference. For the purposes of the detailed description of the present invention, unless specifically stated otherwise, the singular includes the plural and vice versa. The word "including" means "including but not limited to". In addition, terms such as "about", "almost", "substantially", Approximate words such as "approximately" to mean, for example, "at", "adjacent to" or "near" or "within 3-5%" or "within acceptable manufacturing tolerances" "within" or any logical combination thereof.

Embodiments disclosed herein include a system for providing various options for a power-on self-test (POST) procedure of a server's boot path. Various options include options to reduce POST procedure time by bypassing certain initialization steps. Options include out-of-band diagnostics without changing server configuration.

FIG. 1 shows a startup system 100 that allows different options for the startup path of a server. The startup system 100 includes a remote server management and service station 102, a network 104, and a remote computing device (eg, a server 106). The remote server management and service station 102 is accessible to data center operators. The remote server management and service station 102 allows a data center operator to access a management interface to allow the operator to perform remote diagnostics of the server 106 or to set a boot routing policy through out-of-band boot, as described below. The remote server management and service station 102 may generate control signals for the activation path of the server 106 through the network 104 .

The server 106 includes a baseboard management controller (BMC) 110 . The BMC 110 includes a network interface card or a network interface controller 112 , which is coupled to the network 104 . The BMC 110 is coupled to a boot firmware 120, such as a Unified Extensible Firmware Interface (UEFI) Basic Input Output System (BIOS). Server 106 includes hardware components 130, 132, and 134 that perform functions such as storage, computation, and switching. For example, the hardware component 130 may be a central processing unit (CPU). Other hardware components 132 and 134 may be other processors, memory devices, peripheral component interconnect express (PCIe) device slots, and the like. As shown in FIG. 1, only three hardware components are shown, and it is understood that there may be more hardware components on a typical server. In this embodiment, the server 106 includes a persistent memory 136, such as a Flash memory or an I2C EEPROM, which can be partitioned for different purposes, such as storing UEFI BIOS 120.

The BMC 110 reads the policy for the activation path obtained from the remote server management and service station 102 . Startup firmware 120 optimizes hardware initialization of hardware components of server 106 (eg, hardware components 130 , 132 , and 134 ). BMC 110 may also perform hardware diagnostics on hardware components of server 106 (eg, hardware components 130 , 132 , and 134 ). BMC 110 may further monitor the health of hardware components of server 106 (eg, hardware components 130 , 132 , and 134 ). An operating system (OS) 140 starts the operation of the server 106 when the POST procedure of the startup path is completed. Server 106 also includes a Universal Serial Bus (USB) port 142 .

FIG. 2 shows a schematic diagram 200 of different available functions during the transition from power-on to platform initialization to boot-up, which may be implemented according to the boot options of an embodiment of the present invention. Diagram 200 shows the different sequential stages of the POST procedure of the startup path. Thus, the first row 210 represents a security phase. The second row 212 represents an extensible framework interface (EFI) environment initialization (PEI) phase. The third row 214 represents a driver execution environment (DXE) stage. The fourth row 216 represents a Boot Device Selection (BDS) phase. The fifth row 218 represents a transient system load (TSL) phase.

The security phase 210 is initiated by a pre-verifier 220 . The pre-verifier 220 applies the Ucode patch 222 and enables silicon-based security routines 224. The PEI stage 212 includes a UPI/XGMI topology discovery process 230 , an initial memory reference code process 232 and an initial platform porting process 234 . In this embodiment, some boot path options may bypass the memory reference code process 232.

A set of drivers 240 (eg, device drivers, bus drivers, or service drivers) implements the DXE stage 214 . Each driver is executed in sequence until the end of the DXE stage 214. This phase includes a PCI scan and resource allocation process 242, a create startup and runtime services process 244, and a publish ACPI and SMBIOS table process 246. All processes 242, 244 and 246 may be bypassed by certain boot path options.

Boot device selection phase 216 includes a boot allocator process 250 and a scan boot loader process 252 . Transient system load (TSL) phase 218 includes a transient OS boot loader process 260 and an OS switch process 262 . At the conclusion of the transient system loading phase 218, control is transferred to an OS boot loader (eg, Linux GRUB), and the operating system 140 is booted and started.

The embodiment of the present invention provides multiple options of the POST startup path, and each option has a different POST procedure. In an embodiment, the POST boot path options include a general boot option, a fast boot option, a secure boot option, a factory-supplied option, and a hardware diagnostic option. These options may be manipulated by applications that access OS 140 on server 106 through an in-band implementation. The application will allow the operator to select startup options for the server 106 . These options can also be manipulated by an out-of-band implementation that receives commands from the BMC 110 of the server 106 over the network 104 . The Fast Boot and Safe Boot options bypass some of the processes shown in Figure 2 to increase the speed of the boot operation.

For example, the fast boot option provides the shortest POST time to boot into the operating system (OS) 140 and enable a network device (eg, server 106 in FIG. 1 ) to run. Some initialization and configuration of hardware components is bypassed. If there are no hardware changes on the server 106, the UEFI BIOS 120 restores the settings. For example, if software patching is added to OS 140, then The server will restart. The restart procedure can skip unnecessary initialization of hardware components and restore hardware settings.

Among the hardware diagnostic options, UEFI BIOS 120 and Baseboard Management Controller (BMC) 110 are responsible for troubleshooting and reporting information to server 106 in FIG. 1 . In this option, no software configuration or hardware configuration is changed, so the diagnostic option has little impact on the data center environment.

FIG. 3 is a schematic diagram of the functioning of the components of the server 106 during the hardware diagnostic start-up process. When server 106 is powered on, UEFI BIOS 120 performs POST package repair, enables firmware debug messages, and detects input/output speed and link width. The BMC 110 checks the health of hard disk drivers and backplane components. The BMC 110 identifies all firmware versions on the server 106 . The BMC 110 dumps the CPU error register of the server 106 . The BMC 110 checks the server 106 temperature data, fan speed and voltage.

After booting up and performing the above-mentioned initial functions, the UEFI BIOS 120 loads the ISO image from the USB port of the BMC 110 . This is a special feature of the BMC 110, which can emulate a USB port (by linking between the host USB port 142 and the BMC port) as a standard USB bootable image. For example, the ISO image can be stored on a USB compatible memory device inserted into the USB port 142 . This ISO bootable image can contain embedded Linux OS + debug tools + script files. Therefore, the UEFI BIOS 120 can recognize the ISO image as the same as other USB-linked bootable devices. The ISO image can be booted from the USB port to execute script files from the embedded Linux OS. UEFI BIOS 120 runs a boot diagnostic operating system and runs script files. UEFI BIOS 120 stresses the server and collects BMC system error log files 300. System error log file 300 may include entries determined by UEFI BIOS 120, such as a memory error correction code (ECC) entry 302, a CPU Machine Check Exception (MCERR) error item 304 , a PCIe uncorrectable item 306 or a high temperature item 308 .

In general, the general POST program options for the boot path include all the processes listed in the schematic diagram 200 of FIG. 2 . These processes must be processed in the sequence shown in FIG. 2 until the operating system 140 in FIG. 2 loads. The main purpose of the general POST procedure of the boot path is to initialize the hardware components to a ready state and to prepare the platform-dependent data structures for the operating system. The initialization of hardware components is a complex process. Initialization starts with a security check, followed by hardware component detection, followed by programming of the hardware registers. The POST of the boot path of the general options is usually a fixed sequence, and it is also true for the large-scale various hardware components and software requirements. The time it takes to boot the path depends on the hardware components and the number of bootable devices.

The system disclosed in the embodiment of the present invention includes other POST procedures of the startup path. These options include fast boot options, safe boot options, factory supply options and hardware diagnostic options. These options can be manipulated through in-band and out-of-band control of the server 106 . In-band control is performed through the interface of the host system of server 106, while out-of-band control is performed through BMC 110 communicating with a remote device such as station 102 in FIG. 1 from a remote IPMI interface. Different POST procedures for some startup path options speed up server restart times and also provide flexible operating options for operators of data centers, service stations, or factories.

Therefore, the general boot option is the combined POST boot sequence. The UEFI BIOS firmware 120 in FIG. 1 enables the root of trust secure path, initializes all hardware components of the server 106 , creates the bootable device path, and establishes platform dependencies before loading the operating system 140 data structure. The UEFI BIOS 120 includes boot options and reads the UEFI variables to perform the general POST procedure of boot path selection. General startup options are comprehensive POST sequence, except that the UEFI BIOS 120 must complete all necessary hardware initialization and prepare platform information for the OS. In general boot options, UEFI BIOS 120 also stores required hardware scratchpad contents, required UEFI boot element contents, and required OS information contents into persistent memory 136 .

The server 106 performs a normal startup when the data center starts up for the first time. The general startup options are also executed when the data center operator changes the hardware configuration or replaces a replaceable unit of the server 106 .

In this embodiment, UEFI BIOS variables, BMC variables, and OEM IPMI commands or the Redfish AttributeName of RegistryEntries determine which POST program option of the boot path is selected in-band or out-of-band. The BMC variables allow the BMC 110 to obtain boot options from an external device (eg, the service station 102 in FIG. 1). UEFI BIOS 120 reads the values of UEFI variables to determine which boot path to execute. UEFI variables are set via OEM IPMI commands or Redfish commands from BMC 110. Redfish repositories (AttributeName of ResiryEntries) have priorities and dependencies to determine the final startup path selection. AttributeName is the name variable and RegistryEntry is the name repository in Redfish. Through the commands shown in these embodiments, the server management of the data center and the operating system 140 of the server 106 can directly receive the POST options, and then set the POST procedure of the startup path. These commands may set the selected launch path on the server 106 until a new POST option to launch the path is issued by the data center operator or by an application on the server 106 . So the first example OEM IPMI command REQ is "Get POST ofBootpath". This command is the communication protocol between UEFI BIOS 120 and BMC 110. UEFIBIOS 120 uses this command to retrieve requests issued by remote data center operators and to set UEFI BIOS variables for selected boot options. The set variables are used to retrieve configuration parameters The number and startup path options are returned to the POST program. This variable is affected by the result of an in-band programming or out-of-band programming command from the BMC 110. The priority of the get command is mandatory. In this example, NetFN ix is 0x30 and CMD is 0xDA. The second OEM IPMI command REQ is "Set POST of Boot path", which is a POST for setting configuration parameters and boot paths. The priority of the set command is mandatory. In this example, NetFN is 0x30 and CMD is 0xDB.

Figure 4 is a table 400 of Redfish JSON data for boot path options of an embodiment, which may be used in place of an OEM IPMI command. Table 400 includes a BIOS attribute registration request 410 and a corresponding description 420 . As can be seen in the description, the value name determines which startup path is used for POST. The POST procedure selected from normal boot, fast boot, safety boot, factory provision and diagnostic will depend on the value name selected.

FIG. 5 is a communication flow diagram of the POST procedure for the selected boot path between the UEFI BIOS 120 , the BMC 110 and the operating system 140 or the network data center management station 102 . A communication channel (eg, RESTful or IPMI channel 500 ) can be used as an out-of-band mechanism to exchange commands between server management station 102 and BMC 110 and between BMC 110 and UEFI BIOS 120 . An in-band mechanism may exchange commands from operating system 140 to BMC 110 .

The standby power is first turned on (510). This causes the BMC 110 to be activated (512). The operator of the data center sets the POST procedure for the selected activation path (514). The settings of the POST procedure are passed to the BMC 110 via the RESTful or IPMI channel 500 . UEFI BIOS 120 reads the POST procedure of the selected boot path from RESTful or IPMI channel 500 and saves it as a UEFI variable (516). Then, the selected POST procedure is initiated (518). Then, the UEFI BIOS 120 executes the UEFI POST procedure according to the boot path options received from the BMC 110 (520). UEFI BIOS 120 sends the status of the POST procedure of the boot path to BMC 110 (522). The POST procedure then ends (524), allowing operating system 140 to be started (524). The operator of the data center can read the current options for the POST procedure of the initiation path (526) through the management and service station 102. The data center operator can also read through the management and service station 102 the latest status of the POST procedure for the selected activation path (528).

The fast boot option is the most efficient POST boot sequence of the boot options. Among the fast boot options, UEFI BIOS firmware 120 enables the root of the trusted secure path, initializes fewer but important hardware components of server 106, restores hardware scratchpad using data structures copied in the previous normal boot path Server and legacy memory content, and loaded into the operating system 140 with a fixed bootable device. If there are no hardware configuration changes, the fast boot option is more efficient than the normal boot option. For the fast boot option, UEFI BIOS 120 only performs mandatory hardware initialization. The desired content is restored from persistent storage 136 to the hardware components, and then loaded into the operating system from the fixed bootable device. Therefore, UEFI BIOS 120 copies the hardware component configuration and the settings of complex hardware registers into the reserved space of persistent storage 136 . During fast boot options, the UEFI BIOS 120 reuses this information to program hardware components instead of performing serial initialization of the components. Therefore, stored settings such as signal timing, PCIe bus link width and PCIe speed are loaded instead of determining these settings from hardware components.

Executes the quick start option when a server restart occurs in the data center due to an upgrade or downgrade of operating system software. A fast start is also performed when the server restarts without any changes to the hardware configuration. Compared with the general POST procedure, the quick start option can save about 30% time in the POST procedure.

The secure boot option is a flexible POST boot sequence in which the UEFI BIOS firmware 120 reads from the BMC 110 an estimated report of server 106 hard faults. In the secure boot option, the UEFI BIOS firmware 140 automatically disables hardware components upon hard faults, initializes the server 106 for healthy and functional hardware components, creates a usable bootable device path, and before loading the operating system Establish a platform-related data structure. The server management station 102 in the data center disables interfaces for bad and/or faulty hardware components, such as processors (core sockets disabled), memory (DIMM sockets disabled), PCIe IO (PCIe sockets disabled), and onboard devices interface. The secure boot program then initializes the remaining hardware components until the operating system 140 is successfully loaded.

The main purpose of secure boot is to restore the online state of the server 106 . The Safe Boot option allows data center operators to retrieve critical business information for data backup and migration when a failed hardware component is disabled and loaded into the operating system. Execute the secure boot option when a server restart occurs in the data center due to a hardware failure. When a hardware failure occurs, data center operators often wish to retrieve critical data from server 106 and then repair the failed hardware component. Compared with the general POST procedure, using the secure boot option can save about 30% of the POST procedure time.

The factory-supplied boot option is the only POST boot sequence for UEFI BIOS firmware 120. Factory-supplied startup options load firmware settings and enable specific hardware configurations for stress testing of the server 106 based on production line requirements. The factory-supplied option sequence saves the POST program selection of the boot path to the UEFI BIOS variables, starts initialization, and reads the UEFI variables. Then, the UEFI BIOS 120 automatically loads the default firmware configuration. UEFI BIOS 120 provides security feature enablement and disables error correction for stress tests for bad hardware component identification and eradication mechanisms. when A factory supply start occurs when a server is started or restarted in a factory's production line. The factory-supplied start-up option can save about 10% of the POST procedure time compared to the normal POST procedure.

The hardware diagnostic option is a troubleshooting POST boot sequence for scheduled maintenance at the data center and scheduled maintenance at the service station. The hardware diagnostic sequence saves the selected POST procedure of the boot path to the UEFI BIOS variables, starts initialization, and reads the UEFI variables. Because software and hardware changes are prohibited, both UEFI BIOS 120 and BMC 110 must implement new and independent diagnostic services without having access to customer confidential data and information. The main purpose of the hardware diagnostics option is to collect all debug messages for security testing, all hardware error status data for server 106 (eg, processor, PCIe devices, peripheral storage, and peripheral IO devices), and server 106 runtime the system error log. Data center operators can use this data to perform hardware failure analysis and determine the root cause. Therefore, the hardware diagnostics option checks hardware health. For example, adjustments to the operating system user-level configuration can be made to install additional support functions and software. However, such a change could be a cause for concern as it runs counter to the data center usage model. Therefore, hardware diagnostics must be performed in a separate operating system environment that does not access the software configuration of the host operating system of server 106 .

In the hardware diagnostic options, UEFI BIOS 120 enables the maximum debug level. In the diagnostic option, the UEFI BIOS firmware 120 exposes all levels of debug messages to the BMC 110 of the server 106 from the software and hardware initialization of the POST procedure. For example, a memory training error may cause the DIMM number of the memory device to be sent to the BMC 110 for recording. The BMC 110 installs the ISO image of the runtime control library to the server 106 and executes the JTAG main scan engine driver to capture all levels of system errors, peripheral IO device errors, memory errors, thermal level status, and power supply status. JTAG is an industry standard interface used to verify designs and test motherboards. here In an embodiment, the hardware components on the server 106 support JTAG and thus can interface with the JTAG master in the BMC 110 . This allows the BMC 110 to execute JTAG commands to obtain available data from the corresponding hardware components.

Therefore, all POST sequences expose debug text strings to the serial console port and the Serial Over LAN (SOL) connected to the BMC 110. These debug messages include the names of all serial service programs running in the server 106 , the results of the software data structures created during the POST procedure, and the interconnect signals between the device and the chip programmed by the UEFI BIOS 120 . UEFI BIOS 120 creates the necessary data structures and exposes the data structures to the operating system for identification of the platform design. For example, the data structure can be the PCI tree of ACPI tables or the number of CPU cores of SMBIOS. After the POST procedure is executed, this data will remain in physical memory. Typically, only designers can view this material through specific tools. However, in this embodiment, UEFI BIOS 120 can copy these contents of memory and redirect the output to remote server management (eg, service station 102) via the serial console port and SOL. This information can be used by the designer for deeper debugging of the server 106 . The same concept can be applied to hardware signals. UEFI BIOS 120 can fine-tune the signal strength through the hardware controller. This data can be output as debug messages and can be accessed remotely by the designer. In the event of a hardware failure, designers can identify the failure by comparing with the data structure. The BMC 110 installs the ISO image of the runtime control library to the server motherboard USB port 142, emulates the ISO image as a bootable device; then allows the UEFI BIOS 120 to execute the ISO image as an embedded operating system and execute diagnostic applications.

In this embodiment, the BMC 110 enables a debug and programming interface, such as a JTAG host, which connects to the JTAG scan chain of the host processor of the server 106 . Basic Image Transfer Protocol (ITP), such as EnterDebugMode, ReadMSR, and WriteIO, are provided in the firmware stack of the BMC 110. Remote applications, such as Python-based CScripts, may be provided on the remote server management and server station 102. Data center operators can use the application to obtain the contents of all necessary scratchpads and read error status (eg Intel At-Scale protocol).

The hardware diagnostic option may be executed when the server 106 is restarted for maintenance in the data center. This option can also be executed when the server 106 is started at the service station for analysis. Therefore, when a faulty motherboard of a server (eg, server 106 ) is sent to a service station for debugging, the hardware diagnostic option allows the service engineer to quickly determine detailed hardware fault information without having to set up a complex host diagnostic software environment. In this diagnostic option, hardware and software changes to the server 106 are prohibited. This option does not save time compared to normal startup programs.

The flowcharts in FIGS. 6-9 represent machine-readable instructions for different options of the POST program startup path in the system 100 of FIG. 1 . In this embodiment, the machine-readable instructions include an algorithm executed by: (a) a processor, (b) a controller, and/or (c) one or more other suitable processing device. The algorithm may be stored in software on a tangible medium such as flash memory, CD-ROM, floppy disk, hard disk, digital video (DVD) or other memory device. However, those of ordinary skill in the art will readily appreciate that the entire algorithm and/or portions thereof may optionally be executed by means other than a processor and/or embodied in firmware or dedicated hardware in a well-known manner (eg, It may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), a field programmable gate array (FPGA), discrete logic, etc.). For example, any or all components of the interface may be implemented by software, hardware and/or firmware. Furthermore, some or all of the machine-readable instructions represented by the flowcharts may be implemented manually. In addition, although the embodiment of The algorithms are shown in the flowcharts of Figures 6 to 9, but those of ordinary skill in the art will readily appreciate that many other methods of implementing machine-readable instructions may alternatively be used. For example, the execution sequence of blocks may be changed, and/or some of the blocks described may be changed, deleted, or combined.

FIG. 6 depicts a flow diagram 600 for general startup and quick startup options that can be accessed through management and service station 102 and a remote controller (eg, BMC 110 ) on a server (eg, server 106 in FIG. 1 ). ) to communicate to start. The BMC 110 communicates the selected boot options to the UEFI BIOS (eg, UEFI BIOS 120 in Figure 1). After setting the UEFI variables through the UEFI BIOS to retrieve the POST procedure of the selection of the boot path from the BMC 110, the POST procedure begins (610). The program first determines if there is a change request for the startup option (612). If there is a change request, the program saves the new selection of the POST program option for the boot path to a UEFI variable (614). The program then begins the initialization of the wafer set (616). If there is no change request (612), the program uses the previously selected boot option and proceeds directly to initialize the chipset (616).

After the chipset is initialized, the program reads the UEFI boot path variable (618). Based on the value of the variable, the program determines whether the selected startup path is a normal startup or a fast startup option (620). If the normal boot option is selected, the program identifies processor sockets and memory sockets (eg, DIMM sockets) on server 106 (622). The program then initializes the processor and server 106 memory and saves the settings to persistent memory (eg, storage 136 in Figure 1) (624). The program then identifies peripheral IO device slots and creates bootable device paths (626). The program then initializes the IO hardware registers and stores the settings to persistent storage 136 (628). Then, the program loads the bootable device driver (630). Then, the program builds platform information and executes UEFI boot service (632). Platform information (such as CPU memory and PCI tree) is built in physical memory for OS loader identification. UEFI Boot Service Used to find bootable partitions from hard drives and bootable images from network drivers. The program then logs the results of the POST procedure into the system error log (SEL) maintained by the BMC 110 (634).

If the fast boot option is selected (620), the program identifies processor sockets and memory sockets (eg, DIMM sockets) on server 106 (640). The program determines whether a hardware change has occurred based on the identified processor and memory hardware interfaces (642). If a hardware change occurs, the memory of the processor and server 106 is continuously initialized and the settings are stored in persistent storage (eg, storage 136 in Figure 1) (624). The program then completes the general startup sequence described above.

If no hardware changes have occurred (642), the processor memory settings are restored from persistent memory 136 (644). The program then identifies peripheral IO device slots and creates bootable device paths (646). The program determines whether a peripheral hardware change has occurred based on the identified peripheral device slot (648). If the peripheral hardware is changed, the program initializes the IO hardware registers and saves the settings to persistent storage (628). The program then completes the general startup sequence.

If no peripheral hardware changes have occurred (648), the program restores the hardware register settings from persistent storage 136 (650). Then, the program loads the bootable device driver (650). The program then executes platform information and UEFI boot services (632). The program then logs the results of the POST procedure to the system error log maintained by the BMC (634).

FIG. 7 illustrates a flowchart 700 of an exemplary secure boot option. After retrieving the POST procedure options for the selected boot path from the BMC 110, the secure boot options procedure continues with the POST procedure. First, the program determines if there is a change request to the POST program, similar to the general startup options in Figure 6. If there is a change request, the program will start a new POST program of the path Options are stored to UEFI variables. Then, the program starts the initialization of the chipset. If there is no change request (612), the program proceeds directly to initialize the chipset (610, 612, 614, 616 in Figure 6).

Then, the program reads the UEFI variables (710). Based on the UEFI variables read, the program determines whether the program is a secure boot option (712). If the selected option is not a secure boot option, the program starts the POST procedure using another boot option (714). If the secure boot option is selected (712), the program identifies processor sockets and memory sockets (eg, DIMM sockets) on server 106 (716). The program reads the estimate of the error report from the BMC 110 and compares the error report entry to the resource table (718). A resource table is a software data structure that lists the class, ID, and system resource usage (such as memory range and IO) of all hardware components. Resource tables provide an easy way to compare error report entries in the system error log and determine which hardware components are at higher risk of failure. A higher risk of failure can be determined from SEL records showing multiple occurrences of uncorrected errors for a particular hardware component. The program then determines whether a disable request should be issued if the existing hardware component recorded an uncorrected error in the error report entry of the SEL (720). If there is a disable request, the program disables a hardware component (eg, processor or memory) based on the estimate of the error report (722). The program then initializes the remaining processors and memory (724). If no disable request has occurred, the program proceeds to initialize the remaining processors and memory (724).

The program then reads estimates of error reports related to peripheral IO devices (eg, PCIe slots and root controllers) from BMC 110 and compares them to the resource table (728). A peripheral resource table is a software construct that includes hardware device information for devices connected to a PCIe slot, allowing such devices to be enabled or disabled without affecting the general functionality of the root controller. The program then determines whether a disable request related to the peripheral IO device should be initiated (730). E.g, If the hardware device on the resource table has many uncorrected errors recorded in the error report entry of the BMC 110's SEL, the program may decide to initiate a disable request. If there is a disable request, the program disables the PCIe root port and peripheral IO from the estimation of the error report (732). The program then initializes the remaining peripheral IOs (734). If no disable request has occurred (730), the program proceeds to initialize the remaining peripheral IO (734).

The program then loads the bootable device driver (736). Then, the program prepares platform information and UEFI boot services (738). The program then logs the results of the POST to the system error log of the BMC 110 (740).

FIG. 8 is a flowchart 800 for factory supply options. After retrieving the POST of the selected boot path from the BMC 110, the factory-supplied boot options program continues with the POST boot. The program first determines if there is a change request similar to the general startup options. If there is a change request, the program will store the POST of the boot path options to UEFI variables. Then, the program starts the initialization of the chipset. If there is no change request (612), the program proceeds directly to initialize the chipset (610, 612, 614, 616 in Figure 6).

Then, the program reads the UEFI variables (810). Based on the UEFI variables read, the program determines whether the program supplies the factory with boot options (812). If the selected option is not a factory-supplied boot option, the program will use another boot option to initiate POST (814). If the factory-supplied boot option is selected (812), the program loads the current firmware configuration into UEFI variables (816). The program determines if there is a pressure request (818). If there is a stress request, the program disables the system's error correction mechanism (820). This allows stressful applications to run after startup. The stressful application allows the factor operator to identify whether the hardware components and merchandise of the server 106 are available for shipping. Therefore, UEFI BIOS must be open to factory operators Permissions for UEFI variables and allow factory operators to set it to disable error correction mechanisms. If there is no pressure request (818), the program determines whether the secure provisioning option has been selected (822). Security Provisioning is another application that can run after startup. This security provisioning allows the plant operator to enable security functions, such as key provisioning through public keys and encryption of the hard disk of the server 106 to be enabled.

If secure provisioning has been selected, the program enables the security function and allows the to-be-enabled client public key and settings provisioning (824). Security functions in embodiments may include Microsoft bitlocker, Intel TXT or SGX. The factory operator can also install the platform's public key and encryption of the customer image on the hard drive. This is a safety feature that ensures that the operating system is safe and reliable. The client may first encrypt the host operating system of the server 106 using the private key. When UEFI BIOS 120 identifies a bootable operating system with enabled security features, UEFI BIOS 120 uses the public key to decrypt the operating system and switch controls. Therefore, the factory site must install the public key into the server 106 and copy the encrypted image of the customer's private key onto the server 106 hard disk. If there is no security provision, or after the error correction mechanism is disabled, or after the security function is enabled, the program will load the client firmware settings (826). Next, the program logs the results of the POST to the system error log of the BMC 110 (828). After the procedure is complete, a stress test can be performed on the server 106 . Stress tests can include stress applications, script files, and embedded OSs that support this test.

FIG. 9 is a flowchart 900 of diagnostic options. After retrieving the POST of the selected boot path from the BMC 110, the diagnostic options program proceeds with the POST boot. The program first determines if there is a change request similar to the general startup options. If there is a change request, the program will store the POST of the boot path options to UEFI variables. Then, the program starts the initialization of the chipset. if there is not If the change request ( 612 ) is made, the program directly proceeds to initialize the chipset ( 610 , 612 , 614 , and 616 in FIG. 6 ).

Then, the program reads the UEFI variables (910). Based on the UEFI variables read, the program determines whether the program supplies boot options for diagnostics (912). If the selected option is not a diagnostic boot option, the program starts POST with another boot option (914). If the diagnostic enable option is selected (912), the program will determine the level of the debug message (916). The debug message level ranges from 0 to 3, where 0 is none and 3 is the maximum debug message output. The level of debug messages is set through a UEFI BIOS variable that can be programmed in-band or out-of-band. If a debug message is received, the program enables the maximum debug level (918). Also, if a debug message is received, UEFI 7 is a log file (920). The BMC 110 installs the diagnostic ISO image to the server board USB port (922). The BMC 110 uploads the diagnostic results to the management station 102 via the management network 104 (924).

If there is no debug message, or the program enables the maximum debug level, the program initializes the processor, memory, and peripheral IO of the motherboard (930). The program then initializes the IO hardware (932). The program will then install the startup service (934). Then, the program installs the run service (936). The program then identifies a bootable device (eg, a memory device) with an ISO image from the USB port 142 (938). The program determines if the ISO image can be found (940). If an IOS image is found, the embedded operating system is loaded from the USB bootable image installed by the BMC 110 (942). The program then stores the diagnostic results to the BMC 110 (944). If the ISO image is not found, or after storing the diagnostic results, the program logs the results of the POST to the BMC 110's system error log.

The terms "component," "module," "system," etc. as used herein generally refer to a computer-related entity, or hardware (eg, circuitry), a combination of hardware and software, software, or a One or more specific functions related to the operation of a machine. For example, a component may be, but is not limited to, a program, a processor, an object, an executable, an executable thread, a program, and/or a computer running on a processor (eg, a digital signal processor) . As an illustration, both the application running on the controller and the controller can be components. One or more components can be in a program and/or thread, and a component can be localized on one computer and/or distributed between two or more computers. In addition, a "means" may take the form of specially designed hardware, general-purpose hardware that is specialized by executing software thereon, capable of performing a particular function; software stored on a computer-readable medium, or a combination thereof.

The terminology used herein is for the purpose of describing particular embodiments only and not for the purpose of limiting the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. Further, to the extent that the terms "comprise," "include," "have," "have," or variations thereof are used in the detailed description and/or claims, these terms are intended to be included in a manner similar to the term "comprising" Inside.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Also, terms such as those defined in commonly used dictionaries should be interpreted as meanings consistent with their meanings in the relevant art, and should not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation of the present invention. Although shown in one or more embodiments The present invention has been shown and described, but equivalent changes and modifications will occur to others skilled in the art after reading and understanding this specification and the accompanying drawings. Additionally, although a particular feature of the invention is disclosed for only one of the various embodiments, such feature may be combined with one or more other features of other embodiments to the advantage of any given or particular application. Accordingly, the breadth and scope of the present invention should not be limited by any of the above-described embodiments. Rather, the scope of the invention should be defined in light of the appended claims and their equivalents.

To sum up, although the present invention has been disclosed by the above embodiments, it is not intended to limit the present invention. Those skilled in the art to which the present invention pertains can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be determined by the scope of the appended patent application.

100: Start the system

102: Remote Server Management and Service Station

104: Internet

106: Server

110: Baseboard Management Controller (BMC)

112: Web Interface Controller

120: Unified Extensible Firmware Interface (UEFI) Basic Input Output System (BIOS)

130, 132, 134: Hardware Components

136: Persistent memory

140: Operating System (OS)

142: Universal Serial Bus (USB) port

Claims (10)

A system having options for activating a remote computing device, the system comprising: a remote management station; a network in communication with the remote management station; a computing device having a plurality of hardware components and a unified extensible firmware interface (UEFI) basic input output system (BIOS), the UEFI BIOS including a plurality of power-on self-test (POST) programs; and a controller in communication with the UEFI BIOS and with the remote management station communicating over the network, wherein the controller is operable to: receive a selection of one of the POST procedures from the remote management station; and start the computing device using the selected POST procedure, wherein the POST procedures include a general POST procedure procedures, a pre-extensible firmware interface (pre-EFI) initialization environment stage, a driver execution environment stage, a boot device selection stage and a transient system loading stage, a second POST procedure and a third POST procedure , the general POST procedure has a security phase, the pre-EFI initialization environment phase is used to initialize and configure the hardware components of the computing device, the second POST procedure is a fast boot, the fast boot includes bypassing the computing Initialization and configuration of at least some of the hardware components of the device, the third POST procedure is a secure boot that includes disabling the faulty hardware components. The system of claim 1, wherein the quick start further comprises: The scratchpad of the computing device is restored using the data structures stored in a persistent memory in the normal POST procedure. The system of claim 1, wherein the secure boot further comprises: reading an estimate report on the failed hardware components to determine the functional hardware components; and initializing the functional hardware components . The system of claim 1, wherein the POST procedures further include a factory provisioning start including: loading a firmware configuration; disabling an error correction mechanism; and allowing a stress test to be performed on the hardware components. The system of claim 1, wherein the POST procedures further include a diagnostic option, the diagnostic option comprising: collecting debug messages from a security test of the computing device; and collecting hardware error states of the hardware components material. A method of selecting a startup program for a computer device, the method comprising: transmitting a selection of one of a plurality of POST programs from a remote management station over a network to a computing device, wherein the computing device includes a controller, a plurality of hardware components and a UEFI BIOS, the UEFI BIOS includes the POST procedures; Receive the selection of one of the POST procedures from the remote management station on the controller; and start the computing device using the selected POST procedure, wherein the POST procedures include a general POST procedure, a pre-EFI initialization Environment stage, a driver execution environment stage, a boot device selection stage and a transient system loading stage, a second POST procedure and a third POST procedure, the general POST procedure has a security stage, the pre-EFI initialization The environment phase is used to initialize and configure the hardware components of the computing device, the second POST procedure is a fast boot that includes bypassing initialization and configuration of at least some hardware components of the computing device, the third The POST procedure is a secure boot that includes disabling the faulty hardware components. The method of claim 6, wherein the fast boot further comprises: restoring a scratchpad of the computing device using a data structure stored in a persistent memory in the general POST procedure. The method of claim 6, wherein the secure boot further comprises: reading an estimate report on the faulty hardware components to determine the functional hardware components; and initializing the functional hardware components . The method of claim 6, wherein the POST procedures further include a factory supply start, comprising: Loading a firmware configuration; disabling an error correction mechanism; and allowing a stress test to be performed on the hardware components. The method of claim 6, wherein the POST procedures further include a diagnostic option, the diagnostic option comprising: collecting debug messages from a security test of the computing device; and collecting hardware error states of the hardware components material.

Images