Modules
From power-on to the 40-pin header
The course follows your board through everything it does after power reaches it. Each module is one stage, and each stage only depends on the ones before it. You learn what has to be true before the next thing can happen, and you see it happen on your own board.
The modules
| Module | Stage | Lab | What you see on your board |
|---|---|---|---|
| 0. First boot | An OS image on boot media; the serial console | 1 | The full boot log, captured and kept for later |
| 1. What a board is | System-on-chip, memory, storage, regulators, clock, I/O | 2 | Every major part, on the board and in its layout |
| 2. First power-on and voltage rails | Regulators, rails, sequencing, reset | 2 | Rails measured, the power budget measured |
| 3. The boot ROM | Code fixed in the chip runs first | 3 | The boot order, and a board started over USB |
| 4. Loading the bootloader into SRAM | A small first stage in on-chip memory | 3 | An open-source first stage loaded over USB and running |
| 5. Memory bring-up | Timings, training, size detection | 4 | The memory lines of the log; a memory clock change and its effect |
| 6. Software in DRAM | Secure monitor, U-Boot, the memory map | 4 | The U-Boot prompt; a kernel booted by hand |
| 7. UEFI | A standard firmware interface | 5 | A stock generic distribution booting unmodified |
| 8. Linux boots | Kernel, drivers, root filesystem, init | 5 | The kernel's lines annotated; the boot timed |
| 9. Device tree and pin multiplexing | How the OS learns the hardware | 6 | The live device tree; an overlay that binds a driver |
| 10. I/O | GPIO, I2C, SPI, UART, PWM | 6–8 | Parts on the 40-pin header, decoded on a logic analyser |
| 11. Drivers | User space and the kernel | 8 | A userspace driver; a minimal kernel module |
| 12. A whole system | Boot as a service, survive a power cut, recover | 9–10 | The final project, and a broken board brought back |
The boot chain
Where each stage runs
The boot is a chain of handovers. Each stage runs from the only memory that is working at that moment, and its last job is to load the next stage and jump to it.
| Stage | Runs from | Loaded by | Its job |
|---|---|---|---|
| Boot ROM | ROM inside the system-on-chip | Nothing: it is the first instruction after reset | Find a first stage on a boot medium or over USB, check it, copy it into SRAM |
| SRAM stage | On-chip SRAM | The boot ROM | Set up clocks and the console, bring up DRAM, load the next stages into DRAM |
| Secure monitor (TF-A) | DRAM, stays resident | The SRAM stage | Run at the highest privilege level; power CPUs on and off for the OS |
| U-Boot | DRAM | The SRAM stage | Drive storage, network and USB; provide UEFI; load the kernel and device tree |
| Linux kernel | DRAM | U-Boot, directly or through UEFI | Take over the hardware, probe drivers, mount the root filesystem |
| init (systemd) | DRAM, as the first process | The kernel | Start every service, including the login prompt on the serial console |
One boot log, explained module by module
In lab 1 you capture the full boot log of your own board, without any explanation. Each module then explains the lines its stage prints, until every line is accounted for. By the end you can take the log of a board that did not boot and say where it stopped, and why.
| Lab | Lines explained | Modules |
|---|---|---|
| 1 | None: the whole log, unexplained | 0 |
| 3 | The boot ROM's lines, before any code from flash or boot media has run | 3 |
| 3–4 | The SRAM stage and memory bring-up | 4–5 |
| 4–5 | The secure monitor, U-Boot and UEFI | 6–7 |
| 5 | The kernel and init | 8 |
| 6–8 | Driver probe lines for each bus you enable | 9–11 |