|
Author: Terry Jefferson - Wichita, Kansas
Source: THE FIRST 30 SECONDS PC Magazine, 13 Feb 1990, Vol 9, no. 3
What is the POST? Exactly what does the PC do from the time you turn on
the power switch until the DOS prompt appears?
Our reader asks a simple question, but the answer is rather lengthy. POST
stands for power-on self-test. It's a set of diagnostic routines encoded in
ROM that serves as your computer's first line of defense against unwanted
gremlins; it also ensures that the hardware you entrust your data to has been
checked and certified ready to go each time you power it up.
When you turn on your PC and see an error message indicating that a RAM chip
has gone bad, that message is an outward sign that one of the POST's
diagnostic routines failed. The POST validates every byte of memory in your
system at startup with a series of read/write tests designed to ferret out bad
RAM locations. When it finds one, it reports the problem—before you have a
chance to lose data.
But testing RAM is only one of the POST's many responsibilities. Besides
running reliability tests on your system board components, it configures the
various support chips that work with the microprocessor, determines what
optional equipment is attached, gives adapters the chance to initialize
themselves, sets up the interrupt vector table in low memory, gets the keyboard
ready to transmit keystrokes to the CPU, and invokes the bootstrap loader,
which in turn loads the operating system. After this final step, you see the
first evidence that the PC is up and running— the command-line prompt under
DOS and the window-based Presentation Manager in OS/2.
To better understand this process, we'll trace the startup sequence followed
by the original IBM PC, then double back to highlight the differences between
its POST and the POSTs for the AT and PS/2. The complexity of the startup ROM
has grown as hardware has evolved, but the same theme and general order of
operations has been carried through from the very first PC to the most recent.
Figure 1 is a general sketch of the various parts of a typical computer; it
generally applies to both AT and Micro Channel computers.
Figure 1: By testing the primary system board components (the
CPU, DMA controllers, and interrupt the POST ensures that the system is working
properly at the lowest levels.
The very first CPU-related event that takes place when power is applied to
the microprocessor is execution of the instruction at address FFFFh:0000h. In
the IBM PC, this instruction is a far jump to the beginning of the POST encoded
in ROM in the upper 8K of segment F000h.
The startup ROM begins by exercising the CPU and trapping any errors or
inconsistent handling of instructions. Six of the nine status flags—CF, ZF,
SF, AF, OF, and PF—are individually set or cleared and tested with relative
jump instructions whose destination (if the test fails) is an HLT instruction
that simply halts the microprocessor. Each of the CPU's registers (with the
exception of CS and IP, which are implicitly tested by the very execution of
the routine) is written and read to verify that it is capable of handling
data.
After verifying that the ROM containing the BIOS and startup code is intact,
which it does by employing a checksum procedure, the POST turns to the 8253
timer chip. The 8253 provides three multipurpose counter/timers for accurate
timing of events under software control. Timer 0 is wired into the CPU through
the 8259A programmable interrupt controller to generate timer interrupts at a
frequency of roughly 18.2 times per second. Timer 1 is used to trigger dummy
DMA (Direct Memory Access) transfer requests for periodic RAM refresh. Timer 2
is available for tone generation in the speaker and other multipurpose timing
applications under user control (see the January 16, 1990, Tutor column for an
in-depth discussion of how timer 2 can be used to measure time intervals in the
sub-55-millisecond range). The POST tests timer 1 and initializes it to the
proper refresh rate. Then it initializes timer 0, submits it to a crude
frequency check, and configures it to produce a pulse (interpreted as an
interrupt by the 8259A) every 65,536th clock cycle.
The 8253 is accompanied on the system board by an 8237 DMA controller. DMA
is a mechanism for transferring data directly between memory locations without
involving the CPU. On the PC, three of the 8237's four 20-bit DMA channels are
used primarily to free the microprocessor from relatively slow disk I/O; the
fourth is dedicated to memory refresh. Immediately after initializing the 8253,
the POST subjects the registers of the 8237 to a write/read test and, if no
problems are detected, begins the periodic memory refresh.
With dynamic RAM now up and available, the POST reads the system board DIP
switches to determine how much memory is installed on the system board and
expansion cards. The first 16K is subjected to a full integrity test while any
remaining RAM is simply initialized to zero. Then the 8259A is set up to
arbitrate interrupts arriving on its eight request lines, and the first 32
interrupt vectors are directed to a temporary interrupt service routine. The
8259A handles interrupts in the PC by prioritizing requests from external
sources and passing them on one at a time to the CPU. After the 8259A is
initialized, the POST tests it by masking off hardware interrupts and entering
a do-nothing delay loop of approximately 1 second in duration. If no interrupts
occur during that time, then the POST continues; otherwise, execution is
abruptly stopped.
Finally, to round out the first phase of operation, the POST copies the
proper values of interrupt vectors 10h through 1Fh to their respective slots in
low memory.
With the most-basic pieces of hardware now working, the POST turns its
attention to the video controller card. Switch block 1 is read, and the result
is stored in the low byte of the BIOS data area's equipment flag word. The
POST determines the default video mode from sense switches 4 and 5 and calls
function 0 of interrupt 10h to initialize the 6845 video controller, set up
video parameters in the BIOS data area, clear the video buffer, position the
cursor in the upper-left corner of the screen, and enable the video signal. The
Motorola 6845 is the programmable CRT controller used in IBM's original CGA
and MDA display adapters. For compatibility, the 6845 is partially emulated in
today's higher-performance EGA and VGA adapters. As a result, you can insert
an EGA into a slot in an old PC and the POST will still work correctly—even
though it predated the EGA by several years.
Next, video RAM is subjected to a thorough write/read/verify test, and a
single row of characters is written to the video buffer. To make sure the
hardware is functioning properly, the POST delays long enough to verify that
the vertical and horizontal retrace bits in the CRT status register
periodically change polarity. Then, after clearing the screen, it makes a sweep
of ROM address space between segments C000h and C800h in 2K increments, looking
for video adapters with their own internal startup codes like the EGA. If any
additional ROM modules are found, the POST transfers control to them long
enough to let them perform their own specialized hardware initialization
procedures.
Next comes the incremental memory check you see displayed on-screen on
machines postdating the original PC. Every byte of RAM is written and read with
all ones, all zeros, and alternating checkerboard patterns to check for
sympathetic, stuck, and unresponsive bits. Up to this point, the POST's
general response to a test failure has been to shut down the system with no
explanatory remarks or messages to the user. With video now functioning,
however, a data compare or parity check error results in a 201 error code that
is displayed on your screen.
With memory now verified, the keyboard is reset, tested, and checked for
stuck keys. An error produces a 301 message. Interrupt vectors 8 through 0Fh
are set up, and a scan for adapter ROMs in the range of segment addresses C800h
through F400h is initiated. A ROM module is identified by the word value 55AAh
in its first storage location at offset 0. When a ROM module is found, the POST
transfers control to it by effecting a jump to offset 3 in the ROM segment. By
convention, the byte at offset 2 holds the length of the module expressed in
the number of 512-byte blocks, while offset 3 holds the first byte of the
adapter's internal startup code.
The final memory test performed is a simple checksum on the
32K BASIC ROM containing the interpreted BASIC
kernel routines. The POST follows up by enabling disk interrupts, resetting the
floppy disk controller, turning on the drive motor, delaying for one second,
performing a seek, and shutting off the motor again. An error in any of these
exercises produces a 601 indicator on your screen but does not halt
execution.
With most of its work done, the POST does some miscellaneous housekeeping
that includes setting up the remainder of the values not already defined inside
the BIOS data area. The data area is a 256-byte RAM workspace at absolute
address 400h used by the ROM BIOS. The POST sets up the keyboard buffer and
enters default time-out values for parallel and serial ports. It also
determines how many parallel and serial ports are attached and fills in their
respective I/O addresses in the data area's communications address
tables.
The final task the POST performs before calling the bootstrap loader is to
enable NMI. NMI, or nonmaskable interrupt, is "nonmaskable" because it isn't
routed through the 8259A and therefore can't be masked in the same sense that
other interrupts can. It can, however, be enabled and disabled by toggling a
latch accessed through an I/O port. NMI is used on the PC to report parity
check errors and math coprocessor exceptions.
The POST ends by emitting one short beep from the PC's speaker and
executing an interrupt 19h to invoke the bootstrap loader. The loader is
charged with the task of loading an operating system from disk to get the
machine running, without benefit of the operating system's high-level disk
I/O services. The process is called bootstrapping because the PC figuratively
pulls itself up by its bootstraps.
The interrupt 19h handler uses BIOS interrupt 13h to read the very first
sector of the disk in drive A: (called the "boot sector" by DOS) and
copy its contents to absolute address 7C00h. If the call succeeds, control is
transferred to 7C00h with a JMP instruction. If no disk is present in the drive
or if a drive malfunction prevents the sector from being read, the loader
executes an interrupt 18h to invoke cassette BASIC.
On more contemporary machines such as the XT, the BIOS is smart enough to go
to the hard disk before defaulting to BASIC if there is no disk in the A:
drive. Getting an original PC to do the same requires a ROM upgrade. With a
hard disk installed in the system, the sector read by the loader (the first
physical sector on the disk) contains the master partition table and a fragment
of code that inspects the table to determine which operating system Is
bootable. The boot sector belonging to the bootable operating system—found in
the first logical sector of the corresponding partition—is loaded and given
control.
If that operating system is PC-DOS, the bootstrapping code checks to see if
the disk contains a copy of the operating system by reading the first sector of
the root directory and looking for the hidden files IBMBIO.COM and IBMDOS.COM.
The files must occupy the first two slots in the root directory. Moreover,
IBMBIO.COM must lie in contiguous sectors beginning in the disk's first data
sector. If these conditions are met, IBMBIO.COM is read into memory and handed
control. IBMBIO.COM, in turn, loads IBMDOS.COM, which contains the DOS
kernel.
IBMBIO.COM sets up interrupt vectors 20h through 3Fh and performs various
other tasks required to get the operating system working. Among other things,
it is responsible for initializing resident device drivers, processing the
CONFIG.SYS file, loading installable device drivers, and structuring DOS's
layout in memory to accommodate disk buffers, internal tables, file control
blocks, and device drivers. It finishes up by calling the EXEC function to load
and execute COMMAND.COM, or an alternative command processor if one was
specified with the SHELL command in CONFIG.SYS.
It's the command processor that finally brings up the DOS prompt.
COMMAND.COM, DOS's default command processor, processes the AUTOEXEC.BAT
file, then splits itself into a resident and a transient portion. The latter
half is copied into high memory, where it can be overwritten if an application
program needs the extra memory (if a program destroys the upper half,
COMMAND.COM uses the COMSPEC variable to locate its image on disk and reload
itself when the program ends). Its final act during startup is to display the
DOS prompt in the format specified by the PROMPT environment variable and call
DOS function 0Ah to read input from the keyboard—the point at which you can
finally type a command.
Fundamental hardware differences between the PC and the AT dictate that the
AT's POST routines be somewhat more sophisticated than the PC's. The AT
POST, for example, checks for and initializes a hard disk immediately after
initializing the first disk drive and attempts to boot from the hard disk if
drive A: is empty. It checks the keyswitch on the front of the box to make sure
the keyboard isn't locked. And it provides more-descriptive error messages
when problems do occur.
Other AT hardware advancements required more subtle refinements to the POST.
The AT, for example, uses a pair of cascaded 8259A interrupt controllers to
double the number of hardware interrupt lines available. It also implements two
82377 DMA controllers in place of the single one found in the PC. In each case,
two chips must be initialized rather than one. Another key difference arises
from the AT's use of CMOS RAM to store configuration data. CMOS RAM is
validated with a checksum process similar to the one used to check BIOS ROM,
and hardware information is pulled from CMOS RAM rather than system board DIP
switches.
But the most significant change made to the POST was driven by the AT's
use of the 80286. The AT switches from real mode to protected mode and back at
least three times during startup. The first time, the POST determines how much
of the 16-megabit address space is filled with RAM. The second time, all RAM
above the first 64K is tested. Each time thereafter, one or more hardware
functions essential to protected-mode operation are tested.
The bootstrapping process is more a function of the operating system than of
the hardware it's running on and, in general, has remained relatively
unchanged over time. But with the AT—and with 286 and 386 machines in
general—comes the possibility that the operating system being loaded is OS/2
rather than DOS.
The OS/2 bootstrapping process is roughly analogous to DOS's. In Version
1.1, the bootstrap code locates and loads the system file OS2LDR, which in turn
loads OS2KRNL. OS2KRNL immediately jumps into protected mode and initializes
the various components of OS/2, then processes CONFIG.SYS and, based on the
hardware configuration, loads OS/2's internal disk, keyboard, screen, clock,
and printer device drivers. Finally, Presentation Manager is loaded.
Presentation Manager completes the list of startup tasks, which includes
processing the command file STARTUP.CMD and initializing the Start Programs
window along with the Task Manager, DOS compatibility box, and print spooler
icons, before giving the machine up to user control.
We know a little less about the PS/2 startup ROM because the PS/2 BIOS
listings were never published—as were the PC and AT listings. From inference,
we do know that the Personal System/2 POST routines form a superset of those
found in the AT. The chief differences stem from the implementation of a
power-on password and the programmable option select (POS) feature of the Micro
Channel bus.
If a power-on password has been defined, the POST displays a keylike symbol
on the screen and pauses until the user replicates the password from the
keyboard. The password bytes are then locked in CMOS RAM so that no subsequent
program can access them and defeat the protection scheme.
Immediately after the CPU and support chips are checked out and initialized
(or, at least, the equivalent of the support chips; much of what was packaged
in discrete chips in the PC is implemented in custom integrated circuitry in
PS/2s) and CMOS RAM is determined to be in working order, the POST sequence is
started. The POST reads an ID code from each adapter plugged into the Micro
Channel and compares it with the ID code recorded for that slot in CMOS RAM. If
the two agree, the POST sends programmable configuration data to the card; if
the [Ds do not match, the machine beeps and displays an error code. The POST
then proceeds as normal, but it will not boot the computer until the reference
disk has been placed in the A: drive. The reference disk contains the
configuration utility needed to resolve the conflict.
The POST varies in non-IBM BIOSs, but only to accommodate slight differences
in hardware and to ensure that copyrights are not infringed upon. Similarly,
there is a high degree of uniformity among PCs in the way the operating system
is loaded because the bootstrap loader exists primarily in software, not in
firmware.
It's difficult to trace through the actions of the power-on diagnostic and
initialization routines without gaining a deeper appreciation for the
complexity of the hardware and the delicacy of the interactions between
components. And with appreciation comes understanding—the kind that may help
you determine what went wrong the next time the POST reports an error.
|