In the previous article, we introduced Secure Boot as a trust architecture built on:

• Root of Trust
• Chain of Trust
• Cryptographic verification

Those concepts are abstract by design. To work effectively with Secure Boot, however, we must understand where these mechanisms live in a real execution flow.

This article walks through a typical embedded boot sequence commonly found on ARM-based systems:

Boot ROM → Trusted Firmware → Bootloader → Linux

Focusing on:

• execution responsibilities
• trust transitions
• verification boundaries

The Boot Process Starts Before Software Exists

When power is applied to an ARM SoC, no firmware from external storage is running yet. Execution begins inside the processor itself, from immutable Boot ROM.

This stage is:

• burned into silicon
• minimal by design
• part of the hardware Root of Trust

The ROM is responsible for:

1. Initial hardware setup (very limited)
2. Selecting a boot source (eMMC, SD, NAND, SPI…)
3. Loading the first executable image
4. Verifying it if Secure Boot is enabled

At this point:

Trust is anchored purely in hardware.

No external code has executed yet.

Stage 1 — Boot ROM

The Boot ROM is the first execution stage of the system and part of the hardware Root of Trust.

It is:

• manufactured into silicon
• immutable
• not field-updatable
• not modifiable by the device integrator

This immutability is a deliberate design choice. Because ROM code cannot be patched after manufacturing, its functionality is intentionally minimal and security-focused.

The Boot ROM is responsible for:

• Boot source detection
• Loading the first executable image
• Cryptographic authentication (when Secure Boot is enabled)
• Transfer of execution

If Secure Boot is active:

• the ROM validates the image signature
• verification uses keys or hashes stored in hardware (eFuses / OTP^*)
• failures result in halt, fallback, or recovery behavior

Boot ROM: Not Modified, But Configured

Enabling Secure Boot does not involve modifying the Boot ROM.

Instead, its behavior is configured through hardware mechanisms such as:

• programming a root public key hash into eFuses or OTP^* memory
• setting Secure Boot enable bits
• transitioning the device lifecycle state (e.g., open → closed)

These hardware settings instruct the ROM to enforce signature verification when loading the first-stage firmware.

In other words:

The Boot ROM remains unchanged.
The trust policy is altered via hardware configuration.

The ROM does not:

• implement complex drivers
• load operating systems
• support rich update logic

Its only purpose is to securely establish the next link in the Chain of Trust.

^*OTP - One Time Programmable

Stage 2 — Early Firmware

After the Boot ROM successfully loads and authenticates the first image, execution transfers to the next stage: early firmware.

This stage is particularly important because it is typically the first software component fully controlled and modifiable by the device integrator.

Unlike the immutable Boot ROM, Stage 2 firmware:

• resides in external non-volatile storage
• can be updated
• can be rebuilt
• becomes part of the system’s Trusted Computing Base (TCB)

This stage is responsible for initializing hardware components that the ROM intentionally avoids handling, most notably:

• DRAM
• clock configuration
• security controllers
• low-level platform setup

Modern Platforms — Trusted Firmware-A (TF-A)

On modern SoCs, such as ARMv8 systems, the Boot ROM typically loads a firmware framework such as Trusted Firmware-A (TF-A).

TF-A introduces a structured, multi-stage boot design:

• BL1 — initial trusted stage (sometimes part of ROM)
• BL2 — platform initialization (including DRAM)
• BL31 — runtime firmware (EL3 monitor)

Key responsibilities include:

• DRAM initialization
• Exception level configuration
• Security state setup
• Loading and verifying subsequent boot stages

From a Secure Boot perspective:

• TF-A extends the Chain of Trust beyond ROM
• BL stages may authenticate the next firmware components
• Verification logic becomes firmware-driven

This stage represents the first major trust handover from immutable ROM to updatable firmware.

Legacy Platforms

Older ARMv7 platforms, such as NXP i.MX6, follow a different model.

These devices typically rely on:

• High Assurance Boot (HAB) implemented in ROM
• U-Boot SPL (Secondary Program Loader)
• U-Boot proper

The boot flow commonly looks like:

Boot ROM → U-Boot SPL → U-Boot → Linux

In this architecture:

• The ROM performs HAB authentication of the SPL
• The SPL initializes DRAM
• U-Boot loads and optionally verifies the kernel

Unlike ARMv8 systems:

• There is no TF-A multi-stage framework
• DRAM initialization happens inside the SPL
• Secure Boot enforcement relies on HAB mechanisms

Despite structural differences, the security principle remains identical:

Each stage must be authenticated before it is trusted to load the next.

Why Stage 2 Matters

Stage 2 is where the system transitions from:

• minimal immutable hardware logic
  → to
• complex, updateable software components

This stage is critical because it:

• performs DRAM initialization
• defines early security configuration
• becomes part of the Trusted Computing Base (TCB)

A vulnerability, misconfiguration, or unsigned firmware at this level can invalidate the entire Secure Boot chain.

Stage 3 — Bootloader

Once early firmware has completed hardware initialization and established trust for the next stage, control passes to the bootloader. On most embedded Linux platforms, this is U-Boot (“Das U-Boot”), the de facto standard open-source bootloader used across ARM, RISC-V, MIPS, and other architectures.

The bootloader’s responsibilities are far broader and more complex than the earlier stages. They include:

• full hardware initialization (beyond DRAM): buses, peripherals, PMICs, clocks, timers, etc.
• probing and configuring storage devices
• providing a user or console interface (serial, network, USB)
• loading the kernel, device tree, and optional initramfs
• offering scripting and fallbacks for flexible boot paths

SPL vs U-Boot proper

Many U-Boot ports are split into two binaries:

