How to load U-Boot with STM32CubeProgrammer

Applicable for

This page explains how to load and start U-Boot with STM32CubeProgrammer over a UART or USB port.

1. Overview[edit | edit source]

To load and execute U-Boot in DDR with STM32CubeProgrammer, you need first to follow the steps described in AN5275: USB DFU/USART protocols used in STM32MP1 Series bootloaders,then to load and to start FSBL and SSBL to start the programming service:

phase 0x1 loaded by ROM code is the FSBL = TF-A BL2
phase 0x3 loaded by FSBL is the FIP file including the SSBL image: U-Boot

The FSBL, SSBL and FIP definitions can be found in the Boot chain overview (FIP includes the required SSBL).

This feature can be used to debug U-Boot features required for the programming service (USB support, Flash device support, and so on) during board bring-up.

See FAQ of STM32CubeProgrammer for answers to questions specific to this tool.

2. Prepare U-Boot to use the console[edit | edit source]

By default in the STM32 boot command the stm32prog command is executed when the boot device is UART or USB to allow U-Boot (the programming service) to communicate with STM32CubeProgrammer.

To access to U-Boot console when U-Boot is loaded with STM32CubeProgrammer:

For USB boot, you can easily interrupt this command stm32prog usb 0by pressing Ctr + C in the console without U-Boot modification.
For UART boot, the U-Boot console is deactivated to execute the stm32prog serial ${boot_instance} command in the bootcmd.
To use the U-Boot console after STM32CubeProgrammer load, you can deactivate this behavior by:
- deactivate CONFIG_CMD_STM32PROG_SERIAL:
  - use make menuconfig as explained in Kbuild
  - add the line # CONFIG_CMD_STM32PROG_SERIAL is not set in your defconfig (for example stm32mp15_trusted_defconfig)
- recompile U-Boot

Before ecosystem release v3.0.0 :

As CONFIG_CMD_STM32PROG_SERIAL doesn't exist, you need to

deactivate the support of the stm32prog command (for USB and UART devices) with a line #CONFIG_CMD_STM32PROG is not set in your defconfig,
patch the code, in arch/arm/mach-stm32mp/cpu.c (vv2020.01-stm32mp-r2)::arch_cpu_init(), and remove the console deactivation: gd->flags |= GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE;

3. Load U-Boot using Flashlayout[edit | edit source]

You can use a minimal "FlashLayout.tsv" files for <dev> serial boot (see STM32CubeProgrammer_flashlayout for file format details):

 #Opt	id	Name	Type		IP		Offset		Binary
 -	0x01	fsbl		Binary		none	0x00000000	tf-a_<dev>.stm32
 -	0x03	fip		Binary		none	0x00000000	fip.bin

You can then use this with STM32CubeProgrammer command:

 PC $> STM32_Programmer_CLI -c port=<dev_port> -w FlashLayout.tsv

With

For USB: <dev> = usb and <dev_port>=usb1
For UART: <dev> =uart and <dev_port>= UART Interface identifier (ex COM1, /dev/ttyS0,...)

4. Load U-Boot using CLI[edit | edit source]

You can also use the -d/--download option to load each phase and -s/--start option to start them without flashlayout.

For serial USB boot, <dev>=usb device with port=usb1.

 PC $> STM32_Programmer_CLI -c port=usb1 \
    -d tf-a_usb.stm32 0x1 -s 0x1 \
    -d flashlayout.stm32 0x0 -s 0x0 \
    -d fip.bin 0x3 -s 0x3

It is the same for serial UART boot with <dev>=uart and port= the UART Interface identifier.

For information, loading a flashlayout file with STM32 header for phase 0x0, even empty, is mandatory today but is to be removed in future release.

You can generate this empty flashlayout.stm32 file with U-Boot mkimage with the following Linux shell commands:

PC $> echo "" > flashlayout.tsv
PC $> mkimage -T stm32image -a 0xC0000000 -e 0xC0000000 -d flashlayout.tsv flashlayout.stm32