aboutsummaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md23
1 files changed, 14 insertions, 9 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.