Flash Disaster Recovery ROM and Utility to Reprogram Multiple ROMS

The present application is related to U.S. patent application Ser. No. 07/885,805 entitled "FLASH ROM PROGRAMMER" filed May 15, 1992 by Clark Buxton and assigned to the same assignee as the assignee of the present application.

1. Field of the Invention

The present invention relates to a memory system for a computer which includes flash read-only-memory (ROM) for storing programming instructions for the basic input/output system (BIOS) and, more particularly, to a flash memory system which includes a utility which allows multiple types of flash memory devices to be programmed with a single utility program, and also provides disaster recovery to enable the flash ROM to be reprogrammed in the event that the data in the flash ROM becomes corrupted.

2. Description of the Prior Art

IBM-compatible personal computers normally contain a set of routines on a ROM chip within the computer, known as the basic input/output system (BIOS). These BIOS routines primarily control the input/output functions of the computer's peripheral devices, such as the display, keyboard and disc drives. In particular, these BIOS routines act as an interface to translate various software commands for the peripheral devices from the various application programs and disc operating system (DOS) to commands that are compatible with the hardware. In addition, the BIOS includes routines contain information or perform tasks that are fundamental to other aspects of the computer's operation, such as keeping track of the date and the time of day, for example for identifying the time of creation of a file in a file allocation table (FAT).

Occasionally, the BIOS needs to be updated for various reasons. For example, early BIOS versions did not support 31/2-inch floppy disc drives. Thus, older personal computers later equipped with 31/2-inch disc drives required a BIOS change. There are other situations which could require a BIOS update. For example, existing computer systems may include a version of BIOS that does not support a compact disc ROM or newer graphic standards. When the computer is upgraded as such, it is necessary for the BIOS ROM, normally connected to the motherboard inside the computer housing, to be replaced with a new ROM that contains the updated BIOS. Thus, for such BIOS updating, it is necessary that the computer case be opened and the motherboard removed. Once the motherboard is removed, the ROM chip which contains the BIOS is then replaced with the new ROM chip which contains the updated version of the BIOS. The motherboard is then replaced and the computer case is closed. As such, replacement of the BIOS chip is rather cumbersome and often is done by a computer technician, which can be relatively expensive.

In an effort to facilitate updating the BIOS in a personal computer, there is a trend toward storing the BIOS on a flash ROM. Such flash ROM BIOS systems offer several known advantages over existing systems. Firstly, flash ROMs allow for block erase and relatively quicker programming than known electrically erasable read-only memories (EEPROM). Secondly, flash ROMs allow the BIOS to be updated in a portable personal computer rather quickly and efficiently. However, such flash ROMs are known to become corrupt due to various sources including power surges. Thus, in any computer system which utilizes flash ROM for BIOS, it is necessary to provide what is known as flash disaster recovery. Flash disaster recovery relates to the ability to reprogram the BIOS in the flash ROM once the flash ROM has been determined to be corrupt. One system for providing flash disaster recovery for a computer system which utilizes flash ROM for BIOS is disclosed in U.S. application patent Ser. No. 07/885,805, filed on May 15, 1992 entitled "FLASH ROM PROGRAMMER", assigned to the same assignee as the assignee of the present application. In that system, a special purpose hardware interface is provided which allows for mode switching of a standard parallel port from a standard peripheral interface, such as a printer interface, to a special purpose interface to enable the BIOS to be loaded from an external ROM or another computer connected to the parallel port. Although such a system provides for flash disaster recovery, it may not be beneficial for end users who do not have the resources to reprogram the flash ROM by way of the parallel port.

Another known use for flash ROM memory is in socalled solid state disc systems. In such systems, a flash ROM is used in place of or along with a floppy or hard disc. In one known application, the flash memory solid state disc is interfaced to application programs by way of a software interface, such as MicroSoft's Flash File System. However, the Flash File System requires a hardware dependent low level software driver. Thus, in applications that require multiple types of flash memory, additional software drivers are required which increases the software overhead of the system.

It is an object of the present invention to solve various problems of the prior art.

It is another object of the present invention to provide a memory system for a computer which provides a flash ROM for the system BIOS.

