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.
 \item The piggybacker unwraps the kernel image and
       the images of the 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 boot information structure from the
       piggybacker.
\end{enumerate}
 
If the platform supports a more sophisticated native boot loader,
a \textit{multiboot loading} contains 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 boot information structure from the
       boot loader.
\end{enumerate}
 
A third kind of boot loading occurs on platforms with no support
of 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 runs a previously hardwired
       number of initial user space tasks.
\end{enumerate}
 
The following sections describe the particual 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 (i.e. GRUB). The kernel
image (usually called \texttt{image.bin}) 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.
 
An example GRUB configuration file {\em menu.lst}:
\begin{verbatim}
title=HelenOS
root (cd)
kernel /boot/kernel.bin
module /boot/ns
module /boot/init
module /boot/pci
module /boot/fb
module /boot/kbd
module /boot/console
module /boot/tetris
module /boot/ipcc
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 specifying 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:
\begin{verbatim}
 add dcpu mips1
 
add rwm mainmem         0x0             8M      load    "/dev/zero"
add rom startmem        0x1fc00000      1024k   load    "image.boot"
add rwm ns              0x01000000      1M      load    "ns"
add rwm kbd             0x01100000      1M      load    "fb"
add rwm fb              0x01200000      1M      load    "kbd"
add rwm console         0x01300000      1M      load    "console"
add rwm init            0x01400000      1M      load    "init"
add rwm tetris          0x01500000      1M      load    "tetris"
\end{verbatim}
 
Sample gxemul command line arguments:
\begin{verbatim}
gxemul -E testmips -X 0x81800000:../uspace/ns/ns 0x81900000:../uspace/kbd/kbd \
0x81a00000:../uspace/fb/fb 0x81b00000:../uspace/init/init \
0x81c00000:../uspace/console/console 0x81d00000:../uspace/tetris/tetris kernel.bin
\end{verbatim}
 
