docs update

Signed-off-by: Bill Nguyen <bill.nguyen@student.unsw.edu.au>

Author: dreamliner787-9

DEVELOPER.md

@@ -108,15 +108,13 @@ When you build the SDK, provide an extra argument `--toolchain-prefix-riscv64 ri
 The SDK includes a binary of the seL4 kernel.
 During the SDK build process the kernel is build from source.
 
-At this point in time there are some minor changes to the seL4 kernel required for Microkit. This is temporary, more details can be found [here](https://github.com/seL4/microkit/issues/52).
-
 Please clone seL4 from:
 
     https://github.com/seL4/seL4.git
 
-The correct branch to use is `microkit`.
+The correct branch to use is `master`.
 
-Testing has been performed using commit `3aafe9e0b9527794c547d12090117e1000302da0`.
+Testing has been performed using commit `b60b6652a47f4e749d06fbdb9dd7b5d074625b03`.
 
 ## Building the SDK
 

docs/manual.md

@@ -1183,8 +1183,11 @@ PCIDs not supported by the processor
 ```
 
 @billn continue
+
 @billn directing the user to write grub stanzas and stuff is a bit complicated, how about we build a bootable ISO from the tool?
 
+@billn GRUB is also not Mac friendly, maybe recommend users to use something like Limine instead?
+
 ## ZCU102 {#zcu102}
 
 The ZCU102 can run on a physical board or on an appropriate QEMU based emulator.
@@ -1289,9 +1292,6 @@ For the kinds of systems targeted by the Microkit, this reduction of the usable
 The limitation on the size of by-value arguments is forced by the (architecture-dependent) limits on the payload size of the underlying seL4 operations, as well as by efficiency considerations.
 The protected procedure payload should be considered as analogous to function arguments in the C language; similar limitations exist in the C ABIs (Application Binary Interfaces) of various platforms.
 
-\
-\
-
 ## Limits
 
 The limitation on the number of protection domains in the system is relatively arbitrary.
@@ -1318,32 +1318,30 @@ correspond to PD program images to the Microkit tool which is responsible to
 for packaging everything together into a single bootable image for the target
 platform.
 
-This final image contains a couple different things:
+On ARM and RISC-V, this final image contains a couple different things:
 
 * the Microkit loader
 * seL4
-* the Monitor (and associated invocation data)
-* the images for all the user's PDs
+* the capDL initialiser (and associated capDL specification)
 
 When booting the image, the Microkit loader starts, jumps to the kernel, which
-starts the monitor, which then sets up the entire system and starts all the PDs.
+starts the capDL initialiser, which then sets up the entire system and starts all the PDs, including the Monitor.
+
+On x86, the tool produces a boot module that only contains the capDL initialiser.
+The seL4 kernel image is distributed as part of the SDK. You must bring your own
+Multiboot 2 compliant bootloader which then loads the kernel and boot module.
 
 Now, we will go into a bit more detail about each of these stages of the
 booting process as well as what exactly the Microkit tool is doing.
 
-## Loader
+## Loader (ARM and RISC-V)
 
 The loader starts first, it has two main jobs:
 
-1. Unpack all the parts of the system (kernel, monitor, PD images, etc) into
+1. Unpack all the parts of the system (kernel and capDL initialiser) into
    their expected locations within main memory.
 2. Finish initialising the hardware such that the rest of the system can start.
 
-Unpacking the system image is fairly straight-forward, as all the information
-about what parts of the system image need to go where is figured out by the
-tool and embedded into the loader at build-time so when it starts it just goe
-through an array and copies data into the right locations.
-
 Before the Microkit loader starts, there would most likely have been some other
 bootloader such as U-Boot or firmware on the target that did its own hardware
 initialisation before starting Microkit.
@@ -1358,6 +1356,7 @@ that will not be done by a previous booting stage, such as:
 Once this is all completed, the loader jumps to seL4 which starts executing.
 The loader will never be executed again.
 
+@bill continue fixing below
 ## Monitor
 
 Once the kernel has done its own initialisation, it will begin the