CA2020521C - Apparatus and method for decreasing the memory requirements for bios in a personal computer system - Google Patents
Apparatus and method for decreasing the memory requirements for bios in a personal computer systemInfo
- Publication number
- CA2020521C CA2020521C CA002020521A CA2020521A CA2020521C CA 2020521 C CA2020521 C CA 2020521C CA 002020521 A CA002020521 A CA 002020521A CA 2020521 A CA2020521 A CA 2020521A CA 2020521 C CA2020521 C CA 2020521C
- Authority
- CA
- Canada
- Prior art keywords
- bios
- boot record
- master boot
- memory
- storage device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 230000003247 decreasing effect Effects 0.000 title claims abstract description 6
- 238000012360 testing method Methods 0.000 claims description 21
- 230000006870 function Effects 0.000 claims description 16
- 238000010200 validation analysis Methods 0.000 claims description 4
- 230000000694 effects Effects 0.000 claims description 3
- 239000013598 vector Substances 0.000 abstract description 6
- 238000005192 partition Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 11
- 238000012546 transfer Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000002093 peripheral effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000009413 insulation Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
Abstract
ABSTRACT
An apparatus and method for decreasing the memory requirements of BIOS in a personal computer system includes storing a first portion of BIOS in memory and a second portion on a direct storage access device. The personal computer system comprises a system processor, a random access main memory, a read only memory, and at least one direct access storage device. The read only memory includes the first portion of BIOS and data representing the type of system processor and system planar I/O configuration. The first portion of BIOS only includes routines for initializing the system and the direct access storage device to read in a master boot record into the system from the direct access storage device. The master boot record includes a data segment and an executable code segment. The data segment includes data representing system hardware and a system configuration which is supported by the master boot record. The first BIOS portion confirms the master boot record is compatible with the system hardware by verifying that the data from the data segment of the master boot record agrees with the system processor, system planar, and planar I/O configuration. If the master boot record is compatible with the system hardware, the first BIOS portion vectors the system processor to execute the executable code segment of the master boot record. The executable code segment confirms that the system configuration has not changed and loads in the remaining BIOS portion from the direct access storage device into random access memory superseding the first BIOS portion. The executable code segment then verifies the authenticity of the remaining BIOS portion and vectors the system processor to begin executing the remaining BIOS now in random access memory. The remaining BIOS in main memory includes reusable routines for operating the personal computer system in a normal manner.
An apparatus and method for decreasing the memory requirements of BIOS in a personal computer system includes storing a first portion of BIOS in memory and a second portion on a direct storage access device. The personal computer system comprises a system processor, a random access main memory, a read only memory, and at least one direct access storage device. The read only memory includes the first portion of BIOS and data representing the type of system processor and system planar I/O configuration. The first portion of BIOS only includes routines for initializing the system and the direct access storage device to read in a master boot record into the system from the direct access storage device. The master boot record includes a data segment and an executable code segment. The data segment includes data representing system hardware and a system configuration which is supported by the master boot record. The first BIOS portion confirms the master boot record is compatible with the system hardware by verifying that the data from the data segment of the master boot record agrees with the system processor, system planar, and planar I/O configuration. If the master boot record is compatible with the system hardware, the first BIOS portion vectors the system processor to execute the executable code segment of the master boot record. The executable code segment confirms that the system configuration has not changed and loads in the remaining BIOS portion from the direct access storage device into random access memory superseding the first BIOS portion. The executable code segment then verifies the authenticity of the remaining BIOS portion and vectors the system processor to begin executing the remaining BIOS now in random access memory. The remaining BIOS in main memory includes reusable routines for operating the personal computer system in a normal manner.
Description
2~57~
AN APPARATUS AND METHOD FOR DECREASING THE MEMORY
REQUIREMENTS FOR BIOS IN A PERSONAL COMPUTER SYSTEM
Field of the Invention This invention relates to personal computer systems and in particular to a method and device for installing BIOS into a personal computer system.
Back~round Discussion -Personal computer systems in general and IBM
personal computers in particular have attained widespread use for providing computer power to many segments of today s modern society. Personal computer systems can usually be defined as a desk top, floor standing, or portable microcomputer that consists of a system unit having a single system processor, a display monitor, a keyboard, one or more diskette drives, a fixed disk storage, and an optional printer. One of the distinguishing characteristics of these systems is the use of a motherboard or system planar to provide electrical communications between components. These ~ystem~ are designed primarily to give independent computing power to a single user and are inexpensively priced for purchase by individual6 or small businesses.
Example~ of such personal computer systems are the IBM~
PERSONAL COMPUTER AT~ and IBM PERSONAL SYSTEM/2~ Models 25, 30, 50, 60, 70 and 80 computers.
These systems can be classified into two general familie~. The first family, u~ually referred to as Family I Model~, use a bus architecture exemplified by the IBM PERSONAL COMPUTER AT and other "IBM compatible"
machines. The ~econd family, referred to as Family II
Model~, use the IBM MICROCHANNEL~ bu~ architecture exemplified by the IBM PERSONAL SYSTEM/2 Models 50 through 80 computer~.
Beglnning with the earliest personal computer system of the family I models, such a~ the IBM Personal Computer, it wa~ recognized that software compatibility would be of utmost importance. In order to achieve this goal, an insulation layer of ~ystem resident code, 202~2i referred to as "microcode", was established between the hardware and software. This code provided an operational interface between a user s application program/operating system and the device to relieve the user of the concern about the characteristics of hardware devices.
Eventually, the code developed into a BASIC input/output system (BIOS), for allowing new devices to be added to the system, while insulating the application program from the peculiarities of the hardware. The importance of BIOS was immediately evident because it freed a device driver from depending on specific device hardware characteristics while providing the device driver with an intermediate interface to the device. Since BIOS was an integral part of the system and controlled the movement of data in and out of the system processor, it was resident on the system planar, and was shipped to the user in a read only memory (ROM). For example, BIOS in the original IBM Personal Computer occupied 8K of ROM
resident on the planar board.
As new models of the personal computer family were introduced, BIOS had to be updated and expanded to include new hardware and I/O devices. As could be expectedj BIOS started to increase in memory size. For example, with the introduction of the IBM PERSONAL
COMPUTER AT Computer, BIOS grew to require 32K bytes of ROM.
Today, with the development of new technology, personal computer systems of the Family II models are growing even more sophi~ticated and are being made available to consumer~ more frequently. Since the technology is rapidly changing and new I/O devices are being added to the personal computer systems, modification to the BIOS has become a significant problem in the development cycle of the personal computer system.
For in~tance, With the introduction of the IBM
Personal System/2 Computer with MICROCHANNEL
architecture, a significantly new BIOS, known as advanced BIOS, or ABIOS, was developed. However, to maintain software compatibility, BIOS from the Family I models had to be included in the Family II models. The Family I
BIOS became known as Compatibility BIOS or CBIOS.
2~20~2~
BCs-89-025 3 However, as previously noted with respect to the AT
computer, only 32K bytes of ROM were resident on the planar board. Fortunately, the system could be expanded to 96K bytes of ROM. Unfortunately, in an effort to maintain compatibility with older systems, this turned out to be the maximum capacity available for BIOS. Thus BIOS is constrained to be addressable between fixed addresses in memory, where the amount of memory available is 96K bytes. Luckily, even with the addition of A8IOS, ABIOS and CBIOS could still squeeze into 96K of ROM.
However, only a small percentage of the 96K ROM area remained available for expansion. With the addition of future I/O devices, CBIOS and ABIOS will eventually run out of ROM space. Thus, new I/O technology will not be able to be easily integrated within CBIOS and ABIOS.
Due to these problems, it has become necessary to decrease the operating size of BIOS while increasing or at least maintaining the same level of functionality.
Since marketability and consumer acceptance of personal computer systems appear to require the ability to maintain compatibility, it should be appreciated that maintaining the same level of functionality of BIOS is a substantial factor in achieving success in accordance with this invention. Thus, there exists a need for developing a method and apparatus which decreases the code space required for BIOS in Family II machines.
Summary of the Invention The present invention has been developed for the purpo~e of alleviating the above mentioned problems.
Accordingly, the invention has as one of its objects an apparatus and method for decreasing the operating size of BIOS by storing a portion of BIOS on a direct access storage device, while maintaining compatibility with previous BIOS type operating systems.
Another objective of the present invention is to provide an apparatus and method for permitting a portion of BIOS to be executed and then rendered inaccessible to the system.
Another object of thè present invention is to provide a 202~2~
BIOS record format which segments BIOS according to function in order to store those BIOS routines which are executed only once on ROM, while those BIOS routines which are executed more than once are stored on the direct access storage device.
Broadly considered, a personal computer system according to the present invention comprises a system processor, a random access main memory, a read only memory, and at least one direct access storage device.
The read only memory includes a first portion of BIOS
while the remaining portion is stored on the direct access storage device. The first BIOS portion includes routines that are used for initialization and set up, while the remaining portion of BIOS includes routines that are reusable by the operating system. In operation, the first portion of BIOS initializes the system processor and the direct access storage device to read in a master boot record into the random access memory from the direct access storage device.
The ma~ter boot record includes a data segment and an executable code segment. The data segment includes data representing system hardware and a system configuration which is supported by the master boot record. The first BIOS portion confirms the master boot record is compatible with the sy~tem hardware by verifying that the data from the data segment of the ma#ter boot record agrees with the system processor, ~ystem planar, and planar I/O configuration.
If the master boot record is compatible with the system hardware, the first BIOS portion vectors the system processor to execute the executable code segment of the ma~ter boot recoxd. The first BIOS portion is then discarded by the system. The executable code ~egment confirms that the system configuration has not chan~ed and loads in the remaining BIOS portion from the dlrect access storage device into random acce~s memory.
The executable code segment then verifies the authenticity of the remaining BIOS portion and vectors the system processor to begin executing the remaining BIOS now in random access memory. The remaining portion of BIOS includes only those routines needed for normally 2~2~
~C9-89-025 5 operating the system. The first BIOS portion, ~eing no longer addressable and superseded by the remaining BIOS
portion, is abandoned.
Brief Description of the Drawinqs The foreground aspects and other features of the present invention are explained in the following written description, taken in connection with the accompanying drawings, wherein:
Fig. 1 illustrates a cut away view of a personal computer system showing a system planar board connected to a plurality of direct access storage devices;
Fig. 2 shows a system block diagram for the personal computer system of Fig. 1;
Fig. 3 is a memory map for the ROM BIOS included on the planar board;
Fig. 4 is a flowchart describing the overall process for loading a BIOS image from a direct access storage device;
Fig. 5 illustrates the record format for the master boot record;
Fig. 6A is a flowchart describing the operation of the IBL routine;
Fig. 6B is a flowchart showing the steps for loading a BIOS image from a fixed disk;
Fig. 6C is a flowchart showing the steps for loading the BIOS image from a diskette;
Fig. 6D i~ a flowchart showing greater detail in checlcing the compatibility between the master boot record and the planar/proce~sor; and Fig. 7 is a detailed flowchart showing the execution of the executable code segment of the master boot record to load a BIOS image.
D~ iption of a Preferred Embodiment The following detailed description is of the best presently contemplated mode for carrying out the invention. This description i~ not to be taken in a limiting sense but is made merely for the purpose of 2~2~2 ~
illustrating the general principles of the ihvention since the scope of the invention is best defined by the appended claims.
Referring now to the drawings, and in particular to Fig. 1, there is shown a cutaway version of a personal computer system lO, having a plurality of DASD (Direct Access Storage Devices) 12 - 16 connected to a system or planar board 24 through a plurality of I/O slots 18. A
power supply 22 provides electrical power to the system lO in a manner well known. The planar board 24 includes a system processor which operates under the control of instructions to input, process, and output information.
In use, the personal computer system lO is designed primarily to give independent computing power to a small group of users or a single user and is inexpensively priced for purchase by individuals or small businesses.
In operation, the system processor operates under an operating system, such as the IBM OS/2~ Operating System or PC-DOS. This type of system includes a BIOS interface between the DASD 12 - 16 and the Operating System. A
portion of BIOS divided into modules by function is stored in ROM on the planar 24 and hereinafter will be referred to as ROM-BIOS. BIOS provides an interface between the hardware and the operating system software to enable a programmer or user to program their machines without an indepth operating knowledge of a particular device. For example, a BIOS diskette module permits a programmer to program the diskette drive without an lndepth knowledge of the diskette drive hardware. Thus, a number of di~kette drivee designed and manufactured by different companiee can be used in the system. This not only lowere the coet of the eyetem lO, but permits a user to chooee from a number of diekette drives.
Prior to relating the above structure to the present invention, a 0ummary of the operation in general of the pereonal computer system 10 may merit review. Referring to Fig. 2, there is ~hown a block diagram of the personal computer ~yetem 10. Fig. 2 illu~trate~ components of the planar 24 and the connection of the planar 24 to the I/O
elots 18 and other hardware of the personal computer system. Located on the planar 24 is the system processor - 2~2~21 BCs-89-025 7 26 comprised of a microprocessor which is connected by a local bus-28 to a memory controller 30 which is further connected to a random access memory (RAM) 32. While any appropriate microprocessor can be used, one suitable microprocessor is the 80386 which is sold by Intel.
While the present invention is described hereinafter with particular reference to the system block diagram of Fig. 2, it is to be understood at the outset of the description which follows, it is contemplated that the apparatus and methods in accordance with the present invention may be used with other hardware configurations of the planar board. For example, the system processor could be an Intel 80286 or 80486 microprocessor.
Accessible by the processor is a planar identification number (planar ID). The planar ID is unique to the planar and identifies the type of planar being used. For example, the planar ID can be hardwired to be read through an I/O port of the system/processor 26 by using switches.
The local bus 28 is further connected through a bus controller 34 to a read only memory (ROM) 36 on the planar 24.
An additional nonvolatile memory (NVRAM) 58 is connected to the microprocessor 26 through a serial/parallel port interface 40 which is further connected to bu~ controller 34. The nonvolatile memory can be CMOS with battery backup to retain information whenever power is removed from the sy~tem. Since the ROM
is normally resident on the planar, model and submodel values stored in ROM are used to identify the system processor and the system planar I/O configuration re~pectively. Thu~ the~e values will physically identify the proce~sor and planar I/O configuration. The NVRAM 58 is used to store system configuration data.
That is, the NVRAM will contain value~ which describe the pre~ent configuration of the system. For example, NVRAM
contaln~ lnformfltion describing the capacity of a fixed di~k or diskette, the type of display, the amount of memory, time, date, etc. Additionally, the model and ~ubmodel values stored in ROM are copied to NVRAM
whenever a special configuration program, such as SET
2a2~
Configuration, is executed. The purpose of the SET
Configuration program is to store values characterizing the configuration of the system in NVRAM. Thus for a system that is configured properly, the model and submodel values in NVRAM will be e~ual respectively to the model and submodel values stored in ROM. If these values are not equal, this indicates that the configuration of the system has been modiied. Reference is made to Fig. 6D, where this feature in combination with loading BIOS is explained in greater detail.
Continuing, our discussion with reference to Fig. 2, the bus controller 34 is further coupled to I/O slots 18, the serial/parallel interface 40 and peripheral controller 42 by an I/O planar bus 43. The peripheral controller 42 is further connected to a keyboard 44, mouse 46, diagnostic panel 47~ and diskette controller 64. Beside the NVRAM 58, the serial/parallel interface 40 is further connected to a serial port 4~ and parallel port 50 to input/output information to a printer, hard copy device, etc. As is well known in the art, the local bus 28 can also be connected to a cache controller 52, a cache memory 68, a co-processor 54, and a DMA controller 56.
The system processor 26 controls its internal operation as well as interfacing with other elements of the personal computer system 10. For example, system proces~or 26 is shown connected to a small computer sy~tem interface (SCSI) I/O card 60 which is further connected to a DASD, such as a fixed disk drive 62. It is to be understood that other than a SCSI disk drive/adapter can be used as a fixed disk in accordance with the present invention. In addition to the fixed disk 62, the ~ystem proces~or 26 can be interfaced to the diakette controller 64 which controls a diskette drive 66. With respect to terminology, it is al~o to be understood that the term "hardfile" de~cribes fixed disk drive 62 while the term "floppy" alco describe~ diskette drive 66.
Previous to the pre~ent invention, ROM 36 could include all of the BIOS code which interfaced the 21~2a~2~
operating system to the hardware peripherals. According to one aspect of the present invention, however, ROM 36 is adapted to store only a portion of BIOS. This portion includes routines used only for initializing the system and for loading a second or remaining BIOS portion. When the first BIOS portion is executed by the system processor 26, it inputs from either the fixed disk 62 or diskette 66 the second or remaining portion of BIOS, hereinafter referred to as a BIOS image. This BIOS image supersedes the first BIOS portion and includes operating routines which are reusable and therefore are an integral part of the system. In practice, these routines remain resident in main memory such as RAM 32. The first portion of BIOS (ROM-BIOS) as stored in ROM 36 will be explained generally with respect to Figs. 3-4 and in detail with respect to Figs. 6A-D. The second portion of BIOS (BIOS image) will be explained with respect to Fig.
5, and the loading of the BIOS image with respect to Fig.
7. Another benefit from loading a BIOS image from a DASD
is the ability to load BIOS directly into the system processor's RAM 32. Since accessing RAM is much faster than accessing ROM, a significant improvement in the processing speed of the computer system is achieved.
The explanation will now proceed to the operation of the BIOS in ROM 36 and to the operation of loading the BIOS image from either the fixed disk or diskette. In general upon power up, the processor i 8 vectored to ROM-BIOS which initialize~ the sy~tem and DASD and loads A BIOS master boot record into RAM. The master boot record include~ a data segment having validation .tnformation and a code ~egment having executable code.
ROM-BIOS transfers control to the code seyment which code u~es the data information to validate hardware compatibility and system configuration. After testing for hardware compatibility and proper ~ystem configuration, the executable code loads the BIOS image into RAM. The BIOS image supersedes ROM-BIOS and includes operating system routine~ which are useable to provide for the operation of the machine.
2~2~2~
For purposes of clarity, the executable code segment of the master boot record will be referred to as MBR code while the data segment will be referred to as MBR data.
Referring to Fig. 3 there is a memory map showing the different code modules which comprise ROM-BIOS.
These code modules are judicially chosen to include only routines that are necessary to initialize the system, test the hardware necessary to load the BIOS image, and provide communications with the user. ROM-BIOS includes a power on self test (POST) stage I module 70, an Initial BIOS Load (IBL) Routine module 72, a Diskette module 74, a hardfile module 76, a video module 78, a diagnostic-panel module 80, and hardware compatibility data 82. Briefly, POST Stage I 70 performs system pre-initialization and tests. The IBL routine 72 determines whether the BIOS image is to be loaded from disk or diskette, checks compatibility and loads the master boot record. Diskette module 74 provides input/output functions for a diskette drive. Hardfile module 76 controls I/O functions to a fixed disk or the like.
Video module 78 controls output functions to a video I/O
controller which is further connected to a video display.
Diagno~tic panel module 80 provides control to a diagnostic display device for the system. The hardware compatibility data 82 includes data values to confirm hardware compatibility and system configuration which are described later with respect to Fig. 5. It is important to note that the ROM-BIOS routines are not necessary to normally operate the system. The ROM-BIOS routines are used only once to initialize, test, and load. ROM-BIOS
is then discarded and superseded by the BIOS image. This ~egregation of BIOS functions eff0ctively reduces the memory requirement~ for BIOS under normal operating condltions.
Referring now to Fig. 4, there is shown a process overvlew for loading a BIOS image into the sy~tem from either the fixed disk or the diskette. When the system is powered up, the system processor is vectored to the entry point of POST Stage I, step~ 101 and 100. POST
Stage I initializes and te6ts only those system functions 2020~2~
needed to load BIOS image from the selected DASD, step 102. In particular, POST Stage I initializes the processor/planar functions, diagnostic panel, memory subsystem, interrupt controllers, timers, DMA subsyst~m, fixed disk BIOS routine (Hardfile module 76), and diskette BIOS routine (Diskette module 74), if necessary.
After POST Stage I pre-initializes the system, POST
Stage I vectors the system processor to the Initial BIOS
Load (IBL) routine included in the Initial BIOS Load module 72. The IBL routine first, determines whether the BIOS image is stored on fixed disk or can be loaded from diskette; and second, loads the master boot record from the ~elected media (either disk or diskette) into RAM, step 104. The master boot record includes the MBR data and the MBR code. The MBR data is used for verification purposes and the MBR code is executed to load in the BIOS
image. A detailed description of the operation of the IBL routine is presented with respect to Figs. 6A-D.
With continuing reference to Fig. 4, after the IBL
routine loads the master boot record into RAM, the system processor is vectored to the starting address of the MBR
code to begin execution, step 106. The MBR code performs a series of validity tests to determine the authenticity of the BIOS image and to verify the configuration of the system. For a better understanding of the operation of the MBR code, attention is directed to Fig. 7 of the drawings wherein the MBR code is described in greater detail.
On the basis of these validity tests, the MBR code loads the BIOS image into RAM and transfers control to the newly loaded BIOS image in main memory, step 110. In particular, the BIOS image i8 loaded into the address space previously occupied by ROM-BIOS. That is if ROM-BIOS i8 addressed from EOOOOH through FFFFFH, then the BIOS image i~ loaded into this RAM address space of RAM thus superseding ROM-BIOS. Control is then tran~ferred to POST Stage II which was included in the newly loaded BIOS image thus effectively abandoning ROM-BIOS. POST Stage II, now in RAM, initializes and test~ the remaining system in order to load the operating ~ystem boot, step 110. After the system is 2~20 ~2~
initialized and tested, Stage II POST transfers control to the operating system boot to load the operating system, steps 112-114.
Referring back to step 110, it is noted that entry to POST Stage II can be put in effect through a reset function, step 107. ~he reset function is normally actuated by the user whenever a "warm start" is desired, step 108. For example, the reset function can be activated by simultaneously pressing the ctrl-alt-del keys on the keyboard. The effect of a warm start is to bypass the pre-initialization, testing, and initial BIOS
load. It is important to note that a warm start does not reboot BIOS, however, the operating system will be rebooted by POST Stage II. Thus if the BIOS in RAM has not been affected, the system should operate in a normally manner after rebooting.
For clarity, it is appropriate at this point to illustrate a representation for the format of the master boot record. Referring to Fig. 5, there is shown the master boot record. The boot record includes the executable code segment 120 and data segments 122-138.
The MBR code 120 includes DASD dependent code responsible for verifying the identity of the ROM-BIOS, checking that the IBL boot record is compatible with the system, verifying the system configuration, and loading the BIOS image from the selected DASD (disk or~diskette).
The data segment~ 122-138 include information used to define the media, identify and verify the master boot record, locate the BIOS image, and load the BIOS image.
The master boot record is identlfied by a boot record ~ignature 122. The boot record ~ignature 122 can be a unique bit pattern, such a~ a character string "ABC", in the flrst three bytes of the record. The lntegrlty of the master boot record is tested by a checksum value 132 which is compared to a computed check~um value when the boot record i~ loaded. The data segmsnts further include at least one compatible planar ID value 134, compatible model and ~ubmodel values 136.
Th~ master boot record s planar ID value defines which planar that the master boot record is valid for.
-- 2~2~2~L
~C9-89-025 13 Similarly, the master boot record's model and submodel values define the processor and planar I/O configuration respectively that the master boot record is valid for.
It is noted that the boot record's signature and checksum identify a valid master boot record, while the boot record's planar ID, boot record's model and boot record's submodel comparisons are used to identify a boot record compatible with the system and to determine if the system configuration is valid Another value, boot record pattern 124 is used to determine the validity of the ROM-BIOS. The boot record pattern 124 is compared to a corresponding pattern value stored in ROM. If the values match this indicates that a valid ROM-BIOS has initiated the load of a BIOS image from the selected media.
The following description further describes in greater detail each of the values in the master boot record and their functions:
MBR Identifier (122): The first three bytes of the IBL
boot record can consist of characters, such as "ABC".
This ~ignature is used to identify a boot record.
MBR Code Seqment (120): This code verifies the compatibility of the boot record with the planar and processor by comparing corresponding planar id and model/submodel values. If these values match, it will load the BIOS image from the chosen media to system RAM.
If the system image (BIOS image loaded into memory) checksum is valid and no media load errors occur, the MBR
code wi].l map the image to RAM and then transfer control to the POST Stage II routine of the system image.
MBR Pattern (124): The first field of the IBL boot record data segment contains a pattern, such as a character string "ROM-BIOS 1989". This string is used to validate the ROM-BIOS by comparing the Boot Pattern value to the corresponding value stored in ROM (ROM-Pattern).
MBR Version Date_L1~6L~ The master boot record includes a ver~ion date for u~e by an update utility.
Sv8tem Partit~on Pointer (128): The data segment contains a media pointer to the beginning of the media system partition area for use by Stage II POST. On an IBL dislcette, the pointer is in track-head-sector format;
2a2~2~.
on disk the pointer is in Relative Block Address (RBA) format.
SYStem Partition Type (130): The system partition type indicates the structure of the media system partition.
There are three types of system partition structures -full, minimal and "not present". The full system partition contains the setup utility and diagnostics in addition to the BIOS image and master boot record. The minimal system partition contains just the BIOS image and master boot record. If a system does not have a hardfile, the system partition type indicates "not present". In this instance, IBL will occur from the diskette. These three system partition types allow flexibility in how much space the system partition takes up on the media.
Checksum value (132): The checksum value of the data segment is initialized to generate a valid checksum for the record length value (1.5k bytes) of the master boot record code.
MBR Planar ID Value (134): The data segment includes a value, such as a string of words defining compatible planar IDs. Each word is made up of a 16 bit planar ID
and the string is terminated by word value of zero. If a system s planar ID matches the planar ID value in the master boot record, such as one of the words in the string, the IBL media image is compatible with the system planar. If the system s planar ID does not match any word in the ~tring, the IBL media image is not compatible with the system planar.
MBR model and submodel values (136): The data segment includes values, such as a ~tring of words defining compat.ible proce~#ors. Each word is made up of a model and submodel value and the #tring is terminated by a word value of zero. If a system's model and submodel value (stored in ROM) match one of the words in the string, the IBL media lmage is compatible with the system processor.
If the ROM model and ROM submodel values do not match any word ln the string, the IBL media image is not compatible with the system processor.
B_ a~ lenath (138): The IBL map length is initialized to the number of media image blocks. In other words, if 2~20~2~
BCs-89-025 15 the BIOS image is broken into four blocks, the map length will be four indicating four block pointer/length fields.
Usually this length is set to one, since the media image is one contiguous 128K block.
MBR Media Sector Size (138): This word value is initialized to the media sector size in bytes per sector.
Media image block pointer (138): The media image block pointer locates a system image block on the media.
Normally, there is only one pointer since the media image is stored as one contiguous block. On an IBL diskette, the pointers are in track-head-sector format; on disk the pointers are relative block address format.
Media imaqe block lenqth (138): The media image block length indicates the size (in sectors) of the block located at the corresponding image block pointer. In the case of a 128K contiguous media image which includes space for BASIC this field is set to 256, indicating that the BIOS image block takes up 256 sectors (512 bytes/~ector) starting at the media image block pointer location.
Referring now to Figs. 6A-D, there is shown a detailed flow chart of the operation of the IBL routine.
Under normal circumstances, the IBL routine loads the master boot record from the system fixed disk into RAM at a specific address and then vectors the system processor to begin executing the code segment of the master boot record. The IBL routine also contains provisions for a diskette default mode in which the master boot record can be loaded from diskette. However, the IBL routine does not allow the diskette default mode to be performed i~ the system contains the IBL media on the system fixed diek and a valid pas~word is present in NVRAM. The user ha~ the option of ~etting the password in NVRAM. The purpose of preventing the diskette default mode from being effected is to prevent loading an authorized BIOS
image from diskette. In other words, the diskette default mode is used only when a system fixed disk i~ not operational and the user has indicated (by not setting the password) the desire to be able to load from the di~kette. If the IBL routine is not able to load the ~l~?~n~
master boot record from either media, an error message is generated and the system is halted.
Referring now to Fig. 6A, under normal circumstances the system will contain a system fixed disk which the IBL
routine initializes, step 150. Assume for purposes of illustration that the fixed disk is configured for Drive C of the personal computer system. Similarly, assume Drive A is designated as the diskette drive. The IBL
routine then examines Drive C to determine whether it contains IBL media, step 152. Attention is directed to Fig. 6B which describes in detail this process. The IBL
routine starts reading from the fixed disk at the last three sectors and continues reading, decrementing the media pointer, for 99 sectors or until a valid master boot record is found. If a master boot record is found, it is checked for system planar and processor compatibility, step 156. If it is not planar or processor compatible, then an error is reported, step 158. Referring back to step 152, if no master boot record is found on the last 99 sectors of the fixed disk (primary hardfile), an error is reported, step 154.
Referring back to step 156, if a master boot record is found, a series of validity checks are performed to determine if the master boot record is compatible with the computer system. Additionally, the configuration of the sy~tem is checked. Attention is directed to Fig. 6D
which discloses this process in greater detail. If the boot record is compatible With the planar ID, model and submodel, and if furthermore the system configuration has not changed the master boot record is loaded and the code ~egment of the master boot record is executed, ~tep 160.
Referring back to steps 154 and 158, if an error occurs in loading the master boot record from the fixed disk or if a fixed di~k is not available, the IBL routine determines if a valid password is included in NVRAM, step 162. This password determines whether the BIOS image can be loaded from diskette. Note that the password will exi~t only upon being in~talled by the user running a 2~20~21 setup utility. If a password is installed in NVRAM, the BIOS image is prevented from being loaded from diskette, step 164. This permits the user to ensure the integrity of the operation of the system by causing the system to be loaded only with the BIOS image on the fixed disk.
The password can take the form of a string of characters stored in NVRAM.
Referring back to step 162, if a valid password in NVRAM is not present, thus allowing BIOS image to be loaded from diskette, the IBL routine initializes the diskette subsystem, step 166. The IBL routine then determines if Drive A includes the IBL media on a diskette, step 168. If Drive A does not include IBL
media, an error is generated to notify the user that an invalid diskette has been inserted in the drive, step 170. The sy~tem then halts, step 172. Attention is directed to Fig. 6C for a more detailed discussion of ~tep 168.
Referring back to step 168, after Drive A is checked for IBL media, the master boot record is loaded into RAM
and the code segment included in the master boot record is executed, step 160. It is important to note that for diskette the IBL routine does not include the validity checks that are used with the fixed disk system. The reason for the absence of the validity checks is for loading a noncompatihle IBL image from diskette. For example, if a new processor is added to the system, a new BIOS image will be included on a diskette. Since a new proce~or will cau~e validity errors when loading from flxed disk, the IBL routine provide~ the ability to bypaas these tests by loading the BIOS image from diskette.
To recapitulate, the master boot record is checked for compatibility with the system through matching the system planar ID and proce~sor model/submodel values to the boot record values. For disk, this check is done first in the IBL routine and then done again in the IBL
boot record. The first check (in the IBL routine) is ~ 202~
done to make sure the boot record is compatible with the system; the second check (in the boot record) is done to ensure a compatible ROM passed control to the boot record. Notice that the check done in the disk boot record will never fail for a compatible ROM since the IBL
routine will have already checked the compatibility. In contrast, the compatibility check is not done for diskette. The planar/processor compatibility is checked only during diskette boot record execution. This method allows future modifications in loading a new BIOS image from a reference diskette.
In view of the description of the IBL routine of Fig. 6A, the explanation will now proceed to a comprehensive and full understanding of the validity tests discussed above. Referring to Fig. 6B, there is qhown a detailed flowchart of step 152 of Fig. 6A, to determine if a valid master boot record is on drive C.
The process begins by obtaining the drive parameters to enable the IBL routine to access drive C, step 200. An IBL load location i8 set to the last three sectors from the disk (the last three sectors normally contain the master boot record), step 202. A load count indicating the number of attempts to read a master boot record from disk i~ set to 1, step 204. Three æectors are read from disk at the IBL load location, step 206. Any disk drive errors are detected and if a disk drive read error occurs it i0 reported, steps 208-210. The process then returns with an error indication, step~ 212-214.
Referring back to step 208, if no drive error occur0, the di~k record i~ scanned for the master boot record signature, step 216. The boot record signature, such as the character0 "ABC", are compared to the first three bytes of the disk record. If the disk record does have a valid boot record signature (characters "ABC") and the checksum computed from the disk record loaded into memory equals the boot record checksum, the disk record is indicated as being a valid boot record with no errors, step 218. The process then returns, step 214.
2~20~2~
Referring back to step 216, if the boot record signature or checksum is invalid, the load count is incremented by 1, step 220. The load count is then compared to a predetermined constant such as 99, step 222. If 99 attempts to read a boot record have resulted in failure, an error is indicated and the process returns, steps 224, 212 and 214. If less than 99 attempts to read a boot record have occurred, the IBL
load location is decremented by one and three new sectors are read from the new load location, steps 226 and 206.
Thus if a valid IBL boot record cannot be loaded from the last 99 sectors (equivalent to 33 copies) then an error condition is set and control returns to the IBL routine.
Referring now to Fig. 6C, there is shown a detailed flow diagram for loading the master boot record from diskette on drive A. First, the diskette drive parameters to access drive A are retrieved, step 230.
The IBL load location is set to the last 3 sectors on diskette (cylinder, head and sector format), step 232.
The last 3 sectors are read, step 234. If a diskette drive error is detected an error is indicated, steps 236-238. An error condition is set and control is returned to the IBL routine, steps 240-242.
~ eferring back to step 236, if no drive error is detected, the diskette record is checked for boot record ~ignature and the checksum is calculated, step 244. If the boot record signature is missing or checksum is invalid, an error is indicated and control returned to the IBL routine, steps 244, 246, 240 and 242. If a valid boot record signature and valid checksum are detected an indication i~ set and control is returned to the IBL
routine, steps 248 and 242. It is noted that in a dl~kette load, the IBL routine does not search through the media as in the fixed disk load. Therefore, in a di~kette load, the IBL media must be stored in a specific location of the diskette.
Finally, Fig. 6D shows how the IBL routines tests for system planar and processor compatibility and for a 2~2~2 ~
BCs-89-025 20 proper system configuration. The master boot record is checked for compatibility with the system planar by comparing the boot record planar ID value to the system planar ID read by the system processor, step 260. If the system planar ID does not match the boot record planar ID
value, this indicates this master boot record is not compatible with this planar. An error is indicated and control return to the IBL routine, steps 262, 264, and 266.
If the master boot record is compatible with the planar, the master boot record is checked for compatibility with the processor, step 268. The boot record model value and submodel value are compared to the model value and submodel value stored in ROM
respectively. A mismatch indicates a new processor has probably been inserted and this boot record is not compatible with the new processor. An error is indicated and control returned to the IBL routine, steps 270, 264 and 266. If the master boot record is compatible with the planar and processor, the process or checks to determine if NVRAM contains reliable information, step 272. If NVRAM is unreliable, an error is indicated and control returned to the IBL routine, steps 274 and 266.
If NVRAM is reliable, the system configuration is checked, step 276. A change in system configuration is indicated if the model and submodel values stored in NVRAM do not match the model and submodel values stored in ROM. Note that this last comparison will only indicate a configuration error. If a configuration error is indicated, an error i~ generated for the user. This error notifies the user that the configuration of the sy~tem has changed ~ince the la~t time SET Configuration waa run. The u~er is notified of the changed coniguration and control pas~ed back to the IBL routine ~teps 278, 264, and 266. Thi~ error i~ not fatal itself, but notifie~ the u~er that SET Configuration (conflguration program) must be executed. Referring back to ~tep 276, if the system model/submodel values match, an indication of compatibility is #et and the routine return~, ~teps 276, 274, and 266. Thus, the compatibility between the master boot record and the BC9-89-025 21 2 ~ 2 ~
system are tested along with determining if the system configuration has been modified.
After the IBL routine loads the master boot record into RAM, it transfers control to the MBR code starting address. Referring to Fig. 7, the executable code æegment of the master boot record first verifies the boot record pattern to the ROM pattern, step 300. If the pattern in the master boot record does not match the pattern in ROM, an error is generated and the system halts, steps 302 and 305. The check for equality between ROM and boot record patterns ensures that the master boot record loaded from either the disk or diskette is compatible with the RQM on the planar board. Referring back to step 300, if the pattern in ROM matches the pattern in the boot record, the MBR code compares the system planar ID value, model and submodel value against the corresponding master boot record values, step 304.
This process was discussed in greater detail with respect to Fig. 6D. If the values don't match, the master boot record is not compatible with the system planar and processor, or the system configuration has changed, and an error is generated, step 306. The system will halt when the IBL record is incompatible with planar, model, or submodel value, step 305.
Referring back to step 304, if the system planar ID
value, model and submodel values match the corresponding mAster boot record values, the MBR code loads the BIOS
ima~e from the ~elected media into the system RAM, step 308. If a media load error occurs in reading the data, s~ep 310, an error is generated and the system halts, step~ 312 and 305. Referring back to ~tep 310, if no media load error occurs, a checksum is calculated for the BIOS image in memory, step 314. If the checksum is invalid an error is generated and the ~ystem halts, steps 318 and 305. Referring back to step 316, if the checksum i0 valid, the system partition pointers are saved, step 320, and the system processor is vectored to POST Stage II to begin loading the system, step 322.
2~0~2:~
Thus, there has been shown a method and apparatus for decreasing the operating size of BIOS. A first portion of BIOS is stored in ROM and includes system initialization and tests necessary to boot up a remaining portion gf BIOS, stored on a DASD into RAM. The first and remaining portions of BIOS are executed upon powering up, while the remaining portion need only be executed upon resetting the system.
While the invention has been illustrated in connection with a preferred embodiment, it should be understood that many variations will occur to those of ordinary skill in the art, and that the scope of the invention is defined only by the claims appended hereto and equivalent.
AN APPARATUS AND METHOD FOR DECREASING THE MEMORY
REQUIREMENTS FOR BIOS IN A PERSONAL COMPUTER SYSTEM
Field of the Invention This invention relates to personal computer systems and in particular to a method and device for installing BIOS into a personal computer system.
Back~round Discussion -Personal computer systems in general and IBM
personal computers in particular have attained widespread use for providing computer power to many segments of today s modern society. Personal computer systems can usually be defined as a desk top, floor standing, or portable microcomputer that consists of a system unit having a single system processor, a display monitor, a keyboard, one or more diskette drives, a fixed disk storage, and an optional printer. One of the distinguishing characteristics of these systems is the use of a motherboard or system planar to provide electrical communications between components. These ~ystem~ are designed primarily to give independent computing power to a single user and are inexpensively priced for purchase by individual6 or small businesses.
Example~ of such personal computer systems are the IBM~
PERSONAL COMPUTER AT~ and IBM PERSONAL SYSTEM/2~ Models 25, 30, 50, 60, 70 and 80 computers.
These systems can be classified into two general familie~. The first family, u~ually referred to as Family I Model~, use a bus architecture exemplified by the IBM PERSONAL COMPUTER AT and other "IBM compatible"
machines. The ~econd family, referred to as Family II
Model~, use the IBM MICROCHANNEL~ bu~ architecture exemplified by the IBM PERSONAL SYSTEM/2 Models 50 through 80 computer~.
Beglnning with the earliest personal computer system of the family I models, such a~ the IBM Personal Computer, it wa~ recognized that software compatibility would be of utmost importance. In order to achieve this goal, an insulation layer of ~ystem resident code, 202~2i referred to as "microcode", was established between the hardware and software. This code provided an operational interface between a user s application program/operating system and the device to relieve the user of the concern about the characteristics of hardware devices.
Eventually, the code developed into a BASIC input/output system (BIOS), for allowing new devices to be added to the system, while insulating the application program from the peculiarities of the hardware. The importance of BIOS was immediately evident because it freed a device driver from depending on specific device hardware characteristics while providing the device driver with an intermediate interface to the device. Since BIOS was an integral part of the system and controlled the movement of data in and out of the system processor, it was resident on the system planar, and was shipped to the user in a read only memory (ROM). For example, BIOS in the original IBM Personal Computer occupied 8K of ROM
resident on the planar board.
As new models of the personal computer family were introduced, BIOS had to be updated and expanded to include new hardware and I/O devices. As could be expectedj BIOS started to increase in memory size. For example, with the introduction of the IBM PERSONAL
COMPUTER AT Computer, BIOS grew to require 32K bytes of ROM.
Today, with the development of new technology, personal computer systems of the Family II models are growing even more sophi~ticated and are being made available to consumer~ more frequently. Since the technology is rapidly changing and new I/O devices are being added to the personal computer systems, modification to the BIOS has become a significant problem in the development cycle of the personal computer system.
For in~tance, With the introduction of the IBM
Personal System/2 Computer with MICROCHANNEL
architecture, a significantly new BIOS, known as advanced BIOS, or ABIOS, was developed. However, to maintain software compatibility, BIOS from the Family I models had to be included in the Family II models. The Family I
BIOS became known as Compatibility BIOS or CBIOS.
2~20~2~
BCs-89-025 3 However, as previously noted with respect to the AT
computer, only 32K bytes of ROM were resident on the planar board. Fortunately, the system could be expanded to 96K bytes of ROM. Unfortunately, in an effort to maintain compatibility with older systems, this turned out to be the maximum capacity available for BIOS. Thus BIOS is constrained to be addressable between fixed addresses in memory, where the amount of memory available is 96K bytes. Luckily, even with the addition of A8IOS, ABIOS and CBIOS could still squeeze into 96K of ROM.
However, only a small percentage of the 96K ROM area remained available for expansion. With the addition of future I/O devices, CBIOS and ABIOS will eventually run out of ROM space. Thus, new I/O technology will not be able to be easily integrated within CBIOS and ABIOS.
Due to these problems, it has become necessary to decrease the operating size of BIOS while increasing or at least maintaining the same level of functionality.
Since marketability and consumer acceptance of personal computer systems appear to require the ability to maintain compatibility, it should be appreciated that maintaining the same level of functionality of BIOS is a substantial factor in achieving success in accordance with this invention. Thus, there exists a need for developing a method and apparatus which decreases the code space required for BIOS in Family II machines.
Summary of the Invention The present invention has been developed for the purpo~e of alleviating the above mentioned problems.
Accordingly, the invention has as one of its objects an apparatus and method for decreasing the operating size of BIOS by storing a portion of BIOS on a direct access storage device, while maintaining compatibility with previous BIOS type operating systems.
Another objective of the present invention is to provide an apparatus and method for permitting a portion of BIOS to be executed and then rendered inaccessible to the system.
Another object of thè present invention is to provide a 202~2~
BIOS record format which segments BIOS according to function in order to store those BIOS routines which are executed only once on ROM, while those BIOS routines which are executed more than once are stored on the direct access storage device.
Broadly considered, a personal computer system according to the present invention comprises a system processor, a random access main memory, a read only memory, and at least one direct access storage device.
The read only memory includes a first portion of BIOS
while the remaining portion is stored on the direct access storage device. The first BIOS portion includes routines that are used for initialization and set up, while the remaining portion of BIOS includes routines that are reusable by the operating system. In operation, the first portion of BIOS initializes the system processor and the direct access storage device to read in a master boot record into the random access memory from the direct access storage device.
The ma~ter boot record includes a data segment and an executable code segment. The data segment includes data representing system hardware and a system configuration which is supported by the master boot record. The first BIOS portion confirms the master boot record is compatible with the sy~tem hardware by verifying that the data from the data segment of the ma#ter boot record agrees with the system processor, ~ystem planar, and planar I/O configuration.
If the master boot record is compatible with the system hardware, the first BIOS portion vectors the system processor to execute the executable code segment of the ma~ter boot recoxd. The first BIOS portion is then discarded by the system. The executable code ~egment confirms that the system configuration has not chan~ed and loads in the remaining BIOS portion from the dlrect access storage device into random acce~s memory.
The executable code segment then verifies the authenticity of the remaining BIOS portion and vectors the system processor to begin executing the remaining BIOS now in random access memory. The remaining portion of BIOS includes only those routines needed for normally 2~2~
~C9-89-025 5 operating the system. The first BIOS portion, ~eing no longer addressable and superseded by the remaining BIOS
portion, is abandoned.
Brief Description of the Drawinqs The foreground aspects and other features of the present invention are explained in the following written description, taken in connection with the accompanying drawings, wherein:
Fig. 1 illustrates a cut away view of a personal computer system showing a system planar board connected to a plurality of direct access storage devices;
Fig. 2 shows a system block diagram for the personal computer system of Fig. 1;
Fig. 3 is a memory map for the ROM BIOS included on the planar board;
Fig. 4 is a flowchart describing the overall process for loading a BIOS image from a direct access storage device;
Fig. 5 illustrates the record format for the master boot record;
Fig. 6A is a flowchart describing the operation of the IBL routine;
Fig. 6B is a flowchart showing the steps for loading a BIOS image from a fixed disk;
Fig. 6C is a flowchart showing the steps for loading the BIOS image from a diskette;
Fig. 6D i~ a flowchart showing greater detail in checlcing the compatibility between the master boot record and the planar/proce~sor; and Fig. 7 is a detailed flowchart showing the execution of the executable code segment of the master boot record to load a BIOS image.
D~ iption of a Preferred Embodiment The following detailed description is of the best presently contemplated mode for carrying out the invention. This description i~ not to be taken in a limiting sense but is made merely for the purpose of 2~2~2 ~
illustrating the general principles of the ihvention since the scope of the invention is best defined by the appended claims.
Referring now to the drawings, and in particular to Fig. 1, there is shown a cutaway version of a personal computer system lO, having a plurality of DASD (Direct Access Storage Devices) 12 - 16 connected to a system or planar board 24 through a plurality of I/O slots 18. A
power supply 22 provides electrical power to the system lO in a manner well known. The planar board 24 includes a system processor which operates under the control of instructions to input, process, and output information.
In use, the personal computer system lO is designed primarily to give independent computing power to a small group of users or a single user and is inexpensively priced for purchase by individuals or small businesses.
In operation, the system processor operates under an operating system, such as the IBM OS/2~ Operating System or PC-DOS. This type of system includes a BIOS interface between the DASD 12 - 16 and the Operating System. A
portion of BIOS divided into modules by function is stored in ROM on the planar 24 and hereinafter will be referred to as ROM-BIOS. BIOS provides an interface between the hardware and the operating system software to enable a programmer or user to program their machines without an indepth operating knowledge of a particular device. For example, a BIOS diskette module permits a programmer to program the diskette drive without an lndepth knowledge of the diskette drive hardware. Thus, a number of di~kette drivee designed and manufactured by different companiee can be used in the system. This not only lowere the coet of the eyetem lO, but permits a user to chooee from a number of diekette drives.
Prior to relating the above structure to the present invention, a 0ummary of the operation in general of the pereonal computer system 10 may merit review. Referring to Fig. 2, there is ~hown a block diagram of the personal computer ~yetem 10. Fig. 2 illu~trate~ components of the planar 24 and the connection of the planar 24 to the I/O
elots 18 and other hardware of the personal computer system. Located on the planar 24 is the system processor - 2~2~21 BCs-89-025 7 26 comprised of a microprocessor which is connected by a local bus-28 to a memory controller 30 which is further connected to a random access memory (RAM) 32. While any appropriate microprocessor can be used, one suitable microprocessor is the 80386 which is sold by Intel.
While the present invention is described hereinafter with particular reference to the system block diagram of Fig. 2, it is to be understood at the outset of the description which follows, it is contemplated that the apparatus and methods in accordance with the present invention may be used with other hardware configurations of the planar board. For example, the system processor could be an Intel 80286 or 80486 microprocessor.
Accessible by the processor is a planar identification number (planar ID). The planar ID is unique to the planar and identifies the type of planar being used. For example, the planar ID can be hardwired to be read through an I/O port of the system/processor 26 by using switches.
The local bus 28 is further connected through a bus controller 34 to a read only memory (ROM) 36 on the planar 24.
An additional nonvolatile memory (NVRAM) 58 is connected to the microprocessor 26 through a serial/parallel port interface 40 which is further connected to bu~ controller 34. The nonvolatile memory can be CMOS with battery backup to retain information whenever power is removed from the sy~tem. Since the ROM
is normally resident on the planar, model and submodel values stored in ROM are used to identify the system processor and the system planar I/O configuration re~pectively. Thu~ the~e values will physically identify the proce~sor and planar I/O configuration. The NVRAM 58 is used to store system configuration data.
That is, the NVRAM will contain value~ which describe the pre~ent configuration of the system. For example, NVRAM
contaln~ lnformfltion describing the capacity of a fixed di~k or diskette, the type of display, the amount of memory, time, date, etc. Additionally, the model and ~ubmodel values stored in ROM are copied to NVRAM
whenever a special configuration program, such as SET
2a2~
Configuration, is executed. The purpose of the SET
Configuration program is to store values characterizing the configuration of the system in NVRAM. Thus for a system that is configured properly, the model and submodel values in NVRAM will be e~ual respectively to the model and submodel values stored in ROM. If these values are not equal, this indicates that the configuration of the system has been modiied. Reference is made to Fig. 6D, where this feature in combination with loading BIOS is explained in greater detail.
Continuing, our discussion with reference to Fig. 2, the bus controller 34 is further coupled to I/O slots 18, the serial/parallel interface 40 and peripheral controller 42 by an I/O planar bus 43. The peripheral controller 42 is further connected to a keyboard 44, mouse 46, diagnostic panel 47~ and diskette controller 64. Beside the NVRAM 58, the serial/parallel interface 40 is further connected to a serial port 4~ and parallel port 50 to input/output information to a printer, hard copy device, etc. As is well known in the art, the local bus 28 can also be connected to a cache controller 52, a cache memory 68, a co-processor 54, and a DMA controller 56.
The system processor 26 controls its internal operation as well as interfacing with other elements of the personal computer system 10. For example, system proces~or 26 is shown connected to a small computer sy~tem interface (SCSI) I/O card 60 which is further connected to a DASD, such as a fixed disk drive 62. It is to be understood that other than a SCSI disk drive/adapter can be used as a fixed disk in accordance with the present invention. In addition to the fixed disk 62, the ~ystem proces~or 26 can be interfaced to the diakette controller 64 which controls a diskette drive 66. With respect to terminology, it is al~o to be understood that the term "hardfile" de~cribes fixed disk drive 62 while the term "floppy" alco describe~ diskette drive 66.
Previous to the pre~ent invention, ROM 36 could include all of the BIOS code which interfaced the 21~2a~2~
operating system to the hardware peripherals. According to one aspect of the present invention, however, ROM 36 is adapted to store only a portion of BIOS. This portion includes routines used only for initializing the system and for loading a second or remaining BIOS portion. When the first BIOS portion is executed by the system processor 26, it inputs from either the fixed disk 62 or diskette 66 the second or remaining portion of BIOS, hereinafter referred to as a BIOS image. This BIOS image supersedes the first BIOS portion and includes operating routines which are reusable and therefore are an integral part of the system. In practice, these routines remain resident in main memory such as RAM 32. The first portion of BIOS (ROM-BIOS) as stored in ROM 36 will be explained generally with respect to Figs. 3-4 and in detail with respect to Figs. 6A-D. The second portion of BIOS (BIOS image) will be explained with respect to Fig.
5, and the loading of the BIOS image with respect to Fig.
7. Another benefit from loading a BIOS image from a DASD
is the ability to load BIOS directly into the system processor's RAM 32. Since accessing RAM is much faster than accessing ROM, a significant improvement in the processing speed of the computer system is achieved.
The explanation will now proceed to the operation of the BIOS in ROM 36 and to the operation of loading the BIOS image from either the fixed disk or diskette. In general upon power up, the processor i 8 vectored to ROM-BIOS which initialize~ the sy~tem and DASD and loads A BIOS master boot record into RAM. The master boot record include~ a data segment having validation .tnformation and a code ~egment having executable code.
ROM-BIOS transfers control to the code seyment which code u~es the data information to validate hardware compatibility and system configuration. After testing for hardware compatibility and proper ~ystem configuration, the executable code loads the BIOS image into RAM. The BIOS image supersedes ROM-BIOS and includes operating system routine~ which are useable to provide for the operation of the machine.
2~2~2~
For purposes of clarity, the executable code segment of the master boot record will be referred to as MBR code while the data segment will be referred to as MBR data.
Referring to Fig. 3 there is a memory map showing the different code modules which comprise ROM-BIOS.
These code modules are judicially chosen to include only routines that are necessary to initialize the system, test the hardware necessary to load the BIOS image, and provide communications with the user. ROM-BIOS includes a power on self test (POST) stage I module 70, an Initial BIOS Load (IBL) Routine module 72, a Diskette module 74, a hardfile module 76, a video module 78, a diagnostic-panel module 80, and hardware compatibility data 82. Briefly, POST Stage I 70 performs system pre-initialization and tests. The IBL routine 72 determines whether the BIOS image is to be loaded from disk or diskette, checks compatibility and loads the master boot record. Diskette module 74 provides input/output functions for a diskette drive. Hardfile module 76 controls I/O functions to a fixed disk or the like.
Video module 78 controls output functions to a video I/O
controller which is further connected to a video display.
Diagno~tic panel module 80 provides control to a diagnostic display device for the system. The hardware compatibility data 82 includes data values to confirm hardware compatibility and system configuration which are described later with respect to Fig. 5. It is important to note that the ROM-BIOS routines are not necessary to normally operate the system. The ROM-BIOS routines are used only once to initialize, test, and load. ROM-BIOS
is then discarded and superseded by the BIOS image. This ~egregation of BIOS functions eff0ctively reduces the memory requirement~ for BIOS under normal operating condltions.
Referring now to Fig. 4, there is shown a process overvlew for loading a BIOS image into the sy~tem from either the fixed disk or the diskette. When the system is powered up, the system processor is vectored to the entry point of POST Stage I, step~ 101 and 100. POST
Stage I initializes and te6ts only those system functions 2020~2~
needed to load BIOS image from the selected DASD, step 102. In particular, POST Stage I initializes the processor/planar functions, diagnostic panel, memory subsystem, interrupt controllers, timers, DMA subsyst~m, fixed disk BIOS routine (Hardfile module 76), and diskette BIOS routine (Diskette module 74), if necessary.
After POST Stage I pre-initializes the system, POST
Stage I vectors the system processor to the Initial BIOS
Load (IBL) routine included in the Initial BIOS Load module 72. The IBL routine first, determines whether the BIOS image is stored on fixed disk or can be loaded from diskette; and second, loads the master boot record from the ~elected media (either disk or diskette) into RAM, step 104. The master boot record includes the MBR data and the MBR code. The MBR data is used for verification purposes and the MBR code is executed to load in the BIOS
image. A detailed description of the operation of the IBL routine is presented with respect to Figs. 6A-D.
With continuing reference to Fig. 4, after the IBL
routine loads the master boot record into RAM, the system processor is vectored to the starting address of the MBR
code to begin execution, step 106. The MBR code performs a series of validity tests to determine the authenticity of the BIOS image and to verify the configuration of the system. For a better understanding of the operation of the MBR code, attention is directed to Fig. 7 of the drawings wherein the MBR code is described in greater detail.
On the basis of these validity tests, the MBR code loads the BIOS image into RAM and transfers control to the newly loaded BIOS image in main memory, step 110. In particular, the BIOS image i8 loaded into the address space previously occupied by ROM-BIOS. That is if ROM-BIOS i8 addressed from EOOOOH through FFFFFH, then the BIOS image i~ loaded into this RAM address space of RAM thus superseding ROM-BIOS. Control is then tran~ferred to POST Stage II which was included in the newly loaded BIOS image thus effectively abandoning ROM-BIOS. POST Stage II, now in RAM, initializes and test~ the remaining system in order to load the operating ~ystem boot, step 110. After the system is 2~20 ~2~
initialized and tested, Stage II POST transfers control to the operating system boot to load the operating system, steps 112-114.
Referring back to step 110, it is noted that entry to POST Stage II can be put in effect through a reset function, step 107. ~he reset function is normally actuated by the user whenever a "warm start" is desired, step 108. For example, the reset function can be activated by simultaneously pressing the ctrl-alt-del keys on the keyboard. The effect of a warm start is to bypass the pre-initialization, testing, and initial BIOS
load. It is important to note that a warm start does not reboot BIOS, however, the operating system will be rebooted by POST Stage II. Thus if the BIOS in RAM has not been affected, the system should operate in a normally manner after rebooting.
For clarity, it is appropriate at this point to illustrate a representation for the format of the master boot record. Referring to Fig. 5, there is shown the master boot record. The boot record includes the executable code segment 120 and data segments 122-138.
The MBR code 120 includes DASD dependent code responsible for verifying the identity of the ROM-BIOS, checking that the IBL boot record is compatible with the system, verifying the system configuration, and loading the BIOS image from the selected DASD (disk or~diskette).
The data segment~ 122-138 include information used to define the media, identify and verify the master boot record, locate the BIOS image, and load the BIOS image.
The master boot record is identlfied by a boot record ~ignature 122. The boot record ~ignature 122 can be a unique bit pattern, such a~ a character string "ABC", in the flrst three bytes of the record. The lntegrlty of the master boot record is tested by a checksum value 132 which is compared to a computed check~um value when the boot record i~ loaded. The data segmsnts further include at least one compatible planar ID value 134, compatible model and ~ubmodel values 136.
Th~ master boot record s planar ID value defines which planar that the master boot record is valid for.
-- 2~2~2~L
~C9-89-025 13 Similarly, the master boot record's model and submodel values define the processor and planar I/O configuration respectively that the master boot record is valid for.
It is noted that the boot record's signature and checksum identify a valid master boot record, while the boot record's planar ID, boot record's model and boot record's submodel comparisons are used to identify a boot record compatible with the system and to determine if the system configuration is valid Another value, boot record pattern 124 is used to determine the validity of the ROM-BIOS. The boot record pattern 124 is compared to a corresponding pattern value stored in ROM. If the values match this indicates that a valid ROM-BIOS has initiated the load of a BIOS image from the selected media.
The following description further describes in greater detail each of the values in the master boot record and their functions:
MBR Identifier (122): The first three bytes of the IBL
boot record can consist of characters, such as "ABC".
This ~ignature is used to identify a boot record.
MBR Code Seqment (120): This code verifies the compatibility of the boot record with the planar and processor by comparing corresponding planar id and model/submodel values. If these values match, it will load the BIOS image from the chosen media to system RAM.
If the system image (BIOS image loaded into memory) checksum is valid and no media load errors occur, the MBR
code wi].l map the image to RAM and then transfer control to the POST Stage II routine of the system image.
MBR Pattern (124): The first field of the IBL boot record data segment contains a pattern, such as a character string "ROM-BIOS 1989". This string is used to validate the ROM-BIOS by comparing the Boot Pattern value to the corresponding value stored in ROM (ROM-Pattern).
MBR Version Date_L1~6L~ The master boot record includes a ver~ion date for u~e by an update utility.
Sv8tem Partit~on Pointer (128): The data segment contains a media pointer to the beginning of the media system partition area for use by Stage II POST. On an IBL dislcette, the pointer is in track-head-sector format;
2a2~2~.
on disk the pointer is in Relative Block Address (RBA) format.
SYStem Partition Type (130): The system partition type indicates the structure of the media system partition.
There are three types of system partition structures -full, minimal and "not present". The full system partition contains the setup utility and diagnostics in addition to the BIOS image and master boot record. The minimal system partition contains just the BIOS image and master boot record. If a system does not have a hardfile, the system partition type indicates "not present". In this instance, IBL will occur from the diskette. These three system partition types allow flexibility in how much space the system partition takes up on the media.
Checksum value (132): The checksum value of the data segment is initialized to generate a valid checksum for the record length value (1.5k bytes) of the master boot record code.
MBR Planar ID Value (134): The data segment includes a value, such as a string of words defining compatible planar IDs. Each word is made up of a 16 bit planar ID
and the string is terminated by word value of zero. If a system s planar ID matches the planar ID value in the master boot record, such as one of the words in the string, the IBL media image is compatible with the system planar. If the system s planar ID does not match any word in the ~tring, the IBL media image is not compatible with the system planar.
MBR model and submodel values (136): The data segment includes values, such as a ~tring of words defining compat.ible proce~#ors. Each word is made up of a model and submodel value and the #tring is terminated by a word value of zero. If a system's model and submodel value (stored in ROM) match one of the words in the string, the IBL media lmage is compatible with the system processor.
If the ROM model and ROM submodel values do not match any word ln the string, the IBL media image is not compatible with the system processor.
B_ a~ lenath (138): The IBL map length is initialized to the number of media image blocks. In other words, if 2~20~2~
BCs-89-025 15 the BIOS image is broken into four blocks, the map length will be four indicating four block pointer/length fields.
Usually this length is set to one, since the media image is one contiguous 128K block.
MBR Media Sector Size (138): This word value is initialized to the media sector size in bytes per sector.
Media image block pointer (138): The media image block pointer locates a system image block on the media.
Normally, there is only one pointer since the media image is stored as one contiguous block. On an IBL diskette, the pointers are in track-head-sector format; on disk the pointers are relative block address format.
Media imaqe block lenqth (138): The media image block length indicates the size (in sectors) of the block located at the corresponding image block pointer. In the case of a 128K contiguous media image which includes space for BASIC this field is set to 256, indicating that the BIOS image block takes up 256 sectors (512 bytes/~ector) starting at the media image block pointer location.
Referring now to Figs. 6A-D, there is shown a detailed flow chart of the operation of the IBL routine.
Under normal circumstances, the IBL routine loads the master boot record from the system fixed disk into RAM at a specific address and then vectors the system processor to begin executing the code segment of the master boot record. The IBL routine also contains provisions for a diskette default mode in which the master boot record can be loaded from diskette. However, the IBL routine does not allow the diskette default mode to be performed i~ the system contains the IBL media on the system fixed diek and a valid pas~word is present in NVRAM. The user ha~ the option of ~etting the password in NVRAM. The purpose of preventing the diskette default mode from being effected is to prevent loading an authorized BIOS
image from diskette. In other words, the diskette default mode is used only when a system fixed disk i~ not operational and the user has indicated (by not setting the password) the desire to be able to load from the di~kette. If the IBL routine is not able to load the ~l~?~n~
master boot record from either media, an error message is generated and the system is halted.
Referring now to Fig. 6A, under normal circumstances the system will contain a system fixed disk which the IBL
routine initializes, step 150. Assume for purposes of illustration that the fixed disk is configured for Drive C of the personal computer system. Similarly, assume Drive A is designated as the diskette drive. The IBL
routine then examines Drive C to determine whether it contains IBL media, step 152. Attention is directed to Fig. 6B which describes in detail this process. The IBL
routine starts reading from the fixed disk at the last three sectors and continues reading, decrementing the media pointer, for 99 sectors or until a valid master boot record is found. If a master boot record is found, it is checked for system planar and processor compatibility, step 156. If it is not planar or processor compatible, then an error is reported, step 158. Referring back to step 152, if no master boot record is found on the last 99 sectors of the fixed disk (primary hardfile), an error is reported, step 154.
Referring back to step 156, if a master boot record is found, a series of validity checks are performed to determine if the master boot record is compatible with the computer system. Additionally, the configuration of the sy~tem is checked. Attention is directed to Fig. 6D
which discloses this process in greater detail. If the boot record is compatible With the planar ID, model and submodel, and if furthermore the system configuration has not changed the master boot record is loaded and the code ~egment of the master boot record is executed, ~tep 160.
Referring back to steps 154 and 158, if an error occurs in loading the master boot record from the fixed disk or if a fixed di~k is not available, the IBL routine determines if a valid password is included in NVRAM, step 162. This password determines whether the BIOS image can be loaded from diskette. Note that the password will exi~t only upon being in~talled by the user running a 2~20~21 setup utility. If a password is installed in NVRAM, the BIOS image is prevented from being loaded from diskette, step 164. This permits the user to ensure the integrity of the operation of the system by causing the system to be loaded only with the BIOS image on the fixed disk.
The password can take the form of a string of characters stored in NVRAM.
Referring back to step 162, if a valid password in NVRAM is not present, thus allowing BIOS image to be loaded from diskette, the IBL routine initializes the diskette subsystem, step 166. The IBL routine then determines if Drive A includes the IBL media on a diskette, step 168. If Drive A does not include IBL
media, an error is generated to notify the user that an invalid diskette has been inserted in the drive, step 170. The sy~tem then halts, step 172. Attention is directed to Fig. 6C for a more detailed discussion of ~tep 168.
Referring back to step 168, after Drive A is checked for IBL media, the master boot record is loaded into RAM
and the code segment included in the master boot record is executed, step 160. It is important to note that for diskette the IBL routine does not include the validity checks that are used with the fixed disk system. The reason for the absence of the validity checks is for loading a noncompatihle IBL image from diskette. For example, if a new processor is added to the system, a new BIOS image will be included on a diskette. Since a new proce~or will cau~e validity errors when loading from flxed disk, the IBL routine provide~ the ability to bypaas these tests by loading the BIOS image from diskette.
To recapitulate, the master boot record is checked for compatibility with the system through matching the system planar ID and proce~sor model/submodel values to the boot record values. For disk, this check is done first in the IBL routine and then done again in the IBL
boot record. The first check (in the IBL routine) is ~ 202~
done to make sure the boot record is compatible with the system; the second check (in the boot record) is done to ensure a compatible ROM passed control to the boot record. Notice that the check done in the disk boot record will never fail for a compatible ROM since the IBL
routine will have already checked the compatibility. In contrast, the compatibility check is not done for diskette. The planar/processor compatibility is checked only during diskette boot record execution. This method allows future modifications in loading a new BIOS image from a reference diskette.
In view of the description of the IBL routine of Fig. 6A, the explanation will now proceed to a comprehensive and full understanding of the validity tests discussed above. Referring to Fig. 6B, there is qhown a detailed flowchart of step 152 of Fig. 6A, to determine if a valid master boot record is on drive C.
The process begins by obtaining the drive parameters to enable the IBL routine to access drive C, step 200. An IBL load location i8 set to the last three sectors from the disk (the last three sectors normally contain the master boot record), step 202. A load count indicating the number of attempts to read a master boot record from disk i~ set to 1, step 204. Three æectors are read from disk at the IBL load location, step 206. Any disk drive errors are detected and if a disk drive read error occurs it i0 reported, steps 208-210. The process then returns with an error indication, step~ 212-214.
Referring back to step 208, if no drive error occur0, the di~k record i~ scanned for the master boot record signature, step 216. The boot record signature, such as the character0 "ABC", are compared to the first three bytes of the disk record. If the disk record does have a valid boot record signature (characters "ABC") and the checksum computed from the disk record loaded into memory equals the boot record checksum, the disk record is indicated as being a valid boot record with no errors, step 218. The process then returns, step 214.
2~20~2~
Referring back to step 216, if the boot record signature or checksum is invalid, the load count is incremented by 1, step 220. The load count is then compared to a predetermined constant such as 99, step 222. If 99 attempts to read a boot record have resulted in failure, an error is indicated and the process returns, steps 224, 212 and 214. If less than 99 attempts to read a boot record have occurred, the IBL
load location is decremented by one and three new sectors are read from the new load location, steps 226 and 206.
Thus if a valid IBL boot record cannot be loaded from the last 99 sectors (equivalent to 33 copies) then an error condition is set and control returns to the IBL routine.
Referring now to Fig. 6C, there is shown a detailed flow diagram for loading the master boot record from diskette on drive A. First, the diskette drive parameters to access drive A are retrieved, step 230.
The IBL load location is set to the last 3 sectors on diskette (cylinder, head and sector format), step 232.
The last 3 sectors are read, step 234. If a diskette drive error is detected an error is indicated, steps 236-238. An error condition is set and control is returned to the IBL routine, steps 240-242.
~ eferring back to step 236, if no drive error is detected, the diskette record is checked for boot record ~ignature and the checksum is calculated, step 244. If the boot record signature is missing or checksum is invalid, an error is indicated and control returned to the IBL routine, steps 244, 246, 240 and 242. If a valid boot record signature and valid checksum are detected an indication i~ set and control is returned to the IBL
routine, steps 248 and 242. It is noted that in a dl~kette load, the IBL routine does not search through the media as in the fixed disk load. Therefore, in a di~kette load, the IBL media must be stored in a specific location of the diskette.
Finally, Fig. 6D shows how the IBL routines tests for system planar and processor compatibility and for a 2~2~2 ~
BCs-89-025 20 proper system configuration. The master boot record is checked for compatibility with the system planar by comparing the boot record planar ID value to the system planar ID read by the system processor, step 260. If the system planar ID does not match the boot record planar ID
value, this indicates this master boot record is not compatible with this planar. An error is indicated and control return to the IBL routine, steps 262, 264, and 266.
If the master boot record is compatible with the planar, the master boot record is checked for compatibility with the processor, step 268. The boot record model value and submodel value are compared to the model value and submodel value stored in ROM
respectively. A mismatch indicates a new processor has probably been inserted and this boot record is not compatible with the new processor. An error is indicated and control returned to the IBL routine, steps 270, 264 and 266. If the master boot record is compatible with the planar and processor, the process or checks to determine if NVRAM contains reliable information, step 272. If NVRAM is unreliable, an error is indicated and control returned to the IBL routine, steps 274 and 266.
If NVRAM is reliable, the system configuration is checked, step 276. A change in system configuration is indicated if the model and submodel values stored in NVRAM do not match the model and submodel values stored in ROM. Note that this last comparison will only indicate a configuration error. If a configuration error is indicated, an error i~ generated for the user. This error notifies the user that the configuration of the sy~tem has changed ~ince the la~t time SET Configuration waa run. The u~er is notified of the changed coniguration and control pas~ed back to the IBL routine ~teps 278, 264, and 266. Thi~ error i~ not fatal itself, but notifie~ the u~er that SET Configuration (conflguration program) must be executed. Referring back to ~tep 276, if the system model/submodel values match, an indication of compatibility is #et and the routine return~, ~teps 276, 274, and 266. Thus, the compatibility between the master boot record and the BC9-89-025 21 2 ~ 2 ~
system are tested along with determining if the system configuration has been modified.
After the IBL routine loads the master boot record into RAM, it transfers control to the MBR code starting address. Referring to Fig. 7, the executable code æegment of the master boot record first verifies the boot record pattern to the ROM pattern, step 300. If the pattern in the master boot record does not match the pattern in ROM, an error is generated and the system halts, steps 302 and 305. The check for equality between ROM and boot record patterns ensures that the master boot record loaded from either the disk or diskette is compatible with the RQM on the planar board. Referring back to step 300, if the pattern in ROM matches the pattern in the boot record, the MBR code compares the system planar ID value, model and submodel value against the corresponding master boot record values, step 304.
This process was discussed in greater detail with respect to Fig. 6D. If the values don't match, the master boot record is not compatible with the system planar and processor, or the system configuration has changed, and an error is generated, step 306. The system will halt when the IBL record is incompatible with planar, model, or submodel value, step 305.
Referring back to step 304, if the system planar ID
value, model and submodel values match the corresponding mAster boot record values, the MBR code loads the BIOS
ima~e from the ~elected media into the system RAM, step 308. If a media load error occurs in reading the data, s~ep 310, an error is generated and the system halts, step~ 312 and 305. Referring back to ~tep 310, if no media load error occurs, a checksum is calculated for the BIOS image in memory, step 314. If the checksum is invalid an error is generated and the ~ystem halts, steps 318 and 305. Referring back to step 316, if the checksum i0 valid, the system partition pointers are saved, step 320, and the system processor is vectored to POST Stage II to begin loading the system, step 322.
2~0~2:~
Thus, there has been shown a method and apparatus for decreasing the operating size of BIOS. A first portion of BIOS is stored in ROM and includes system initialization and tests necessary to boot up a remaining portion gf BIOS, stored on a DASD into RAM. The first and remaining portions of BIOS are executed upon powering up, while the remaining portion need only be executed upon resetting the system.
While the invention has been illustrated in connection with a preferred embodiment, it should be understood that many variations will occur to those of ordinary skill in the art, and that the scope of the invention is defined only by the claims appended hereto and equivalent.
Claims (20)
1. An apparatus for decreasing the operating size of BIOS for a personal computer system , the personal computer system having a system processor electrically coupled to a read only memory , random access memory and direct access storage device, said apparatus comprising:
a first portion of BIOS resident in the read only memory, said first portion of BIOS having means for initializing the system and the direct access storage device;
a master boot record included in the direct access storage device, said master boot record including an executable code segment; and a remaining portion of BIOS being included on the direct access storage device, said remaining portion of BIOS having means for operating the personal computer system, wherein the first portion of BIOS initializes the system and the direct access storage device to load the master boot record, said first portion of BIOS
transferring control to the executable code segment of the master boot record in order to effect the loading of the remaining portion of BIOS into the random access memory to begin operating the system.
a first portion of BIOS resident in the read only memory, said first portion of BIOS having means for initializing the system and the direct access storage device;
a master boot record included in the direct access storage device, said master boot record including an executable code segment; and a remaining portion of BIOS being included on the direct access storage device, said remaining portion of BIOS having means for operating the personal computer system, wherein the first portion of BIOS initializes the system and the direct access storage device to load the master boot record, said first portion of BIOS
transferring control to the executable code segment of the master boot record in order to effect the loading of the remaining portion of BIOS into the random access memory to begin operating the system.
2. The apparatus of claim 1, wherein said initializing means of said first portion of BIOS includes a power on self test routine, said power on self test routine initializing and testing only those system functions necessary to load the remaining portion of BIOS.
3. The apparatus of claim 2, wherein said power on self test initializes the system processor functions, memory subsystems, and direct access storage device subsystem.
4. The apparatus of claim 1, wherein said initializing means of said first portion of BIOS includes a load routine for loading said master boot record into random access memory and transferring control to said master boot record.
5. The apparatus of claim 1, wherein the master boot record further includes a data segment, the data segment representing a hardware configuration of the personal computer system which is compatible with said master boot record, and further wherein the read only memory includes data representing a hardware configuration of the system processor, wherein before said remaining portion of BIOS
is loaded into random access memory, said executable code segment compares the hardware configuration data from the master boot record with the hardware configuration data from the read only memory to verify the master boot record is compatible with the system processor.
is loaded into random access memory, said executable code segment compares the hardware configuration data from the master boot record with the hardware configuration data from the read only memory to verify the master boot record is compatible with the system processor.
6. The apparatus of claim 5, wherein the data segment of the master boot record includes a value representing the system planar which is compatible with the master boot record and further wherein the system planar further includes a means for uniquely identifying the system planar in order to verify that the master boot record is compatible to the system planar.
7. The apparatus of claim 5, wherein the hardware configuration data on the master boot record includes a model value and a submodel value, wherein the model value identifies a system processor which is compatible with said master boot record and the submodel value represent an I/O configuration of the system planar which is compatible with the master boot record, and further wherein said read only memory includes a corresponding model value identifying the system processor and submodel value representing the I/O configuration of the system planar, wherein said model value and submodel value of the master boot record are compared to the corresponding model and submodel values of the read only memory respectively, in order to verify that the master boot record is compatible with the system processor and the I/O configuration of the system planar.
8. An apparatus for loading BIOS into a personal computer system, the personal computer system having a system processor, a read only memory, a random access memory, and at least one direct access storage device, said apparatus comprising:
a first portion of BIOS included in the read only memory, said first portion of BIOS including:
means for initializing the system processor and the at least one direct access storage device, a loading means for loading data records from the at least one direct access storage device into random access memory, a validation means for confirming the personal computer system is compatible with BIOS;
a remaining portion of BIOS included in the at least one direct access storage device, said remaining portion of BIOS including reusable means for assisting in the operation of the personal computer system, wherein said first portion of BIOS initializes the system and the at least one direct access storage device for effecting the loading of said remaining BIOS portion into random access memory after confirming that said remaining portion of BIOS is compatible with the system.
a first portion of BIOS included in the read only memory, said first portion of BIOS including:
means for initializing the system processor and the at least one direct access storage device, a loading means for loading data records from the at least one direct access storage device into random access memory, a validation means for confirming the personal computer system is compatible with BIOS;
a remaining portion of BIOS included in the at least one direct access storage device, said remaining portion of BIOS including reusable means for assisting in the operation of the personal computer system, wherein said first portion of BIOS initializes the system and the at least one direct access storage device for effecting the loading of said remaining BIOS portion into random access memory after confirming that said remaining portion of BIOS is compatible with the system.
9. The apparatus of claim 8, wherein said initialization means of said first portion of BIOS includes a power on self test routine, said power on self test routine initializing and testing only those system functions necessary to load the remaining portion of BIOS.
10. The apparatus of claim 9, wherein said power on self test initializes the system processor functions, memory subsystems, and direct access storage device subsystem.
11. The apparatus of claim 8, wherein said validation means includes data representing the type of system processor and configuration of a system planar coupled to the system processor.
12. The apparatus of claim 11, wherein said validation means includes a means for indicating errors in loading said remaining portion of BIOS.
13. The apparatus of claim 12, wherein said means for indicating errors comprises a diagnostic panel.
14. The apparatus of claim 12, wherein said means for indicating errors comprises a video I/O controller.
15. The apparatus of claim 8, wherein the at least one direct access storage device comprises a fixed disk drive wherein said loading means loads data records from said fixed disk drive into random access memory.
16. The apparatus of claim 8, wherein the at least one direct access storage device comprises a diskette drive wherein said loading means loads data records from said diskette drive into random access memory.
17. A method for storing BIOS in a personal computer system, the system including a system processor electrically coupled to a read only memory, a random access memory, and direct storage access device, said method comprising the steps of:
(a) storing a first portion of BIOS in the read only memory, the first portion of BIOS including means for initializing the system and the direct access storage device;
(b) storing a remaining portion of BIOS on the direct access storage device, the remaining portion of BIOS including means for operating the personal computer system in a normal manner;
(c) initializing the system and the direct access storage device with the first portion of BIOS;
(d) loading a master boot record into random access memory, the master boot record including an executable code segment;
(e) transferring control to the executable code segment to load the remaining portion of BIOS into the random access memory.
(a) storing a first portion of BIOS in the read only memory, the first portion of BIOS including means for initializing the system and the direct access storage device;
(b) storing a remaining portion of BIOS on the direct access storage device, the remaining portion of BIOS including means for operating the personal computer system in a normal manner;
(c) initializing the system and the direct access storage device with the first portion of BIOS;
(d) loading a master boot record into random access memory, the master boot record including an executable code segment;
(e) transferring control to the executable code segment to load the remaining portion of BIOS into the random access memory.
18. The method of claim 17, further including the step (f) of verifying the master boot record is compatible with the system by comparing data stored in the first BIOS portion with corresponding data stored in the master boot record.
19. The method of claim 17, further including the step(g) of verifying the master boot record is compatible with the system processor by comparing data in the read only memory to corresponding data included in the master boot record.
20. The method of claim 18, including the step(h) of generating an indication that the master boot record is not compatible.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/398,860 US5136713A (en) | 1989-08-25 | 1989-08-25 | Apparatus and method for decreasing the memory requirements for bios in a personal computer system |
| US398,860 | 1989-08-25 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2020521A1 CA2020521A1 (en) | 1991-02-26 |
| CA2020521C true CA2020521C (en) | 1993-11-09 |
Family
ID=23577082
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002020521A Expired - Fee Related CA2020521C (en) | 1989-08-25 | 1990-07-05 | Apparatus and method for decreasing the memory requirements for bios in a personal computer system |
Country Status (15)
| Country | Link |
|---|---|
| US (1) | US5136713A (en) |
| EP (1) | EP0417888B1 (en) |
| JP (1) | JPH0756631B2 (en) |
| KR (1) | KR920008445B1 (en) |
| CN (1) | CN1017839B (en) |
| AT (1) | ATE138747T1 (en) |
| AU (1) | AU635550B2 (en) |
| CA (1) | CA2020521C (en) |
| DE (1) | DE69027164T2 (en) |
| GB (1) | GB9012946D0 (en) |
| HK (1) | HK203296A (en) |
| IL (1) | IL95228A0 (en) |
| MY (1) | MY106707A (en) |
| NZ (1) | NZ234711A (en) |
| SG (1) | SG44435A1 (en) |
Families Citing this family (58)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5355489A (en) * | 1989-08-25 | 1994-10-11 | International Business Machines Corp. | Bios load for a personal computer system having a removable processor card |
| US5872967A (en) * | 1989-12-29 | 1999-02-16 | Packard Bell Nec | Method for warm boot from reset |
| US5497492A (en) * | 1990-09-04 | 1996-03-05 | Microsoft Corporation | System and method for loading an operating system through use of a fire system |
| IT1254937B (en) * | 1991-05-06 | 1995-10-11 | DYNAMIC UPDATE OF NON-VOLATILE MEMORY IN A COMPUTER SYSTEM | |
| DE4215063C2 (en) * | 1991-05-10 | 1999-11-25 | Intel Corp | Device and method for changing pages in a non-volatile memory |
| US5388267A (en) * | 1991-05-29 | 1995-02-07 | Dell Usa, L.P. | Method and apparatus for updating and restoring system BIOS functions while maintaining BIOS integrity |
| US5276863A (en) * | 1991-06-28 | 1994-01-04 | Digital Equipment Corporation | Computer system console |
| US5471674A (en) * | 1992-02-07 | 1995-11-28 | Dell Usa, L.P. | Computer system with plug-in override of system ROM |
| US5432939A (en) * | 1992-05-27 | 1995-07-11 | International Business Machines Corp. | Trusted personal computer system with management control over initial program loading |
| US5446898A (en) * | 1992-06-22 | 1995-08-29 | International Business Machines Corporation | Method and apparatus for configuring and installing a loadable ABIOS device support layer in a computer system |
| US5495611A (en) * | 1992-06-22 | 1996-02-27 | International Business Machines Corporation | Method and apparatus for dynamic load of an ABIOS device support layer in a computer system |
| US5481709A (en) * | 1992-06-22 | 1996-01-02 | International Business Machines Corporation | Method and apparatus for providing a modular ABIOS device support layer in a computer system |
| US5465357A (en) * | 1992-06-22 | 1995-11-07 | International Business Machines Corporation | Method and apparatus for an automated dynamic load of an ABIOS device support layer in a computer system |
| US6438683B1 (en) * | 1992-07-28 | 2002-08-20 | Eastman Kodak Company | Technique using FIFO memory for booting a programmable microprocessor from a host computer |
| US5870520A (en) * | 1992-12-23 | 1999-02-09 | Packard Bell Nec | Flash disaster recovery ROM and utility to reprogram multiple ROMS |
| US6357000B1 (en) | 1993-01-29 | 2002-03-12 | Microsoft Corporation | Method and system for specified loading of an operating system |
| US5519843A (en) * | 1993-03-15 | 1996-05-21 | M-Systems | Flash memory system providing both BIOS and user storage capability |
| US5581766A (en) * | 1993-05-17 | 1996-12-03 | Compaq Computer Corporation | Selectable video driver system |
| US6453363B1 (en) | 1993-10-21 | 2002-09-17 | Microsoft Corporation | Method and computer system for integrating a compression system with an operating system |
| US5651139A (en) * | 1993-12-23 | 1997-07-22 | International Business Machines Corporation | Protected system partition read/write access on a SCSI controlled DASD |
| US5768568A (en) * | 1994-04-29 | 1998-06-16 | International Business Machines Corp. | System and method for initializing an information processing system |
| US5673385A (en) * | 1994-06-15 | 1997-09-30 | Hewlett-Packard Company | Method for downloading special code from a computer to a hard copy apparatus |
| US5864698A (en) * | 1994-08-24 | 1999-01-26 | Packard Bell Nec | Disk based bios |
| US6421776B1 (en) * | 1994-10-14 | 2002-07-16 | International Business Machines Corporation | Data processor having BIOS packing compression/decompression architecture |
| US5642506A (en) * | 1994-12-14 | 1997-06-24 | International Business Machines Corporation | Method and apparatus for initializing a multiprocessor system |
| US5701477A (en) * | 1995-03-30 | 1997-12-23 | Cirrus Logic, Inc. | Method and apparatus for master boot record shadowing |
| GB2300497B (en) * | 1995-05-03 | 1999-12-15 | Brasil International | Computer control device for use with a TV game machine |
| US5822581A (en) * | 1995-09-29 | 1998-10-13 | Intel Corporation | Method for CMOS configuration information storage and retrieval in flash |
| US5835760A (en) * | 1995-10-13 | 1998-11-10 | Texas Instruments Incorporated | Method and arrangement for providing BIOS to a host computer |
| US5860139A (en) * | 1996-06-11 | 1999-01-12 | Data General Corporation | BIOS memory address decoder for providing an extended BIOS memory address space by reclaiming a portion of non-BIOS address space |
| US5930504A (en) * | 1996-07-22 | 1999-07-27 | Intel Corporation | Dynamic nonvolatile memory update in a computer system |
| KR100191269B1 (en) * | 1996-08-23 | 1999-06-15 | 윤종용 | A computer system testing method using hard disk |
| US5875349A (en) * | 1996-12-04 | 1999-02-23 | Intersect Technologies, Inc. | Method and arrangement for allowing a computer to communicate with a data storage device |
| KR100298420B1 (en) * | 1997-03-10 | 2001-10-24 | 윤종용 | Method for updating rom bios |
| US6938254B1 (en) * | 1997-05-06 | 2005-08-30 | Microsoft Corporation | Controlling memory usage in systems having limited physical memory |
| US6523112B1 (en) * | 1997-06-30 | 2003-02-18 | Emc Corporation | Operating system software boot program execution method |
| KR100299119B1 (en) * | 1997-09-30 | 2001-09-03 | 윤종용 | PC possessing apparatus for controlling flash ROM |
| US6854000B2 (en) * | 1997-12-27 | 2005-02-08 | Canon Kabushiki Kaisha | Image forming apparatus and control method for the same |
| US5968174A (en) * | 1998-03-19 | 1999-10-19 | Bay Networkds, Inc. | Method and apparatus for implementing a 32-bit operating system which supports 16-bit code |
| US6546489B1 (en) | 1999-03-04 | 2003-04-08 | Western Digital Ventures, Inc. | Disk drive which provides a secure boot of a host computer system from a protected area of a disk |
| US6401198B1 (en) * | 1999-03-09 | 2002-06-04 | Texas Instruments Incorporated | Storing system-level mass storage configuration data in non-volatile memory on each mass storage device to allow for reboot/power-on reconfiguration of all installed mass storage devices to the same configuration as last use |
| CN1433542A (en) | 1999-12-08 | 2003-07-30 | 印西德软件公司 | System and method for delivery, retrieval and display of content prior to operating system loading |
| US20050160213A1 (en) * | 2004-01-21 | 2005-07-21 | Chen Ben W. | Method and system for providing a modular server on USB flash storage |
| CN1110748C (en) * | 2000-04-26 | 2003-06-04 | 刘海全 | Method for increasing capacity of Boot ROM as carrier to extend BIOS software of computer and its carrier |
| US6584561B1 (en) * | 2000-09-19 | 2003-06-24 | Dell Products L.P. | System and method to modify CD boot |
| US6725178B2 (en) | 2002-01-15 | 2004-04-20 | International Business Machines Corporation | Use of hidden partitions in a storage device for storing BIOS extension files |
| US6971003B1 (en) * | 2002-04-02 | 2005-11-29 | Adaptec, Inc. | Method and apparatus for minimizing option ROM BIOS code |
| US20040123093A1 (en) * | 2002-12-20 | 2004-06-24 | Rothman Michael A. | Method and apparatus for loading BIOS and option ROM's from alternate locations |
| US7134006B2 (en) * | 2003-06-03 | 2006-11-07 | Gateway Inc. | Method and system for changing software access level within or outside a host protected area |
| US7487345B2 (en) * | 2003-10-10 | 2009-02-03 | Dell Products L.P. | Method of comparing build capability flags of replacement BIOS with boot capability flags of current BIOS to determine compatibility between BIOS revisions and installed hardware during flash update |
| EP1656866A1 (en) | 2004-11-12 | 2006-05-17 | Nestec S.A. | Device and method for the preparation of froth from a liquid milk-based food product |
| TWI287743B (en) | 2005-10-17 | 2007-10-01 | Asustek Comp Inc | Method for initiating a display chip |
| CN1916853B (en) * | 2006-09-18 | 2010-05-19 | 华为技术有限公司 | Method and device of protecting code segment in use for MIPS system |
| JP4735845B2 (en) * | 2006-09-25 | 2011-07-27 | マツダ株式会社 | Lighting control device for instrument panel for vehicle |
| CN102846222B (en) | 2007-05-23 | 2015-03-04 | 雀巢产品技术援助有限公司 | Appliance for conditioning a milk-based liquid |
| CN101807152B (en) * | 2009-02-13 | 2013-10-23 | 环旭电子股份有限公司 | Basic output and input system for self verification of selection read only memory and verification method thereof |
| US20180032351A1 (en) * | 2016-07-29 | 2018-02-01 | Lenovo (Beijing) Co., Ltd. | Information processing method and storage device |
| CN113608827A (en) * | 2021-06-30 | 2021-11-05 | 济南浪潮数据技术有限公司 | Virtualized cluster node checking method and device, electronic equipment and storage medium |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3931504A (en) * | 1972-02-07 | 1976-01-06 | Basic Computing Arts, Inc. | Electronic data processing security system and method |
| US3996449A (en) * | 1975-08-25 | 1976-12-07 | International Business Machines Corporation | Operating system authenticator |
| US4446519A (en) * | 1981-05-26 | 1984-05-01 | Corban International, Ltd. | Method and apparatus for providing security for computer software |
| US4593353A (en) * | 1981-10-26 | 1986-06-03 | Telecommunications Associates, Inc. | Software protection method and apparatus |
| JPS5897724A (en) * | 1981-12-04 | 1983-06-10 | Mitsubishi Electric Corp | Loading method of initial program |
| US4525599A (en) * | 1982-05-21 | 1985-06-25 | General Computer Corporation | Software protection methods and apparatus |
| US4785361A (en) * | 1982-11-08 | 1988-11-15 | Vault Corporation | Method and apparatus for frustrating the unauthorized copying of recorded data |
| US4562306A (en) * | 1983-09-14 | 1985-12-31 | Chou Wayne W | Method and apparatus for protecting computer software utilizing an active coded hardware device |
| JPS60116054A (en) * | 1983-11-29 | 1985-06-22 | Usac Electronics Ind Co Ltd | Control system of initial program load |
| US4577289A (en) * | 1983-12-30 | 1986-03-18 | International Business Machines Corporation | Hardware key-on-disk system for copy-protecting magnetic storage media |
| US4748561A (en) * | 1984-05-14 | 1988-05-31 | Mark Brown | Method of protecting computer software |
| US4747139A (en) * | 1984-08-27 | 1988-05-24 | Taaffe James L | Software security method and systems |
| CA1238427A (en) * | 1984-12-18 | 1988-06-21 | Jonathan Oseas | Code protection using cryptography |
| JPS61201357A (en) * | 1985-03-02 | 1986-09-06 | Nec Corp | Information processor |
| US4688169A (en) * | 1985-05-30 | 1987-08-18 | Joshi Bhagirath S | Computer software security system |
| US4685056A (en) * | 1985-06-11 | 1987-08-04 | Pueblo Technologies, Inc. | Computer security device |
| US4685055A (en) * | 1985-07-01 | 1987-08-04 | Thomas Richard B | Method and system for controlling use of protected software |
| US4817140A (en) * | 1986-11-05 | 1989-03-28 | International Business Machines Corp. | Software protection system using a single-key cryptosystem, a hardware-based authorization system and a secure coprocessor |
| US4796220A (en) * | 1986-12-15 | 1989-01-03 | Pride Software Development Corp. | Method of controlling the copying of software |
| JPH01140230A (en) * | 1987-11-26 | 1989-06-01 | Nec Corp | Program load control system |
| JPH01154226A (en) * | 1987-12-10 | 1989-06-16 | Nec Corp | Hard disk device system including bios |
| JPH0223427A (en) * | 1988-07-13 | 1990-01-25 | Toshiba Corp | Personal computer |
| US5022077A (en) * | 1989-08-25 | 1991-06-04 | International Business Machines Corp. | Apparatus and method for preventing unauthorized access to BIOS in a personal computer system |
-
1989
- 1989-08-25 US US07/398,860 patent/US5136713A/en not_active Expired - Lifetime
-
1990
- 1990-06-11 GB GB909012946A patent/GB9012946D0/en active Pending
- 1990-07-04 DE DE69027164T patent/DE69027164T2/en not_active Expired - Fee Related
- 1990-07-04 EP EP90307297A patent/EP0417888B1/en not_active Expired - Lifetime
- 1990-07-04 SG SG1996000369A patent/SG44435A1/en unknown
- 1990-07-04 AT AT90307297T patent/ATE138747T1/en not_active IP Right Cessation
- 1990-07-05 CA CA002020521A patent/CA2020521C/en not_active Expired - Fee Related
- 1990-07-25 MY MYPI90001241A patent/MY106707A/en unknown
- 1990-07-30 NZ NZ234711A patent/NZ234711A/en unknown
- 1990-07-30 AU AU59992/90A patent/AU635550B2/en not_active Ceased
- 1990-07-30 IL IL95228A patent/IL95228A0/en not_active IP Right Cessation
- 1990-08-11 KR KR1019900012417A patent/KR920008445B1/en not_active IP Right Cessation
- 1990-08-11 CN CN90106955A patent/CN1017839B/en not_active Expired
- 1990-08-23 JP JP2220133A patent/JPH0756631B2/en not_active Expired - Fee Related
-
1996
- 1996-11-07 HK HK203296A patent/HK203296A/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| DE69027164T2 (en) | 1996-12-12 |
| CN1017839B (en) | 1992-08-12 |
| IL95228A0 (en) | 1991-06-10 |
| JPH0756631B2 (en) | 1995-06-14 |
| MY106707A (en) | 1995-07-31 |
| EP0417888A3 (en) | 1992-01-29 |
| AU635550B2 (en) | 1993-03-25 |
| KR910005169A (en) | 1991-03-30 |
| GB9012946D0 (en) | 1990-08-01 |
| ATE138747T1 (en) | 1996-06-15 |
| NZ234711A (en) | 1993-04-28 |
| KR920008445B1 (en) | 1992-09-29 |
| HK203296A (en) | 1996-11-15 |
| JPH0391839A (en) | 1991-04-17 |
| EP0417888A2 (en) | 1991-03-20 |
| CN1049731A (en) | 1991-03-06 |
| AU5999290A (en) | 1991-02-28 |
| US5136713A (en) | 1992-08-04 |
| SG44435A1 (en) | 1997-12-19 |
| DE69027164D1 (en) | 1996-07-04 |
| EP0417888B1 (en) | 1996-05-29 |
| CA2020521A1 (en) | 1991-02-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2020521C (en) | Apparatus and method for decreasing the memory requirements for bios in a personal computer system | |
| US5210875A (en) | Initial bios load for a personal computer system | |
| US5410699A (en) | Apparatus and method for loading BIOS from a diskette in a personal computer system | |
| EP0417889B1 (en) | Protection method and apparatus for computer system | |
| KR950002945B1 (en) | Apparatus and method for loading a system reference diskette image from a system partition in a personal computer system | |
| US5214695A (en) | Apparatus and method for loading a system reference diskette image from a system partition in a personal computer system | |
| US5509120A (en) | Method and system for detecting computer viruses during power on self test | |
| US6944867B2 (en) | Method for providing a single preloaded software image with an ability to support multiple hardware configurations and multiple types of computer systems | |
| KR100678974B1 (en) | Apparatus and method for security and user comfortability in rebooting computer system | |
| KR19980046409A (en) | Booting method by CD-ROM drive and its device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |