amd64 system bootstrapping procedures
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
The boot drive is usually specified in the BIOS setup.
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
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.
: 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 “re-map”
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
On most OpenBSD
from the BIOS will load the
-specific first-stage bootstrap,
, which in turn
will locate and load the second-stage bootstrap,
. 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.
In case of system crashes, the kernel will usually enter the kernel debugger,
, 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
during the next
multi-user boot cycle. It is also possible to force other behaviours from ddb.
- default system kernel
- single processor capable kernel
- multiprocessor capable kernel
- standalone installation kernel, suitable for disaster
- system MBR image
- system primary stage bootstrap (PBR)
- system second stage bootstrap (usually also installed as
- PXE bootstrap
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