It is yet another object of the present invention to provide a flash ROM memory system which includes means for allowing recovery from a flash disaster.

It is yet another object of the present invention to provide a system which allows for programming of multiple types of flash ROM memory.

These and other objects of the present invention will be readily understood with reference to the following specification and accompanying drawing, wherein:

FIG. 1 is memory map of a flash recovery ROM which forms a portion of the present invention;

FIG. 2 is similar to FIG. 1 and illustrates a memory map of a BIOS ROM in accordance with the present invention;

FIG. 3 is a simplified block diagram illustrating the memory transfer from a floppy disc to a flash ROM in accordance with the present invention;

FIGS. 4A-4D are flow diagrams of the flash programming utility in accordance with the present invention;

FIG. 5 is a system block diagram of a flash recovery utility in accordance with the present invention;

FIG. 6A is a flow diagram of a loader utility which forms a portion of the flash recovery utility in accordance with the present invention; and

FIG. 6B is a flow diagram of a flash utility which forms a portion of the flash recovery utility in accordance with the present invention.

FIG. 6C is a flow diagram of a flash utility in accordance with one portion of the invention.

The present invention relates to a memory system for an IBM-compatible type personal computer. The memory system includes a flash read-only memory (ROM) for the basic input/output system (BIOS) and a flash recovery ROM. The flash recovery ROM, along with a flash recovery utility allows the BIOS ROM to be updated in the event the data therein becomes corrupt.

The use of a flash ROM for the BIOS allows for block erasure and in-circuit reprogramming of the BIOS in order to facilitate BIOS updates in personal computers. In particular, as will be discussed in more detail below, the system in accordance with the present invention enables the BIOS to be updated by way of a floppy disc. As such, the BIOS can be rather quickly and easily updated by an end user without the need to open the computer case; thus, obviating the need for a computer service technician.

In the event that the flash ROM containing the BIOS becomes corrupt, the flash recovery ROM is provided. The flash recovery ROM is provided with a hardware protected memory area that is virtually secure from corruption that includes program instructions for checking the validity of both flash ROMs (e.g., checksum) as well as sufficient BIOS functions (e.g., initialization functions) to enable the corrupt flash ROM containing the BIOS instructions to be reprogrammed by way of the flash disaster recovery utility. The recovery flash ROM is updated by way of a floppy disc in a similar manner as the BIOS flash ROM.

The flash recovery ROM may be an Intel-type 28F001BX, for example. As shown in FIG. 1, the flash recovery ROM, generally identified with the reference numeral 20, includes an 8K byte hardware protected area 22, two parameter 4K byte block areas 24 and 26 and a 112K byte main block area 28. A memory map of an Intel-type 28F001BX is illustrated in FIG. 1, as disclosed in publication "MEMORY PRODUCTS 1992", by Intel copyright 1991, hereby incorporated by reference.

As indicated in FIG. 1, the protected area 22 is used as a boot block 22 for various BIOS functions discussed below, such as initializations functions, that are separated from the BIOS flash ROM to enable the boot block 22 to reprogram the BIOS flash ROM 30 in the event it becomes corrupt. In addition, the boot block is provided with a utility for performing checksums of both the flash recovery ROM 20 and the BIOS ROM 30.

The parameter blocks 24 and 26 are used for various purposes. For example, the parameter blocks 24 and 26, which are unprotected, may be used for less crucial functions, such as international language symbols which may be used, for example, in international sales applications.

The main block 28, which may be 112K, also unprotected, may be used for various utility programs, such as a battery management utility for monitoring and controlling battery power consumption for portable personal computers. The main block 28, as well as the parameter blocks 24 and 26, may be updated by a floppy disc in the same manner as the boot block 22.

An Intel-type 28F010 may be used as a BIOS ROM 30. However, although specific types and numbers of Intel flash ROMs are described and illustrated for the flash recovery ROM 20 and BIOS ROM 30, it should be clear that the present invention is not so limited.

The BIOS ROM 30 may be used for all of the BIOS functions except for the functions separated out and contained in the boot block 22 of the flash recovery ROM 20 as discussed above. In addition to BIOS functions, the BIOS ROM may include a flash programming utility program 32 in accordance with the present invention. As such, the flash programming utility 32 can be rather quickly and easily updated by way of a floppy disc by the end user.

