ST Employee

FAQ: How to bring up STM32MPx

October 14, 2026 at 3:13 PM
2 replies
22839 views

Purpose

The new development board is available, and a user might wonder how to get started.
The design includes STM32MPx, DDR RAM, STPMIC1 or STPMIC2 for the power supply, and a boot flash device.

How to configure the bootloaders for the application?
What to check if the boot chain fails to start or returns errors?
What tool to use to download the software to flash

This article applies for STM32MP1 and STM32MP2 series.

Procedure

Trusted Firmware-A (TF-A) in SYSRAM and U-Boot and OP-TEE firmwares in DRAM can be loaded from a serial link boot device, such as USB or UART, or from a boot flash device, such as an SD card, eMMC, SLC NAND, serial NAND, or serial NOR.
As first step, bring up can be from serial boot interface then from boot flash.

1. Adapt the TF-A configuration to the printed circuit board (PCB) application.

Configure TF-A in the TF-A device tree files.

Two options are available:

If the PCB is identical to the ST reference boards for the high-speed external oscillator (HSE), UART, I2C4, or I2C7 on STM32MP257D-DK for the PMIC, DRAM, and SDMMC subsystems, the TF-A binary provided in the Starter Package can be reused.
If the PCB differs from the ST reference board, for example for another STM32MPx device, DRAM, flash, or GPIOs, create the TF-A, OP-TEE, U-Boot, and kernel device tree files from empty files. Then add the nodes of the STM32MPx peripherals that the application uses.

For each peripheral driver that TF-A uses, the corresponding device tree file contains a related node that provides the driver configuration. For each peripheral, the following link points to the device tree node parameters: https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration. These articles also provide links to the driver binding files (st,txt files), which describe the meaning of the node parameters. In most cases, these parameters are the same across TF-A, U-Boot, and the kernel.

To develop the device tree file, start an STM32CubeMX project from the STM32CubeMX MCU selector. STM32CubeMX partially generates the device tree.

The device tree files that STM32CubeMX generates are incomplete. They cannot be used as generated.

The device tree that STM32CubeMX generates contains the GPIO pin multiplexing, the RCC settings, the DRAM configuration, and the hardware execution context for peripheral isolation. STM32CubeMX checks for GPIO conflicts to prevent multiple definitions. The tool does not generate the driver node parameters.

ST recommends reading the explanation and completing the hands-on session in the FAQ: STM32MPUs: How to create a device tree adapted to your design with STM32CubeMX

2. Launch TF-A serial boot

Configure the boot pins so that the boot ROM starts from a serial boot device. The boot ROM loads TF-A into internal SYSRAM from STM32MPx USB OTG, for which the boot ROM requires only two dedicated pins, or from UART. Select a UART other than UART console. For available booting UARTs and related pins, see https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#UART_Boot.

Use an STM32CubeProgrammer .tsv file from the STM32MPx Starter package with TF-A binaries (Id = 0x1).

For example, in FlashLayout_SD-Card_stm32mp157c-dk2-trusted.tsv or FlashLayout_sdcard_stm32mp257f-dk-ca35tdcid-ostl-optee.ts, select the "fsbl-boot" partition with Id = 0x1 in the STM32CubeProgrammer graphical user interface (GUI).

STM32CubeProgrammer and the boot ROM load TF-A into internal SYSRAM and start execution.

TF-A traces appear on UART4 or USART2 for the STM32MP2 console. TF-A enables this console by default.

For more information about STM32CubeProgrammer, see: https://wiki.st.com/stm32mpu/wiki/STM32MP15_Evaluation_boards_-Starter_Package#Downloading_the_image_and_flashing_it_on_the_board https://wiki.st.com/stm32mpu/wiki/STM32MP25_Discovery_kits-_Starter_Package#Downloading_the_image_and_flashing_it_on_the_board

After TF-A loads and runs successfully, the following message also appears: "Warning: DDR not configured".

3. Configuration of the DDR by T-FA

At this point, Trusted Firmware-A (TF-A) has not yet configured the DDR controller, so DRAM is not yet functional.

3.1 DRAM parameters in the device tree

Trusted Firmware-A (TF-A) first-stage boot loader (FSBL) loads DDR timings into the DDR controller registers. The register values are stored in the TF-A device tree source include (*.dtsi) files of the TF-A binary.

There are two ways to build these files:

If the printed circuit board (PCB) contains DDR3L at 533 MHz, the ST reference board files can be reused directly. Select stm32mp15-ddr3-2x4Gb-1066-binG.dtsi or stm32mp15-ddr3-1x4Gb-1066-binG.dtsi according to the configuration. These timings can be applied to any DDR3L device with speed bin 1066-G.
For LPDDR4, 32-bit STM32MP257F-DK bring-up can use stm32mp25-lpddr4-1x32Gbits-1x32bits-1200MHz.dtsi or stm32mp25-ddr4-2x16Gbits-2x16bits-1200MHz.dtsi.
If the PCB uses another DRAM type, for example LPDDR2, or requires line-impedance adaptation, STM32CubeMX can help compute the DDR controller configuration and generate the TF-A device tree file for STM32MP1 DDR controller settings. To generate a TF-A binary with DRAM timings, save the DRAM parameters and generate the *.dtsi DRAM file with the new parameters. Copy the files from the STM32CubeMX project into the TF-A fdts folder, then recompile TF-A.

More information is available at https://wiki.st.com/stm32mpu/wiki/DDRCTRL_and_DDRPHYC_device_tree_configuration.

