*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> amd64/boot_amd64 (8)              



NAME    [Toc]    [Back]

     boot_amd64 - amd64 system bootstrapping procedures

DESCRIPTION    [Toc]    [Back]

   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
     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
     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

   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
     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
     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

   Boot process options    [Toc]    [Back]
     On most OpenBSD systems, booting OpenBSD from the BIOS  will
     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
     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
     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.

FILES    [Toc]    [Back]

     /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

SEE ALSO    [Toc]    [Back]

     ddb(4),  boot(8),  halt(8),  init(8),  installboot(8),  pxeboot(8), reboot(8),
     savecore(8), shutdown(8)

BUGS    [Toc]    [Back]

     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 ]
 Similar pages
Name OS Title
boot_i386 FreeBSD system bootstrapping procedures
boot FreeBSD system bootstrapping procedures
boot_i386 OpenBSD i386 system bootstrapping procedures
boot_cats OpenBSD CATS system bootstrapping procedures
boot_vax OpenBSD vax-specific system bootstrapping procedures
boot_hppa OpenBSD hppa system bootstrapping procedures
boot_sparc OpenBSD sparc system bootstrapping procedures
boot_alpha OpenBSD Alpha system bootstrapping procedures
boot_sparc64 OpenBSD sparc64 system bootstrapping procedures
boot_macppc OpenBSD macppc system bootstrapping procedures
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service