aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorWojtek Kosior <kwojtus@protonmail.com>2020-01-21 17:30:42 +0100
committerWojtek Kosior <kwojtus@protonmail.com>2020-01-21 17:30:42 +0100
commit01e7392be71591fc6ae8de2bcb53734527b7190e (patch)
tree5a6ceb87b94f721405d9c4e32c44f0ea6f3d5b15
parent6d0b7fe4d2980a039208939e30ad01d33e5e4a61 (diff)
downloadrpi-MMU-example-01e7392be71591fc6ae8de2bcb53734527b7190e.tar.gz
rpi-MMU-example-01e7392be71591fc6ae8de2bcb53734527b7190e.zip
loader paragraph
-rw-r--r--README.md23
-rw-r--r--README.org21
2 files changed, 27 insertions, 17 deletions
diff --git a/README.md b/README.md
index 84365da..56aa06c 100644
--- a/README.md
+++ b/README.md
@@ -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.
diff --git a/README.org b/README.org
index 9005e20..ab071dd 100644
--- a/README.org
+++ b/README.org
@@ -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.