os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Whitespace only changes. Wrap stuff as much as possible under

Browse source 
70 columns.
This commit is contained in:
Giorgos Keramidas 2002-08-28 19:19:51 +00:00
parent a828c35ea5
commit 6282b35e9b
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=14065
2 changed files with 194 additions and 124 deletions
en_US.ISO8859-1/books
arch-handbook/boot
chapter.sgml
developers-handbook/boot
chapter.sgml

159
en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml
View file

@ -44,13 +44,13 @@ $FreeBSD$
<listitem><para>kernel initialization</para></listitem>
</itemizedlist>
<para>The <literal>boot0</literal> and <literal>boot2</literal> stages are also referred to as
<emphasis>bootstrap stages 1 and 2</emphasis> in &man.boot.8; as
the first steps in FreeBSD's 3-stage bootstrapping procedure.
Various information is printed on the screen at each stage, so
you may visually recognize them using the table that follows.
Please note that the actual data may differ from machine to
machine:</para>
<para>The <literal>boot0</literal> and <literal>boot2</literal>
stages are also referred to as <emphasis>bootstrap stages 1 and
2</emphasis> in &man.boot.8; as the first steps in FreeBSD's
3-stage bootstrapping procedure. Various information is printed
on the screen at each stage, so you may visually recognize them
using the table that follows. Please note that the actual data
may differ from machine to machine:</para>
<informaltable>
<tgroup cols="2">
@ -74,9 +74,9 @@ Default: 1:ad(1,a)/boot/loader
boot:</screen>
</para></entry>
<entry><para><literal>boot2</literal><footnote><para>This prompt will appear
if the user presses a key just after selecting an OS to
boot at the <literal>boot0</literal>
<entry><para><literal>boot2</literal><footnote><para>This
prompt will appear if the user presses a key just after
selecting an OS to boot at the <literal>boot0</literal>
stage.</para></footnote></para></entry>
</row>
<row>
@ -242,14 +242,14 @@ Timecounter "i8254" frequency 1193182 Hz</screen>
<sect1>
<title><literal>boot2</literal> stage</title>
<para>You might wonder, why <literal>boot2</literal> comes after <literal>boot0</literal>, and not
boot1. Actually, there is a 512-byte file called
<filename>boot1</filename> in the directory
<para>You might wonder, why <literal>boot2</literal> comes after
<literal>boot0</literal>, and not boot1. Actually, there is a
512-byte file called <filename>boot1</filename> in the directory
<filename>/boot</filename> as well. It is used for booting from
a floppy. When booting from a floppy,
<filename>boot1</filename> plays the same role as
<filename>boot0</filename> for a harddisk: it locates <filename>boot2</filename> and
runs it.</para>
<filename>boot0</filename> for a harddisk: it locates
<filename>boot2</filename> and runs it.</para>
<para>You may have realized that a file
<filename>/boot/mbr</filename> exists as well. It is a
@ -259,29 +259,34 @@ Timecounter "i8254" frequency 1193182 Hz</screen>
<para>The code implementing <filename>boot2</filename> resides in
<filename>sys/boot/i386/boot2/</filename>, and the executable
itself is in <filename>/boot</filename>. The files <filename>boot0</filename> and
<filename>boot2</filename> that are in <filename>/boot</filename> are not used by the
bootstrap, but by utilities such as
<application>boot0cfg</application>. The actual position for
<filename>boot0</filename> is in the MBR. For <filename>boot2</filename> it is the beginning of a
itself is in <filename>/boot</filename>. The files
<filename>boot0</filename> and <filename>boot2</filename> that
are in <filename>/boot</filename> are not used by the bootstrap,
but by utilities such as <application>boot0cfg</application>.
The actual position for <filename>boot0</filename> is in the
MBR. For <filename>boot2</filename> it is the beginning of a
bootable FreeBSD slice. These locations are not under the
filesystem's control, so they are invisible to commands like
<application>ls</application>.</para>
<para>The main task for <literal>boot2</literal> is to load the file
<filename>/boot/loader</filename>, which is the third stage in
the bootstrapping procedure. The code in <literal>boot2</literal> cannot use any
services like <function>open()</function> and
<function>read()</function>, since the kernel is not yet loaded.
It must scan the harddisk, knowing about the filesystem
structure, find the file <filename>/boot/loader</filename>, read
it into memory using a BIOS service, and then pass the execution
to the loader's entry point.</para>
<para>The main task for <literal>boot2</literal> is to load the
file <filename>/boot/loader</filename>, which is the third stage
in the bootstrapping procedure. The code in
<literal>boot2</literal> cannot use any services like
<function>open()</function> and <function>read()</function>,
since the kernel is not yet loaded. It must scan the harddisk,
knowing about the filesystem structure, find the file
<filename>/boot/loader</filename>, read it into memory using a
BIOS service, and then pass the execution to the loader's entry
point.</para>
<para>Besides that, <literal>boot2</literal> prompts for user input so the loader can
be booted from different disk, unit, slice and partition.</para>
<para>Besides that, <literal>boot2</literal> prompts for user
input so the loader can be booted from different disk, unit,
slice and partition.</para>
<para>The <literal>boot2</literal> binary is created in special
way:</para>
<para>The <literal>boot2</literal> binary is created in special way:</para>
<programlisting><filename>sys/boot/i386/boot2/Makefile</filename>
boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \
@ -290,8 +295,9 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
<para>This Makefile snippet shows that &man.btxld.8; is used to
link the binary. BTX, which stands for BooT eXtender, is a
piece of code that provides a protected mode environment for the
program, called the client, that it is linked with. So <literal>boot2</literal> is
a BTX client, i.e. it uses the service provided by BTX.</para>
program, called the client, that it is linked with. So
<literal>boot2</literal> is a BTX client, i.e. it uses the
service provided by BTX.</para>
<para>The <application>btxld</application> utility is the linker.
It links two binaries together. The difference between
@ -302,9 +308,10 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
BTX, producing the binary file suitable to be put on the
beginning of the partition for the system boot.</para>
<para><literal>boot0</literal> passes the execution to BTX's entry point. BTX then
switches the processor to protected mode, and prepares a simple
environment before calling the client. This includes:</para>
<para><literal>boot0</literal> passes the execution to BTX's entry
point. BTX then switches the processor to protected mode, and
prepares a simple environment before calling the client. This
includes:</para>
<itemizedlist>
<listitem><para>virtual v86 mode. That means, the BTX is a v86
@ -366,10 +373,11 @@ init.2: shr %bx # Handle this int?
the kernel to change the protected mode data structures, such as
page tables, GDT, IDT, etc later, if needed.</para>
<para><literal>boot2</literal> defines an important structure, <literal>struct
bootinfo</literal>. This structure is initialized by <literal>boot2</literal> and
passed to the loader, and then further to the kernel. Some
nodes of this structures are set by <literal>boot2</literal>, the rest by the
<para><literal>boot2</literal> defines an important structure,
<literal>struct bootinfo</literal>. This structure is
initialized by <literal>boot2</literal> and passed to the
loader, and then further to the kernel. Some nodes of this
structures are set by <literal>boot2</literal>, the rest by the
loader. This structure, among other information, contains the
kernel filename, BIOS harddisk geometry, BIOS drive number for
boot device, physical memory available, <literal>envp</literal>
@ -398,9 +406,9 @@ struct bootinfo {
u_int32_t bi_modulep; /* preloaded modules */
};</programlisting>
<para><literal>boot2</literal> enters into an infinite loop waiting for user input,
then calls <function>load()</function>. If the user does not
press anything, the loop brakes by a timeout, so
<para><literal>boot2</literal> enters into an infinite loop waiting
for user input, then calls <function>load()</function>. If the
user does not press anything, the loop brakes by a timeout, so
<function>load()</function> will load the default file
(<filename>/boot/loader</filename>). Functions <function>ino_t
lookup(char *filename)</function> and <function>int xfsread(ino_t
@ -511,19 +519,23 @@ NON_GPROF_ENTRY(btext)</programlisting>
structure into the kernel memory.</entry>
</row>
<row>
<entry><function>identify_cpu</function></entry> <entry>This
functions tries to find out what CPU it is running on,
storing the value found in a variable
<varname>_cpu</varname>.</entry>
<entry><function>identify_cpu</function></entry>
<entry>This functions tries to find out what CPU it is
running on, storing the value found in a variable
<varname>_cpu</varname>.</entry>
</row>
<row>
<entry><function>create_pagetables</function></entry>
<entry>This function allocates and fills out a Page Table Directory
at the top of the kernel memory area.</entry>
<entry>This function allocates and fills out a Page Table
Directory at the top of the kernel memory area.</entry>
</row>
</tgroup>
</informaltable>
<para>The next steps are enabling VME, if the CPU supports it:</para>
<para>The next steps are enabling VME, if the CPU supports
it:</para>
<programlisting> testl $CPUID_VME, R(_cpu_feature)
jz 1f
@ -578,17 +590,39 @@ begin:</programlisting>
to initialize protected mode execution:</para>
<itemizedlist>
<listitem><para>Initialize the kernel tunable parameters, passed from
the bootstrapping program.</para></listitem>
<listitem><para>Prepare the GDT.</para></listitem>
<listitem><para>Prepare the IDT.</para></listitem>
<listitem><para>Initialize the system console.</para></listitem>
<listitem><para>Initialize the DDB, if it is compiled into kernel.
</para></listitem>
<listitem><para>Initialize the TSS.</para></listitem>
<listitem><para>Prepare the LDT.</para></listitem>
<listitem><para>Setup proc0's pcb.</para></listitem>
<listitem>
<para>Initialize the kernel tunable parameters, passed from
the bootstrapping program.</para>
</listitem>
<listitem>
<para>Prepare the GDT.</para>
</listitem>
<listitem>
<para>Prepare the IDT.</para>
</listitem>
<listitem>
<para>Initialize the system console.</para>
</listitem>
<listitem>
<para>Initialize the DDB, if it is compiled into
kernel.</para>
</listitem>
<listitem>
<para>Initialize the TSS.</para>
</listitem>
<listitem>
<para>Prepare the LDT.</para>
</listitem>
<listitem>
<para>Setup proc0's pcb.</para>
</listitem>
</itemizedlist>
<para>What <function>init386()</function> first does is
@ -848,7 +882,8 @@ __asm(".previous");</programlisting>
section, so forming an array of 32-bit pointers.</para>
<para>Running <application>objdump</application> on a kernel
binary, you may notice the presence of such small sections:</para>
binary, you may notice the presence of such small
sections:</para>
<screen>&prompt.user; <userinput>objdump -h /kernel</userinput>
7 .set.cons_set 00000014 c03164c0 c03164c0 002154c0 2**2

159
en_US.ISO8859-1/books/developers-handbook/boot/chapter.sgml
View file

@ -44,13 +44,13 @@ $FreeBSD$
<listitem><para>kernel initialization</para></listitem>
</itemizedlist>
<para>The <literal>boot0</literal> and <literal>boot2</literal> stages are also referred to as
<emphasis>bootstrap stages 1 and 2</emphasis> in &man.boot.8; as
the first steps in FreeBSD's 3-stage bootstrapping procedure.
Various information is printed on the screen at each stage, so
you may visually recognize them using the table that follows.
Please note that the actual data may differ from machine to
machine:</para>
<para>The <literal>boot0</literal> and <literal>boot2</literal>
stages are also referred to as <emphasis>bootstrap stages 1 and
2</emphasis> in &man.boot.8; as the first steps in FreeBSD's
3-stage bootstrapping procedure. Various information is printed
on the screen at each stage, so you may visually recognize them
using the table that follows. Please note that the actual data
may differ from machine to machine:</para>
<informaltable>
<tgroup cols="2">
@ -74,9 +74,9 @@ Default: 1:ad(1,a)/boot/loader
boot:</screen>
</para></entry>
<entry><para><literal>boot2</literal><footnote><para>This prompt will appear
if the user presses a key just after selecting an OS to
boot at the <literal>boot0</literal>
<entry><para><literal>boot2</literal><footnote><para>This
prompt will appear if the user presses a key just after
selecting an OS to boot at the <literal>boot0</literal>
stage.</para></footnote></para></entry>
</row>
<row>
@ -242,14 +242,14 @@ Timecounter "i8254" frequency 1193182 Hz</screen>
<sect1>
<title><literal>boot2</literal> stage</title>
<para>You might wonder, why <literal>boot2</literal> comes after <literal>boot0</literal>, and not
boot1. Actually, there is a 512-byte file called
<filename>boot1</filename> in the directory
<para>You might wonder, why <literal>boot2</literal> comes after
<literal>boot0</literal>, and not boot1. Actually, there is a
512-byte file called <filename>boot1</filename> in the directory
<filename>/boot</filename> as well. It is used for booting from
a floppy. When booting from a floppy,
<filename>boot1</filename> plays the same role as
<filename>boot0</filename> for a harddisk: it locates <filename>boot2</filename> and
runs it.</para>
<filename>boot0</filename> for a harddisk: it locates
<filename>boot2</filename> and runs it.</para>
<para>You may have realized that a file
<filename>/boot/mbr</filename> exists as well. It is a
@ -259,29 +259,34 @@ Timecounter "i8254" frequency 1193182 Hz</screen>
<para>The code implementing <filename>boot2</filename> resides in
<filename>sys/boot/i386/boot2/</filename>, and the executable
itself is in <filename>/boot</filename>. The files <filename>boot0</filename> and
<filename>boot2</filename> that are in <filename>/boot</filename> are not used by the
bootstrap, but by utilities such as
<application>boot0cfg</application>. The actual position for
<filename>boot0</filename> is in the MBR. For <filename>boot2</filename> it is the beginning of a
itself is in <filename>/boot</filename>. The files
<filename>boot0</filename> and <filename>boot2</filename> that
are in <filename>/boot</filename> are not used by the bootstrap,
but by utilities such as <application>boot0cfg</application>.
The actual position for <filename>boot0</filename> is in the
MBR. For <filename>boot2</filename> it is the beginning of a
bootable FreeBSD slice. These locations are not under the
filesystem's control, so they are invisible to commands like
<application>ls</application>.</para>
<para>The main task for <literal>boot2</literal> is to load the file
<filename>/boot/loader</filename>, which is the third stage in
the bootstrapping procedure. The code in <literal>boot2</literal> cannot use any
services like <function>open()</function> and
<function>read()</function>, since the kernel is not yet loaded.
It must scan the harddisk, knowing about the filesystem
structure, find the file <filename>/boot/loader</filename>, read
it into memory using a BIOS service, and then pass the execution
to the loader's entry point.</para>
<para>The main task for <literal>boot2</literal> is to load the
file <filename>/boot/loader</filename>, which is the third stage
in the bootstrapping procedure. The code in
<literal>boot2</literal> cannot use any services like
<function>open()</function> and <function>read()</function>,
since the kernel is not yet loaded. It must scan the harddisk,
knowing about the filesystem structure, find the file
<filename>/boot/loader</filename>, read it into memory using a
BIOS service, and then pass the execution to the loader's entry
point.</para>
<para>Besides that, <literal>boot2</literal> prompts for user input so the loader can
be booted from different disk, unit, slice and partition.</para>
<para>Besides that, <literal>boot2</literal> prompts for user
input so the loader can be booted from different disk, unit,
slice and partition.</para>
<para>The <literal>boot2</literal> binary is created in special
way:</para>
<para>The <literal>boot2</literal> binary is created in special way:</para>
<programlisting><filename>sys/boot/i386/boot2/Makefile</filename>
boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \
@ -290,8 +295,9 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
<para>This Makefile snippet shows that &man.btxld.8; is used to
link the binary. BTX, which stands for BooT eXtender, is a
piece of code that provides a protected mode environment for the
program, called the client, that it is linked with. So <literal>boot2</literal> is
a BTX client, i.e. it uses the service provided by BTX.</para>
program, called the client, that it is linked with. So
<literal>boot2</literal> is a BTX client, i.e. it uses the
service provided by BTX.</para>
<para>The <application>btxld</application> utility is the linker.
It links two binaries together. The difference between
@ -302,9 +308,10 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
BTX, producing the binary file suitable to be put on the
beginning of the partition for the system boot.</para>
<para><literal>boot0</literal> passes the execution to BTX's entry point. BTX then
switches the processor to protected mode, and prepares a simple
environment before calling the client. This includes:</para>
<para><literal>boot0</literal> passes the execution to BTX's entry
point. BTX then switches the processor to protected mode, and
prepares a simple environment before calling the client. This
includes:</para>
<itemizedlist>
<listitem><para>virtual v86 mode. That means, the BTX is a v86
@ -366,10 +373,11 @@ init.2: shr %bx # Handle this int?
the kernel to change the protected mode data structures, such as
page tables, GDT, IDT, etc later, if needed.</para>
<para><literal>boot2</literal> defines an important structure, <literal>struct
bootinfo</literal>. This structure is initialized by <literal>boot2</literal> and
passed to the loader, and then further to the kernel. Some
nodes of this structures are set by <literal>boot2</literal>, the rest by the
<para><literal>boot2</literal> defines an important structure,
<literal>struct bootinfo</literal>. This structure is
initialized by <literal>boot2</literal> and passed to the
loader, and then further to the kernel. Some nodes of this
structures are set by <literal>boot2</literal>, the rest by the
loader. This structure, among other information, contains the
kernel filename, BIOS harddisk geometry, BIOS drive number for
boot device, physical memory available, <literal>envp</literal>
@ -398,9 +406,9 @@ struct bootinfo {
u_int32_t bi_modulep; /* preloaded modules */
};</programlisting>
<para><literal>boot2</literal> enters into an infinite loop waiting for user input,
then calls <function>load()</function>. If the user does not
press anything, the loop brakes by a timeout, so
<para><literal>boot2</literal> enters into an infinite loop waiting
for user input, then calls <function>load()</function>. If the
user does not press anything, the loop brakes by a timeout, so
<function>load()</function> will load the default file
(<filename>/boot/loader</filename>). Functions <function>ino_t
lookup(char *filename)</function> and <function>int xfsread(ino_t
@ -511,19 +519,23 @@ NON_GPROF_ENTRY(btext)</programlisting>
structure into the kernel memory.</entry>
</row>
<row>
<entry><function>identify_cpu</function></entry> <entry>This
functions tries to find out what CPU it is running on,
storing the value found in a variable
<varname>_cpu</varname>.</entry>
<entry><function>identify_cpu</function></entry>
<entry>This functions tries to find out what CPU it is
running on, storing the value found in a variable
<varname>_cpu</varname>.</entry>
</row>
<row>
<entry><function>create_pagetables</function></entry>
<entry>This function allocates and fills out a Page Table Directory
at the top of the kernel memory area.</entry>
<entry>This function allocates and fills out a Page Table
Directory at the top of the kernel memory area.</entry>
</row>
</tgroup>
</informaltable>
<para>The next steps are enabling VME, if the CPU supports it:</para>
<para>The next steps are enabling VME, if the CPU supports
it:</para>
<programlisting> testl $CPUID_VME, R(_cpu_feature)
jz 1f
@ -578,17 +590,39 @@ begin:</programlisting>
to initialize protected mode execution:</para>
<itemizedlist>
<listitem><para>Initialize the kernel tunable parameters, passed from
the bootstrapping program.</para></listitem>
<listitem><para>Prepare the GDT.</para></listitem>
<listitem><para>Prepare the IDT.</para></listitem>
<listitem><para>Initialize the system console.</para></listitem>
<listitem><para>Initialize the DDB, if it is compiled into kernel.
</para></listitem>
<listitem><para>Initialize the TSS.</para></listitem>
<listitem><para>Prepare the LDT.</para></listitem>
<listitem><para>Setup proc0's pcb.</para></listitem>
<listitem>
<para>Initialize the kernel tunable parameters, passed from
the bootstrapping program.</para>
</listitem>
<listitem>
<para>Prepare the GDT.</para>
</listitem>
<listitem>
<para>Prepare the IDT.</para>
</listitem>
<listitem>
<para>Initialize the system console.</para>
</listitem>
<listitem>
<para>Initialize the DDB, if it is compiled into
kernel.</para>
</listitem>
<listitem>
<para>Initialize the TSS.</para>
</listitem>
<listitem>
<para>Prepare the LDT.</para>
</listitem>
<listitem>
<para>Setup proc0's pcb.</para>
</listitem>
</itemizedlist>
<para>What <function>init386()</function> first does is
@ -848,7 +882,8 @@ __asm(".previous");</programlisting>
section, so forming an array of 32-bit pointers.</para>
<para>Running <application>objdump</application> on a kernel
binary, you may notice the presence of such small sections:</para>
binary, you may notice the presence of such small
sections:</para>
<screen>&prompt.user; <userinput>objdump -h /kernel</userinput>
7 .set.cons_set 00000014 c03164c0 c03164c0 002154c0 2**2