An important aspect of the invention relates to the ability of the flash programming utility 32 to erase and reprogram multiple types of flash ROM (e.g., 20 and 30) with a single utility. As such, updating of the flash recovery ROM 20 and the BIOS ROM 30 is relatively quicker than other flash ROM programming utilities which are hardware-specific and thus only allow for programming of a single specific type of flash ROM. Moreover, since the flash programming utility system 32 is installed on the BIOS ROM 30, it may be updated by way of a floppy disc to enable additional or other types of flash ROM to be utilized.

The flash programming utility in accordance with the present invention is illustrated in flow chart format in FIGS. 3 and 4, while a flash recovery utility is illustrated in FIGS. 5 and 6. A copy of the source code for the flash programming utility 32 is included in Appendix 1. It should be noted that portions of the source code files in Appendices 1 and 2 are provided with multiple versions. For example, the flash programming utility can be provided in a DOS based version which enables the BIOS ROM code to be updated from DOS. Another version (e.g., Appendix 1), is provided as a BIOS-based version. This version is installed in a ROM (not shown) during manufacturing installation. Thereafter, the system is updated by way of a floppy disc by the end user by way of the BIOS-based version.

A simplified block diagram illustrating the sequence of memory transfer of the flash programming utility system in accordance with the present invention is illustrated in FIG. 3. Updates for the flash recovery ROM 20 as well as the BIOS ROM 30 are provided in the form of image files on a floppy disc 34. Since flash ROMs are block erased, the updated portion, as well as the unchanged portion of the boot block 22 or the BIOS ROM 30, is included on an image file on the floppy disc 34. In the case of the flash recovery ROM 20, the memory is segmented into the four blocks 22, 24, 26 and 28 as discussed above. Thus, any of the particular blocks 22, 24, 26 and 28 can be updated at one time. On the other hand, the BIOS flash ROM 30 contains a single 128 kilobyte main block. Thus, this block is updated at one time.

For simplicity, the flash programming utility is illustrated and discussed for updating the boot block 22 in the flash recovery ROM 20 as well as the main block of the BIOS ROM 30. As will be discussed in more detail below, various commands are used for updating the main block of the BIOS ROM 30, the main block 28, the two parameter blocks 24 and 26 and the boot block 22 of the flash recovery ROM 20. It will be understood by those of ordinary skill in the art that other commands could be used to update the parameter blocks 24 and 26 as well as the main block 28 of the flash recovery ROM 20.

Referring to FIG. 3, the particular block to be updated (e.g., boot block 22 or BIOS ROM 30 main block) are disposed on an image file on the floppy disc 34. Initially, the image file is transferred to main memory 36. Once the image file is transferred to the main memory 36, a checksum of the image file is performed in order to ascertain the validity of the file. This is done to avoid unnecessarily programming the flash ROM. The program instructions for performing the checksum are contained in the flash utility. If the checksum of the image file is determined to be valid, the image file is transferred to the particular flash ROM 20 or 30. As indicated above, an important aspect of the flash programming utility is that it can be used with multiple types of flash ROM.

Referring to FIG. 4, the flash programming utility may be entered from a monitor program (identified as MPM) primarily used to monitor and decode various keyboard (not shown) entries. In Zenith Data System (ZDS) computers, the monitor program may be entered by simultaneously depressing the keys CTL-ALT-INSERT after the DOS prompt. The ZDS monitor program is described in "Z-NOTE USER'S GUIDE" by Zenith Data Systems Corporation, Copyright 1992, hereby incorporated by reference. In non-ZDS computers slight modifications would have to be made to the DEBUG program in order to enter the utility program in accordance with the present invention. Such DEBUG modifications are well within the ordinary skill in the art and do not form a part of the present invention.

