linux-boot-arm · m00 · Orientation

The boot chain at a glance

explanationrpi4bbbstm32mp157not yet verified

When you power on an ARM board, the first code that runs is not yours. It is a small program inside the chip: the boot ROM. Its job is to find the next program and run it. That program finds the next one, and so on, until the Linux kernel starts the first user process, PID 1. This sequence is the boot chain.

Each stage does a little, then hands over

The boot ROM can’t start Linux directly. When it runs, the board’s main memory (DRAM) is not set up yet, so only a small on-chip memory is usable. The first loader has to fit there, and its main job is to bring up DRAM so the next, larger stage has room.

0:boot-chainBCM2711 · 4× Cortex-A72

Boot starts on the VideoCore GPU; the Arm cores wait in reset until the firmware releases them.

Stage 1 of 6

Boot ROM

(mask ROM) · loaded from inside the SoC

VideoCore VPUArm in resetFirmware, no Arm world yetnot yet verified
  • The GPU-side VPU executes first. The Arm cores are still held in reset.
  • Looks for the second-stage bootloader in the SPI EEPROM.
  • If that image is corrupt, loads recovery.bin from the SD card to reflash it.

Sources: Raspberry Pi documentation: Raspberry Pi hardware, boot sequence and boot EEPROM

Where it runs

VPU boot ROM
(mask ROM)
VPU on-chip memoryWhere the EEPROM bootloader executes is not yet confirmed from a primary source.
LPDDR4 SDRAM0x0000_0000 · 1 to 8 GB, shared by GPU and Arm

Serial · 115200 8N1 · illustrative

(ROM is silent)

Play the chain on each board and watch three things:

  1. Where code runs moves from ROM, to on-chip memory, to DRAM.
  2. Who runs first differs. On the Raspberry Pi 4 the VideoCore GPU starts before the Arm cores. On the BeagleBone Black and the STM32MP157, an Arm core runs the boot ROM.
  3. The world changes. On the STM32MP157 the early stages run in the secure world, and U-Boot and Linux run in the normal world.

Memory decides the order

1:memory-mapAM3358 (AM335x)
ROM code
Internal SRAM0x402F_0400 · Download area for the first-stage image, up to 109 KB
DDR3L0x8000_0000 · 512 MB

The BeagleBone Black’s ROM copies the first loader, U-Boot SPL, into internal SRAM, because DDR is not ready yet. SPL sets up DDR, then loads the full U-Boot into it. You will see the same pattern on every board, with different names.

The console tells you where you are

2:consolestm32mp157 · 115200 8N1 · illustrative
(ROM is silent; it falls back to USB or UART download when no image boots)
NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
NOTICE: BL2: v2.x(release)
NOTICE: BL2: Booting BL32
I/TC: OP-TEE version: 4.x
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
U-Boot 20xx.xx
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
DRAM: 512 MiB
Retrieving file: /extlinux/extlinux.conf
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] OF: fdt: Machine model: STMicroelectronics STM32MP157C-DK2 Discovery Board
[ 2.300000] Run /sbin/init as init process

Each stage prints its own banner on the serial console. Reading those banners is the fastest way to find which stage failed when a board does not boot.

What comes next

Module 01 covers the ARM architecture you need to follow these stages: exception levels and processor modes, and how the CPU moves from one stage to the next.

Sources

  1. Linux kernel documentation: Booting ARM Linux
  2. Linux kernel documentation: Booting AArch64 Linux
  3. Raspberry Pi documentation: Raspberry Pi hardware, boot sequence and boot EEPROM
  4. U-Boot documentation: AM335x generic boards
  5. Trusted Firmware-A documentation: STMicroelectronics STM32MP1
LEARNlinux-boot-armm00 Orientationlesson 1/1