60 |
|
|
61 |
\section{Booting} |
\section{Booting} |
62 |
|
|
63 |
A multiboot-compliant bootloader, for example GRUB, loads the loader |
A multiboot-compliant bootloader, for example GNU GRUB, loads the |
64 |
program \texttt{laden}, the kernel, $\sigma_0$, the rootserver and |
loader program \texttt{laden}, the kernel, $\sigma_0$, the rootserver |
65 |
further modules. The loader is started, patches the kernel interface |
and further modules. The loader is started, patches the kernel |
66 |
page, and starts the kernel. The kernel starts $\sigma_0$ and the |
interface page, and starts the kernel. The kernel starts $\sigma_0$ |
67 |
rootserver. The rootserver has to deal with the other modules. |
and the rootserver. The rootserver has to deal with the other |
68 |
|
modules. |
69 |
|
|
70 |
|
|
71 |
\subsection{System bootstrap} |
\subsection{System bootstrap} |
77 |
|
|
78 |
On the ia32, the BIOS will be one of the first things to run. |
On the ia32, the BIOS will be one of the first things to run. |
79 |
Eventually, the BIOS will start the bootloader. The Hurd requires a |
Eventually, the BIOS will start the bootloader. The Hurd requires a |
80 |
multiboot-compliant bootloader, such as GRUB. A typical configuration |
multiboot-compliant bootloader, such as GNU GRUB. A typical |
81 |
file entry in the \verb/menu.list/ file of GRUB will look like this: |
configuration file entry in the \verb/menu.list/ file of GNU GRUB will |
82 |
|
look like this: |
83 |
|
|
84 |
\begin{verbatim} |
\begin{verbatim} |
85 |
title = The GNU Hurd on L4 |
title = The GNU Hurd on L4 |
96 |
yet. |
yet. |
97 |
\end{comment} |
\end{comment} |
98 |
|
|
99 |
GRUB loads the binary image files into memory and jumps to the entry |
GNU GRUB loads the binary image files into memory and jumps to the |
100 |
point of \texttt{laden}. |
entry point of \texttt{laden}. |
101 |
|
|
102 |
|
|
103 |
\subsection{The loader \texttt{laden}} |
\subsection{The loader \texttt{laden}} |
104 |
|
|
105 |
\texttt{laden} is a multiboot compliant kernel from the perspective of |
\texttt{laden} is a multiboot compliant kernel from the perspective of |
106 |
GRUB. It expects at least three modules. The first module is the L4 |
GNU GRUB. It expects at least three modules. The first module is the |
107 |
kernel image, the second module is the $\sigma_0$ server image, and |
L4 kernel image, the second module is the $\sigma_0$ server image, and |
108 |
the third module is the rootserver image. |
the third module is the rootserver image. |
109 |
|
|
110 |
\begin{comment} |
\begin{comment} |
133 |
\begin{itemize} |
\begin{itemize} |
134 |
\item The memory descriptors are filled in according to the memory |
\item The memory descriptors are filled in according to the memory |
135 |
layout of the system. On ia32, this information is -- at least |
layout of the system. On ia32, this information is -- at least |
136 |
partially -- provided by GRUB. |
partially -- provided by GNU GRUB. |
137 |
|
|
138 |
\begin{comment} |
\begin{comment} |
139 |
GRUB seems to omit information about the memory that is shared |
GNU GRUB seems to omit information about the memory that is shared |
140 |
with the VGA card. \texttt{laden} creates a special entry for |
with the VGA card. \texttt{laden} creates a special entry for |
141 |
that region, overriding any previous memory descriptor. |
that region, overriding any previous memory descriptor. |
142 |
\end{comment} |
\end{comment} |
155 |
\item The \verb/boot_info/ field is initialized. |
\item The \verb/boot_info/ field is initialized. |
156 |
|
|
157 |
\begin{comment} |
\begin{comment} |
158 |
The \verb/boot_info/ field is currently set to the GRUB |
The \verb/boot_info/ field is currently set to the GNU GRUB |
159 |
\verb/multiboot_info/ structure. This only works for the ia32 |
\verb/multiboot_info/ structure. This only works for the ia32 |
160 |
architecture of course. We might want to have a more architecture |
architecture of course. We might want to have a more architecture |
161 |
independent way to pass the information about further modules to |
independent way to pass the information about further modules to |
162 |
the rootserver. We also might want to gather the information |
the rootserver. We also might want to gather the information |
163 |
provided by GRUB in a single page (if it is not). |
provided by GNU GRUB in a single page (if it is not). |
164 |
\end{comment} |
\end{comment} |
165 |
\end{itemize} |
\end{itemize} |
166 |
|
|