Once in the monitor program, the flash programming utility in accordance with the present invention is accessed by typing specific commands by way of the keyboard. For example, a NEWBIOS command is used to update the main block of the BIOS flash ROM 30, the main block 28 and the two parameter blocks 24 and 26 of the flash recovery ROM 20. A P command is used to load the boot block 22 of the flash recovery ROM 20. Thus, once in the monitor program, identified with the reference numeral 40, the system awaits a command from the keyboard. The commands are decoded in order to determine whether a NEWBIOS or P command has been entered. In particular, the system checks for a NEWBIOS command in step 42. In applications for portable personal computers, if a NEWBIOS command has been entered at the keyboard, the system checks to determine if the computer is in an AC mode in step 44 in order to conserve battery power. In particular, as mentioned above, the entire BIOS flash ROM 30 is block erased and updated at one time. Thus, in the case of, for example, an Intel 28F010, an entire 128 kilobytes is erased at once. Thus, in such an application, the system checks in step 44 to determine if the computer system is in an AC mode to avoid a flash disaster which may occur as a result of an interrupted BIOS update process due to a drain of the battery. If a NEWBIOS command has been entered and the system is not in an AC mode of operation, a user message is displayed in step 46; BIOS UPDATE NEED AC POWER. Once the computer system is determined to be in the AC mode, the system loads the update from an image file on the floppy disc 34 into main memory 36 and eventually into the main block of the BIOS ROM 30 by way of a LOAD.sub.-- EEPROM function 48.

As mentioned above, in order to update the boot block 22 of the flash recovery ROM 20, the P command is utilized. In particular, if the system determines that a NEWBIOS command has not been input in step 42, it checks in step 50 whether a P command has been entered. If a P command has been entered, the system proceeds to the LOAD.sub.-- BBLOCK function in step 52. If neither a NEWBIOS nor a P command have been input as determined in step 50, the system may proceed to other entries as identified with the reference numeral 54.

The LOAD.sub.-- EEPROM and LOAD.sub.-- BBLOCK functions 48 and 52 are illustrated in FIG. 4A. If the NEWBIOS command was entered at the keyboard in step 42, the target file name (e.g., boot block or BIOS) is parsed and copied to a global buffer in step 56. In addition, buffer space for the image file is requested. After the file name is parsed and copied to the global buffer, the global variables (e.g., disc drive parameters) are initialized in step 58. Once the global variables are initialized in step 58, Video Mode 3 is set up in step 60 to display text in a color mode. Video Mode 3 may be set with interrupt 10H. Subsequent to step 60, the argument for the LOAD.sub.-- FLASH.sub.-- EEPROM function is set in step 62.

If the NEWBIOS command was entered, the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function is set to the character N. If the P command has been entered, the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function is set to the character Y as will be discussed below. If the P command was selected, the LOAD.sub.-- BBLOCK function 52 will be executed. The P command relates to update of the boot block 22 in the flash recovery ROM 20. The LOAD.sub.-- BBLOCK function 52 is initiated by copying the file name for the boot block to the global buffer in step 64. Subsequently, the global variables are initialized in step 66 and Video Mode 3 is set up in step 68.

The arguments N and Y are used to control the operation of the LOAD.sub.-- FLASH.sub.-- EEPROM function. In particular, the argument N is used to indicate that the BIOS flash ROM 30 is to be updated, while the argument Y is used to indicated that the boot block 22 of the flash recovery ROM 20 is to be updated.

Once the argument of the function LOAD.sub.-- FLASH.sub.-- EEPROM is set by the LOAD.sub.-- EEPROM or LOAD.sub.-- BBLOCK functions 48 and 52, respectively, the video RAM is cleared in step 72 to enable a program banner to be displayed in step 74. The program banner may be the title of the program, for example, FLASH EEPROM PROGRAMMING UTILITY. After the program banner is displayed in step 74, the delay constant is set for byte programming in step 76. This delay constant is set to erase and program the flash devices properly.

