Subversion Repositories HelenOS-doc

Rev

Rev 150 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
124 decky 1
\chapter{Boot Loading Process}
2
 
3
The startup of HelenOS happens in several steps.
153 jermar 4
Depending on the platform, these steps can be either
124 decky 5
described as \textit{piggybacker loading}:
6
 
7
\begin{enumerate}
8
 \item Platform boot loader loads the piggybacker image
9
       and jumps to its entry point.
10
 \item The piggybacker unwraps the kernel image and
11
       the images of the initial user space tasks, creates
12
       a boot information structure and jumps to the
13
       entry point of the kernel.
14
 \item The kernel initializes and runs the initial tasks
15
       according the boot information structure from the
16
       piggybacker.
17
\end{enumerate}
18
 
19
If the platform supports a more sophisticated native boot loader,
153 jermar 20
the \textit{multiboot loading} consists of the following steps:
124 decky 21
 
22
\begin{enumerate}
23
 \item Platform boot loader loads the kernel image and initial
24
       user space tasks, creates a boot information structure
25
       and jumps to the entry point of the kernel.
26
 \item The kernel initializes and runs the initial tasks
153 jermar 27
       according the the boot information structure from the
124 decky 28
       boot loader.
29
\end{enumerate}
30
 
31
A third kind of boot loading occurs on platforms with no support
153 jermar 32
from boot loader. It is called \textit{image loading} and is
124 decky 33
used mostly on simulated architectures.
34
 
35
\begin{enumerate}
36
 \item The kernel and initial user space images are placed
37
       on well-known physical memory locations (usually
38
       by a simulator configuration file). The execution
39
       starts directly on the kernel entry point.
153 jermar 40
 \item The kernel initializes and spawns compiled-in
124 decky 41
       number of initial user space tasks.
42
\end{enumerate}
43
 
153 jermar 44
The following sections describe the particular features of the
149 palkovsky 45
boot loading process on the supported platforms. Sample
46
configuration files for all simulators are in the directory
47
{\em kernel/contrib/conf}.
124 decky 48
 
49
\section{IA-32 and AMD64}
50
 
153 jermar 51
On both platforms, HelenOS depends on a boot loader which
52
supports the Multiboot Specification (e.g. GRUB). The kernel
53
image (usually called \texttt{image.iso}) is loaded by the
124 decky 54
boot loader just above the 1st megabyte of the physical
149 palkovsky 55
memory (the exact location is 1081344 bytes). Modules loaded by
56
GRUB are automatically detected by the kernel and after initialization
57
they are started as userspace tasks. The GRUB loading is the
58
easiest in terms of using userspace tasks.
59
 
60
An example GRUB configuration file {\em menu.lst}:
61
\begin{verbatim}
62
title=HelenOS
63
root (cd)
64
kernel /boot/kernel.bin
65
module /boot/ns
66
module /boot/init
67
module /boot/pci
68
module /boot/fb
69
module /boot/kbd
70
module /boot/console
71
module /boot/tetris
72
module /boot/ipcc
73
module /boot/klog
74
\end{verbatim}
75
 
76
\section{32-bit MIPS}
77
The MIPS port is fully supported in the {\em msim} and {\em gxemul} simulators.
153 jermar 78
These simulators allow to specify a memory contents of the simulated
149 palkovsky 79
computer. Unfortunately, the autodetection of loaded modules does
80
not work. In order to change number of loaded modules, the file
81
kernel/arch/mips32/src/mips32.c must be modified.
82
 
83
Sample msim configuration file:
84
\begin{verbatim}
85
 add dcpu mips1
86
 
150 palkovsky 87
add rwm mainmem         0x0             8M      load    "/dev/zero"
149 palkovsky 88
add rom startmem        0x1fc00000      1024k   load    "image.boot"
150 palkovsky 89
add rwm ns              0x01000000      1M      load    "ns"
90
add rwm kbd             0x01100000      1M      load    "fb"
91
add rwm fb              0x01200000      1M      load    "kbd"
92
add rwm console         0x01300000      1M      load    "console"
93
add rwm init            0x01400000      1M      load    "init"
94
add rwm tetris          0x01500000      1M      load    "tetris"
149 palkovsky 95
\end{verbatim}
96
 
150 palkovsky 97
Sample gxemul command line arguments:
149 palkovsky 98
\begin{verbatim}
150 palkovsky 99
gxemul -E testmips -X 0x81800000:../uspace/ns/ns 0x81900000:../uspace/kbd/kbd \
100
0x81a00000:../uspace/fb/fb 0x81b00000:../uspace/init/init \
101
0x81c00000:../uspace/console/console 0x81d00000:../uspace/tetris/tetris kernel.bin
149 palkovsky 102
\end{verbatim}
103
 
104
The kernel can boot on the SGI Indy (and probably other SGI computers
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
107
is created which can be later loaded directly with ARC boot loader
108
e.g. using BOOTP protocol.
109
 
153 jermar 110
\section{IA-64}
111
The IA-64 port is supported on the Ski simulator. The situation is very similar
149 palkovsky 112
to the MIPS loader - the loaded modules must be loaded on correct addresses in
153 jermar 113
the Ski configuration file and specified in the file
149 palkovsky 114
kernel/arch/ia64/src/ia64.c.
115
 
153 jermar 116
Sample IA-64 configuration file:
149 palkovsky 117
\begin{verbatim}
118
load kernel.bin
119
romload ../uspace/ns/ns 0x400000
120
romload ../uspace/init/init 0x800000
121
romload ../uspace/console/console 0xc00000
122
romload ../uspace/fb/fb 0x1000000
123
romload ../uspace/kbd/kbd 0x1400000
124
romload ../uspace/tetris/tetris 0x1800000
125
romload ../uspace/klog/klog 0x1c00000
126
romload ../uspace/ipcc/ipcc 0x2000000
127
\end{verbatim}
128
 
129
\section{Power PC}
130
The PowerPC boot image contains complete kernel with user tasks.
131
The loader build system automatically creates such image using information
132
residing in boot/arch/ppc32/loader/Makefile.inc. The variable COMPONENTS
133
specifies, which tasks will be loaded into the image.