Patent Publication Number: US-9846616-B2

Title: Boot recovery system

Description:
BACKGROUND 
     The present disclosure relates generally to information handling systems, and more particularly to a boot recovery system for an information handling system. 
     As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an information handling system (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems. 
     Conventional IHS&#39;s typically include a boot system such as, for example, a Basic Input/Output System (BIOS) that operates to, for example, initialize and test the IHS hardware components, load an operating system from the IHS memory or storage device, and/or perform a variety of other BIOS actions known in the art during an IHS boot process. In some situations, the BIOS can fail such that the operating system does not load. Causes of BIOS failure include BIOS corruption, a missing BIOS, a misconfigured BIOS, and/or a variety of other BIOS failure causes known in the art. In the case of missing or corrupt BIOS, a user may be unable to access the BIOS to correct the problem. One conventional solution to a missing or corrupt BIOS includes reinstalling the BIOS from a copy that is stored in a separate chip, but such solutions require a motherboard that is usable without a working BIOS and an processor that can operate to perform the BIOS reinstall process. If the motherboard is unusable without a working BIOS, the user typically will be required to obtain a replacement chip that includes a working BIOS from the motherboard manufacturer. 
     Accordingly, it would be desirable to provide an improved BIOS recovery system. 
     SUMMARY 
     According to one embodiment, an information handling system (IHS) includes a processing system; a primary boot block storage that stores a primary boot block; and an embedded controller (EC) that includes an EC storage that stores a recovery boot block, wherein the EC is coupled to the primary boot block storage through a secondary serial peripheral interface (SPI), and wherein the EC is configured, while the processing system is not in an operating mode, to: determine that the primary boot block should be replaced; retrieve the recovery boot block from the EC storage; replace the primary boot block in the primary boot block storage with the recovery boot block through the secondary SPI; and initiate an information handling system (IHS) reboot process. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic view illustrating an embodiment of an information handling system. 
         FIG. 2  is a schematic view illustrating an embodiment of a boot recovery system. 
         FIG. 3  is a flow chart illustrating an embodiment of a method for boot recovery. 
     
    
    
     DETAILED DESCRIPTION 
     For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an IHS may be a personal computer, a PDA, a consumer electronic device, a display device or monitor, a network server or storage device, a switch router or other network communication device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The IHS may include memory, one or more processing resources such as a central processing unit (CPU) or hardware or software control logic. Additional components of the IHS may include one or more storage devices, one or more communications ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The IHS may also include one or more buses operable to transmit communications between the various hardware components. 
     In one embodiment, IHS  100 ,  FIG. 1 , includes a processor  102 , which is connected to a bus  104 . Bus  104  serves as a connection between processor  102  and other components of IHS  100 . An input device  106  is coupled to processor  102  to provide input to processor  102 . Examples of input devices may include keyboards, touchscreens, pointing devices such as mouses, trackballs, and trackpads, and/or a variety of other input devices known in the art. Programs and data are stored on a mass storage device  108 , which is coupled to processor  102 . Examples of mass storage devices may include hard discs, optical disks, magneto-optical discs, solid-state storage devices, and/or a variety other mass storage devices known in the art. IHS  100  further includes a display  110 , which is coupled to processor  102  by a video controller  112 . A system memory  114  is coupled to processor  102  to provide the processor with fast storage to facilitate execution of computer programs by processor  102 . Examples of system memory may include random access memory (RAM) devices such as dynamic RAM (DRAM), synchronous DRAM (SDRAM), solid state memory devices, and/or a variety of other memory devices known in the art. In an embodiment, a chassis  116  houses some or all of the components of IHS  100 . It should be understood that other buses and intermediate circuits can be deployed between the components described above and processor  102  to facilitate interconnection between the components and the processor  102 . 
     Referring now to  FIG. 2 , an embodiment of a boot recovery system  200  is illustrated. The boot recovery system  200  includes a chipset  200  that, for example, may be included in the IHS  100  discussed above with reference to  FIG. 1  and that may include one or more components of an integrated circuit that manages information flow between a processing system in the IHS  100  (e.g., the processor  102 ), a memory system in the IHS  100  (e.g., the system memory  114 ), peripheral devices coupled to the IHS  100 , and/or a variety of other components of the IHS  100 . In some examples, the chipset  202  is included in a circuit board (e.g., a motherboard) in the IHS  100 . However, other locations of the chipset  202  are envisioned as falling within the scope of the present disclosure. 
     The boot recovery system  200  also includes a storage that, in the illustrated embodiment, includes a Serial Peripheral Interface (SPI) flash storage device  204 . However, other types of storage devices used by controllers other than primary SPI controllers (discussed below) will fall within the scope of the present disclosure. The SPI flash storage device  204  provides address space for a boot storage  204   a , a management engine storage  204   b , a Local Area Network (LAN) Electrically Erasable Programmable Read-Only Memory (EEPROM) storage  204   c , an embedded controller storage  204   d , and a permissions map  204   e  (e.g., a flash access permissions map or descriptor). The boot recovery system  200  also includes an embedded controller (EC)  206  having an EC storage that, in the illustrated embodiment, includes an EC flash storage device  206   a.    
     The chipset  202  includes a flash access permissions logic  208  that provides logic for controlling access to the SPI flash storage device  204  (e.g., using the permissions map  204   e .) In the illustrated embodiment, the flash access permissions logic  208  provides a primary SPI controller  208   a  that operates to control access to address space in the SPI flash storage device  204  through a primary SPI bus  210 . In the illustrated embodiment, a host processing system  212 , which may include the processor  102  in the IHS  100  of  FIG. 1 , has direct access to address space on the SPI flash storage device  204  (e.g., the boot storage  204   a , the LAN EEPROM storage  204   c , etc.) via the primary SPI controller  208   a  through a coupling  212  to the flash access permissions logic  208 . The host processing system  212  may include a processor, operating system software, a BIOS, and/or a variety of other host processing system components known in the art. 
     In the illustrated embodiment, the chipset  202  includes a management engine  214  that has direct access to address space on the SPI flash storage device  204  (e.g., the management engine storage  204   b ) via the primary SPI controller  208   a  through a coupling  216  to the flash access permissions logic  208 . In some embodiments, the management engine  214  may be coupled to, for example, a remote access controller (not illustrated) such as, for example, the integrated Dell Remote Access Controller (iDRAC) available from Dell Inc. of Round Rock, Tex., that may include an interface card that is coupled to a network (e.g., a Local Area Network (LAN), the Internet, etc.). In the illustrated embodiment, the chipset  202  includes a secondary SPI controller (distinguished from the primary SPI controller  208   a ) that, in the illustrated embodiment, is an enhanced SPI (eSPI) controller  218 . As is known in the art, primary SPI controllers such as the primary SPI controller  208   a  conventionally operate to map addresses received from the host processing system  212  to addresses for devices coupled to the primary SPI bus  210  such that the host processing system  212  can access those devices. Secondary SPI controllers such as the eSPI controller  218  were created to allow the host processing system  212  to access the embedded controller  206  directly (e.g., via a bus  219 ), and to allow the embedded controller  206  to retrieve and/or store addresses used by the primary SPI controller  208   a  to map to the devices coupled to the primary SPI bus  210  (e.g., such that the embedded controller  206  could access the EC storage  204   d  that is provided on the SPI flash storage device  204 ) through a coupling  220 . As discussed in further detail below, the systems and methods of the present disclosure provide for the utilization of the eSPI controller  218  by the embedded controller  206  to replace a primary boot block  224  in the boot storage  204   a  of the SPI flash storage device  204 . 
     The secondary SPI controller  218  provides for has direct access to address space on the SPI flash storage device  204  (e.g., the boot storage  204   a ) via the primary SPI bus  210  through the coupling  220  to the flash access permissions logic  208 . The secondary SPI controller  218  provides direct access to address space on the SPI flash storage device  204  to the EC  206  through a secondary SPI bus  222  (e.g., an eSPI bus). As discussed below, the secondary SPI bus  222  and secondary SPI controller  218  may be active in any or all of the reduced power states defined by the Advanced Configuration and Power Interface (ACPI) specification, including but not limited to the G1/“sleep” states (S1, S2, S3, and S4) and G2/S5 state. As such, the secondary SPI bus  222  and secondary SPI controller  218  may be used by the EC  206  to directly access address space on the SPI flash storage device  204  when the host processing system  212  is not in an operating mode. 
     In the illustrated embodiment, a primary boot block  224  is stored in the boot storage  204   a  in the SPI flash storage device  204 , and a recovery boot block  226  is stored in the EC flash storage device  206   a . In the example of the boot recovery system  200  discussed below, the boot system is a BIOS boot system such that the primary boot block  224  is a BIOS boot block and the recovery boot block  226  is a recovery BIOS boot block. However, other boot systems including, for example, the Unified Extensible Firmware Interface (UEFI) system, are envisioned as falling within the scope of the present disclosure. Each of the primary boot block  224  and the recovery boot block  226  may provide a portion of BIOS software that is run first and that is updated separately from the remainder of the BIOS, and that operates to verify if the rest of the BIOS is intact before transferring control to it. As such, the recovery boot block  226  may be (at least initially) identical to the primary boot block  224  (e.g., prior to any errors being introduced into the primary boot block  224 ). 
     Referring now to  FIG. 3 , an embodiment of a method  300  for boot recovery is illustrated. The method  300  begins at block  302  where the embedded controller boots. In an embodiment, a user may power-on, reset, or otherwise initiate a boot of an IHS (e.g., the IHS  100  discussed above with reference to  FIG. 1 ) that includes the boot recovery system  200  and, in response the EC  206  will boot at block  302 . As is known in the art, the EC  206  may include an EC processing system and an EC memory system that includes instructions that, when executed by the EC processing system, cause the EC processing system to perform the functions of the EC  206  discussed below. At block  302 , the EC  206  may perform an initial set of operations (e.g., in response to a power-on or reset of the IHS) that allow the EC  206  to perform the remaining blocks of the method  300 . In some embodiments, the EC  206  may hold the host processing system  212  (e.g., the processor  102 ) in a non-operational mode such as, for example, a reset mode, during and/or following the booting of the EC  206  at block  302 . In the specific illustrated example, the EC  206  operates to hold the host processing system  212  in a reset mode while the EC  206  determines whether to utilize the recovery boot block  226 , discussed in further detail below. 
     The method  300  then proceeds to decision block  304  where it is determined whether a command has been received to replace the primary boot block. In an embodiment, the EC  206  operates to determine whether a command has been received to replace the primary boot block  224  in the boot storage  204   a  of the SPI flash storage device  204 . In some embodiments, systems other than the IHS may send a primary boot block replacement command to the IHS to replace the primary boot block  224 . For example, a remote management system may send a primary boot block replacement command (or other out-of-band request) over the network to the management engine  214  via a remote access controller while the IHS is reduced power state or non-operating mode. As such, following the EC boot at block  302 , the EC  206  may operate to check whether a command to replace the primary boot block was received. While a specific example of a primary boot block replacement command sent from a remote management system over a network while the IHS system is powered down has been provided, a wide variety of commands to replace the primary boot block may be received from different systems at different times and while the IHS is in different operating states while remaining within the scope of the present disclosure. 
     If, at decision block  304 , it is determined that no command to replace the primary boot block was received, the method  300  then proceeds to decision block  306  where it is determined whether the primary boot block is valid. In an embodiment, the EC  206  operates to determine whether the primary boot block  224  in the boot storage  204   a  of the SPI flash storage device  204  is valid. For example, at decision block  306 , the EC  206  may directly access the primary boot block  224  in the boot storage  204   a  of the SPI flash storage device  204  through the secondary SPI bus  222  and secondary SPI controller  218  and operate to perform a checksum operation, hash operation, and/or other validity determination operation on the primary boot block  224  to determine whether the primary boot block  224  is bad, missing, or otherwise whether errors exist in the primary boot block  224  such that the primary boot block  224  may be invalid. While a specific example of determining the validity of a primary boot block has been provided, a wide variety of systems and methods may be used to determine whether a primary boot block is valid while remaining within the scope of the present disclosure. 
     If, at decision block  306 , it is determined that the primary boot block is valid, the method  300  then proceeds to decision block  308  where it is determined whether a timer was tripped during a previous boot of the IHS. In an embodiment, the EC  206  may include, or have access to, a timer (e.g., a “watchdog timer”), discussed in further detail below, that may be initiated in response to an IHS boot process and used to determine whether that IHS boot process has taken too long and should be restarted. At decision block  308 , the EC  206  may operate to determine whether that timer was tripped during the previous IHS boot process to determine whether that previous IHS boot process failed. For example, at decision block  308 , the EC  206  may access a memory location (e.g., in the EC  206 , in the chipset  202 , etc.) and operate to check whether a flag (referred to below as a “timer-trip” flag) was set in that memory location during a previous performance of the method  300 . While a specific example of the determination of whether a previous boot of the IHS failed, a wide variety of systems and methods may be used to determine whether a boot of an IHS previously failed while remaining within the scope of the present disclosure. 
     If, at decision block  308 , it is determined that a timer was not tripped during a previous boot of the IHS, the method  300  then proceeds to block  310  where the host processing system is released and a timer is started. As discussed above, in some embodiments the EC  206  may hold the host processing system  212  (e.g., the processor  102 ) in a non-operational mode such as, for example, a reset mode or a reduced power mode, during and following the booting of the EC  206  at block  302  while the EC  206  determines whether to utilize the recovery boot block  226  at decisions blocks  304 ,  306 , and  308 . In such embodiments, at block  310  the EC  206  may release the host processing system  212  (e.g., release the processor  202  from a reset mode) such that a BIOS in the host processing system  212  may attempt to perform BIOS operations. In addition, in an embodiment of block  310 , the EC  206  may operate to initiate the timer (e.g., a watchdog timer) and begin monitoring the IHS boot process. For example, the EC  206  may operate at block  310  to initiate the timer that was checked at decision block  308  and begin monitoring (via the secondary SPI bus  222 ) the IHS boot process using the primary boot block  224 . 
     The method  300  then proceeds to decision block  312  where it is determined whether the timer has expired prior to the completion of an IHS boot process. In an embodiment, the EC  206  operates to monitor the timer initiated at block  310  and determine whether that timer has expired. For example, the timer initiated at block  310  may be configured to expire after a time period that is indicative of a problem with the IHS boot process. If at decision block  312 , the EC  206  determines that the timer has expired, the method  300  then proceeds to block  314  where a timer-trip flag is set and the IHS is rebooted. In an embodiment of block  314 , the EC  206  operates to set a timer-trip flag and cause the IHS to reboot. For example, the EC  206  may set the timer-trip flag in the memory location that was checked at decision block  308 , and then send a signal to the host processing system  212  to cause the host processing system  212  to reboot. The method  300  then proceeds back to block  302 . One of skill in the art in possession of the present disclosure will recognize that the setting of the timer-trip flag at block  314  and causing the IHS to reboot may cause the method  300  to eventually proceed back to decision block  308  where it will then be determined that the timer was tripped during a previous boot of the IHS (i.e., based on the setting of the timer-trip flag by the EC  206 .) 
     If, at decision block  312 , it is determined that the timer has not expired prior to the completion of an IHS boot process, the method  300  proceeds to block  316  where the timer is cancelled. In an embodiment, the EC  206  operates to cancel the timer initiated at block  310 . For example, as discussed above, the timer initiated at block  310  may be configured to expire after a time period that is indicative of a problem with the IHS boot process, and a determination that the timer has not expired at decision block  312  is indicative that the IHS boot process is operating normally and has completed. In some examples of block  316 , the EC  206  may cancel the timer in response to the host processing system  212  entering BIOS setup (e.g., by providing a BIOS configuration menu), in response to the host processing system  212  starting full BIOS recovery, and/or in response to a variety of other events known in the art that are indicative of a normal IHS boot process completing. The method  300  then proceeds to block  318  where the host processing system  212  proceeds with a normal boot process. 
     Returning back to decision blocks  304 ,  306 , and  308 , if at decision block  304  it is determined that a command to replace the primary boot block has been received, or if at decision block  306  it is determined that the primary boot block is not valid, or if at decision block  308  it is determined that the timer was tripped during a previous boot of the IHS, the method  300  then proceeds to block  320  where a recovery boot block is retrieved. In an embodiment of block  320 , the EC  206  operates to retrieve the recovery boot block  226  from the EC Flash storage device  206   a . The method  300  then proceeds to block  322  where the primary boot block is replaced using a direct access interface. In an embodiment, the EC  206  replaces the primary boot block  224  with the recovery boot block  226  using the secondary SPI bus  222  and secondary SPI controller  218  to directly access the address space on the SPI flash storage device  204  that is designated for the boot storage  204   a , and replaces the primary boot block  224  with the recovery boot block  226 . As discussed above, the secondary SPI controller  218  provides direct access to address space designated for the boot storage  204  on the SPI flash storage device  204  (e.g., via the coupling  220  to the flash access permissions logic  208  and the primary SPI bus  210 ), and allows the EC  206  to utilize the secondary SPI bus  222 , the secondary SPI controller  218 , the coupling  220 , and the primary SPI bus  210  as a direct access interface to replace the primary boot block  224 . As also discussed above, the secondary SPI bus  222  and secondary SPI controller  218  allow the EC  206  to perform block  322  while the host processing system is in a reduced power state or otherwise not in an operating mode (e.g., while the EC  206  holds the host processing system  212  in a non-operational mode such as, for example, a reset mode). The method  300  then proceeds to block  324  where the IHS is rebooted. In an embodiment of block  324 , the EC  206  operates to cause the host processing system  212  to reboot following the replacement of the primary boot block  224  with the recovery boot block  226 . One of skill in the art in possession of the present disclosure will recognize that following the replacement of the primary boot block with the recovery boot block at block  322 , the reboot of the IHS  324  should cause the method  300  to proceed as discussed above to block  318  where the normal boot of the IHS occurs (i.e., because the boot block being used has been replaced, is valid, and/or is not associated with the timer expiring during a previous boot attempt.) 
     Thus, systems and methods have been described that provide for boot recovery without the need for an operating host processing system. Utilizing a direct access interface such as, for example, a secondary or enhanced Serial Peripheral Interface bus, an embedded controller may determine whether a primary boot block should be replaced (i.e., based on a replacement command, a failed previous boot, a determination of boot block errors, etc.) and directly access a boot storage to replace the primary boot block with a recovery boot block that is stored in the embedded controller. This replacement of corrupted or damaged boot blocks may be performed while the host processing system in the IHS is in an off mode, a sleep mode, a reset mode, and/or any other reduced power mode known in the art, providing substantial benefits over conventional systems in which BIOS recovery requires reinstallation of the BIOS from a copy that is stored in a separate chip, along with host processing system that can operate to perform the BIOS reinstall process. 
     Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.