1. Article purpose[edit source]
This section details the TF-A BL2 stage (Trusted Firmware-A Boot Loader stage 2) used as FSBL (First Stage Boot Loader).
TF-A BL2 is the FSBL for ST boot chain. It is loaded by the ROM code in internal SYSRAM.
The main goal of this stage is to configure the DDR to load (and authenticate) other components from a FIP binary.
2. STM32 binary file[edit source]
To be properly loaded into SYSRAM by the ROM code, the TF-A BL2 firmware needs to be encapsulated in a binary that starts with an STM32 header.
The STM32 header information is mandatory for the ROM code to be able to load, authenticate and start the firmware.
As the ROM code can only load a single binary, the STM32 file must embed in a single image, the header, the device tree and the BL2 firmware.
TF-A BL2 is part of the trusted boot and can be signed to be authenticated by ROM code. See Secure boot process for more details.
3. Device tree[edit source]
TF-A BL2 is based on device tree configuration. It uses the same device tree as the kernel but keeping only the mandatory nodes for the boot stage (to reduce binary size) thanks to a dedicated device tree file (such as fdts/stm32mp15-bl2.dtsi ).
The device tree is part of the final STM32 file in order to be authenticated by the ROM code and loaded at the same time in the SYSRAM.
It must be configured or updated depending on your platform.
4. Storage management[edit source]
TF-A BL2 needs to access storage devices to load the FIP binary. By default, it uses the boot device selected by boot pins or OTP.
The selected device needs to be properly set up:
- Device tree configuration (all devices)
- BL2 boot device configuration for Flash memories .
Each device support needs a specific framework in the BL2 firmware.
By default, STMicroelectronics chose to select one single device support per binary. A BL2 with full storage support cannot fit in the SYSRAM size.
Storage build flags allow the BL2 firmware to be configured to support the requested boot storage.
5. DDR[edit source]
TF-A BL2 needs to set up the DDR to load the next binaries. DDR settings come from the device tree and must be adapted by the customer depending on DDR type, DDR configuration and boards. This can be done using STM32CubeMX.
6. Clock management[edit source]
An initial clock tree must be set up to allow accessing the DDR and the external storage devices.
It also improves the performance by increasing the default CPU speed and the storage transfer speed.
7. Binary mapping[edit source]
Below the TF-A BL2 mapping including the STM32 header layout:
The different sizes can be customized depending on build options and device tree customization. All sizes can be changed in the platform definition file. STM32MP1 platform uses plat/st/stm32mp1/stm32mp1_def.h :
- STM32MP_BL2_DTB_BASE: device tree base address in SYSRAM with its associated SIZE
- STM32MP_BL2_RO_BASE: start address from which the code is loaded and executed
- STM32MP_BL2_RW_BASE: start address of the read and write data used by the code. It depends on the STM32MP_BL2_RO_SIZE, which cannot exceed SYSRAM size.
8. BL2 load processing[edit source]
Based on FIP and firmware configuration file, the same BL2 can dynamically manage different secure environments:
The BL2 process is executed as described below:
- The ROM Code loads (and authenticates if required) the STM32 TF-A BL2 file together with its device tree.
- BL2 loads (and authenticates) FW_CONFIG file from FIP. BL2 parses the firmware configuration file to identify the load binary properties.
- BL2 loads (and authenticates) all the binaries listed in FW_CONFIG from FIP.
8.1. FW_CONFIG[edit source]
The FW_CONFIG file is based on the device tree. It describes the properties of the binaries to be loaded. This file is mandatory in the FIP binary to dynamically configure BL2 so that it properly loads all images. It depends on the DDR size, defined mapping and selected binaries. More details on FW_CONFIG and its configuration can be found here.
8.2. BL2 load in Programmer mode[edit source]
The Programmer mode (USB or UART boot device) requires the complete FIP binary to start the load image process as previously explained.
This is achieved by loading the complete FIP binary into DDR before starting the normal boot sequence.
The FIP load address is fixed and must not override the next loaded address:
DWL_BUFFER_BASE used in plat/st/common/stm32_io_storage.c
8.3. Low-power mode[edit source]
When exiting from low-power mode, BL2 has to wake up the DDR from self-refresh mode and reload only the binaries that have been lost.
.
9. Trusted boot support[edit source]
This is a key feature for the secure boot. It completes the STM32 ROM code secure boot process.
This feature is enabled by defining the TRUSTED_BOARD_BOOT = 1 build flag (not enabled by default).
As soon as the flag is enabled, all the binaries loaded by the BL2 stage are authenticated. The certificates listed in the CoT are mandatory into the FIP binary.
9.1. MBEDTLS[edit source]
When FIP is used, X509.v3 certificates are embedded in the package to authenticate all loaded binaries. The certificate parsing is done using MBEDTLS. The MBEDTLS[1] project is partially used during the trusted boot build process to retrieve part of the library and parse the certificates. The project must be downloaded close to the TF-A sources and the path using the MBEDTLS_DIR variable must be defined.
9.2. Disabling dynamic authentication[edit source]
A DYN_DISABLE_AUTH flag can be used to build the full BL2 content (including the disable MDEBTLS files). It allows the authentication to be enabled or disabled using a device tree property:
disable_auth = <0x0>; // To enable authentication disable_auth = <0x1>; // To bypass authentication
This device tree property is located in the BL2 device tree (trusted boot device tree).
9.3. Cryptographic Library[edit source]
The STM32 MPU uses its own cryptographic library (thanks to hardware accelerators or ROM Code services (STM32MP15 Only)) to verify certificate signatures: plat/st/common/stm32mp_crypto_lib.c
9.4. Keys[edit source]
The authentication is based on different keys and certificates. By default, the Arm® TBBR CoT is used. The topology is defined in the BL2 device tree fdts/cot_descriptors.dtsi and can be customized using <link here to authentication article>.
The STM32 MPU uses the default public root key hash in OTP as main root key for the CoT.
It can be modified by the customer in device tree by redefining pkh_otp.
During the development, the ROTPK hash is not mandatory. If it is not fused in OTP, it is seen as NOT DEPLOYED and the final ROTPK hash control is bypassed. However the entire CoT is verified.
10. Secure secret provisioning (SSP)[edit source]
The STM32 MPU supports the SSP feature. Part of this feature is based on TF-A BL2:
- Exchange with STM32_CubeProgrammer
- Secure programing secret OTPs
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.