WebSVN – HelenOS-doc – Diff – /usrman/trunk/boot/boot.tex



\chapter{Boot Loading Process}
 
The startup of HelenOS happens in several steps.
Depending on the platform, these steps can be either
described as \textit{piggybacker loading}:
 
\begin{enumerate}
 \item Platform boot loader loads the piggybacker image
       and jumps to its entry point.

       according the boot information structure from the
       piggybacker.
\end{enumerate}
 
If the platform supports a more sophisticated native boot loader,
the \textit{multiboot loading} consists of the following steps:
 
\begin{enumerate}
 \item Platform boot loader loads the kernel image and initial
       user space tasks, creates a boot information structure
       and jumps to the entry point of the kernel.
 \item The kernel initializes and runs the initial tasks
       according the the boot information structure from the
       boot loader.
\end{enumerate}
 
A third kind of boot loading occurs on platforms with no support
from boot loader. It is called \textit{image loading} and is
used mostly on simulated architectures.
 
\begin{enumerate}
 \item The kernel and initial user space images are placed
       on well-known physical memory locations (usually
       by a simulator configuration file). The execution
       starts directly on the kernel entry point.
 \item The kernel initializes and spawns compiled-in
       number of initial user space tasks.
\end{enumerate}
 
The following sections describe the particular features of the
boot loading process on the supported platforms. Sample
configuration files for all simulators are in the directory
{\em kernel/contrib/conf}.
 
\section{IA-32 and AMD64}
 
On both platforms, HelenOS depends on a boot loader which
supports the Multiboot Specification (e.g. GRUB). The kernel
image (usually called \texttt{image.iso}) is loaded by the
boot loader just above the 1st megabyte of the physical
memory (the exact location is 1081344 bytes). Modules loaded by
GRUB are automatically detected by the kernel and after initialization
they are started as userspace tasks. The GRUB loading is the
easiest in terms of using userspace tasks.

module /boot/klog
\end{verbatim}
 
\section{32-bit MIPS}
The MIPS port is fully supported in the {\em msim} and {\em gxemul} simulators.
These simulators allow to specify a memory contents of the simulated
computer. Unfortunately, the autodetection of loaded modules does
not work. In order to change number of loaded modules, the file
kernel/arch/mips32/src/mips32.c must be modified.
 
Sample msim configuration file:

with 32-bit ARC firmware). It uses ARC for output and input. When
the kernel is compiled to be loaded on the SGI Indy, an ECOFF image
is created which can be later loaded directly with ARC boot loader
e.g. using BOOTP protocol.
 
\section{IA-64}
The IA-64 port is supported on the Ski simulator. The situation is very similar
to the MIPS loader - the loaded modules must be loaded on correct addresses in
the Ski configuration file and specified in the file
kernel/arch/ia64/src/ia64.c.
 
Sample IA-64 configuration file:
\begin{verbatim}
load kernel.bin
romload ../uspace/ns/ns 0x400000
romload ../uspace/init/init 0x800000
romload ../uspace/console/console 0xc00000

