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