After the delay constant is set, the number of retries is set at three in step 78 for determining if the floppy disc containing the flash ROM update has been inserted in the appropriate drive. The system checks whether the retries are exhausted in step 80. If the retries are exhausted, the system returns to the monitor program in step 82. If the retries are not exhausted, the number of retries is decremented in step 84. After the number of retries is decremented in step 84, the system next checks in step 86 to determine if the disc has been inserted in the appropriate drive in step 86. If not, the system checks the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function in order to display the appropriate user message. More particularly, the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function is checked in step 88. If the argument is determined to be the character Y, the user message INSERT BOOT BLOCK IMAGE FILE is displayed in step 90. If the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function is not the character Y, the user message INSERT ROM IMAGE FILE is displayed in step 92. After the appropriate user message is displayed in either step 90 or 92, the system again checks in step 94 to determine if a disc has been inserted in the appropriate drive in step 94. If a disc has not been inserted after the user messages have been displayed, the system will loop back to step 94 and wait for the disc insertion. Once a disc has been inserted in the appropriate drive, the system checks the disc for the appropriate file in step 96. In particular, the system determines in step 98 whether the disc contains appropriate file by comparing the file names on the disc with the target file name stored in the global buffer. If the file is not found, the system checks in step 100 to determine if the number of retries has been exhausted. If so, the system returns to the monitor program 82. If not, the system checks in step 102 to determine if the disc has been removed. If so, the system returns to step 80.

Three retries are set in step 103 for reading the appropriate image file. If the desired image file is found on the floppy disc, the system checks in step 104 whether the retries have been exhausted. If so, the system returns to the monitor program in step 106. If not, the retries are decremented in step 108 and the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function is checked in step 110 in order to read the appropriate image file into the main memory 36. In particular, if the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function has been set to Y, the boot block image file is read into main memory in step 112. If not, the BIOS image file is read into main memory in step 114.

Once the appropriate image file has been read into main memory 36, the system checks to determine if that operation was successful in step 116. In addition, the system does a checksum of the image file to determine if it is valid. The system also checks in step 118 the machine identification code. This is done in order to determine if the floppy disc has the proper BIOS image file for the machine in order to avoid unnecessarily programming the BIOS flash ROM 30. The system also checks in step 118 whether the retries for reading either the BIOS image file or the boot block image file have been exhausted. If the retries have been exhausted or the floppy disc contains the incorrect BIOS file for the particular machine or the BIOS image file is determined to be corrupt as a result of the checksum, the system may display a user message prompting the user to remove the floppy disc as part of step 118. Subsequently, the system waits until the disc is removed from the drive in step 120. Once the floppy disc is removed from the drive, system control returns to the monitor program in step 106.

If the reading of the BIOS image file or boot block image file into the main memory 36 was successful in step 116, the floppy disc drive is reset and the drive motor is turned off in step 118. The system then sets the number of retries for two for programming the BIOS ROM 30 and the flash recovery ROM 20 in step 120. In step 122, the system checks to determine if the number of retries has been exhausted. If so, program control is returned to the monitor program in step 124. If not, the number of retries is decremented in step 126. Subsequently, the system checks the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function in step 128. If the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function was set for Y, this means that a P command was entered, indicating programming of the boot block 22 of the flash recovery ROM 20. If not, the system proceeds to erase the BIOS ROM 30 in step 130. The system then checks in step 132 to determine if the erasure was successful. If not, an error message is displayed in step 134. Subsequently, the system loops back to step 122 until the retries are exhausted. Once the system determines that the BIOS ROM 30 was successfully erased, the BIOS ROM 30 is programmed in step 134. The system then checks in step 136 to see if the programming of the BIOS ROM 30 was successful. If not, an error message is displayed in step 134 and the cycle is repeated until the retries are exhausted. If so, the system proceeds to step 138 to erase the main block 28 and the two parameter blocks 24 and 26 of the flash recovery ROM 20 in step 138. If the erasure of the main blocks 24, 26 and 28 of the flash recovery ROM 20 was successful as determined in step 140, the image of those blocks from the main memory is programmed into the corresponding block of the flash recovery ROM 20 in step 142. The system then checks to determine if the programming of those blocks was successful in step 144. If the programming of those blocks is found to be unsuccessful, an error message is displayed in step 134 and the cycle is repeated until the retries are exhausted. If the programming of the blocks 24, 26 and 28 was successful, a message is displayed in step 146 requesting the user to touch the ENTER key on the keyboard (not shown). If the ENTER key is depressed, the video RAM is cleared in step 150 and the system initiates a cold reset 150.