1. SPL (Secondary Program Loader)

   • a minimal “first stage” within U-Boot
   • typically performs very early hardware init (DDR, clocks)
   • loads the full U-Boot into DRAM

2. U-Boot proper (full bootloader)

   • provides rich bootloader features
   • implements filesystem drivers, scripting, network protocol support

The SPL/U-Boot split is common on platforms with small ROM-accessible RAM or where tight memory constraints exist.

Verification Authority Moves Here

From a Secure Boot perspective, the bootloader is the next point of authority:

• it inherits trust from firmware that brought it this far
• it may verify downstream payloads (kernel, DTB, initramfs)
• it can enforce policy via embedded cryptographic mechanisms

Common mechanisms include:

• FIT image verification — signing a single combined image including kernel, device tree, and optionally initramfs
• signature checks of individual artifacts
• integration with SoC vendor secure boot infrastructure

Failures here (e.g., missing signatures, corrupt images) typically lead to:

• halting the boot process
• entering recovery or maintenance mode
• triggering fallback boot paths

Additional Bootloader Features (Optional)

Be aware that modern bootloaders may also provide:

• scripting support (bootcmd, environment variables)
• network boot (TFTP/NFS)
• fastboot / DFU for field recovery
• debug interfaces

These features help recover or update devices in the field when designed securely alongside the Secure Boot model.

Stage 4 — Linux Kernel Handoff

When the bootloader has successfully authenticated all required images and made final configuration decisions, it begins the handoff to the kernel.

The kernel handoff involves:

1. Loading the kernel binary into RAM
2. Loading the Device Tree Blob (DTB)
   • describes hardware for the Linux driver model
3. Optionally loading an initramfs
4. Setting bootargs — kernel command line arguments
5. Jumping to the kernel entrypoint

At this point, Secure Boot’s primary responsibility is complete:
the kernel has been authenticated and execution transitions to the operating system.

Once the kernel takes over:

• early platform initialization continues inside the kernel
• drivers bring up remaining hardware
• root filesystem is mounted
• userland is started

Secure Boot does not validate runtime integrity within the kernel — that responsibility lies with other subsystems (e.g., dm-verity, IMA), which are outside core Secure Boot, and will be discussed later in this series.

What the Kernel Expects

The kernel boot protocol generally assumes:

• relocatable code in RAM
• valid DTB describing hardware
• correct bootargs for root filesystem and console settings

If the bootloader fails to provide any of these correctly, the kernel will not successfully start.

In embedded Linux, the bootloader’s job is to prepare a well-formed execution context for the kernel — both in terms of memory layout and configuration.

Trust Transitions Across the Boot Chain

A Secure Boot system can be viewed as a sequence of controlled trust transitions:

Stage	Executes From	Trust Established By	Verifies	Modifiable
Boot ROM	Immutable on-chip ROM	Hardware Root of Trust	First-stage firmware	❌ No
Early Firmware	External storage (flash/eMMC/SD)	ROM authentication	Bootloader	✅ Yes
Bootloader	External storage (executed from DRAM)	Firmware authentication	Kernel, DTB, initramfs	✅ Yes
Linux Kernel	DRAM	Bootloader authentication	Optional runtime assets	✅ Yes

From a security perspective, the boot chain is effectively a controlled delegation of trust. Each stage is authenticated before execution and becomes responsible for verifying subsequent components.

Where Secure Boot Logic Actually Lives

Secure Boot is not implemented in a single component.

Instead, verification logic is intentionally distributed across multiple stages:

• the Boot ROM authenticates the first executable image
• early firmware authenticates the bootloader
• the bootloader authenticates operating system payloads

This layered design provides several advantages:

• minimal complexity in immutable ROM
• flexibility in updateable firmware
• software-defined policy at the bootloader level

However, it also introduces an important implication:

Every verified stage becomes part of the Trusted Computing Base (TCB).

A vulnerability, misconfiguration, or verification bypass in any stage can undermine the integrity of the entire boot chain.

Why This Matters for Embedded Linux

Embedded Linux systems rely heavily on the correct interaction between:

• SoC Boot ROM mechanisms
• early firmware initialization
• bootloader configuration
• kernel loading conventions

Secure Boot enforcement shifts across these layers.

Verification responsibilities, key usage, and failure behaviors differ at each stage.

Without a clear execution model, Secure Boot workflows often degrade into:

“Follow these signing steps and hope the device boots.”

With a proper mental model, developers can:

• reason about verification failures
• design robust recovery paths
• structure key hierarchies correctly
• integrate build systems such as Yocto with confidence

Summary

A typical ARM boot chain progresses through:

Boot ROM → Early Firmware → Bootloader → Linux Kernel

Secure Boot enforcement:

• originates in immutable hardware
• transitions into updateable firmware
• continues through the bootloader

Each stage inherits trust from the previous one and becomes responsible for verifying subsequent components.

This staged trust transfer model underpins Secure Boot implementations across virtually all modern ARM platforms.

Next: Secure Boot on NXP i.MX Platforms — HAB vs AHAB

With a clear understanding of how trust flows across the ARM boot chain, we can now examine how real-world SoCs implement Secure Boot.

NXP i.MX devices provide an ideal reference because they span multiple generations of Secure Boot architectures:

• HAB (High Assurance Boot) — used in legacy platforms such as i.MX6 and i.MX7
• AHAB (Advanced High Assurance Boot) — used in modern platforms such as i.MX8 and i.MX9

In the next article, we will explore:

• architectural differences between HAB and AHAB
• Super Root Keys (SRK) and trust anchors
• eFuse provisioning
• device lifecycle states
• implications for firmware and bootloader signing