Overview

Modern embedded platforms often use multiple boot stages during system startup - for example, Trusted Firmware-A, OP-TEE in the secure world, and U-Boot or other bootloaders in the normal world. These components frequently need to exchange configuration data, memory layout information, firmware metadata, or platform-specific runtime context. Historically, this information exchange has been implemented in ad-hoc, vendor-specific ways, resulting in fragile integration, poor portability, and maintenance challenges across diverse hardware platforms.

To address this, Firmware Handoff Specification is introduced, which standardizes how information is passed across bootloader stages. The key concept of the specification is the Transfer List (TL): a contiguous data structure residing in memory that holds one or more Transfer Entries (TEs). Each entry describes a specific piece of information that one boot stage exports for consumption by later stages.

I published an article about the implementation of Firmware Handoff on Linaro Blog:

Passing information across bootloader components, Linaro Blog (April 29, 2024), Author: Raymond Mao.

Key Concepts

Transfer List (TL): A header plus a sequence of variable-length Transfer Entries stored in memory.

Transfer Entry (TE): A structured item identified by a unique type ID, containing metadata and the data payload.

Extensibility: The specification defines a standard set of TE types but allows for vendor- or platform-specific extensions without breaking compatibility.

Adoption Across Firmware Components

Integration of multiple open-source firmware projects:

  • TF-A: TL generation and handoff introduced since v2.10 and with full features since v2.13.0;

  • OP-TEE: TL parsing and memory management support since v4.1.0 and with full features since v4.7.0;

  • U-Boot: Support implemented by mapping TL into U-Boot’s bloblist infrastructure since v2024.01 and all features ready since v2025.04.

Enabling the flow typically involves:

  • Building TF-A with Transfer List library enabled and the appropriate Secure Payload Dispatcher.

  • Ensuring OP-TEE exports necessary TE contents back to TF-A and onward.

  • Configuring U-Boot with Bloblist selected and defining memory placement for the TL.

Example Workflow

A typical startup sequence might look like this:

  • BL2 creates the TL and inserts an entry containing the system’s Device Tree Blob.

  • BL31 validates and augments the TL (e.g., OP-TEE memory layout).

  • OP-TEE consumes and updates entries (e.g., reserved-memory regions), then returns control.

  • BL31 copies the TL to non-secure memory.

  • U-Boot imports the TL into its bloblist and uses it to configure its runtime environment.

Why This Matters

This common handoff format:

  • Reduces reliance on platform-specific boot integration code

  • Improves maintainability across different SoCs and boards

  • Avoids misusing the Device Tree as a general-purpose message-passing structure

  • Enables more predictable and repeatable boot flows in both secure and non-secure environments

Quick Build and Demo

Get the makefile for building from my Github project: https://github.com/raymo200915/firmware_handoff_build_with_measured_boot

$ git clone git@github.com:raymo200915/firmware_handoff_build_with_measured_boot.git

Follow README (use case A) for build and run instructions. It fetches all necessary components across TF-A / OP-TEE / U-Boot, builds and runs with Firmware Handoff enabled.

All Patches enabled Firmware Handoff across boot components

Contributions to the specification:

TF-A:

OP-TEE:

U-Boot: