Mistake on this page? Email us

System architecture

A summary of the key BSP system architecture:

  • Security: Trusted Firmware for Cortex-A provides a generic solution for authenticating software components.
  • Firmware Update: Pelion Device Management Update service is used to update device firmware. This leads to a flash partition layout where trusted firmware, kernel, root file system and applications are independently updatable.
  • Reuse: Where possible, suitable existing solutions and software are reused.

Boot flow

secure boot chain flow
A summary form of the secure boot chain flow

The image above shows the main entities in the secure bootchain sequence: Soc Boot ROM, Trusted Firmware (TF), OP-TEE, U-Boot and Linux kernel:

  1. After the power is turned on, the Soc Boot ROM runs. This is the first-stage bootloader (BL1), which is programmed into the chip during manufacture.
  2. BL1 authenticates the second-stage bootloader, which is Trusted Firmware for Cortex-A (TF-A). TF-A supplies:
    • The second-stage bootloader BL2.
    • Part 1 of the third-stage bootloader BL31.
  3. BL31 runs OP-TEE, also called BL32.
  4. BL31 runs the Normal world bootloader, U-Boot (referred to as BL33).
  5. U-Boot runs the Linux kernel.

AArch32 boot flow

AArch32 secure boot processLinaro Connect 2016 Presentation LAS16-402 slide 16 showing the AArch32 secure boot process.

The image above shows the Cortex-v7A AArch32 generic secure boot process, which is the starting point for discussing secure boot on the WaRP7.

The diagram is divided into four columns, corresponding to the memory type and physical location from which the boot code runs:

  1. The first column shows the software components that execute from secure ROM.
  2. The second column shows the software components that execute from secure on-chip RAM.
  3. The third column shows the software components that execute from secure RAM, which may be on or off the SoC.
  4. The fourth column shows the software components that execute from insecure DRAM, which is off-chip.

The boot sequence consists of the following events:

  1. BL1 loads BL2.
  2. BL1 runs BL2 (in this step and all subsequent steps, running a component is preceded by successful authentication of the component).
  3. BL2 loads BL31 (TF-A secure monitor).
  4. BL2 loads BL32 (OP-TEE OS).
  5. BL2 loads BL33 (U-Boot, the Normal world bootloader).
  6. BL2 runs BL31 (TF-A secure monitor)
  7. BL31 runs BL32 (OP-TEE OS). OP-TEE OS modifies the kernel device tree to communicate shared information between OP-TEE OS and the kernel, for example the address and size of the shared memory buffer that is used OP-TEE OS and the kernel.
  8. BL32 runs U-Boot (change from SW to NW).
  9. BL33 (U-Boot) runs kernel.

The secure boot chain process is now complete.

AArch64 boot flow

AArch64Linaro Connect 2016 Presentation LAS16-402 slide 15 showing AArch64 secure boot process.

The image above shows the Cortex-v8A AArch64 generic secure boot process, which is the starting point for discussing the Raspberry Pi 3 and NXP IMX8 Mini secure boot.

For steps 1-6, the boot flow for AArch64 is the same as the AArch32 boot flow described in the previous section. Thereafter, the boot flow differs slightly:

  1. BL31 runs BL32 and then blocks waiting for BL32 to complete initialization.
  2. BL32 (Secure Payload, OP-TEE) runs and initializes.
  3. BL31 (SoC AP Firmware, Secure Monitor) resumes and runs BL33 (Normal world firmware, U-Boot). BL31 continues to run in the system.
  4. BL33 orchestrates the loading and running of the Rich OS.

The secure boot chain process is now complete.

See the Basic Signing Flow document for a more detailed description of the AArch64 secure boot flow.

Partitioning software components into FIP and FIT images

Partitioning of software componentsPartitioning of software components.

The image above shows the factoring of software components into four binary images:

  1. SoC Compatible Image: This image contains the TF-A generated BL2 and the ROTPK and is signed.

  2. FIP Image: This image is the TF-A fiptool-generated FIP image and contains many TBBR-CLIENT-defined key and content certificates, as well as the BL3x bootchain components.

    The FIP image contains the following components:

    1. TRUSTED-KEY-CERT.
    2. SOC-FW-KEY-CERT1.
    3. TOS-FW-KEY-CERT.
    4. NT-FW-KEY-CERT.
    5. SOC-FW-CERT.
    6. BL31 (TF-A).
    7. TOS-FW-CERT.
    8. BL32 (OP-TEE).
    9. BL33 (U-Boot).
    10. U-Boot device tree containing the FIT verification public key.
  3. FIT Image: Use u-boot-mkimage to create the FIT image, which contains:

    1. Linux kernel.
    2. Linux kernel device tree.
    3. boot.scr. This is a compiled version of the U-Boot boot script.
    4. The initramfs image.
    5. A configuration block.
  4. Rootfs Partition: This image contains the root file system.

For more information, please refer to the Trusted Board Boot Requirements CLIENT document.

Flash partition layout

See our Partition Layout document for information about partition layouts.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.