From d367b5a6eec7845d9d3e55ad8287b529f569c2c2 Mon Sep 17 00:00:00 2001 From: Annie Tallund Date: Fri, 6 Nov 2026 13:49:59 -0800 Subject: [PATCH] Update TF-A BL2 responsibilities in boot flow --- .../neoverse-rdv3-swstack/2_rdv3_bootseq.md | 44 ++++++++++--------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/2_rdv3_bootseq.md b/content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/2_rdv3_bootseq.md index d66b7efa59..7900c1401d 100644 --- a/content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/2_rdv3_bootseq.md +++ b/content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/2_rdv3_bootseq.md @@ -20,13 +20,15 @@ The following diagram from the [Neoverse Reference Design documentation](https:/ ## Stage 1: Security validation starts (RSE) -After BL2, the Runtime Security Engine (RSE, Cortex-M55) authenticates critical firmware components that include SCP, UEFI, and kernel images, using secure-boot mechanisms. It performs cryptographic measurements and establishes a Root of Trust (RoT) before allowing other processors to start. +At platform reset, the Runtime Security Engine (RSE, Cortex-M55) starts executing Trusted Firmware-M (TF-M) boot firmware from RSE ROM while SCP and MCP remain in reset. The RSE boot stages authenticate and load TF-M BL2 (MCUboot), which authenticates and loads the SCP and MCP firmware images and TF-A BL1. RSE records boot measurements and releases SCP and MCP from reset after loading their firmware. + +TF-M BL2 runs on RSE and is separate from TF-A BL2, which runs later on the application processor (AP). ***RSE acts as the platform’s security gatekeeper.*** ## Stage 2: Early hardware initialization (SCP/MCP) -Once RSE completes verification, the System Control Processor (SCP, Cortex-M7) and the Manageability Control Processor (MCP, where present) are released from reset. +After TF-M BL2 authenticates and loads their firmware, RSE releases the System Control Processor (SCP, Cortex-M7) and the Manageability Control Processor (MCP, where present) from reset. They perform essential bring-up: * Initializing clocks, reset lines, and power domains @@ -37,7 +39,7 @@ They perform essential bring-up: ## Stage 3: Secure execution setup (TF-A) -When the AP is released, it begins executing Trusted Firmware-A (TF-A) at EL3 from the reset vector address programmed during boot-image layout. TF-A configures the secure world, sets up exception levels, and prepares for handoff to UEFI. +When SCP releases the AP from reset, the AP begins executing Trusted Firmware-A (TF-A) BL1 from AP SRAM. TF-A continues the authenticated boot chain on the AP and prepares for handoff to UEFI through BL31, the runtime Root Monitor. ***TF-A is the ignition controller, launching the next stages securely.*** @@ -71,11 +73,12 @@ Each stage of the boot chain is backed by a dedicated component, such as secure ### RSE: Runtime Security Engine (Cortex-M55) (Stage 1: Security Validation) RSE firmware runs on the Cortex‑M55 and plays a critical role in platform attestation and integrity enforcement. -* Authenticates BL2, SCP, and UEFI firmware images (Secure Boot) -* Records boot-time measurements (for example, PCRs, ROT) -* Releases boot authorization only after successful validation -RSE acts as the second layer of the chain of trust, maintaining a monitored and secure environment throughout early boot. +* Runs TF-M BL2 (MCUboot), which authenticates and loads SCP, MCP, LCP, and TF-A BL1 firmware images +* Records boot measurements and receives measurements from TF-A for platform attestation +* Releases SCP and MCP from reset after their firmware has been authenticated and loaded + +RSE starts the platform's chain of trust, which TF-A continues on the AP. ### SCP: System Control Processor (Cortex‑M7) (Stage 2: Early Hardware Bring-up) @@ -84,12 +87,13 @@ RSE acts as the second layer of the chain of trust, maintaining a monitored and * Manages DRAM setup and enables power for the AP * Coordinates boot readiness with RSE via the Message Handling Unit (MHU) -### TF-A: Trusted Firmware-A (BL1/BL2) (Stage 3) +### TF-A: Trusted Firmware-A (BL1/BL2/BL31) (Stage 3) -* **BL1** executes from ROM, initializes minimal hardware (clocks, UART), and loads BL2 -* **BL2** validates and loads SCP, RSE, and UEFI images, setting up secure handover to later stages +* **BL1** executes from AP SRAM after being authenticated and loaded by TF-M BL2, then authenticates and loads TF-A BL2 +* **BL2** authenticates and loads TF-A BL31, the Realm Management Monitor (RMM), and UEFI (BL33) +* **BL31** acts as the runtime Root Monitor, sets up the TF-RMM interface, and triggers RMM initialization. When RMM returns control, BL31 hands off to UEFI (BL33) -TF-A establishes the system’s chain of trust and ensures downstream components are authenticated and loaded from trusted sources. +SCP and RSE are already running before TF-A BL2 executes. For details of authentication on the AP, see the [RD-V3 chain of trust documentation](https://neoverse-reference-design.docs.arm.com/en/rd-infra-2025.07.03/shared/cot_cca.html). ### UEFI, GRUB, and the Linux kernel (Stages 4–5) @@ -112,19 +116,19 @@ LCP support depends on the FVP model and can be omitted in simplified setups. The RD-V3 boot sequence follows a multi-stage, dependency-driven handshake model, where each firmware module validates, powers, or authorizes the next. -| Stage(s) | Dependency chain | Description | -|------:|----------------------|-------------------------------------------------------------------------------| -| 1 | RSE ← BL2 | RSE is loaded and triggered by BL2 to begin security validation | -| 2 | SCP ← BL2 + RSE | SCP initialization requires BL2 and authorization from RSE | -| 3 | AP ← SCP + RSE | The AP starts only after SCP sets power and RSE permits | -| 4-5 | UEFI → GRUB → Linux | UEFI launches GRUB, which loads the kernel and enters the OS | +| Stage(s) | Dependency chain | Description | +|------:|------------------|-------------| +| 1 | TF-M BL1_1 → BL1_2 → BL2 | RSE starts in ROM and reaches TF-M BL2 (MCUboot) through its boot stages | +| 2 | SCP/MCP ← RSE TF-M BL2 | TF-M BL2 authenticates and loads controller firmware, then releases the controllers from reset | +| 3 | AP ← SCP + RSE | RSE loads TF-A BL1 into AP SRAM; SCP releases the AP to execute TF-A BL1, followed by BL2 and BL31 | +| 4–5 | UEFI → GRUB → Linux | BL31 hands off to UEFI after RMM initialization; UEFI launches GRUB, which loads the kernel | This handshake ensures no stage proceeds unless its dependencies have securely initialized and authorized the next step. {{% notice Note %}} -In the table, arrows (←) indicate **dependency** - the component on the left depends on the component(s) on the right to be triggered or authorized. -For example, `RSE ← BL2` means BL2 loads/triggers RSE; `AP ← SCP + RSE` means the AP can start only after SCP has initialized hardware and RSE has granted authorization. -The right-facing arrows in `UEFI → GRUB → Linux` indicate a **direct execution path**—each stage passes control directly to the next. +In the table, arrows (←) indicate **dependency**: the component on the left depends on the component(s) on the right. For example, `SCP/MCP ← RSE TF-M BL2` means the controllers depend on TF-M BL2 running on RSE to load their firmware and release them from reset. The AP depends on RSE loading TF-A BL1 and SCP releasing it from reset. + +Right-facing arrows (→) indicate an **execution sequence**, either through the RSE boot stages or from UEFI through GRUB to Linux. TF-M BL2 on RSE and TF-A BL2 on the AP are separate bootloaders. {{% /notice %}} This layered approach supports modular testing, independent debugging, and early simulation, which is essential for secure and robust platform bring-up.