1. Diagram frames and legend[edit | edit source]
The hardware execution contexts are shown with vertical frames in the boot diagrams:
- The Arm Cortex-A secure context, in pink.
- The Arm Cortex-A nonsecure context, in dark blue.
- The Arm Cortex-M secure context, in light blue.
- The Arm Cortex-M nonsecure context, in light blue.
The horizontal frame in:
- The bottom part shows the boot chain.
- The top part shows the runtime services, that are installed by the boot chain.
The legend on the right illustrates how the information about the various components shown in the frames are involved in the boot process. These are highlighted as follows:
- The box color shows the component source code origin.
- The arrows show the loading and calling actions between the components.
- The Cube logo is used on the top right corner of components that can be configured via STM32CubeMX.
- The lock shows the components that can be authenticated during the boot process.
2. STM32MP2 A35-TD flavor 
boot chain[edit | edit source]
2.1. Overview[edit | edit source]
When A35-TD flavor is selected, the Cortex-A35 is booting first. Cortex-M33 is kept under reset by hardware until application request to start it.
STM32MP2 boot chain uses Trusted Firmware-A (TF-A) as the FSBL in order to fulfill all the requirements for security-sensitive customers, and it uses U-Boot as the SSBL executing in Cortex-A35 nonsecure context.
Note that the authentication is optional with this boot chain, so it can run on any STM32MP2 device security variant (that is, with or without the secure boot).
Refer to the security overview for an introduction of the secure features available on STM32MP2, from the secure boot up to trusted applications execution.
Once system is initialized (clock tree, regulators, system firewall) by OP-TEE secure OS, it is possible to start Cortex-M33 at SSBL level by the U-Boot early boot feature or, later, by the Linux remoteproc framework, depending on the application startup time-targets.
Cortex-M33 processor management could directly be done by U-Boot or Linux kernel in case of non-authenticated Cortex-M33 firmware or could rely on OP-TEE remoteproc trusted application in case of authenticated Cortex-M33 firmware.
Cortex-M33 firmware could be made up of different parts depending on customer product requirements:
- Cortex-M33 nonsecure: STM32 Cube for application.
- Cortex-M33 secure: TF-M secure OS for runtime secure services (optional).
- Cortex-M33 secure: low power functions for Cortex-M33 low power entry and exit management (optional).
The following figure shows an authenticated Cortex-M33 firmware load and start by Linux kernel through OP-TEE remoteproc TA.
2.2. ROM code[edit | edit source]
The ROM code starts the processor in secure mode. It supports the FSBL authentication and decryption.
2.3. First stage bootloader (FSBL)[edit | edit source]
The FSBL is executed from the SYSRAM.
Among other things, this bootloader initializes (part of) the clock tree and the DDR controller.
The FSBL loads (and optionally authenticates) the secure monitor, the secure OS and the second-stage bootloader (SSBL) into the DDR external RAM and jumps to secure monitor.
Trusted Firmware-A (TF-A) BL2 is used as FSBL on STM32MP2 series.
2.4. Second stage bootloader (SSBL)[edit | edit source]
U-Boot is commonly used as a bootloader in embedded software and it is the one used on STM32 Arm® Cortex® MPUs 
.
2.5. Linux[edit | edit source]
Linux® OS is loaded in DDR by U-Boot and executed in the nonsecure context.
2.6. Secure monitor[edit | edit source]
The Cortex-A35 secure world (EL3) supports TF-A BL31 secure monitor. Its role is to manage transitions between Cortex-A35 secure and nonsecure contexts and Cortex-A35 cluster low power states.
2.7. Secure OS[edit | edit source]
The Cortex-A35 secure world supports OP-TEE secure OS.
2.8. Arm Cortex-M33 firmware[edit | edit source]
The Arm Cortex-M33 can be started at the SSBL level by U-Boot with the remoteproc feature (rproc command) or, later, by Linux remoteproc framework, depending on the application startup time-targets.
Thanks to a specific OP-TEE trusted application (TA) running on the Arm® TrustZone and to the Resource Isolation Framework, it is possible to authenticate the Cortex®-M33 firmware, and install it on isolated memory region to ensure its integrity during the execution. For details, please refer to How to protect the Cortex-M coprocessor firmware article.
3. STM32MP2 M33-TD flavor boot chain[edit | edit source]
3.1. Overview[edit | edit source]
When M33-TD flavor is selected, the Arm Cortex-A35 starts the ROM code which loads and verifies FSBL-M in Retention RAM RETRAM) before starting the Arm Cortex-M33 in secure mode. Then the Arm Cortex-A35 is set in low power mode ready to wakeup on Arm Cortex-M33 request. The Arm Cortex-M33 is defined as the master of the system and is responsible of system initialization.
Once system initialized the Arm Cortex-M33 will wake up the Arm Cortex-A35 using a SEV signal that will start again the ROM code and load the Arm Cortex-A35 FSBL and the rest of the ecosystem while Arm Cortex-M33 is running (as done on A35-TD flavor boot chain.
3.2. ROM code[edit | edit source]
3.3. First stage bootloader (FSBL)[edit | edit source]
There is 2 FSBL to consider: FSBL-M and FSBL-A
- FSBL-M:
The FSBL-M is loaded and executed from RETRAM by ROM code. It is responsible for the minimal configuration of the platform (clock, power supplies, memory access) to load, authenticate and execute secure and non-secure Arm Cortex-M33 firmware images. MCUboot is used as FSBL-M on STM32MP2 series.
- FSBL-A:
When the Arm Cortex-M33 wakes-up the Arm Cortex-A35 the The FSBL-A is executed from the SYSRAM. The FSBL-A loads (and optionally authenticates) the secure monitor, the secure OS and the second-stage bootloader (SSBL) into the DDR external RAM and jumps to secure monitor.Trusted Firmware-A (TF-A) BL2 is used as FSBL-A on STM32MP2 series
3.4. Second stage bootloader (SSBL)[edit | edit source]
U-Boot is commonly used as a bootloader in embedded software and it is the one used on STM32 Arm® Cortex® MPUs .
3.5. Linux[edit | edit source]
Linux® OS is loaded in DDR by U-Boot and executed in the nonsecure context.
3.6. Secure monitor[edit | edit source]
The Cortex-A35 secure world (EL3) supports TF-A BL31 secure monitor. Its role is to manage transitions between Cortex-A35 secure and nonsecure contexts and Cortex-A35 cluster low power states.
3.7. Secure OS[edit | edit source]
The Cortex-M33 secure world supports TF-M secure OS.
The Cortex-A35 secure world supports OP-TEE secure OS.
3.8. Arm Cortex-M33 non secure firmware[edit | edit source]
The Arm Cortex-M33 non secure firmware is loaded by the FSBL-M and started by the Cortex-M33 secure OS. Note that an application is needed to wake up the Arm Cortex-A35.
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.