Abstract:
The system architecture of the present invention programs a permanent version of firmware in ROM and employs a validation scheme for downloaded firmware. The downloaded firmware is executed when the validation scheme successfully validates the firmware. In the event that the downloaded firmware fails to download successfully or bring up the system, the processor is able to complete the booting process using the permanent or most recently validated version of firmware.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to an architecture and methodology for downloading firmware and specifically to an architecture and methodology for recovering from an unsuccessful firmware download. 
     BACKGROUND OF THE INVENTION 
     To maintain computational systems at peak levels of efficiency, it is common to periodically upgrade software in such systems. A common type of upgrade is to the firmware of the system. “Firmware” is an ordered set of instructions and/or data that is used in booting a computational system. After the firmware instructions or data are coded into ROM, they become part of the hardware (microcode) or a combination of hardware and software (microprograms). An example of firmware is BIOS (Basic Input Output System), which is a set of procedures stored on a ROM chip inside PC-compatible computers. 
     In normal firmware upgrade operations, new firmware is downloaded into RAM and, if the downloaded new firmware is valid, the new firmware is written into nonvolatile memory such as EPROM, PROM, flash memory, and the like. Typically, old firmware is written over or erased when the new firmware is recorded in nonvolatile memory. 
     Prolonged system downtime can be caused by malfunctions in the upgrade operation. For example, the new or upgraded firmware can be corrupted or incompatible with the system hardware. Alternatively, the system can go down during writing of new firmware to system memory, thereby causing a loss of both old and new firmware code (known as a “death by download”). For any of these reasons, the new firmware can fail to boot the system. 
     To correct this problem, the operator typically has no alternative but to redownload the firmware until it brings up the system. The system will thus be out of service until downloading is successful and the new or upgraded firmware successfully runs the system. For example, if a BIOS upgrade fails on a PC, the PC becomes unusable until the BIOS upgrade can be successfully completed and, until a successfully completed BIOS upgrade, the system cannot be used to download another BIOS image such as from a WEB server. 
     SUMMARY OF THE INVENTION 
     The method and architecture of the present invention solves these and other problems and represents a significant advancement over the art. 
     In one embodiment, a method is provided for booting a computational component. The method is particularly useful when a new version of firmware or a firmware upgrade (hereinafter “new” or “first” firmware) is loaded on the computational component which contains an older version of firmware (hereinafter “old” or “second” firmware). As will be appreciated, old firmware can be a permanent version of firmware (such as BIOS recorded on a chip) or an earlier firmware upgrade or firmware replacement recorded in writeable, nonvolatile memory. The method includes the steps of validating the first firmware; executing the first firmware when the first firmware is successfully validated; and executing the second firmware when the first firmware is invalid. 
     When the first firmware is unsuccessfully validated, the computational component executes the older version of the firmware to ensure availability of the computational component in the event that the first firmware is corrupt, nonexistent or otherwise invalid. An invalidating process can be used to invalidate the first firmware and revert back to the older version of firmware that is known to work. For example, the older version of firmware can be a prior firmware upgrade, modification, or replacement that previously was successfully validated and/or that previously successfully operated the component. 
     The older version of firmware can be stored in any suitable location. In one configuration, the older version of firmware is permanently stored in ROM as part of or in addition to the boot code. In this configuration, the firmware is not erasable. In another configuration, the older version of firmware is stored in writeable, nonvolatile memory (e.g., flash memory, EPROM or EEPROM) and is erasable. 
     In one configuration, the validating step is repeated for a predetermined number of attempts. The providing (e.g., loading) step includes the substep of setting at least one of a validation flag to a next state (e.g., “PENDING”) and a counter to an initial number (e.g., zero); determining if the validation flag and/or counter has reached a predetermined state (e.g., “PENDING” and/or “three” respectively); and invalidating the firmware when the validation flag has reached the predetermined state (e.g., by setting the validation flag to “INVALID”). Other states for the validation flag include “EMPTY” (meaning that the firmware is being uploaded or downloaded), and “VALID” (meaning that the validation step was successful). As will be appreciated, the validation flag can be any symbol (e.g., alphabetical, numerical, alphanumerical, etc.) denoting a state of the computational component (e.g., the validating process). 
     In another configuration, the validating step can be preceded by the steps of reading a (boot) code discrete from the firmware (the code typically being recorded in permanent ROM) and determining if new firmware is present. If not, the validation step is not performed. 
     In another configuration, the validating step includes calculating a checksum of the first firmware and determining if the checksum is valid. As will be appreciated, other validation techniques can be used including Cyclic Redundancy Check (“CRC”). 
     In another embodiment, a computational system containing firmware is provided that includes: 
     (a) means for reading a boot code (e.g., a code stored in ROM) of a computational component; 
     (b) means for determining, in response to reading of the boot code, if firmware is present in the computational component; 
     (c) means for validating the firmware when firmware is present; and 
     (d) means for executing the firmware, when the firmware is successfully validated. 
     In yet another embodiment, a computational system including downloadable firmware is provided that includes: 
     (a) a central processor for validating firmware; 
     (b) memory containing first and second firmware wherein the second firmware corresponds to the first firmware; and 
     (c) a firmware validator for validating the first firmware. The first or new firmware “corresponds” to the second or old firmware in the sense that it upgrades or replaces the old firmware. 
     The various embodiments represent a significant improvement in system availability. Having a full copy of the firmware in permanent ROM provides much greater system availability than a system having only a boot code in permanent ROM. With only one boot code in ROM, if the new firmware download fails, the system is out of service until the download can be successfully completed. If the new firmware fails to bring up the system, the system will be out of service until the user can procure a second copy of the new firmware for downloading. With the present invention, the system can be brought up to working condition by running either the previously known good firmware version in nonpermanent ROM or in permanent ROM, one or both of which are known to work. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a computational component according to one embodiment of the present invention; 
     FIG. 2 is a flow schematic of a firmware downloading method according to another embodiment of the present invention; and 
     FIG. 3 is a flow schematic of a boot method according to yet another embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION 
     Referring to FIG. 1, a computational component  10  according to the present invention is depicted. The computational component includes a central processing unit  14 , a timer  18 , volatile and nonvolatile memory  22  and  26 , respectively, a validator  30 , validation flag  34  and a counter  38 . 
     The nonvolatile memory  26  includes a boot code  42  and old firmware  46  stored in permanent (nonwritable) ROM  50  and new firmware  54  stored in nonpermanent ROM  56 . The nonvolatile memory  26  can be any long-term storage medium including magnetic, magnetoptical, and optical media. Nonpermanent ROM  56  is writeable. The new firmware  54  is typically stored on writeable, archival media such as EPROM, EEPROM, or Flash PROM. 
     The operation of the computational component is depicted in FIGS. 2 and 3. The user initiates  100  the load sequence of new firmware into the nonvolatile memory  26 . The new firmware  54  can be loaded from a disk or uploaded or downloaded from another computational component. For example, the new firmware  54  can be downloaded from a WEB server. Although the operation is described with reference to downloading, the new firmware can be loaded by other techniques. 
     The validation flag  34  is set  104  to “EMPTY” to denote that nonvolatile memory contains no new firmware, and all or a portion of the new firmware  54  is downloaded to nonvolatile memory. As will be appreciated, the new firmware can be first downloaded into RAM  22 , verified, and if valid copied into nonvolatile memory. Alternatively, blocks of the new firmware can be sequentially downloaded into RAM  22 , verified, and if valid copied into nonvolatile memory. Alternatively, the new firmware can be copied directly to nonvolatile memory and verified. 
     The processor  14  determines in decision diamond  112  whether the new firmware  54  was successfully downloaded. This determination is typically made by computing a checksum(s) for the firmware and determining if the checksum(s) are valid. The checksum is a number that accompanies data transferred from one place to another to ensure that the data was transmitted correctly. A simple way to compute a checksum is to add up ASCII codes for all of the characters of data in a packet of information and take the result modulo  256 . Although this method gives  256  possible checksums, it is very unlikely that a transmission error would change a packet of information into another packet with the same checksum. Accordingly, errors can be detected by transmitting the checksum along with each packet and testing whether the checksum matches the data actually received. Other methodologies for calculating the checksum and determining whether or not it is valid are well known in the art. As will be appreciated, techniques other than the checksum method can be employed to validate the firmware. Examples of such techniques include CRC. 
     If the new firmware was not successfully downloaded (e.g., a checksum is invalid), the user is notified  116  of a failure. The user next determines  120  whether or not to retry downloading the new firmware  54 . If the user decides to retry downloading the new firmware  54 , step  100  is repeated. Otherwise, the process is terminated  124 . 
     If the new firmware is downloaded successfully (all checksums were valid), the validation flag  34  is set  128  to a next state “PENDING” and the counter  38  to zero. 
     Referring to FIG. 3, the boot sequence of FIG. 3 is initiated  200  (i.e., the system is rebooted). During the reboot, the processor  14  reads  204  the permanent boot code  42 . As will be appreciated, the boot code  42  directs the processor  14  to read any new firmware as part of the boot sequence, which requires the processor  14  to determine  208  whether any new firmware  54  is present to upgrade or replace the old firmware  46 . 
     If no new firmware is present, the processor  14  reads and executes the old firmware  46  and completes the booting process using the old firmware. 
     If new firmware is present, the processor  14  determines  212  whether or not the new firmware  54  has been previously validated, such as in the downloading operation described above or in a previous booting operation. 
     If the firmware has not been validated previously, the processor  14  increments  216  the counter  38 . The validation flag  34  indicates whether the validator is pending, successful (valid), or unsuccessful (invalid). The counter  38  determines the number of attempts to validate the new firmware  54 . 
     The processor  14  next determines  220  whether the counter  38  has reached a predetermined limit or threshold. When the counter  38  is the same as the predetermined limit (or the number of unsuccessful validation attempts equals a predetermined number), the new firmware  54  is invalidated  224  and the validation flag is set to “INVALID”. The processor  14  next reads and executes  230  the old (or latest) version of firmware. If the counter  38  is less than the predetermined threshold, the processor  14  continues to box  228 , which is discussed in detail below. 
     Returning to decision diamond  212  if the firmware  54  has been validated previously, the processor  14  calculates  228  the checksum of the new firmware  54  and thereafter determines  232  whether the checksum is valid. This is done in the event that one or more bits of the firmware  54  have been lost or corrupted since the previous validation determination. 
     If the checksum is invalid (or the firmware is invalid), the processor invalidates  224  the new firmware  54  and reads and executes  230  the old (or latest) version of firmware to complete the boot operation. 
     If the checksum is valid, the new firmware  54  is executed  236  and, after executing the new firmware, the processor  14  determines  240  whether the system is up and running. As will be appreciated, the criterion for determining whether the system is up and running depends on the particular system architecture. 
     If the system is up and running, the validation flag is set  244  to the “VALID” state, and the boot operation is completed using the new firmware  54 . 
     If the system is not up and running within a specified time interval (e.g.,  60  seconds), the processor  14  reinitiates  200  the boot sequence. 
     The various validation flag and counter settings in the process described above are demonstrated below. The validation flag and counter settings for a successful downloading and validation sequence are as follows: 
     
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 ACTION 
                 VALIDATION FLAG 
                 COUNTER 
               
               
                   
                   
               
             
             
               
                   
                 Begin Download 
                 EMPTY 
                 N/A 
               
               
                   
                 Download 
                 PENDING 
                 0 
               
               
                   
                 Reboot 
                 PENDING 
                 1 
               
               
                   
                 System Up 
                 VALID 
                 N/A 
               
               
                   
                   
               
             
          
         
       
     
     This table assumes that only one attempt (the first) is required to execute the new firmware  54 . 
     The validation flag and counter settings for a predetermined maximum of three attempts are as follows: 
     
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 ACTION 
                 VALIDATION FLAG 
                 COUNTER 
               
               
                   
                   
               
             
             
               
                   
                 Begin Download 
                 EMPTY 
                 N/A 
               
               
                   
                 Complete Download 
                 PENDING 
                 0 
               
               
                   
                 Reboot 
                 PENDING 
                 1 
               
               
                   
                 System Not Up 
                 PENDING 
                 1 
               
               
                   
                 Reboot 
                 PENDING 
                 2 
               
               
                   
                 System Not Up 
                 PENDING 
                 2 
               
               
                   
                 Reboot 
                 PENDING 
                 3 
               
               
                   
                 Validation Retry 
               
               
                   
                 Limit Reached 
                 INVALID 
                 N/A 
               
               
                   
                   
               
             
          
         
       
     
     The foregoing description of the present invention has been presented for purposes of illustration and description. Furthermore, the description is not intended to limit the invention to the form disclosed herein. Consequently, variations and modifications commensurate with the above teachings, and the skill or knowledge of the relevant art, are within the scope of the present invention. By way of example, the validation flag could be a combination of a state flag and the counter. In that event, the validation flag would have the settings ‘PENDING X”, where X is the number of validation attempts, “VALID” and “INVALID.” The symbol for each state can be changed at the user&#39;s discretion. For example, the valid state could be renamed the “VALIDATION SUCCESS” state, the pending state “VALIDATION PENDING” state, and the invalid state the “VALIDATION FAILURE” state. The number of attempts before the firmware is invalidated can be more or less than three. The old firmware can include the boot code or be separate from the boot code. The old firmware can be firmware programmed into ROM at the factory or a prior (latest) valid (executable) version of firmware written into nonvolatile memory by a user. In the event that the new firmware is not executable, the processor would be directed by the boot code to execute the latest valid version of the firmware in nonvolatile memory in preference to executing a permanent version of the firmware programmed at the factory. Accordingly, the computational component can include more than two versions of the firmware at any one time. The embodiments described herein above are further intended to explain best modes known for practicing the invention and to enable others skilled in the art to utilize the invention in such, or other, embodiments and with various modifications required by the particular applications or uses of the present invention. It is intended that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art.