If the P command was depressed from the monitor program, indicating that the boot block 22 of the flash recovery ROM is to be updated, the argument of the LOAD.sub.-- FLASH.sub.-- EEPROM function will have been set to the character Y causing the boot block 22 of the flash recovery ROM 20 to be erased in step 152. Subsequently, in step 154, the system checks to determine if the erasure was successful. If not, an error message is displayed in step 134 and the system returns to step 122 until the number of retries are exhausted. If the erasure was successful, the boot block 22 of the flash recovery ROM 20 is reprogrammed in step 156. After reprogramming of the boot block 22, the system again checks in step 144 to determine if the programming was successful. If not, an error message is displayed on the monitor in step 134 and the cycle is repeated until the number of retries has been exhausted. If so, a message is displayed prompting the user to depress the ENTER key in step 146. The system waits in step 148 for the ENTER key to be depressed. Once it is depressed, the video RAM is cleared in step 150 and a cold reset is initiated.

An important aspect of the invention is the ability of the programming utility in accordance with the present invention to program different types of flash memory devices with a single utility. In addition to minimizing the software overhead for programming different types of flash memory devices within a computer system, the system also provides for faster programming since a single floppy disc can be used to program multiple types of flash memory devices. Moreover, if the checksum routine was utilized with 32-bit register addressing (e.g., executed in protected mode for an Intel-type 80.times.86 based machine), an entire image file (i.e., 128K byte) can be executed in a single operation in order to circumvent the 64K byte DOS limitation resulting from 16-bit register addressing to provide for faster flash ROM programming.

As mentioned above, another important aspect of the invention relates to the ability of the system to recover from a flash disaster. As discussed above, a flash disaster relates to a condition when the data in flash ROMs and, in particular, the BIOS ROM 30, becomes corrupt as determined by a checksum. The flash disaster recovery utility in accordance with the present invention provides for recovery (e.g., ability to reprogram flash ROMs 20, 30) in such a condition. In particular, the flash disaster recovery utility includes three segments: a boot block segment 160, a loader segment 162 and a flash utility segment 164. These segments are identified by the dashed boxes in FIG. 5. As noted above, certain of the normal BIOS functions are separated out and stored in the boot block 22 in order to enable recovery of the system when a ROM image file has been found to be corrupt. In particular, the principal BIOS function separated out relate to those basic BIOS functions used for initialization of hardware. In addition to the BIOS hardware initialization function, the boot block 22 also includes a utility for performing a checksum of the BIOS ROM 30 as discussed above. Lastly, the boot block utility 160 is also used to load the loader utility 162 into main memory 36. As will be discussed in more detail below, the loader utility 162 is used, in turn, to load the flash recovery utility 164 in order to allow the flash ROMs 20 and 30 to be reprogrammed whenever a checksum of the data within these devices is determined to be corrupt.

A generalized block diagram of the entire flash disaster recovery utility illustrating the boot block segment 160, the loader segment 162, as well as the flash utility segment 164 is illustrated in FIG. 5. A more detailed flow diagram of the loader utility 162 (FIG. 6B) and the flash utility 164 is illustrated in FIGS. 6A and 6B. Additionally, the source code for the loader utility 162 (FIG. 6B) which includes the source code files PPLOADER.C, PLDFLASH.C and PPBBINTF.ASM is included in Appendix 2. The source code for the flash utility 164 (FIG. 6C) includes the files PPFLOPPY.C, FLDFLASH.C, PPBBINTF.ASM and FPPINTL.C, also illustrated in Appendix 2. It is also to be noted that the source code files in Appendix 2 may be implemented in a protected mode to enable full 32-bit addressing. As indicated above, 32-bit addressing enables a single checksum to be executed for an entire 128 kilobytes. As such, the checksum execution can be done relatively quicker than other systems which utilize separate checksum utilities for each 64 kilobyte segment in the system. Accordingly, in a system utilizing a 128 kilobyte flash ROM, two such checksum operations would be required for each flash ROM; thus requiring a relatively longer time period to reprogram the flash ROM.

