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 on the the U-Boot console when U-Boot is loaded with STM32CubeProgrammer:
- For USB boot you can easily interrupt this command
stm32prog usb 0
by entering ControlC in 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)
- Use
- recompile U-Boot
- deactivate CONFIG_CMD_STM32PROG_SERIAL:
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 ssbl Binary none 0x00000000 tf-a-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 tf-a-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