The boot process¶
The boot process is divided into 3 stages:
- Hardware boot
- Early userspace init
- Userspace init
The are two types of storage devices used in rxOS, based on the target device. On Raspberry Pi, SD cards are used, while on CHIP, the built-in NAND flash storage is used.
SD card boot partition contents¶
The first partition of the SD card is a 400MB FAT32 partition with the following contents:
- Raspberry Pi stage 2 bootloader (
- Raspberry Pi stage 3 bootloader (
- Raspberry Pi fixup data (
- device tree blob (
- kernel image with early userspace (
- main root filesystem image (
- backup root filesystem image (
- original factory root filesystem image (
The NAND contains the following:
- SPL (secondary program loader) partition
- SPL backup partition
- U-Boot bootloader partition
- U-Boot bootloader environment partition
- boot partition
- kernel image (
- device tree blob (
- kernel image (
- root filesystem partition
- backup root filesystem partition
- data partitions
Before any of the rxOS-specific software is executed, there is a phase in which the base hardware is initialized and the hardware-specific bootloaders are run.
Raspberry Pi boot¶
The first stage is the same for all Raspberry Pi devices, but it will be described here for completeness.
The ROM on the Raspberry Pi board contains the stage 1 bootloader (S1). When
power is applied, VideoCore GPU is activated, and S1 is executed on a small
RISC core that is present on the board. The S1 bootloader mounts the SD card,
and loads S2,
bootcode.bin, into the GPU’s L2 cache and executes it on the
S2 activates the SDRAM. It also understands ELF binaries, and loads S3,
start.elf, from the SD card. S3 is also known as GPU firmware, and this is
what causes the rainbow splash (4 pixels that are blown up to full-scren) to be
If there is a rainbow splash on the screen but no further activity, it means that S3 has been loaded successfully but kernel image did not boot.
S3 reads the firmware configuration file
config.txt (if any), and then
proceeds to split the RAM between GPU and ARM CPU. S3 also loads a file called
cmdline.txt if it exists, and will pass its contents as kernel command
line. S3 finally enables the ARM CPU and loads the kernel image (
by default, configurable via
config.txt), which is executed on the ARM CPU.
start.elf is actually a complete proprietary operating system known as
VCOS (VideoCore OS).
The kernel image contains a minimal early userspace and its
init script is
When the board receives power, code in the boot rom (BROM) is executed. This code will activate a small amount of memory and load SPL from either the first NAND partition or its backup image on the second partition.
SPL’s job is to activate all of DRAM and load the U-Boot bootloader from the third partition.
When U-Boot is activated it reads the boot parameters from the U-Boot environment partition. By default, this will cause U-Boot to mount the boot partition (labelled ‘linux’), and load the kernel image and the DTB from it.
Finally, the kernel image is executed.
The early userspace¶
Early userspace initialization happens within the
init script in the root
of the kernel’s initramfs. We will refer to this script as EI for brevity
EI is generated from a template found in
The asterix in the name can be either ‘nand’ or ‘sdcard’ depending on the
target platform. The sources are thoroughly documented, so if you need to know
more than what’s presented here, you are welcome to peruse the sources.
It first mounts devtmpfs to
/dev so that device nodes are accessible. It
then mounts the boot partition in order to access root filesystem
On Raspberry Pi, additional data partitions are created. For NAND-based boot, this step is skipped because the extra partitions are programmed along with the base system when the NAND is flashed at the factory.
On Raspberry Pi, there are three possible candidates for the final userspace,
and those are
factory.sqfs. On CHIP,
there are two possible candidates,
A RAM disk with size configurable at build-time (default is 80 MiB) is created
to serve as a write-enabled overlay over the read-only root filesystem. The
mount points for the SD card and devtmpfs are moved to
in the target rootfs, respectively.
If overlay SquashFS images are found (named
overlay-<name>.sqfs), they are
laid over the root filesystem to provide device-specific extension.
For each candidate root filesystem, EI mounts the image, and creates a write
overlay using OverlayFS and the previously configured RAM disk. It then
attempts to switch to the new root filesystem using BusyBox’s
command which executes the
/sbin/init binary in the target root filesystem.
If the switch is successful, early userspace initialization is complete and the userspace proper takes over.
If the switch is not successful, the next candidate is tried until no root filesystem candidates are left. If none of the root filesystem images/partitions can be booted, EI starts an emergency shell where troubleshooting can be performed.
Even if switch is successful, it does not mean the boot will succeed.
Minimal checking is performed to ensure that the root filesystem contains a
/sbin/init which an executable file or a symlink pointing to one,
but nothing beyond that is done. If the executable fails or does something
that terminates the init process, kernel will panic and boot will fail.
In general, however, this is not quite realistic as long as valid images
built for rxOS are used.
Userspace initialization happens in the rootfs and is carried out by the init
/etc/init.d. The init scripts are executed synchronously in the
lexical file name order.
The userspace will start the WiFi hotspot, web and database servers, and Outernet applications. Any attached external storage devices will also be mounted during this stage.