Rev 150	Rev 153
Line 1...	Line 1...
1	\chapter{Boot Loading Process}	1	\chapter{Boot Loading Process}
2		2
3	The startup of HelenOS happens in several steps.	3	The startup of HelenOS happens in several steps.
4	Depending on the platform these steps can be either	4	Depending on the platform, these steps can be either
5	described as \textit{piggybacker loading}:	5	described as \textit{piggybacker loading}:
6		6
7	\begin{enumerate}	7	\begin{enumerate}
8	\item Platform boot loader loads the piggybacker image	8	\item Platform boot loader loads the piggybacker image
9	and jumps to its entry point.	9	and jumps to its entry point.
Line 15...	Line 15...
15	according the boot information structure from the	15	according the boot information structure from the
16	piggybacker.	16	piggybacker.
17	\end{enumerate}	17	\end{enumerate}
18		18
19	If the platform supports a more sophisticated native boot loader,	19	If the platform supports a more sophisticated native boot loader,
20	a \textit{multiboot loading} contains following steps:	20	the \textit{multiboot loading} consists of the following steps:
21		21
22	\begin{enumerate}	22	\begin{enumerate}
23	\item Platform boot loader loads the kernel image and initial	23	\item Platform boot loader loads the kernel image and initial
24	user space tasks, creates a boot information structure	24	user space tasks, creates a boot information structure
25	and jumps to the entry point of the kernel.	25	and jumps to the entry point of the kernel.
26	\item The kernel initializes and runs the initial tasks	26	\item The kernel initializes and runs the initial tasks
27	according the boot information structure from the	27	according the the boot information structure from the
28	boot loader.	28	boot loader.
29	\end{enumerate}	29	\end{enumerate}
30		30
31	A third kind of boot loading occurs on platforms with no support	31	A third kind of boot loading occurs on platforms with no support
32	of boot loader. It is called \textit{image loading} and is	32	from boot loader. It is called \textit{image loading} and is
33	used mostly on simulated architectures.	33	used mostly on simulated architectures.
34		34
35	\begin{enumerate}	35	\begin{enumerate}
36	\item The kernel and initial user space images are placed	36	\item The kernel and initial user space images are placed
37	on well-known physical memory locations (usually	37	on well-known physical memory locations (usually
38	by a simulator configuration file). The execution	38	by a simulator configuration file). The execution
39	starts directly on the kernel entry point.	39	starts directly on the kernel entry point.
40	\item The kernel initializes and runs a previously hardwired	40	\item The kernel initializes and spawns compiled-in
41	number of initial user space tasks.	41	number of initial user space tasks.
42	\end{enumerate}	42	\end{enumerate}
43		43
44	The following sections describe the particual features of the	44	The following sections describe the particular features of the
45	boot loading process on the supported platforms. Sample	45	boot loading process on the supported platforms. Sample
46	configuration files for all simulators are in the directory	46	configuration files for all simulators are in the directory
47	{\em kernel/contrib/conf}.	47	{\em kernel/contrib/conf}.
48		48
49	\section{IA-32 and AMD64}	49	\section{IA-32 and AMD64}
50		50
51	On both platforms HelenOS depends on a boot loader which	51	On both platforms, HelenOS depends on a boot loader which
52	supports the Multiboot Specification (i.e. GRUB). The kernel	52	supports the Multiboot Specification (e.g. GRUB). The kernel
53	image (usually called \texttt{image.bin}) is loaded by the	53	image (usually called \texttt{image.iso}) is loaded by the
54	boot loader just above the 1st megabyte of the physical	54	boot loader just above the 1st megabyte of the physical
55	memory (the exact location is 1081344 bytes). Modules loaded by	55	memory (the exact location is 1081344 bytes). Modules loaded by
56	GRUB are automatically detected by the kernel and after initialization	56	GRUB are automatically detected by the kernel and after initialization
57	they are started as userspace tasks. The GRUB loading is the	57	they are started as userspace tasks. The GRUB loading is the
58	easiest in terms of using userspace tasks.	58	easiest in terms of using userspace tasks.
Line 73...	Line 73...
73	module /boot/klog	73	module /boot/klog
74	\end{verbatim}	74	\end{verbatim}
75		75
76	\section{32-bit MIPS}	76	\section{32-bit MIPS}
77	The MIPS port is fully supported in the {\em msim} and {\em gxemul} simulators.	77	The MIPS port is fully supported in the {\em msim} and {\em gxemul} simulators.
78	These simulators allow specifying a memory contents of the simulated	78	These simulators allow to specify a memory contents of the simulated
79	computer. Unfortunately, the autodetection of loaded modules does	79	computer. Unfortunately, the autodetection of loaded modules does
80	not work. In order to change number of loaded modules, the file	80	not work. In order to change number of loaded modules, the file
81	kernel/arch/mips32/src/mips32.c must be modified.	81	kernel/arch/mips32/src/mips32.c must be modified.
82		82
83	Sample msim configuration file:	83	Sample msim configuration file:
Line 105...	Line 105...
105	with 32-bit ARC firmware). It uses ARC for output and input. When	105	with 32-bit ARC firmware). It uses ARC for output and input. When
106	the kernel is compiled to be loaded on the SGI Indy, an ECOFF image	106	the kernel is compiled to be loaded on the SGI Indy, an ECOFF image
107	is created which can be later loaded directly with ARC boot loader	107	is created which can be later loaded directly with ARC boot loader
108	e.g. using BOOTP protocol.	108	e.g. using BOOTP protocol.
109		109
110	\section{IA64}	110	\section{IA-64}
111	The IA64 port is supported on the ski simulator. The situation is very similar	111	The IA-64 port is supported on the Ski simulator. The situation is very similar
112	to the MIPS loader - the loaded modules must be loaded on correct addresses in	112	to the MIPS loader - the loaded modules must be loaded on correct addresses in
113	the ski configuration file and specified in the file	113	the Ski configuration file and specified in the file
114	kernel/arch/ia64/src/ia64.c.	114	kernel/arch/ia64/src/ia64.c.
115		115
116	Sample IA64 configuration file:	116	Sample IA-64 configuration file:
117	\begin{verbatim}	117	\begin{verbatim}
118	load kernel.bin	118	load kernel.bin
119	romload ../uspace/ns/ns 0x400000	119	romload ../uspace/ns/ns 0x400000
120	romload ../uspace/init/init 0x800000	120	romload ../uspace/init/init 0x800000
121	romload ../uspace/console/console 0xc00000	121	romload ../uspace/console/console 0xc00000

Subversion Repositories HelenOS-doc

(root)/usrman/trunk/boot/boot.tex @ 153 – Rev 150 → 153