As mentioned above, the boot block 22 contains program instructions for performing a checksum of the BIOS ROM 30 in step 166. If the checksum of the BIOS ROM 30 indicates the data in the BIOS ROM 30 is valid in step 168, the system executes a normal system sequence. If the checksum indicates that the data in the BIOS ROM 30 is corrupt, the boot block utility 22 performs certain BIOS functions and additionally loads the loader utility 162 into main memory 36 to enable the flash recovery utility. In particular, as indicated by step 170, the boot block utility 160 initializes hardware as well as the floppy disc in step 170. The boot block utility also loads the loader utility 162 into main memory 36 in step 170. After the hardware and floppy disc has been initialized and the loader utility 162 has been loaded, the system checks in step 172 to determine if the loading of the loader utility 162 was successful in step 172. If not, an aural warning is generated in step 174. Subsequent to the aural warning in step 174, the system waits in step 176 for a system reset. Once the system is reset, the system control is returned to step 166 and the cycle may be repeated.

If the system determines that the loader utility 162 was successfully loaded into main memory 36, the system executes the loader utility in step 178, as will be discussed in more detail below. In addition to executing the loader utility 162, the system slushes an SCP call to main memory 36 from the floppy disc 34. In particular, during a condition when the BIOS ROM 30 has been determined to be corrupt, an additional BIOS function is included on the floppy disc with the flash ROM update and is loaded into main memory 36. More specifically, for portable personal computers which normally use liquid crystal displays (LCD), a system control processor (SCP) call is used to check the LCD type. In addition, the SCP call controls the programming voltage V.sub.pp as well as having responsibility for auto-reset of the system.

In addition to slushing the SCP call, the video RAM is initialized and the flash utility 164 is loaded into main memory 36. The system next checks in step 180 whether these functions were successful. If not, the system provides a visual error message and prompts the user to re-boot in step 182. After the visual error message is provided, the system waits for reset in step 184. After reset, the system returns to step 166.

If the functions identified in step 178 are found to be successful, the flash utility 164 is executed in step 186. As will be discussed in more detail below, execution of the flash utility 164 includes loading of the ROM image from the floppy disc 34 into main memory 36 and finally into the flash ROM. If this operation is successful, as determined in step 188, the system then checks to see if the flash recovery was successful in step 190. If not, a visual error message is generated and the user is prompted to re-boot in step 192. If the flash recovery is successful, as determined in step 190, the system is reset in step 194.

The loader utility 162 is illustrated in FIG. 6A. This utility, identified as file PPLOADER.C in Appendix 2, is used to load the flash programming utility 164 from a floppy disc 34 into main memory 36. Subsequently, control is transferred to the flash programming utility 164 to update the flash ROM 20, 30 which has been corrupted. The utility is set up to operate in the protected mode using the global descriptor table (GDT).

As illustrated in FIG. 6A, initially, in step 200, variables are initialized and buffer space is requested for the ROM image file. In particular, the loader utility 164 is provided with sufficient code to perform all its own BIOS functions. Accordingly, various disc variables such as number of sectors per track, sector size, cluster size and head number are initialized. In addition, buffer space is requested for the ROM image file and the file allocation table (FAT). More particularly, the floppy disc 34 used for flash disaster recovery to update the flash ROMs 20, 30 is a DOS-formatted disc which includes a boot sector and a FAT table. As such, memory space for the FAT table and the ROM image file is reserved in step 200. In addition, the target name of the ROM image file for the flash utility 164 is copied into a global buffer.

As mentioned above, an SCP call is used for various functions including checking the LCD type; controlling of the LCD; controlling of the programming voltage V.sub.pp and control of reset. During a flash recovery mode of operation, the SCP code is stored on the floppy disc 34. Accordingly, this SCP code is copied to main memory 36 in step 202. In addition, the video RAM is initialized and a banner is displayed which, for example, may indicate the name of the utility; flash programming utility.

Next, in steps 204 and 206, the system checks to see if a floppy disc containing the flash programming utility 164 has been inserted in the designated drive. If not, an error message is displayed and an error flag is set in step 208. The system may permit several retries after which the user may be prompted to re-boot in step 210. After the user prompt, the system awaits reset in step 212, after which it returns to the boot block.

