How to load U-Boot with STM32CubeProgrammer

This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

This page explains how to load and start U-Boot with STM32CubeProgrammer over uart or usb.

1. Overview[edit source]

To load and execute U-Boot in DDR with STM32CubeProgrammer, you need to follow the steps described in AN5275: USB DFU/USART protocols used in STM32MP1 Series bootloaders, load and 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 include the required SSBL).

This feature can be used to debug U-Boot features required for programming service (USB support, flash devcie support,...) during board bringup.

See FAQ of STM32CubeProgrammer for specific question on this tools.

2. Prepare U-Boot to use the console[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 explain in Kbuild
  - Add the line # CONFIG_CMD_STM32PROG_SERIAL is not set in your defconfig (stm32mp15_trusted_defconfig for example)
- recompile U-Boot

Before ecosystem release v3.0.0 :

As CONFIG_CMD_STM32PROG_SERIAL don't exist, you need to

deactivate the support of the stm32prog command (for usb and uart device) 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 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

Then you use it with STM32CubeProgrammer command:

  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 source]

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

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

  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 uart serial 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 it will be removed in future release.

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

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