The kernel can boot on the SGI Indy (and probably other SGI computers
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{IA64}
The IA64 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 IA64 configuration file:
\begin{verbatim}
load kernel.bin
romload ../uspace/ns/ns 0x400000
romload ../uspace/init/init 0x800000
romload ../uspace/console/console 0xc00000
romload ../uspace/fb/fb 0x1000000
romload ../uspace/kbd/kbd 0x1400000
romload ../uspace/tetris/tetris 0x1800000
romload ../uspace/klog/klog 0x1c00000
romload ../uspace/ipcc/ipcc 0x2000000
\end{verbatim}
 
\section{Power PC}
The PowerPC boot image contains complete kernel with user tasks.
The loader build system automatically creates such image using information
residing in boot/arch/ppc32/loader/Makefile.inc. The variable COMPONENTS
specifies, which tasks will be loaded into the image.
 

Rev 149	Rev 150
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.
10	\item The piggybacker unwraps the kernel image and	10	\item The piggybacker unwraps the kernel image and
11	the images of the initial user space tasks, creates	11	the images of the initial user space tasks, creates
12	a boot information structure and jumps to the	12	a boot information structure and jumps to the
13	entry point of the kernel.	13	entry point of the kernel.
14	\item The kernel initializes and runs the initial tasks	14	\item The kernel initializes and runs the initial tasks
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	a \textit{multiboot loading} contains 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 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	of 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 runs a previously hardwired
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 particual 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 (i.e. GRUB). The kernel
53	image (usually called \texttt{image.bin}) is loaded by the	53	image (usually called \texttt{image.bin}) 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.
59		59
60	An example GRUB configuration file {\em menu.lst}:	60	An example GRUB configuration file {\em menu.lst}:
61	\begin{verbatim}	61	\begin{verbatim}
62	title=HelenOS	62	title=HelenOS
63	root (cd)	63	root (cd)
64	kernel /boot/kernel.bin	64	kernel /boot/kernel.bin
65	module /boot/ns	65	module /boot/ns
66	module /boot/init	66	module /boot/init
67	module /boot/pci	67	module /boot/pci
68	module /boot/fb	68	module /boot/fb
69	module /boot/kbd	69	module /boot/kbd
70	module /boot/console	70	module /boot/console
71	module /boot/tetris	71	module /boot/tetris
72	module /boot/ipcc	72	module /boot/ipcc
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 specifying 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:
84	\begin{verbatim}	84	\begin{verbatim}
85	add dcpu mips1	85	add dcpu mips1
86		86
87	add rwm mainmem 0x0 8M load "/dev/zero"	87	add rwm mainmem 0x0 8M load "/dev/zero"
88	add rom startmem 0x1fc00000 1024k load "image.boot"	88	add rom startmem 0x1fc00000 1024k load "image.boot"
89	add rwm ns 0x01000000 1M load "../uspace/ns/ns"	89	add rwm ns 0x01000000 1M load "ns"
90	add rwm kbd 0x01100000 1M load "../uspace/fb/fb"	90	add rwm kbd 0x01100000 1M load "fb"
91	add rwm fb 0x01200000 1M load "../uspace/kbd/kbd"	91	add rwm fb 0x01200000 1M load "kbd"
92	add rwm console 0x01300000 1M load "../uspace/console/console"	92	add rwm console 0x01300000 1M load "console"
93	add rwm init 0x01400000 1M load "../uspace/init/init"	93	add rwm init 0x01400000 1M load "init"
94	add rwm tetris 0x01500000 1M load "../uspace/tetris/tetris"	94	add rwm tetris 0x01500000 1M load "tetris"
95	\end{verbatim}	95	\end{verbatim}
96		96
97	Sample gxemul command line arguments	97	Sample gxemul command line arguments:
98	\begin{verbatim}	98	\begin{verbatim}
-		99	gxemul -E testmips -X 0x81800000:../uspace/ns/ns 0x81900000:../uspace/kbd/kbd \
-		100	0x81a00000:../uspace/fb/fb 0x81b00000:../uspace/init/init \
99	gxemul -E testmips -X 0x81800000:../uspace/ns/ns 0x81900000:../uspace/kbd/kbd 0x81a00000:../uspace/fb/fb 0x81b00000:../uspace/init/init 0x81c00000:../uspace/console/console 0x81d00000:../uspace/tetris/tetris kernel.bin	101	0x81c00000:../uspace/console/console 0x81d00000:../uspace/tetris/tetris kernel.bin
100	\end{verbatim}	102	\end{verbatim}
101		103
102	The kernel can boot on the SGI Indy (and probably other SGI computers	104	The kernel can boot on the SGI Indy (and probably other SGI computers
103	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
104	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
105	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
106	e.g. using BOOTP protocol.	108	e.g. using BOOTP protocol.
107		109
108	\section{IA64}	110	\section{IA64}
109	The IA64 port is supported on the ski simulator. The situation is very similar	111	The IA64 port is supported on the ski simulator. The situation is very similar
110	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
111	the ski configuration file and specified in the file	113	the ski configuration file and specified in the file
112	kernel/arch/ia64/src/ia64.c.	114	kernel/arch/ia64/src/ia64.c.
113		115
114	Sample IA64 configuration file:	116	Sample IA64 configuration file:
115	\begin{verbatim}	117	\begin{verbatim}
116	load kernel.bin	118	load kernel.bin
117	romload ../uspace/ns/ns 0x400000	119	romload ../uspace/ns/ns 0x400000
118	romload ../uspace/init/init 0x800000	120	romload ../uspace/init/init 0x800000
119	romload ../uspace/console/console 0xc00000	121	romload ../uspace/console/console 0xc00000
120	romload ../uspace/fb/fb 0x1000000	122	romload ../uspace/fb/fb 0x1000000
121	romload ../uspace/kbd/kbd 0x1400000	123	romload ../uspace/kbd/kbd 0x1400000
122	romload ../uspace/tetris/tetris 0x1800000	124	romload ../uspace/tetris/tetris 0x1800000
123	romload ../uspace/klog/klog 0x1c00000	125	romload ../uspace/klog/klog 0x1c00000
124	romload ../uspace/ipcc/ipcc 0x2000000	126	romload ../uspace/ipcc/ipcc 0x2000000
125	\end{verbatim}	127	\end{verbatim}
126		128
127	\section{Power PC}	129	\section{Power PC}
128	The PowerPC boot image contains complete kernel with user tasks.	130	The PowerPC boot image contains complete kernel with user tasks.
129	The loader build system automatically creates such image using information	131	The loader build system automatically creates such image using information
130	residing in boot/arch/ppc32/loader/Makefile.inc. The variable COMPONENTS	132	residing in boot/arch/ppc32/loader/Makefile.inc. The variable COMPONENTS
131	specifies, which tasks will be loaded into the image.	133	specifies, which tasks will be loaded into the image.
132		134

Subversion Repositories HelenOS-doc

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