If the disc is ready in step 206, the utility looks for the flash ROM image file on the floppy disc 34 in step 214. This is done by first locating the FAT table. After the FAT table is located on the floppy disc 34, it is loaded into the main memory along with the root directory. Subsequently, the root directory is searched for the flash ROM image file name that was stored in the global buffer in step 200 in step 216. If the flash ROM image file is found, it is loaded into main memory in step 218. If not, an error message is displayed and error flag is set in step 220.

The system then checks to determine if the operation of loading the ROM image file into main memory was successful in step 222. If not, an error message is displayed and an error flag is set in step 224. If the image file was successfully loaded into main memory 36, a success flag is set in step 226. Once the system acknowledges that the success flag is set in step 228, the GDT is updated in step 230. Once the GDT is updated, control is transferred to the flash programming utility 164 in step 232.

As illustrated in FIG. 6B, once control is transferred to the flash programming utility 164, the variables are initialized and the file name of the ROM image file is copied to the global buffer in step 234. Subsequently, in step 236, the program banner, identifying the flash programming utility, is displayed. Additionally, the utility sets the program delay constant as well as checks for disc insertion in step 238. If the disc has been inserted into the appropriate drive, the utility searches for the ROM image file in step 240. If not, an error message is displayed in step 242 and the user is prompted to re-boot in step 244. Once the user is prompted to re-boot, the system waits for a reset in step 246, after which the system transfers to the boot block.

The system next checks for the ROM image file in step 248 by comparing file names in the root directory with the target file name copied to the global buffer. If the ROM image file is located, it is loaded into main memory 36 in step 250. If the ROM image file is not located, an error message is displayed in step 252.

As illustrated in FIG. 6B, once the image file is successfully loaded into main memory 36, the system checks in step 254 to determine if the operation was successful. If not, an error message is displayed in step 256. Subsequently, a checksum of the image file is performed in step 255. If the checksum indicates corrupt data, an error message is given in step 257. If the checksum indicates that the data in the image file is valid, the system proceeds to erase the flash BIOS ROM 30 which is located in the lower address space in step 256. Once the BIOS ROM 30 is erased, the system checks in step 258 to determine if the erasure was successful in step 258. If not, an error message is displayed in step 260. If the erasure was successful, the ROM image file in main memory is programmed into the flash ROM 30 in step 262. The system next checks in step 264 to determine whether programming of the flash ROM 30 was successful. If not, an error message is displayed in step 266. If erasure and programming of the BIOS ROM 30 was successful, the system next proceeds to erase the main block and two parameter blocks of the flash recovery ROM 20 in step 268. After those blocks of the flash recovery ROM 20 have been erased, the system next checks to see if the erasure was successful in step 270. If not, an error message is displayed in step 272. If so, the blocks 24, 26 and 28 of the flash recovery ROM 20 is programmed with the ROM image file in main memory in step 274. The system next checks to determine if programming of the those blocks was successful in step 276. If not, an error message is displayed in step 278. If the blocks 24, 26 and 28 of the flash recovery ROM 20 are successfully programmed, the system displays a user message indicating that the recovery was successful and proceeds to initiate a system reset in step 280. Subsequently, the system returns to the boot block 22.

The programming utility described above enables multiple types of flash ROMs to be reprogrammed during a single operation. In addition, in the event that the data in the flash ROM becomes corrupt, a recovery utility is provided which enables the flash ROM to be reprogrammed during such a condition.

Various implementations of the programming utilities are contemplated. In one implementation, it is contemplated that the system utilize 32-bit register addressing. By enabling 32-bit register addressing, the checksum routines performed on the ROMs and ROM image files can be performed in a single operation, thus speeding up the operation.

It should be noted that the instructions for erasing and programming the specific Intel-type flash ROM identified herein are described in detail in a publication entitled "MEMORY PRODUCTS 1992", supra, hereby incorporated by reference. In addition, the specific flash ROM programming instructions are also included in the appropriate source code files in Appendices 1 and 2.

Obviously, many modifications and variations of the present invention are possible in light of the above teachings. Thus, it is to be understood that, within the scope of the appended claims, the invention may be practiced otherwise than as specifically described above. ##SPC1##