Date: May 2002
From: BobComputer Startup
Startup
Before the first step, the PC sits there, the tabula rasae. Hit the power-on button and
magic happens. DC Power is shunted to the CPU. The CPU clears its internal memory
registers, and the program counter (an internal register in the CPU) is initialized to the
address, F000 (CS:IP set to F000:0000H.) The value stored in the program counter is the
address of the next instruction to be executed. For PC architecture, that address
appears just short of the 1 MB mark. In other words, the initial location of the BIOS is at the top of upper memory.
The starting address of the ROM BIOS (Read-Only Memory ... Basic Input/Output System)
is the address of the first instruction of the boot code and the address of the next
instruction that will be processed. In other words, that instruction is the first
instruction or the boot program and it is permanently stored in the system ROM BIOS
chip(s). All interrupts are disabled at this point. Any hardware that would attempt to
generate an interrupt, at this time, would not be able to get that request to the
CPU.
During POST on most PCs, the name and version of the BIOS appears briefly on the
screen. Although BIOS's from most suppliers perform similar functions, identifying the
supplier of the BIOS used on your system is important to understanding the range of
specific features and capabilities likely to be included with your PC.
The boot program invokes a series of system tests known as the POST (Power-On Self
Test). POST only occurs for "Cold Boots." For a warm boot, the
CPU does not initialize its registers and the POST is bypassed. The IBM-PC (I-8088
circa1981) performed 14 tests as part of the POST suite of tests. As you might expect, the
suite of tests for succeeding Ix86 computers has been expanded since then.
During the POST if any errors are detected, the computer may deliver an error
code. Error codes, both visual and audible differ from manufacturer to
manufacturer. To interpret either the visual (printed) or audible (beeps)
error codes, you will need a table of these codes from the manufacturer of the
computer/motherboard. These error codes typically report problems with hardware like
memory, keyboard, monitor, and disk drives. Because of the inter-related nature of
some of these devices, troublshooting may not be straight forward--a problem might be
masked by an error code that seems to point to a different part of the system.
The POST starts with an internal CPU check, and with a check of the boot code by
comparing code at various locations against a fixed template. On PC-AT and later systems,
the results of the POST are compared to data held in CMOS (Complementary Metal-Oxide
Semiconductor). CMOS is a technology used in many chip devices (including
CPU's). However, in common usage for PC's, CMOS is understood to be the
chip(s) that preserve system setup data (supported via a trickle charge from a system
board battery) when the power is turned off. Parameters (data) in CMOS can be changed with
a setup program. The setup program is, typically, stored in firmware, but in older
machines, this program may be stored on a disk.
The POST checks computer things like the bus, ports, system clock, display adapter
memory, RAM, DMA, keyboard, floppy drives, hard drives, and so forth. The system sends
signals over the system bus to make sure that these devices are functioning. If
there is a parameter for it in CMOS, it is possible that the POST performs a test on
it. In addition to the POST, the BIOS initialization routines initialize memory
refresh, and set up the interrupt vector table at the base of memory (starting at address
0000:0000H), set up the BIOS tables (in memory just above the interrupt vectors) and load
BIOS routines to memory. BIOS initialization routines will add to the system
BIOS routines with routines and data from other BIOS chips on installed controllers
(video, drives, etc.) Following this sequence of events, the system loader runs.
The system loader (bootstrap loader) searches for the presence of
a master boot record on media in a designated drive. On finding the boot record, code is
loaded from the drive and processed. This is the "next to last" job for the BIOS
routines. On finding readable media in a designated boot drive, the first sector image is
copied to a location in RAM (7C00H), and the data is examined to detect either a long jump
or a short jump that is readable as 8086 family code. If this test is passed, ROM code is
invoked to load the system loader and control is passed to the system loader. Otherwise,
the sector is considered to be from a non-bootable disk. The system loader uses ROM BIOS
services made available through the interrupt table to load part of the operating system
into low memory. Before loading the OS into low memory, the system loader must know how to
read the system boot disk. To read the system boot disk, the system loader looks at a data
structure, loaded from disk, called the BPB (BIOS Parameter Block). The location of the
disk root directory is calculated from information retrieved from the BPB. The root
directory will supply the location of two hidden system files, IO.SYS and MSDOS.SYS. The
system loader then loads IO.SYS and MSDOS.SYS (unless IO.SYS loads MSDOS.SYS) and passes
control to IO.SYS along with the identity of the boot device. At this point, the system
loader is finished, and the memory it occupied becomes available for use.
IO.SYS contains resident device drivers, the basic MS-DOS BIOS extensions
initialization module, and the MS-DOS system initialization module, SYSINIT. Both
initialization modules are discarded after use. The device drivers remain resident.
MSDOS init examines the interrupt table to determine what devices were found by ROM
BIOS routines at POST time and adjusts the list of resident device drivers accordingly.
Drivers with no corresponding hardware are removed. Some tables within device drivers may
be modified by MSDOS init.
SYSINIT locates the top of RAM and locates itself there. Control is then transferred to
the copy of SYSINIT at the top of RAM. MSDOS.SYS is then moved to the end of the resident
portion of IO.SYS which contains the resident device drivers. This move effectively
overwrites the original copy of SYSINIT and the MSDOS BIOS initialization routine. SYSINIT
then calls the initialization routine in the newly relocated MSDOS kernel. This routine
performs internal setup in the kernel and initializes interrupt vectors 20H through 3FH
with appropriate values.
The MSDOS kernel initialization routine then calls the initialization function (code)
from each device driver to setup vectors for external hardware interrupts. Each block
device driver returns a pointer to BPB for each drive that it supports. These BPB's are
inspected by SYSINIT to find the largest sector size used by any of the drivers. The
kernel initialization routine then allocates a sector buffer the size of the largest
sector found and places the NUL device driver at the head of the device driver list.
The kernel initialization routine displays the MS-DOS copyright message and returns
control to SYSINIT. The loading of MS-DOS in now complete, and SYSINIT can use DOS
services as well as BIOS services along with resident device drivers to work.
SYSINIT opens CONFIG.SYS if it exists. CONFIG.SYS is read into high memory and converts
all characters to uppercase. The file contents are read to determine the system parameters
that will be used. If a parameter setting is not specified in CONFIG.SYS, the default
value is set. The data structures built to specification are stored in memory after the
MSDOS kernel. SYSINIT processes the CONFIG.SYS parameters sequentially.
"Installable" device drivers are loaded and initialized one at a time. SYSINIT
then closes all open files and opens the character deviced, CON, PRN (LPT1), and AUX
(COM1). SYSINIT loads the command shell using the MSDOS EXEC function.
The typical basic shell
under DOS is COMMAND.COM or CLI (command line interface) and it consists of a resident
portion, an initialization portion and a transient portion. The initialization module is
called once by COMMAND.COM and it moves the transient portion of the command shell to high
memory. Next it processes AUTOEXEC.BAT and returns control to the resident portion of
COMMAND.COM. Under 16 bit Windows 3.XX, COMMAND.COM continues as the basic shell
with Windows running as an operating environment under DOS. Under Windows 9X and
variants, this relationship is the same but the Windows GUI (graphical user interface)
becomes the primary shell for system manipulation with typical CLI shell functions
occuring in secondary command processors. Under Windows NT and variants, the CLI is
a subordinate subsystem to the basic shell which is the Windows GUI.
More or Less... |
Forums 
