boot_amd64 - amd64 system bootstrapping procedures
Cold starts
The Athlon64 computers and clones will perform a POST (Power
On Self
Test) upon being booted cold. This test will find and initialize memory,
keyboard, and other devices. It will search for and initialize any extension
ROMs that are present, and then attempt to boot the
operating
system from an available boot drive.
The boot drive is usually specified in the BIOS setup.
Warm starts [Toc] [Back]
The BIOS loads the first block (at physical location: track
0, head 0,
sector 1) off the boot device into memory, and if the last
two bytes in
the block match the signature 0xAA55, the BIOS considers the
block a
valid bootable drive. The BIOS then proceeds to call the
machine code
program in this block. If the BIOS is current, it will also
pass the
boot drive to the boot block in register %dl.
There are two different types of boot blocks on devices.
There is the
MBR (master boot record) and the PBR (partition boot
record). A digression
into a little piece of history will quickly give light
as to why
this is so. In the beginning, the PC ``architecture'' came
with single
or dual floppy drives, and no hard drives. The only type of
bootable
sectors on any device were the PBRs. They were responsible
for loading
the rest of the operating system from the correct device.
When hard
disks came out, it was felt that such a huge space should be
able to be
partitioned into separate drives, and this is when the MBR
was invented.
The MBR relocates itself upon being loaded and invoked by
the BIOS. Embedded
within the MBR is a partition table, with four partition table entries.
The MBR code traverses this table (which was loaded
with the MBR
by the BIOS), looking for an active entry, and then loads
the MBR or PBR
from the disk location specified by the partition table entry. So in reality,
the MBR is nothing more than a fancy chaining PBR.
Note: The MBR could load another MBR, which is the case when
you are
booting off an extended partition. In other words, the
first block of an
extended partition is really an MBR, which will then load
the corresponding
MBR or PBR out of its extended partition's partition
table.
Geometry translation [Toc] [Back]
WARNING: This portion of the ``PC BIOS Architecture'' is a
mess, and a
compatibility nightmare.
The PC BIOS has an API to manipulate any disk that the BIOS
happens to
support. This interface uses 10 bits to address the cylinder, 8 bits to
address the head, and 6 bits to address the sector of a
drive. This restricts
any application using the BIOS to being able to address only 1024
cylinders, 256 heads, and 63 (since the sectors are 1 based)
sectors on a
disk. These limitations proved to be fine for roughly 3
years after the
debut of hard disks on PC computers.
Many (if not all) newer drives have many more cylinders than
the BIOS API
can support, and likely more sectors per track as well. To
allow the
BIOS the ability of accessing these large drives, the BIOS
would ``remap''
the cylinder/head/sector of the real drive geometry
into something
that would allow the applications using the BIOS to access a
larger portion
of the drive, still using the restricted BIOS API.
The reason this has become a problem is that any modern OS
will use its
own drivers to access the disk drive, bypassing the BIOS
completely.
However, the MBR, PBR, and partition tables are all still
written using
the original BIOS access methods. This is for backwards
compatibility to
the original IBM PC!
So the gist of it is, the MBR, PBR, and partition table need
to have BIOS
geometry offsets and cylinder/head/sector values for them to
be able to
load any type of operating system. This geometry can, and
likely will,
change whenever you move a disk from machine to machine, or
from controller
to controller. They are controller and machine
specific.
Boot process options [Toc] [Back]
On most OpenBSD systems, booting OpenBSD from the BIOS will
eventually
load the amd64 bootstrapping code. This versatile program
is described
in a separate document, boot(8). Other bootstrapping software may be
used, and can chain-load the OpenBSD bootstrapping code, or
directly load
the kernel. In the latter case, refer to your bootloader
documentation
to know which options are available.
Abnormal system termination [Toc] [Back]
In case of system crashes, the kernel will usually enter the
kernel debugger,
ddb(4), unless it is not present in the kernel, or
it is disabled
via the ddb.panic sysctl. Upon leaving ddb, or if ddb was
not entered,
the kernel will halt the system if it was still in device
configuration
phase, or attempt a dump to the configured dump device, if
possible. The
crash dump will then be recovered by savecore(8) during the
next multiuser
boot cycle. It is also possible to force other behaviours from ddb.
/bsd default system kernel
/usr/mdec/mbr system MBR image
/usr/mdec/biosboot system primary stage bootstrap (PBR)
/usr/mdec/boot system second stage bootstrap (usually
also installed
as /boot)
/usr/mdec/pxeboot PXE bootstrap
ddb(4), boot(8), halt(8), init(8), installboot(8), pxeboot(8), reboot(8),
savecore(8), shutdown(8)
The ``PC BIOS Architecture'' makes this process very prone
to weird and
wonderful interactions between different operating systems.
There is no published standard to the MBR and PBR, which
makes coding
these a nightmare.
OpenBSD 3.6 March 9, 2004
[ Back ] |