3.2 Recompile TF-A with DDR `*.dtsi` files

Reload TF-A with STM32CubeProgrammer and the ROM code. Then verify that the TF-A trace appears, for example on DK2 with ecosystem V1.0.0:

"INFO: RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.41 INFO: Memory size = 0x20000000 (512 MB) ..."

Then U-Boot can be loaded and started in DDR.

More information about compiling the device tree in the Developer Package for TF-A and U-Boot is available at https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package#Updating_BOOT_firmwares.

3.3 Check DRAM is functional

There are two possibilities:

If DRAM works correctly and U-Boot shows no abnormal behavior at this stage, skip the DDR testing step with STM32DDRFW-UTILS (see below).
If DRAM does not work correctly, perform the checks and tests in this section.

Before DDR validation, the board design is expected to follow the recommendations in AN5122, AN5431 for STM32MP13x, or AN5724 for STM32MP2. These design rules strongly affect signal timing and are important.

If the DRAM to STM32MPx layout is reused from ST layout examples or ST boards, signal integrity tests have already been passed on the DRAM to STM32MPx connection.

If DRAM does not work correctly:

If the FSBL device tree has been adapted to the PCB, check that the correct binary is installed on the target.
Check the pin multiplexing of the DRAM signals against the PCB schematics.
Measure the voltages on VDD_DDR, VREF_DDR, and VDD_VTT, if present, on the PCB. Double-check the voltage values in the device tree STPMIC node of U-Boot SPL.
Check the DRAM timings for the DDR speed bin or grade against the DRAM datasheet.
Run all DDR tests with the STM32CubeMXDDRFW-UTIL

To run the DRAM tests, use the STM32DDRFW-UTILS binary. See https://wiki.st.com/stm32mpu/wiki/STM32DDRFW-UTIL for the test procedure.

If DRAM tests fail or the application shows abnormal behavior:

Double-check the DRAM connections in the schematics and layout.
Check for supply noise on VDDQ_DDR and the DDR_VREF pin.
Check that the DDR signal track lengths comply with the constraints in AN5122.
Use a 24 MHz oscillator on the HSE pin if the design includes LTCD outputs. See the errata sheet.
Additional DDR controller settings in STM32CubeMX DDR parameters are described in AN5168. The impedance on the DQ and DQS byte lines can be modified as described in AN5168, Section 5, or timings can be relaxed as described in AN5168, Section 6. For STM32MP2, DDRFW-UTILS shows the impedance margin during testing. This information helps select the appropriate DDR controller impedance parameters.

4. Check U-Boot and OP-TEE DTS configuration

Start with a DTS file in which all peripheral nodes are disabled.

Adapt the STM32CubeMX <project name>-u-boot.dtsi and DTS files to the board, using the same TF-A method described above.

U-Boot requires the USB OTG node for flash loading with STM32CubeProgrammer.

See https://wiki.st.com/stm32mpu/wiki/How_to_configure_U-Boot_for_your_board#USB_node

The U-Boot .dts file is the same as the kernel .dts file. The <project name>_uboot.dtsi file is an overlay for the U-Boot .dts file and overrides the node values.

Check the OP-TEE device tree to ensure that the console USART and the I²C bus for the PMIC are correct.

Load U-Boot and OP-TEE in DRAM

Use a method similar to the TF-A boot method above, for example, from a serial link with STM32CubeProgrammer.

In the .tsv file, select the following items in the STM32CubeProgrammer user interface:

TF-A (Id = 0x1)
"fip-ddr" partition (Id = 0x2) for STM32MP2
"fip-boot" partition (Id = 0x3), which contains U-Boot and OP-TEE

5. Linux Kernel bring-up

Use the same TF-A method described above. Start with a DTS file in which all peripheral nodes are disabled.

For each peripheral, use the first device tree description in the wiki to add the properties that match the printed circuit board (PCB) in the peripheral nodes.

Device tree description entry: https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration

Also use the ST reference board device tree files and related schematics as examples.

If the flash boot device is not available or has not been tested, the kernel can also boot with initramfs. In this case, STM32CubeProgrammer loads the root file system (rootfs) in DRAM.

6. Boot from a flash device

At this point, TF-A, OP-TEE, and U-Boot are configured for the printed circuit board (PCB) and can be loaded from a serial boot device by using STM32CubeProgrammer. From the U-Boot console, test whether the flash memory is accessible and correctly configured is sucessful.

The partitions that contain TF-A and U-Boot can now be flashed and then loaded to boot the kernel.

Before the kernel boots from flash, write the required partitions: the TF-A raw partition, the FIP partition (U-Boot and OP-TEE), bootfs (kernel), rootfs (kernel modules and user-space libraries), userfs, and others.

STM32CubeProgrammer and the U-Boot flashing service can write the partitions to the flash device.

Create the corresponding .tsv input file according to the flash-device partition layout.

The .tsv file from the Starter Package can be a starting point.

Further information is available at: https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#Typical_flashlayout-tsv_file

When the boot device is an SLC NAND, some U-Boot configuration is required to ensure correct flash programming.

For more information, see: https://wiki.st.com/stm32mpu/wiki/FMC_device_tree_configuration#DT_configuration_of_the_NAND_Flash_controller_-28board_level-29

Additional resources

It is strongly recommended for device tree creation adapted to the customer design to see FAQ: STM32MPUs: How to create a device tree adapted to your design with STM32CubeMX | Community
It is strongly recommended to read STM32MPUs bring-up troubleshooting guide
STM32MPU STM32 Community forum and other FAQs

STM32 MPUs products