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,
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}.
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.
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}
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:
\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.
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
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}
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.