diff options
-rw-r--r-- | README.md | 23 | ||||
-rw-r--r-- | README.org | 21 |
2 files changed, 27 insertions, 17 deletions
@@ -31,9 +31,9 @@ <ul> <li><a href="#sec-5-2-1">5.2.1. Stage 1</a></li> <li><a href="#sec-5-2-2">5.2.2. Stage 2</a></li> -<li><a href="#sec-5-2-3">5.2.3. Notes</a></li> </ul> </li> +<li><a href="#sec-5-3">5.3. Notes</a></li> </ul> </li> <li><a href="#sec-6">6. MMU</a> @@ -428,18 +428,23 @@ address is determined based on information in the elf. Our kernel has been executed on qemu emulating RaspberryPi 2 as well as on real RaspberryPi 3 running rpi-open firmware (although not every -functionality works everywhere). To quicken running new images of the +functionality works everywhere). + +## Loader<a id="sec-5-1" name="sec-5-1"></a> + +To quicken running new images of the kernel on the board, a simple bootloader has been written by us, which can be run from the SD card instead of the actual kernel. It reads the kernel image from uart, and executes it. The bootloader can also be used within qemu, but there are several problems with passing keyboard input to the kernel once it's running. -Both bootloader and kernel are split into 2 stages. +It is worth noting, that a project named raspbootin (<https://github.com/mrvn/raspbootin>) exists, which does a very simillar thing. +We did, however, choose to write our own bootloader, which we did. -## Loader<a id="sec-5-1" name="sec-5-1"></a> +Bootloader is split into 2 stages. -In case of the loader it is due to the fact, that the the actual kernel +This is due to the fact, that the the actual kernel read by it from UART is supposed to be written at 0x8000. If the loader also ran from 0x8000 or a close address, it could possibly overwrite it's own code while writing kernel to memory. To avoid this, the first @@ -457,9 +462,9 @@ program pipe\\<sub>image</sub> is used to prepend kernel image with its size. ## Kernel<a id="sec-5-2" name="sec-5-2"></a> - In case of kernel, it is desired to have image run from 0x0, -because that's where the interrupt vector table is under default -settings. This is also achieved by splitting it into 2 stages. +The kernel is, just like bootloader, split into 2 stages. +It is desired to have image run from 0x0, because that's where the exception vector table is under default +settings. This was the main reason for splitting kernel into 2 parts. ### Stage 1<a id="sec-5-2-1" name="sec-5-2-1"></a> @@ -491,7 +496,7 @@ vector, which is not normally unused. In our case, when stage 1 jumps to 0x0, first instruction of stage 2, it jumps to that vector, which then calls the setup routine. -### Notes<a id="sec-5-2-3" name="sec-5-2-3"></a> +## Notes<a id="sec-5-3" name="sec-5-3"></a> In both loader and the kernel, at the beginning of stage1 it is ensured, that only one ARM core is executing. @@ -367,18 +367,22 @@ address is determined based on information in the elf. Our kernel has been executed on qemu emulating RaspberryPi 2 as well as on real RaspberryPi 3 running rpi-open firmware (although not every -functionality works everywhere). To quicken running new images of the +functionality works everywhere). + +** Loader +To quicken running new images of the kernel on the board, a simple bootloader has been written by us, which can be run from the SD card instead of the actual kernel. It reads the kernel image from uart, and executes it. The bootloader can also be used within qemu, but there are several problems with passing keyboard input to the kernel once it's running. -Both bootloader and kernel are split into 2 stages. +It is worth noting, that a project named raspbootin (https://github.com/mrvn/raspbootin) exists, which does a very simillar thing. +We did, however, choose to write our own bootloader, which we did. -** Loader +Bootloader is split into 2 stages. -In case of the loader it is due to the fact, that the the actual kernel +This is due to the fact, that the the actual kernel read by it from UART is supposed to be written at 0x8000. If the loader also ran from 0x8000 or a close address, it could possibly overwrite it's own code while writing kernel to memory. To avoid this, the first @@ -395,9 +399,9 @@ UART (4 bytes, little endian). Then, the actual kernel image. Our program pipe\_image is used to prepend kernel image with its size. ** Kernel - In case of kernel, it is desired to have image run from 0x0, -because that's where the interrupt vector table is under default -settings. This is also achieved by splitting it into 2 stages. + The kernel is, just like bootloader, split into 2 stages. + It is desired to have image run from 0x0, because that's where the exception vector table is under default + settings. This was the main reason for splitting kernel into 2 parts. *** Stage 1 Stage 1 is loaded at some higher address. It has second stage image embedded in it. It copies it to 0x0 and jumps to it. What gets @@ -425,7 +429,8 @@ vector, which is not normally unused. In our case, when stage 1 jumps to 0x0, first instruction of stage 2, it jumps to that vector, which then calls the setup routine. -*** Notes + +** Notes In both loader and the kernel, at the beginning of stage1 it is ensured, that only one ARM core is executing. |