Source string Read only

(itstool) path: sect1/para
504/5040
Context English State
Kernel
Bootstrapping and Kernel Initialization
<personname> <firstname>Sergey</firstname> <surname>Lyubka</surname> </personname> <contrib>Contributed by </contrib>
<personname> <firstname>Sergio Andrés</firstname> <surname> Gómez del Real</surname> </personname> <contrib>Updated and enhanced by </contrib>
Synopsis
<primary>BIOS</primary>
<primary>firmware</primary>
<primary>POST</primary>
<primary>IA-32</primary>
<primary>booting</primary>
<primary>system initialization</primary>
This chapter is an overview of the boot and system initialization processes, starting from the <acronym>BIOS</acronym> (firmware) <acronym>POST</acronym>, to the first user process creation. Since the initial steps of system startup are very architecture dependent, the IA-32 architecture is used as an example.
The FreeBSD boot process can be surprisingly complex. After control is passed from the <acronym>BIOS</acronym>, a considerable amount of low-level configuration must be done before the kernel can be loaded and executed. This setup must be done in a simple and flexible manner, allowing the user a great deal of customization possibilities.
Overview
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:
FreeBSD Component
Output (may vary)
<literal>boot0</literal>
F1 FreeBSD
F2 BSD
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.
<literal>boot2</literal> <_:footnote-1/>
&gt;&gt;FreeBSD/i386 BOOT
Default: 1:ad(1,a)/boot/loader
boot:
<filename>loader</filename>
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
(root@snap.freebsd.org, Thu Jan 16 22:18:05 UTC 2014)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0xed9008 data=0x117d28+0x176650 syms=[0x8+0x137988+0x8+0x1515f8]
kernel
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
root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
The <acronym>BIOS</acronym>
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.

Loading…

No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Flags
read-only
Source string location
book.translate.xml:335
String age
a year ago
Source string age
a year ago
Translation file
books/arch-handbook.pot, string 33