Subversion Repositories HelenOS-doc

Rev

Rev 149 | Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | Download | RSS feed

  1. \chapter{Boot Loading Process}
  2.  
  3. The startup of HelenOS happens in several steps.
  4. Depending on the platform these steps can be either
  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,
  20. a \textit{multiboot loading} contains following steps:
  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
  27.       according the boot information structure from the
  28.        boot loader.
  29. \end{enumerate}
  30.  
  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
  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.
  40. \item The kernel initializes and runs a previously hardwired
  41.       number of initial user space tasks.
  42. \end{enumerate}
  43.  
  44. The following sections describe the particual features of the
  45. boot loading process on the supported platforms. Sample
  46. configuration files for all simulators are in the directory
  47. {\em kernel/contrib/conf}.
  48.  
  49. \section{IA-32 and AMD64}
  50.  
  51. On both platforms HelenOS depends on a boot loader which
  52. supports the Multiboot Specification (i.e. GRUB). The kernel
  53. image (usually called \texttt{image.bin}) is loaded by the
  54. boot loader just above the 1st megabyte of the physical
  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.
  78. These simulators allow specifying a memory contents of the simulated
  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.  
  87. add rwm mainmem         0x0             8M      load    "/dev/zero"
  88. add rom startmem        0x1fc00000      1024k   load    "image.boot"
  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"
  95. \end{verbatim}
  96.  
  97. Sample gxemul command line arguments:
  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 \
  101. 0x81c00000:../uspace/console/console 0x81d00000:../uspace/tetris/tetris kernel.bin
  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.  
  110. \section{IA64}
  111. The IA64 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
  113. the ski configuration file and specified in the file
  114. kernel/arch/ia64/src/ia64.c.
  115.  
  116. Sample IA64 configuration file:
  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.
  134.