loader paragraph

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.