#Loading boot.elf code

The documentation for this process is also limited.ДЇor static systems, where there is a static set of task ELF files that are loaded at system startup, this can also lead to both elfloader and the root task being responsible for loading ELF binaries into memory. The interface between the kernel and whatever starts it is fairly limited and can make it difficult to start the kernel via something other than elfloader (such as a ROM-based firmware loader) without needing to maintain a fork of the kernel itself.

#Loading boot.elf code

For x86, the kernel boots directly from multiboot and the boot code within the kernel is responsible for ELF loading the initial task and initialising additional cores. The current situation differs somewhat between architectures, ARM and RISC-V both boot via the intermediary elfloader which is responsible for booting multiple cores, unpacking the ELF for the kernel and the initial task into physical memory a small amount of information about the initial task and device tree (although the form this currently takes is fairly limited). Some recent offline discussions have brought up a number of questions about how the boot process works, how we get from an external bootloader such as U-Boot to an initial task executing on seL4, and which components are involved and what their precise responsibilities are.