No matching activity found.
|The boot process is an extremely machine-dependent activity. Not only must code be written for every computer architecture, but there may also be multiple types of booting on the same architecture. For example, a directory listing of <filename>/usr/src/sys/boot</filename> reveals a great amount of architecture-dependent code. There is a directory for each of the various supported architectures. In the x86-specific <filename>i386</filename> directory, there are subdirectories for different boot standards like <filename>mbr</filename> (Master Boot Record), <filename>gpt</filename> (<acronym>GUID</acronym> Partition Table), and <filename>efi</filename> (Extensible Firmware Interface). Each boot standard has its own conventions and data structures. The example that follows shows booting an x86 computer from an <acronym>MBR</acronym> hard drive with the FreeBSD <filename>boot0</filename> multi-boot loader stored in the very first sector. That boot code starts the FreeBSD three-stage boot process.|
|The key to understanding this process is that it is a series of stages of increasing complexity. These stages are <filename>boot1</filename>, <filename>boot2</filename>, and <filename>loader</filename> (see <citerefentry><refentrytitle>boot</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more detail). The boot system executes each stage in sequence. The last stage, <filename>loader</filename>, is responsible for loading the FreeBSD kernel. Each stage is examined in the following sections.|
|Here is an example of the output generated by the different boot stages. Actual output may differ from machine to machine:|
|Output (may vary)|
F5 Disk 2
|This prompt will appear if the user presses a key just after selecting an OS to boot at the <literal>boot0</literal> stage.|
BTX loader 1.00 BTX version is 1.02
Consoles: internal video/keyboard
BIOS drive C: is disk0
BIOS 639kB/2096064kB available memory
FreeBSD/x86 bootstrap loader, Revision 1.1
Console internal video/keyboard
(email@example.com, Thu Jan 16 22:18:05 UTC 2014)
/boot/kernel/kernel text=0xed9008 data=0x117d28+0x176650 syms=[0x8+0x137988+0x8+0x1515f8]
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
|When the computer powers on, the processor's registers are set to some predefined values. One of the registers is the <emphasis>instruction pointer</emphasis> register, and its value after a power on is well defined: it is a 32-bit value of <literal>0xfffffff0</literal>. The instruction pointer register (also known as the Program Counter) points to code to be executed by the processor. Another important register is the <literal>cr0</literal> 32-bit control register, and its value just after a reboot is <literal>0</literal>. One of <literal>cr0</literal>'s bits, the PE (Protection Enabled) bit, indicates whether the processor is running in 32-bit protected mode or 16-bit real mode. Since this bit is cleared at boot time, the processor boots in 16-bit real mode. Real mode means, among other things, that linear and physical addresses are identical. The reason for the processor not to start immediately in 32-bit protected mode is backwards compatibility. In particular, the boot process relies on the services provided by the <acronym>BIOS</acronym>, and the <acronym>BIOS</acronym> itself works in legacy, 16-bit code.|
|The value of <literal>0xfffffff0</literal> is slightly less than 4 GB, so unless the machine has 4 GB of physical memory, it cannot point to a valid memory address. The computer's hardware translates this address so that it points to a <acronym>BIOS</acronym> memory block.|
|The <acronym>BIOS</acronym> (Basic Input Output System) is a chip on the motherboard that has a relatively small amount of read-only memory (<acronym>ROM</acronym>). This memory contains various low-level routines that are specific to the hardware supplied with the motherboard. The processor will first jump to the address 0xfffffff0, which really resides in the <acronym>BIOS</acronym>'s memory. Usually this address contains a jump instruction to the <acronym>BIOS</acronym>'s POST routines.|
|The <acronym>POST</acronym> (Power On Self Test) is a set of routines including the memory check, system bus check, and other low-level initialization so the <acronym>CPU</acronym> can set up the computer properly. The important step of this stage is determining the boot device. Modern <acronym>BIOS</acronym> implementations permit the selection of a boot device, allowing booting from a floppy, <acronym>CD-ROM</acronym>, hard disk, or other devices.|
|The very last thing in the <acronym>POST</acronym> is the <literal>INT 0x19</literal> instruction. The <literal>INT 0x19</literal> handler reads 512 bytes from the first sector of boot device into the memory at address <literal>0x7c00</literal>. The term <emphasis>first sector</emphasis> originates from hard drive architecture, where the magnetic plate is divided into a number of cylindrical tracks. Tracks are numbered, and every track is divided into a number (usually 64) of sectors. Track numbers start at 0, but sector numbers start from 1. Track 0 is the outermost on the magnetic plate, and sector 1, the first sector, has a special purpose. It is also called the <acronym>MBR</acronym>, or Master Boot Record. The remaining sectors on the first track are never used.|
|This sector is our boot-sequence starting point. As we will see, this sector contains a copy of our <filename>boot0</filename> program. A jump is made by the <acronym>BIOS</acronym> to address <literal>0x7c00</literal> so it starts executing.|
|The Master Boot Record (<literal>boot0</literal>)|
|After control is received from the <acronym>BIOS</acronym> at memory address <literal>0x7c00</literal>, <filename>boot0</filename> starts executing. It is the first piece of code under FreeBSD control. The task of <filename>boot0</filename> is quite simple: scan the partition table and let the user choose which partition to boot from. The Partition Table is a special, standard data structure embedded in the <acronym>MBR</acronym> (hence embedded in <filename>boot0</filename>) describing the four standard PC <quote>partitions</quote> <_:footnote-1/>. <filename>boot0</filename> resides in the filesystem as <filename>/boot/boot0</filename>. It is a small 512-byte file, and it is exactly what FreeBSD's installation procedure wrote to the hard disk's <acronym>MBR</acronym> if you chose the <quote>bootmanager</quote> option at installation time. Indeed, <filename>boot0</filename> <emphasis>is</emphasis> the <acronym>MBR</acronym>.|
|As mentioned previously, the <literal>INT 0x19</literal> instruction causes the <literal>INT 0x19</literal> handler to load an <acronym>MBR</acronym> (<filename>boot0</filename>) into memory at address <literal>0x7c00</literal>. The source file for <filename>boot0</filename> can be found in <filename>sys/boot/i386/boot0/boot0.S</filename> - which is an awesome piece of code written by Robert Nordier.|
|A special structure starting from offset <literal>0x1be</literal> in the <acronym>MBR</acronym> is called the <emphasis>partition table</emphasis>. It has four records of 16 bytes each, called <emphasis>partition records</emphasis>, which represent how the hard disk is partitioned, or, in FreeBSD's terminology, sliced. One byte of those 16 says whether a partition (slice) is bootable or not. Exactly one record must have that flag set, otherwise <filename>boot0</filename>'s code will refuse to proceed.|
|A partition record has the following fields:|
|the 1-byte filesystem type|
|the 1-byte bootable flag|
|the 6 byte descriptor in CHS format|
|the 8 byte descriptor in LBA format|
No matching activity found.