Last edited 2 years ago

STM32CubeProgrammer flashlayout

1. Article purpose[edit source]

This article describes the FlashLayout file format.

This file is used as an input by STM32CubeProgrammer tool in order to:

  1. define the Flash memory partitions (see STM32MP15_Flash_mapping)
  2. select the files used to boot (see Boot chain overview) and then populate each partition.

The embedded programming service processes this file on the device and interacts with STM32CubeProgrammer to update the Flash memory.
This is done by the stm32prog command in U-Boot. This command is automatically executed for a serial boot (bootcmd on USB or UART boot). However you can launch it manually from the U-Boot console: this is useful if you want to perform a non-virgin board update front of STM32CubeProgrammer, without manipulating the boot pins.

See AN5275: USB DFU/USART protocols used in STM32MP1 Series bootloaders for protocol details and refer to STM32CubeProgrammer article to know how to use this tool.

The next chapters:

The FSBL, SSBL definitions can be found in the Boot chain overview.

As explain in TF-A overview, the FIP file includes all the binaries loaded by FSBL=TF-A BL2:
SSBL=U-Boot, the non secure device tree, BL32 = OP-TEE or SP-MIN...

2. FlashLayout file format[edit source]

The FlashLayout is a text file with a tab-separated-value format (tsv). It includes the below elements:

The lines beginning with the '#' character are ignored and treated as comments.

The "Binary" last column is not used by U-Boot. It is used by STM32CubeProgrammer on the host computer to select the files to be sent to the target.

Several tabulations (<tab>) can be used to allow the correct column alignment in the editor. They are ignored by STM32CubeProgrammer and by U-Boot.

Empty fields are not allowed. The FlashLayout file format supports the none reserved word.

2.1. Examples[edit source]

Below some valid FlashLayout files: 

#opt	Id	Name		Type		Device	Offset		Binary
-	0x01	fsbl-boot	Binary		none	0x00000000	tf-a-usb.stm32
-	0x03	fip-boot	Binary		none	0x00084400	fip.bin
P	0x04	fsbl1		Binary		mmc0	0x00004400	tf-a-sdcard.stm32
P	0x05	fsbl2		Binary		mmc0	0x00044400	tf-a-sdcard.stm32
P	0x06	fip		Binary		mmc0	0x00084400	fip.bin
P	0x10	bootfs		System		mmc0	0x00484400	bootfs.ext4
P	0x11	vendorfs		System		mmc0	0x04484400	vendorfs.ext4
P	0x12	rootfs		FileSystem	mmc0	0x05484400	rootfs.ext4
P	0x13	userfs		FileSystem	mmc0	0x33E84400	userfs.ext4

Above, the first line contains only header information. This is not mandatory, as shown below: 

-	0x01	fsbl_boot	Binary		none	0x0	tf-a-usb.stm32
-	0x03	fip_boot	Binary		none	0x0	fip.bin
P	0x32	sdcard		RawImage	mmc0	0x0	sdcard.bin

2.2. Field1: Options[edit source]

The Options field defines the operations to perform with a combination of characters: - P D E provided in any order;
First select the line of the FlashLayout with '-' or 'P':

  • '-' : none option, the partition or the device is not modified (mandatory if #Field5: Device = none)
  • 'P' : Program the partition or the device
U-Boot requests the binary to STM32CubeProgrammer and programs the partition or the Flash device.
On the block devices (SD card or e•MMC), the GPT partitioning is performed if all partitions of the device are selected with P.
For the 'P' option, two optional modifiers can be added:
  • 'E' : Empty partition or device, update is not requested (associated "Id" is skipped)
  • 'D' : Delete partition or device

The only supported combinations are the following (with character in any order):

  • - : no action
  • P : update = program the partition or the flash device
  • PE : do not update (also EP) : allow the GPT partitioning with empty partition for the block device but equivalent to '-' for RAW flash device
  • PD : delete and update (also DP)
  • PDE : delete and keep empty (also PED / DPE / DEP / EPD / EDP)

All other combinations are invalid.

2.3. Field2: Id[edit source]

Id identifies in a unique way the "download phase" requested by the device to STM32CubeProgrammer.
It is used by the embedded programming service to identify the next binary that is downloaded to the device.

Their destination depends on the executed code:

  • ROM code and TF-A (FSBL): binary loaded in RAM, to start the embedded programming service
  • U-Boot(SSBL): the embedded programming service is running, the binary is populated in Flash memory by stm32prog command.

The FlashLayout supported ranges are :

Range Partition
0x01 to 0x0F Boot partitions with FIP header or with STM32 header: SSBL, FSBL, other (TEE, Cortex-M4 firmware)
0x10 to 0xF0 User partitions programmed without header (uimage, dtb, rootfs, vendorfs, userfs)

All the other values are forbidden in FlashLayout file.

The Id 0x01 and 0x03 are reserved for binaries containing FSBL and SSBL respectively; the presence of these two Id in the FlashLayout file is mandatory to load the embedded service.

2.3.1. Reserved Id[edit source]

The reserved and allowed values in FlashLayout file are the following:

Code Content Description
0x01 image containing FSBL loaded by ROM code in embedded RAM
0x03 image containing SSBL loaded by FSBL in external RAM

For information some other Id are reserved and used for the communication between the embedded programming service and STM32CubeProgrammer, but they are forbidden in FlashLayout file.

Code Virtual Partition or State
0x00 FlashLayout
0xF1 Command GetPhase
0xF2 OTP
0xF3 SSP
0xF4 PMIC NVM
0xFE State = End of operation
0xFF State = Reset

2.3.2. Using Id for boot partition[edit source]

Even if in the FlashLayout file, any other Id lower than 0x10 (boot partition with FIP header or STM32 header) can identify the binaries containing the FSBL and SSBL to be programmed in Flash memory, the recommended mapping is:

Code Comment Content Description
0x01 reserved FSBL to boot file containing FSBL with serial load support: loaded by ROM code
0x03 reserved SSBL to boot file containing SSBL with programming support : loaded by FSBL
0x04 FSBL to program 1 file containing FSBL to program in Flash memory (first copy)
0x05 FSBL to program 2 file containing FSBL to program in Flash memory (second copy)
0x06 SSBL to program file containing SSBL to program in Flash memory

It enables having different binaries loaded in RAM (with Reserved ID 0x1 and 0x3) and programmed in Flash memory, for example when an updated feature is deactivated in the binaries to be programmed in Flash memory (see example in #Load and program different binaries).

We also skip the Id 0x2 (not reserved) to have a more coherent order, as U-Boot requests and programs the partitions in Id order.

With OpenSTLinux binaries (FSBL=TF-A and the FIP contains SSBL=U-Boot) , this recommended mapping uses two ID (0x03 and 0x06) for the same FIP file used to boot and to program:

Code Comment File Description
0x01 reserved tf-a-usb.stm32 TF-A to boot with serial load support on usb
0x03 reserved fip.bin FIP image file to boot, including U-Boot
0x04 tf-a-<dev>.stm32 TF-A for <dev> boot device to program: first copy
0x05 tf-a-<dev>.stm32 TF-A for <dev> boot device to program: second copy
0x06 fip.bin FIP file to program, including U-Boot (same FIP binary than FIP to boot)

This behavior is required since ecosystem release v3.0.0 More info.png , with the updated STM32 MPU boot chain (Trusted Firmware-A (TF-A) as FSBL and FIP file, including U-Boot, as SSBL) because TF-A provides one binary by boot device, including the serial boot over uart or over usb.

However the minimal mapping is, when the same FSBL and SSBL binaries can be loaded in RAM and programmed in Flash memory:

Code Comment Content Description
0x01 reserved FSBL file containing FSBL (first copy) to program in Flash memory, also used for serial boot, loaded by ROM code
0x02 default FSBL file containing FSBL second copy to program in Flash memory
0x03 reserved SSBL file containing SSBL programmed in Flash memory, also used for serial boot, loaded by FSBL

2.4. Field3: Name[edit source]

Name of the alternate setting of the USB DFU[1] for U-Boot enumeration. This is a string descriptor that indicates the target memory segment (see Interface Descriptor in DFU spec [2])

This is also the name of the Block device GPT partition: SD card / e•MMC.

The requirements for the GPT partitions, only for device = mmc + instance, are:

  • FSBL for SD card boot: the name must start with "fsbl"= fsbl, fsbl1, fsbl2... (ROM code requirement)
  • If FIP is supported by TF-A:
    • FIP containing SSBL for e•MMC/SD card boot: the name must be "fip"
  • If the FIP is not supported by TF-A (SSBL with STM32 header, deprecated):
    • STM32 image containing SSBL for e•MMC/SD card boot: the name must be "ssbl"
    • TEE partition names (when present) must use the names expected by TF-A :
      • OPTEE_HEADER_IMAGE_NAME "teeh"
      • OPTEE_PAGED_IMAGE_NAME "teed"
      • OPTEE_PAGER_IMAGE_NAME "teex"

These requirements are not verified by U-Boot during the Flash programming. If they are not fulfilled, the ROM code or TF-A does not find the boot stage binary and the boot from Flash memory fails.

2.5. Field4: Type[edit source]

Type is only used in U-Boot to select the part of Flash memory to be updated:

The supported values are:

GPT MTD
Type SD card e•MMC NAND Flash memory NOR Flash memory RAM
Binary x x x x x
Binary(N) fsbl
FileSystem x x x x dtb
System x x UBI UBI kernel
RawImage x user data x x

2.5.1. Block device GPT partition: SD card / e•MMC[edit source]

Refer to GPT standard for details [3].

The supported values, with associated partition type GUID (globally unique identifiers[4]), are:

  • Binary : raw data / linux reserved
    (GUID = 8DA63339-0007-60C0-C436-083AC8230908)
  • FileSystem : Linux filesystem data
    (GUID = 0FC63DAF-8483-4772-8E79-3D69D8477DE4)
    ext2/ext4/fat file system
  • System : FileSystem partition marked as bootable and used by U-Boot to find extlinux.conf configuration file (normally only one in the device, generic DISTRO feature)

For a Block device, the GPT header is updated only if all the partitions of this device are selected with the P option (full update).

2.5.2. Raw Flash device (NAND/NOR Flash memories) MTD partition[edit source]

The supported values are:

  • Binary: raw data, skip bad block (partition erase is not needed)
  • Binary(N): raw data, skip bad block. The loaded binary is repeated N times.
    It is only supported for NAND Flash memories when the partition name starts with "fsbl". It is used to avoid disturbances during the first boot (uncorrectable ECC errors).
    The first good block is read from NAND and duplicated N times in the same partition (write skip bad block).
  • FileSystem: unspecified File system, raw data
  • System : normally UBI volume, U-Boot erases all the blocks following the last data in the MTD partition to avoid mount errors.

2.5.3. Hardware device[edit source]

Export the associated device as one alternate setting by using Type=RawImage.

  • For SD card, NOR and NAND Flash memories: all the devices
  • For e•MMC: the user data area of e•MMC (see #Field6: Offset for access to the boot area partitions)

For RawImage, Offset=0x0 and PartId >= 0x10

2.5.4. RAM device (DDR)[edit source]

The supported values are:

  • Binary: raw data
  • FileSystem: device tree used in the bootm command
  • System : kernel image used in the bootm command (uImage.bin for example)

When a RAM device is present in the FlashLayout, the programming service will not reboot but start the loaded kernel image with the associated device tree (when present, when it is absent the U-Boot device tree is used).

2.6. Field5: Device[edit source]

Select the targeted device and the instance (starting at 0) as defined by U-Boot device tree:

  • mmc + instance : mmc0, mmc1, mmc2
    It is used for e•MMC or SD card on SDMMC. In the below examples:
    • SD card = mmc0 (SDMMC1)
    • e•MMC = mmc1 (SDMMC2)
  • nor + instance : nor0
    It is used for NOR on QUADSPI.
  • nand + instance : nand0
    It is used for parallel NAND Flash memories on FMC.
  • spi-nand + instance : spi-nand0
    It is used for serial NAND Flash memories on QSPI.
  • none only used to load the programming service in RAM
    It is allowed only for the reserved bootloaders partition (FSBL=0x1 and SSBL=0x3). In this case, the only allowed fields are: Type=Binary, Offset=0x0 and option=-
  • ram + instance : ram0
    It is used for files loaded in RAM by the programming service, for example to load and execute kernel.

Several devices can be mixed in the same FlashLayout file.

2.7. Field6: Offset[edit source]

The supported values are:

  • boot1: first boot area partition of e•MMC (offset is 0x0)
  • boot2: second boot area partition of e•MMC (offset is 0x0)
  • Offset in Bytes: offset in Flash memory area (in the user data area for e•MMC)

Refer to #Partition sizes for offset constraints.

2.8. Field7: Binary[edit source]

This file is used by STM32CubeProgrammer to find the file associated to each Id when it is requested by embedded programming service .

The file can be absent (Binary=none in the tsv file) only for skipped partitions tagged with the E option. In all other cases, this file is sent to U-Boot to update the Flash memory only for the partitions selected with the P option.

2.9. GPT partuuid of rootfs partition[edit source]

If #Field3: Name = rootfs for block device (SD card / e•MMC), U-Boot also sets a unique partition guid [4](PARTUUID) for each instance:

  • mmc0: PARTUUID = "e91c4e10-16e6-4c0e-bd0e-77becf4a3582"
  • mmc1: PARTUUID = "491f6117-415d-4f53-88c9-6e0de54deac6"
  • mmc2: PARTUUID = "fd58f1c7-be0d-4338-8ee9-ad8f050aeb18"

This partition PARTUUID is distinct from the filesystem UUID and it is persistent.

Refer to GPT standard for details. [3]

This value can be used with the "root" argument in the kernel bootargs to identify the partition used for the "Root filesystem". For instance, "root=PARTUUID=e91c4e10-16e6-4c0e-bd0e-77becf4a3582" [5] starts with the partition named rootfs on mmc0.

2.10. Partition operations[edit source]

To update only one partition, use the same FlashLayout file, keep the #Field1: Options=P for the partition to update and change the others to -.
And to delete only one partition, add the DE option on the corresponding line.

To update fip partition (based on #Examples): 

 -	0x01	fsbl-boot	Binary		none	0x00000000	tf-a-usb.stm32
 -	0x03	fip-boot	Binary		none	0x00084400	fip.bin
 -	0x04	fsbl1		Binary		mmc0	0x00004400	tf-a-sdcard.stm32
 -	0x05	fsbl2		Binary		mmc0	0x00044400	tf-a-sdcard.stm32
 P	0x06	fip		Binary		mmc0	0x00084400	fip.bin
 -	0x10	bootfs		System		mmc0	0x00484400	bootfs.ext4
 -	0x11	vendorfs		FileSystem	mmc0	0x04484400	vendorfs.ext4
 -	0x12	rootfs		FileSystem	mmc0	0x05484400	rootfs.ext4
 -	0x13	userfs		FileSystem	mmc0	0x33E84400	userfs.ext4

To delete fip partition: 

 -	0x01	fsbl-boot	Binary		none	0x00000000	tf-a-usb.stm32
 -	0x03	fip-boot	Binary		none	0x00084400	fip.bin
 -	0x04	fsbl1		Binary		mmc0	0x00004400	tf-a-sdcard.stm32
 -	0x05	fsbl2		Binary		mmc0	0x00044400	tf-a-sdcard.stm32
 PDE	0x06	fip		Binary		mmc0	0x00084400	fip.bin
 -	0x10	bootfs		System		mmc0	0x00484400	bootfs.ext4
 -	0x11	vendorfs		FileSystem	mmc0	0x04484400	vendorfs.ext4
 -	0x12	rootfs		FileSystem	mmc0	0x05484400	rootfs.ext4
 -	0x13	userfs		FileSystem	mmc0	0x33E84400	userfs.ext4

2.11. Partition sizes[edit source]

The partitions are contiguous (no holes in Flash memory).
The last partition continues until the end of the selected Flash memory.

To reduce the size of the last partition, use an 'Empty' partition and leave it unused.

All the partitions need to be present in the FlashLayout file, even if they are not selected or empty.
Then the offset and size of each partition are compared with:

  • pre-existing GPT partitioning, for updates on block devices (e•MMC or SD card)
  • predefined partitioning for MTD devices (NOR and NAND): see mtdparts environment variable in U-Boot for more information.

In case of partition size error, compare the existing partition size in U-Boot with the offset in the FlashLayout file.

2.11.1. GPT partition sizes[edit source]

Each GPT partition must be aligned to:

  • 512 bytes (LBA)
  • e•MMC erase group size

The first partition starts after 17 Kbytes (default size of GPT header for 128 entries in U-Boot).

Prior to updating partitions in a block device, check the partition size by executing the U-Boot command "part list" on the selected device: 


  part list mmc 0
 
 Partition Map for MMC device 0  --   Partition Type: EFI
 
 Part	Start LBA	End LBA		Name
 	Attributes
 	Type GUID
 	Partition GUID
   1	0x00000022	0x00000221	"fsbl1"
 	attrs:	0x0000000000000000
 	type:	8da63339-0007-60c0-c436-083ac8230908
 	guid:	35b71598-cc09-43f0-b9e2-f2a4037202ee
   2	0x00000222	0x00000421	"fsbl2"
 	attrs:	0x0000000000000000
 	type:	8da63339-0007-60c0-c436-083ac8230908
 	guid:	3a8bb930-75b1-473a-819b-0749b62893f7
   3	0x00000422	0x00002421	"fip"
 	attrs:	0x0000000000000000
 	type:	8da63339-0007-60c0-c436-083ac8230908
 	guid:	1014bf09-4e50-418c-82a3-807576a5f25c
   4	0x00002422	0x00022421	"bootfs"
 	attrs:	0x0000000000000004
 	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
 	type:	linux
 	guid:	6a1a0147-cc61-41ed-b0a7-e8fed794d4ab
   5	0x00022422	0x0002a421	"vendorfs"
 	attrs:	0x0000000000000000
 	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
 	type:	linux
 	guid:	28f351bb-f287-4223-9c35-c318e0d669b1
   6	0x0002a422	0x001aa421	"rootfs"
 	attrs:	0x0000000000000000
 	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
 	type:	linux
 	guid:	e91c4e10-16e6-4c0e-bd0e-77becf4a3582
   7	0x001aa422	0x01dacbdc	"userfs"
 	attrs:	0x0000000000000000
 	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
 	type:	linux
 	guid:	3c26f1ba-c7cd-4b58-ae90-340bfe9b02bd

Warning: Start and end are indicated in multiple of LBA (512 bytes by default).

To check the e•MMC erase group size in U-Boot, select the mmc device (here 1) and use the command "mmc info" in U-Boot. 

   mmc dev 1
 switch to partitions #0, OK
 mmc1(part 0) is current device
 
   mmc info
 Device: STM32 SD/MMC
 Manufacturer ID: 11
 OEM: 100
 Name: 004GA 
 Bus Speed: 52000000
 Mode: MMC High Speed (52MHz)
 Rd Block Len: 512
 MMC version 5.0
 High Capacity: Yes
 Capacity: 3.7 GiB
 Bus Width: 8-bit
 Erase Group Size: 512 KiB
 HC WP Group Size: 4 MiB
 User Capacity: 3.7 GiB WRREL
 Boot Capacity: 2 MiB ENH
 RPMB Capacity: 512 KiB ENH
 Boot area 0 is not write protected
 Boot area 1 is not write protected

2.11.2. MTD partition sizes[edit source]

Each MTD partition must be aligned to the device erase block size (NOR/NAND Flash memory).

In U-Boot command : 

  nand info
 Device 0: nand0, sector size 256 KiB
   Page size       4096 b
   OOB size         224 b
   Erase size    262144 b
   subpagesize     4096 b
   options     0x00084200
   bbt options 0x00060000

  sf probe
 SF: Detected mx25l51235f with page size 256 Bytes, erase size 64 KiB, total 64 MiB

For MTD, the U-Boot uses the mtdparts variable. Execute the U-Boot command mtdparts to know the current value: 

  mtdparts

By default on ST board, the mtdpart variable is built dynamically in board_mtdparts_default() under CONFIG_SYS_MTDPARTS_RUNTIME with the STMicroelectronics configs:

  • CONFIG_MTDPARTS_NAND0_BOOT = "2m(fsbl),4m(fip1),4m(fip2)"
  • CONFIG_MTDPARTS_NOR0_BOOT = "256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env)"
  • CONFIG_MTDPARTS_SPINAND0_BOOT = 2m(fsbl),4m(fip1),4m(fip2)"

When FIP is not supported in U-Boot (deprecated), the used configs are:

  • CONFIG_MTDPARTS_NAND0_BOOT = "2m(fsbl),2m(ssbl1),2m(ssbl2)"
  • CONFIG_MTDPARTS_NAND0_TEE = "512k(teeh),512k(teed),512k(teex)"
  • CONFIG_MTDPARTS_NOR0_BOOT = "256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env)"
  • CONFIG_MTDPARTS_NOR0_TEE = "256k(teeh),512k(teed),256k(teex)"
  • CONFIG_MTDPARTS_SPINAND0_BOOT = 2m(fsbl),2m(ssbl1),2m(ssbl2)"
  • CONFIG_MTDPARTS_SPINAND0_TEE = "512k(teeh),512k(teed),512k(teex)"

On NAND Flash, the last partition 'UBI' uses the remaining space with several UBI volumes for OpenSTLinux: uboot_config, uboot_config_r, boot, rootfs, vendorfs, and userfs ("boot" is the volume name expected by U-Boot).

On NOR Flash, the last partition named 'nor_user', is a free MTD partition which uses the remaining space.

We align each partition size on max supported erase block size (512 Kbytes on NAND and 256 Kbytes on NOR).

To change the MTP partitioning on NOR and NAND Flash memories, update these configurations in your U-Boot defconfig as explained in U-Boot and in 'MTD partitions in U-Boot' or override this behavior in your board.

2.11.3. NOR MTD partition on ST board[edit source]

The default MTD partitions used on the ST boards for NOR boot is, when FIP is supported in U-Boot: 

  mtdparts
 SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 MiB
 
 device nand0 <nand0>, # parts = 1
  #: name		size		offset		mask_flags
  0: UBI                 0x40000000	0x00000000	0
 
 device nor0 <nor0>, # parts = 5
  #: name		size		offset		mask_flags
  0: fsbl1               0x00040000	0x00000000	0
  1: fsbl2               0x00040000	0x00040000	0
  2: fip                 0x00400000	0x00080000	0
  3: u-boot-env          0x00080000	0x00480000	0
  4: nor_user            0x03b00000	0x00500000	0
 
 active partition: nand0,0 - (UBI) 0x40000000 @ 0x00000000
 
 defaults:
 mtdids  : nand0=nand0,nor0=nor0
 mtdparts: mtdparts=nand0:-(UBI);nor0:256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env),-(nor_user)

This default partitioning is compatible for any NOR device, as we align each partition size on max supported erase block size on = 256 Kbytes.

2.11.4. NAND MTD partition on ST board[edit source]

The default MTD partitions used on the ST boards for NAND boot is, when FIP is supported in U-Boot: 

  mtdparts
 
 device nand0 <nand0>, # parts = 4
  #: name		size		offset		mask_flags
  0: fsbl               0x00100000	0x00000000	0
  1: fip1                0x00400000	0x00200000	0
  2: fip2                0x00400000	0x00600000	0
  3: UBI                 0x3f700000	0x00a00000	0
 
 active partition: nand0,0 - (fsbl1) 0x00100000 @ 0x00000000
 
 defaults:
 mtdids  : nand0=nand0
 mtdparts: mtdparts=nand0:2048k(fsbl),4096k(fip1),4096k(fip2),-(UBI)

This default partitioning is compatible for any NAND device, as we align each partition size on max supported erase block size on NAND = 512 Kbytes.

3. Typical FlashLayout file with FIP[edit source]

This chapter describes the Layout file for the typical boot use cases based on STM32MP15_Flash_mapping when FIP is used.

Data are presented in tables for better readability despite the Layout file is plain text.

In the next examples, the STM32MP15 boot chain of OpenSTLinux is used together with the following files:

  • FSBL = TF-A with 2 different binary
    • FSBL to boot with serial boot over USB = tf-a-usb.stm32
      TF-A BL2 with STM32CubeProgrammer USB support, replaced by tf-a-uart.stm32 when UART is used
    • FSBL to program = tf-a-<dev>.stm32 (TF-A with boot from <dev> support, <dev> = emmc, sdcard, nand, spinand, nor)
  • FIP file containing SSBL = fip.bin, it includes secure monitor, from TF-A = SPMIN or from OP-TEE, SSBL=U-Boot binary and device tree.

3.1. NOR Flash memory and SD card with FIP[edit source]

NOR Flash memory in RAW, containing the bootloaders. It uses two copies for TF-A (for failsafe update) and one copy for FIP.
SD card using GPT: several EXT4 partitions.

We align each partition on max supported erase block size of NOR 256 Kbytes, based on default MTD partition on NOR but the size of ENV partition can be optimized for NOR with lower erase block size.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl1 Binary nor0 0x00000000 tf-a-nor.stm32
P 0x05 fsbl2 Binary nor0 0x00040000 tf-a-nor.stm32
P 0x06 fip Binary nor0 0x00080000 fip.bin
PED 0x07 env Binary nor0 0x00480000 none
PE 0x08 unused Binary nor0 0x00500000 none
P 0x10 bootfs System mmc0 0x00004400 bootfs.ext4
P 0x11 vendorfs FileSystem mmc0 0x04004400 vendorfs.ext4
P 0x12 rootfs FileSystem mmc0 0x05004400 rootfs.ext4
P 0x13 userfs FileSystem mmc0 0x33A04400 userfs.ext4

The PartId 0x07 is empty/deleted in nor0 ('PED' flag), the U-Boot environment is cleared.

The PartId 0x08 is an empty/free (user partition associated to 'nor_user' MTD partition in U-Boot ('PE' flag).

The 'System' partition 0x10 named "bootfs" is marked 'bootable'.

The partition 0x12 named "rootfs" has a specific PARTUUID.

3.2. NAND Flash memory with FIP[edit source]

The next example is compatible for any NAND device, as we align each partition size on max supported erase block size on NAND = 512 Kbytes.

We have, based on the default MTD partitions on NAND:

  • 2 copy of TF-A (Binary(2)) in a MTD partition of 2MB, with at least 4 block of 512kB and 2 remaining spare block to skip potential bad blocks.
  • 2 copies of FIP in 2 MTD partition of 4MB: fip1 and fip2; the number of remaining spare block, allowing to skip bad blocks, depends of the size of the FIP file = fip.bin.

For parallel NAND, the MTD device is nand0:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl Binary(2) nand0 0x000000 tf-a-nand.stm32
P 0x05 fip1 Binary nand0 0x200000 fip.bin
P 0x06 fip2 Binary nand0 0x600000 fip.bin
P 0x10 UBI System nand0 0xA00000 ubi.bin

For serial NAND, the MTD device is spi-nand0:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl Binary(2) spi-nand0 0x000000 tf-a-spinand.stm32
P 0x05 fip1 Binary spi-nand0 0x200000 fip.bin
P 0x06 fip2 Binary spi-nand0 0x600000 fip.bin
P 0x10 UBI System spi-nand0 0xA00000 ubi.bin
Warning white.png Warning
It is only a example of tsv file because the number of copies of TF-A and FIP to embed and the number of spare blocks for possible bad block are a critical part of NAND based product dimensioning !


see STM32MP15_Flash_mapping#NAND_memory_mapping for details

This partitioning can be optimized for NAND with erase block size lower than 512kB.

Nota: If you increase the number of copie of FIP, you need to check the number spare block and perhaps update the MTD partition in U-Boot.

For OpenSTLinux, the name of UBI MTD partition names is required by the U-Boot UBI bootcmd and by CONFIG_ENV_UBI_PART.
System is required by for UBI support to erase the last block of the partition.
This partition have several UBI volumes as defined in NAND memory mapping:

Name Type Description
uboot_config RAW The RAW partition used by U-Boot to save its environment (CONFIG_ENV_IS_IN_UBI), the volume name is defined by CONFIG_ENV_UBI_VOLUME
uboot_config_r RAW The RAW partition used by U-Boot to save its redundancy environment (CONFIG_ENV_IS_IN_UBI), the volume name is defined by CONFIG_ENV_UBI_VOLUME_REDUND
boot UBIFS The partition used by U-Boot to boot the kernel, with extlnux.conf file; the volume name boot is required by the U-Boot UBI bootcmd: ubifs_boot
vendorfs UBIFS A file system for third-party proprietary binaries
rootfs UBIFS Linux root file system
userfs UBIFS The user file system

3.3. e•MMC with FIP[edit source]

TF-A is copied in the two boot area partitions of e•MMC (hidden partition) for failsafe update.

The GPT partitioning is used on the user area. U-Boot starts just after the GPT header at 17-Kbyte offset.

The other partitions are pre-populated with ext4 partition.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl1 Binary mmc1 boot1 tf-a-emmc.stm32
P 0x05 fsbl2 Binary mmc1 boot2 tf-a-emmc.stm32
PD 0x06 fip Binary mmc1 0x00080000 fip.bin
P 0x10 bootfs System mmc1 0x00480000 bootfs.ext4
P 0x11 vendorfs FileSytem mmc1 0x04480000 vendorfs.ext4
P 0x12 rootfs FileSytem mmc1 0x05480000 rootfs.ext4
P 0x13 userfs FileSytem mmc1 0x33E80000 userfs.ext4

The partition 0x6 fip is erased before update with option D to clean the U-Boot environment located at the end of this partition.

The 'System' partition named "bootfs" is marked 'bootable'.

The partition named "rootfs" has a specific PARTUUID.

3.4. SD card with FIP[edit source]

RAW partition: two TF-A partitions (for fail safe update), then FIP.

The GPT partitioning is used so fsbl1 starts just after the GPT header at 17-Kbyte offset.

The other partitions are pre-populated with ext4 partition.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl1 Binary mmc0 0x00004400 tf-a-sdcard.stm32
P 0x05 fsbl2 Binary mmc0 0x00044400 tf-a-sdcard.stm32
PD 0x06 fip Binary mmc0 0x00084400 fip.bin
P 0x10 bootfs System mmc0 0x00484400 bootfs.ext4
P 0x11 vendorfs FileSytem mmc0 0x04484400 vendorfs.ext4
P 0x12 rootfs FileSytem mmc0 0x05484400 rootfs.ext4
P 0x13 userfs FileSytem mmc0 0x33E84400 userfs.ext4

The FIP partition 0x6 named "fip" is erased before update with option D to clean the U-Boot environment located at the end of this partition.

The 'System' partition named "bootfs" is marked 'bootable'.

The partition named "rootfs" has a specific PARTUUID.

4. Typical FlashLayout file without FIP[edit source]

Warning white.png Warning
The support of STM32 image containing SSBL is deprecated by FIP support in the latest Ecosystem release.

The STM32 image header for SSBL binary is supported in ecosystem release ≤ v2.1.0 or if you activate CONFIG_STM32MP15x_STM32IMAGE in your U-Boot defconfig for ecosystem release v3.0.0 More info.png (this temporary option is only introduced to facilitate the FIP migration but it will be removed in the next Ecosystem release).

4.1. Typical FlashLayout file[edit source]

This chapter describes the Layout file for the typical boot use cases based on STM32MP15_Flash_mapping when TEE is not used and associated partitions are absent (teeh, teed and teex).

Data are presented in tables for better readability despite the Layout file is plain text.

In the next examples, the STM32MP15 boot chain is used together with the following files:

  • FSBL = TF-A, with 2 different binary as by default TF-A as no STM32CubeProgrammer support
    • FSBL to boot = tf-a-serialboot.stm32 (TF-A with STM32CubeProgrammer support)
    • FSBL to program = tf-a.stm32 (TF-A without OP-TEE support)
  • binary containing SSBL: U-Boot = u-boot.stm32

4.1.1. NOR Flash memory and SD card[edit source]

NOR Flash memory in RAW, containing the bootloaders. It uses two copies for TF-A (for failsafe update) and one copy for U-Boot.
SD card using GPT: several user EXT4 partitions.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary nor0 0x0 tf-a.stm32
P 0x04 fsbl2 Binary nor0 0x40000 tf-a.stm32
P 0x03 ssbl Binary nor0 0x80000 u-boot.stm32
PED 0x20 env Binary nor0 0x280000 none
PE 0x21 unused Binary nor0 0x300000 none
P 0x10 bootfs System mmc0 0x00004400 bootfs.ext4
P 0x11 vendorfs FileSystem mmc0 0x04284400 vendorfs.ext4
P 0x12 rootfs FileSystem mmc0 0x05284400 rootfs.ext4
P 0x13 userfs FileSystem mmc0 0x35284400 userfs.ext4

The PartId 0x20 is empty/deleted in nor0, the U-Boot environment is cleared.

The PartId 0x21 is an empty/free user partition associated to 'nor_user' MTD partition in U-Boot

The 'System' partition named "bootfs" is marked 'bootable'.

The partition named "rootfs" has a specific PARTUUID.

4.1.2. NAND Flash memory[edit source]

BootLoader using RAW and then U-Boot environment and file system in UBI volume.

TF-A uses two RAW copies to avoid NAND Flash memory disturbances inside one partition.

U-Boot uses two copies in two RAW partitions to avoid NAND Flash memory disturbances inside one partition.

One MTD partition for UBI with several volumes: uboot_config, uboot_config_r, bootfs, rootfs, vendorfs, and userfs.

For parallel NAND, the MTD device is nand0:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl Binary(2) nand0 0x0 tf-a.stm32
P 0x03 ssbl1 Binary nand0 0x200000 u-boot.stm32
P 0x04 ssbl2 Binary nand0 0x400000 u-boot.stm32
P 0x10 UBI FileSystem nand0 0x600000 ubi.bin

For serial NAND, the MTD device is spi-nand0:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl Binary(2) spi-nand0 0x0 tf-a.stm32
P 0x03 ssbl1 Binary spi-nand0 0x200000 u-boot.stm32
P 0x04 ssbl2 Binary spi-nand0 0x400000 u-boot.stm32
P 0x10 UBI FileSystem spi-nand0 0x600000 ubi.bin

4.1.3. e•MMC[edit source]

TF-A is copied in the two boot area partitions of e•MMC (hidden partition).

The GPT partitioning is used on the user area. U-Boot starts just after the GPT header at 17-Kbyte offset.

The other partitions are pre-populated with ext4 partition.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary mmc1 boot1 tf-a.stm32
P 0x04 fsbl2 Binary mmc1 boot2 tf-a.stm32
PD 0x03 ssbl Binary mmc1 0x00080000 u-boot.stm32
P 0x10 bootfs System mmc1 0x00280000 bootfs.ext4
P 0x11 vendorfs FileSytem mmc1 0x04280000 vendorfs.ext4
P 0x12 rootfs FileSytem mmc1 0x05280000 rootfs.ext4
P 0x13 userfs FileSytem mmc1 0x35280000 userfs.ext4

The partition 0x3 U-Boot is erased before update with option D to clean the U-Boot environment located at the end of this partition.

The 'System' partition named "bootfs" is marked 'bootable'.

The partition named "rootfs" has a specific PARTUUID.

4.1.4. SD card[edit source]

RAW partition: two TF-A partitions, then U-Boot. The GPT partitioning is used so fsbl1 starts just after the GPT header at 17-Kbyte offset.

The other partitions are pre-populated with ext4 partition.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary mmc0 0x4400 tf-a.stm32
P 0x04 fsbl2 Binary mmc0 0x00044400 tf-a.stm32
PD 0x03 ssbl Binary mmc0 0x00084400 u-boot.stm32
P 0x10 bootfs System mmc0 0x00284400 bootfs.ext4
P 0x11 vendorfs FileSytem mmc0 0x04284400 vendorfs.ext4
P 0x12 rootfs FileSytem mmc0 0x05284400 rootfs.ext4
P 0x13 userfs FileSytem mmc0 0x35284400 userfs.ext4

The partition 0x3 U-Boot is erased before update with option D to clean the U-Boot environment located at the end of this partition.

The 'System' partition named "bootfs" is marked 'bootable'.

The partition named "rootfs" has a specific PARTUUID.

4.2. Typical FlashLayout file with TEE without FIP[edit source]

This chapter describes the Layout file with TEE partitions for the trusted typical boot use case based on STM32MP15_Flash_mapping.

Since TF-A binary for OPTEE without FIP does not support STM32CubeProgrammer, two different FSBL binaries are used:

  • FSBL to boot = tf-a-serialboot.stm32 (TF-A with STM32CubeProgrammer support)
  • FSBL to program= tf-a-optee.stm32(TF-A with OP-TEE support)

4.2.1. NOR Flash memory and SD card with TEE[edit source]

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary nor0 0x0 tf-a-optee.stm32
P 0x04 fsbl2 Binary nor0 0x40000 tf-a-optee.stm32
P 0x03 ssbl Binary nor0 0x80000 u-boot.stm32
PED 0x20 env Binary nor0 0x280000 none
P 0x05 teeh Binary nor0 0x00300000 tee-header.stm32
P 0x06 teed Binary nor0 0x00340000 tee-pageable.stm32
P 0x07 teex Binary nor0 0x00380000 tee-pager.stm32
PE 0x21 unused Binary nor0 0x400000 none
P 0x10 bootfs System mmc0 0x00004400 bootfs.ext4
P 0x11 vendorfs FileSystem mmc0 0x04284400 vendorfs.ext4
P 0x12 rootfs FileSystem mmc0 0x05284400 rootfs.ext4
P 0x13 userfs FileSystem mmc0 0x35284400 userfs.ext4

4.2.2. NAND Flash memory with TEE[edit source]

WARNING: the 'tee' partitions are not duplicated in the next example, possible reliability issue with NAND disturbance.

For parallel NAND, the MTD device is nand0:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary(2) nand0 0x0 tf-a-optee.stm32
P 0x03 ssbl1 Binary nand0 0x200000 u-boot.stm32
P 0x04 ssbl2 Binary nand0 0x400000 u-boot.stm32
P 0x05 teeh Binary nand0 0x600000 tee-header.stm32
P 0x06 teed Binary nand0 0x680000 tee-pageable.stm32
P 0x07 teex Binary nand0 0x700000 tee-pager.stm32
P 0x10 UBI FileSystem nand0 0x780000 ubi.bin

For serial NAND, the MTD device is spi-nand0:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary(2) spi-nand0 0x0 tf-a-optee.stm32
P 0x03 ssbl1 Binary spi-nand0 0x200000 u-boot.stm32
P 0x04 ssbl2 Binary spi-nand0 0x400000 u-boot.stm32
P 0x05 teeh Binary spi-nand0 0x600000 tee-header.stm32
P 0x06 teed Binary spi-nand0 0x680000 tee-pageable.stm32
P 0x07 teex Binary spi-nand0 0x700000 tee-pager.stm32
P 0x10 UBI FileSystem spi-nand0 0x780000 ubi.bin

4.2.3. e•MMC with TEE[edit source]

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary mmc1 boot1 tf-a-optee.stm32
P 0x04 fsbl2 Binary mmc1 boot2 tf-a-optee.stm32
PD 0x03 ssbl Binary mmc1 0x00080000 u-boot.stm32
P 0x05 teeh Binary mmc1 0x00280000 tee-header.stm32
P 0x06 teed Binary mmc1 0x00300000 tee-pageable.stm32
P 0x07 teex Binary mmc1 0x00380000 tee-pager.stm32
P 0x10 bootfs System mmc1 0x00400000 bootfs.ext4.stm32
P 0x11 vendorfs FileSytem mmc1 0x04400000 vendorfs.ext4
P 0x12 rootfs FileSytem mmc1 0x05400000 rootfs.ext4
P 0x13 userfs FileSytem mmc1 0x35400000 userfs.ext4

4.2.4. SD card with TEE[edit source]

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
P 0x02 fsbl1 Binary mmc0 0x4400 tf-a-optee.stm32
P 0x04 fsbl2 Binary mmc0 0x00044400 tf-a-optee.stm32
PD 0x03 ssbl Binary mmc0 0x00084400 u-boot.stm32
P 0x05 teeh Binary mmc0 0x00284400 tee-header.stm32
P 0x06 teed Binary mmc0 0x002C4400 tee-pageable.stm32
P 0x07 teex Binary mmc0 0x00344400 tee-pager.stm32
P 0x10 bootfs System mmc0 0x00384400 bootfs.ext4
P 0x11 vendorfs FileSytem mmc0 0x04384400 vendorfs.ext4
P 0x12 rootfs FileSytem mmc0 0x05384400 rootfs.ext4
P 0x13 userfs FileSytem mmc0 0x35304400 userfs.ext4

5. FlashLayout file to load and start U-Boot[edit source]

To be abble to load U-Boot with STM32CubeProgrammer, you can use this file:

For USB:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin

For UART:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-uart.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin

6. FlashLayout file to load and start kernel[edit source]

Load programming service with Device=none.

Load kernel uImage and device tree in DDR, Device=ram0.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x10 kernel System ram0 0xC2000000 uImage.bin
P 0x11 dtb FileSytem ram0 0xC4000000 stm32mp157f-ev1.dtb

This Linux kernel is started by a bootm command after the STM32CubeProgrammer DFU detach request, by using CLI -detach option.

For example on usb: 

  STM32_Programmer_CLI -c port=USB1 -d flashlayout.tsv
  STM32_Programmer_CLI -c port=USB1 -detach

To fully boot this Linux kernel, the used rootfs must be defined (it is a generic feature not explained in this WIKI):

  • initramfs integrated in uImage.bin (with INITRD command in Linux build configuration file or with INITRAMFS_IMAGE_BUNDLE with YOCTO),
  • an external roofs, with a location defined in command line provided in the provided Linux kernel device tree.

7. Using provided FlashLayout files[edit source]

The binary and the associated pre-defined FlashLayout files for STM32CubeProgrammer over USB are provided by ST in the Discovery kit.

For example, in STM32MP15 Discovery kits, you can find the distribution images as well as the file FlashLayout_sdcard_stm32mp157f-ev1-trusted.tsv: 

#Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157f-ev1-usb.stm32
-	0x03	fip-boot	Binary	none	0x0	fip/fip-stm32mp157f-ev1-trusted.bin
P	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
P	0x05	fsbl2	Binary	mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
PD	0x06	fip	Binary	mmc0	0x00084400	fip/fip-stm32mp157f-ev1-trusted.bin
P	0x10	boot	System	mmc0	0x00484400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P	0x11	vendorfs	FileSystem	mmc0	0x04484400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P	0x12	rootfs	FileSystem	mmc0	0x05484400	st-image-weston-openstlinux-weston-stm32mp1.ext4
P	0x13	userfs	FileSystem	mmc0	0x33E84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

They are used to program over USB all the binary on the flash device . You can use these FlashLayout files as a starting point and simply modify them:

7.1. Using STM32Programmer over UART[edit source]

To use the provided STM32CubeProgrammer over UART, the TF-A BL2 binary with USB support tf-a-<board>-usb.stm32 must be replaced in the flashlayout file by the TF-A BL2 binary with UART support: tf-a-<board>-uart.stm32.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 arm-trusted-firmware/tf-a-stm32mp157f-ev1-uart.stm32
- 0x03 fip-boot Binary none 0x0 fip/fip-stm32mp157f-ev1-trusted.bin
P 0x04 fsbl1 Binary mmc0 0x00004400 arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
P 0x05 fsbl2 Binary mmc0 0x00044400 arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
PD 0x06 fip Binary mmc0 0x00084400 fip/fip-stm32mp157f-ev1-trusted.bin
P 0x10 bootfs System mmc0 0x00484400 st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P 0x11 vendorfs FileSystem mmc0 0x04484400 st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P 0x12 rootfs FileSystem mmc0 0x05484400 st-image-core-openstlinux-weston-stm32mp1.ext4
P 0x13 userfs FileSystem mmc0 0x33E84400 st-image-userfs-openstlinux-weston-stm32mp1.ext4

The associated text file becomes : 

 #Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157f-ev1-uart.stm32
-	0x03	fip-boot	Binary	none	0x0	fip/fip-stm32mp157f-ev1-trusted.bin
P	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
P	0x05	fsbl2	Binary	mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
PD	0x06	fip	Binary	mmc0	0x00084400	fip/fip-stm32mp157f-ev1-trusted.bin
P	0x10	boot	System	mmc0	0x00484400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P	0x11	vendorfs	FileSystem	mmc0	0x04484400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P	0x12	rootfs	FileSystem	mmc0	0x05484400	st-image-weston-openstlinux-weston-stm32mp1.ext4
P	0x13	userfs	FileSystem	mmc0	0x33E84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

7.2. Updating partitions[edit source]

To update only some partitions, change the FlashLayout and only "select" the partitions that need to be updated:
Options field inside the FlashLayout is kept to P for partition(s) that need to be updated, others are changed to -.
Then execute STM32CubeProgrammer as before.

Example to update only U-Boot binary and st-image-bootfs filesystem :

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 arm-trusted-firmware/tf-a-stm32mp157f-ev1-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip/fip-stm32mp157f-ev1-trusted.bin
- 0x04 fsbl1 Binary mmc0 0x00004400 arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
- 0x05 fsbl2 Binary mmc0 0x00044400 arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
PD 0x06 fip Binary mmc0 0x00084400 fip/fip-stm32mp157f-ev1-trusted.bin
P 0x10 bootfs System mmc0 0x00484400 st-image-bootfs-openstlinux-weston-stm32mp1.ext4
- 0x11 vendorfs FileSystem mmc0 0x04484400 st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
- 0x12 rootfs FileSystem mmc0 0x05484400 st-image-core-openstlinux-weston-stm32mp1.ext4
- 0x13 userfs FileSystem mmc0 0x33E84400 st-image-userfs-openstlinux-weston-stm32mp1.ext4

The associated text file becomes : 

#Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157f-ev1-usb.stm32
-	0x03	fip-boot	Binary	none	0x0	fip/fip-stm32mp157f-ev1-trusted.bin
-	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
-	0x05	fsbl2	Binary	mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp157f-ev1-sdcard.stm32
PD	0x06	fip	Binary	mmc0	0x00084400	fip/fip-stm32mp157f-ev1-trusted.bin
P	0x10	boot	System	mmc0	0x00484400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
-	0x11	vendorfs	FileSystem	mmc0	0x04484400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
-	0x12	rootfs	FileSystem	mmc0	0x05484400	st-image-weston-openstlinux-weston-stm32mp1.ext4
-	0x13	userfs	FileSystem	mmc0	0x33E84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

7.3. Updating partitions using official ST bootloaders[edit source]

If TF-A or FIP are modified, and the STM32CubeProgrammer support is lost for any reason (for example if the stm32prog command is removed), you can still program these new files by selecting the correct binary setting for the partitions 0x01 and 0x03 with Device=none and change the Id for the binaries to program in Flash, as indicated in chapter "Field2: Id".

For example, with ST board, you can flash Customer-modified binary by using the ST original file. The new Layout file is:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 arm-trusted-firmware/tf-a-stm32mp157f-ev1-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip/fip-stm32mp157f-ev1-trusted.bin
P 0x04 fsbl1 Binary mmc0 0x00004400 <customer-tf-a>.stm32
P 0x05 fsbl2 Binary mmc0 0x00044400 <customer-tf-a>.stm32
PD 0x06 fip Binary mmc0 0x00084400 <customer-fip>.bin
P 0x10 bootfs System mmc0 0x00484400 st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P 0x11 vendorfs FileSystem mmc0 0x04484400 st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P 0x12 rootfs FileSystem mmc0 0x05484400 st-image-core-openstlinux-weston-stm32mp1.ext4
P 0x13 userfs FileSystem mmc0 0x33E84400 st-image-userfs-openstlinux-weston-stm32mp1.ext4

The associated text file becomes : 

#Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157f-ev1-usb.stm32
-	0x03	fip-boot	Binary	none	0x0	fip/fip-stm32mp157f-ev1-trusted.bin
P	0x04	fsbl1	Binary	mmc0	0x00004400	customer-tf-a.stm32
P	0x05	fsbl2	Binary	mmc0	0x00044400	customer-tf-a.stm32
PD	0x06	fip	Binary	mmc0	0x00084400	customer-fip.bin
P	0x10	boot	System	mmc0	0x00484400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P	0x11	vendorfs	FileSystem	mmc0	0x04484400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P	0x12	rootfs	FileSystem	mmc0	0x05484400	st-image-weston-openstlinux-weston-stm32mp1.ext4
P	0x13	userfs	FileSystem	mmc0	0x33E84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

8. Other FlashLayout examples[edit source]

8.1. NOR and NAND Flash memories[edit source]

NOR Flash memory in RAW: TF-A uses several partitions for failsafe update, then FIP.
NAND Flash memory in UBI: only one large MTD partition for UBI volumes and UBIFS.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl1 Binary nor0 0x000000 tf-a.stm32
P 0x05 fsbl2 Binary nor0 0x040000 tf-a.stm32
P 0x06 fip Binary nor0 0x080000 fip.bin
PED 0x10 env Binary nor0 0x480000 none
PE 0x11 unused Binary nor0 0x500000 none
P 0x20 UBI System nand0 0x00000000 ubi.bin

The PartId 0x11 is an empty/free user partition associated to 'nor_user' MTD partition in U-Boot.

8.2. SD card: FAT[edit source]

Below an example with FAT bootfs partition (kernel and RAMFS) and an empty userfs partition, deleted and formatted by Linux on first boot:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl1 Binary mmc0 0x000000 tf-a-sdcard.stm32
P 0x05 fsbl2 Binary mmc0 0x040000 tf-a-sdcard.stm32
P 0x06 fip Binary mmc0 0x080000 fip.bin
P 0x10 bootfs System mmc0 0x200000 bootfs.vfat
PED 0x11 userfs Empty mmc0 0x400000 none

8.3. RawImage[edit source]

The SD card content is exported as RAW device and updated with the image.sdcard file:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x10 sdcard RawImage mmc0 0x0 image.sdcard

You can also erase the device before performing the update, by adding D in option.

8.4. Deleting device content[edit source]

For example, NOR and NAND Flash memories are deleted with:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot none none 0x0 tf-a-usb.stm32
- 0x03 fip-boot none none 0x0 fip.bin
PDE 0x10 nor RawImage nor0 0x0 none
PDE 0x11 nand RawImage nand0 0x0 none

To erase all other devices, including the e•MMC boot partition, proceed as follows:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary none 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
PDE 0x10 sdcard RawImage mmc0 0x0 none
PED 0x20 emmc_boot1 Binary mmc1 boot1 none
DPE 0x21 emmc_boot2 Binary mmc1 boot2 none
EPD 0x22 emmc RawImage mmc1 0x0 none
DPE 0x30 nand RawImage nand0 0x0 none
PDE 0x40 nor RawImage nor0 0x0 none

Warning: A timeout may occur in STM32CubeProgrammer since deleting NOR Flash memory might be slow. To avoid this issue you can delete only the used partitions (Option=PED), for example: 

#Opt	Id	Name		Type		Device	Offset		Binary
-	0x01	fsbl-boot	Binary		none	0x0		tf-a-usb.stm32
-	0x03	fip-boot	Binary		none	0x0		fip.bin
#delete ALL devices
EPD	0x10	sdcard		RawImage	mmc0	0x0		none
PED	0x20	emmc_b1		Binary		mmc1	boot1		none
PED	0x21	emmc_b2		Binary		mmc1	boot2		none
PED	0x22	emmc		RawImage	mmc1	0x0		none
PED	0x30	nand		RawImage	nand0	0x0		none
# on NOR (slow device): delete ALL used MTD partitions
PE	0x40	nor		RawImage	nor0	0x00000000	none
PED	0x41	fsbl1_nor	Binary		nor0	0x00000000	none
PED	0x42	fsbl2_nor	Binary		nor0	0x00040000	none
PED	0x43	fip_nor		Binary		nor0	0x00080000	none
PED	0x44	env_nor		Binary		nor0	0x00280000	none
PE	0x45	unused		Binary		nor0	0x002C0000	none

8.5. Complex use case[edit source]

Update SD card (mmc0 on SDMMC1). The GPT partition is created since all partitions are selected and Userfs is deleted and empty.

Erase all other devices, including e•MMC hidden boot partition.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl-boot Binary node 0x0 tf-a-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip.bin
P 0x04 fsbl1 Binary mmc0 0x00004400 tf-a-sdcard.stm32
P 0x05 fsbl2 Binary mmc0 0x00044400 tf-a-sdcard.stm32
P 0x06 fip Binary mmc0 0x00084400 fip.bin
P 0x10 bootfs System mmc0 0x00484400 bootfs.stm32
P 0x11 rootfs FileSytem mmc0 0x08484400 rootfs.ext4
DEP 0x12 userfs FileSytem mmc0 0x28484400 none
PED 0x60 emmc_boot1 Binary mmc1 boot1 none
DPE 0x61 emmc_boot2 Binary mmc1 boot2 none
EPD 0x62 emmc RawImage mmc1 0x0 none
EPD 0x10 nand RawImage nand0 0x0 none

9. Reference list[edit source]

  1. ↑ https://en.wikipedia.org/wiki/USB#Device_Firmware_Upgrade
  2. ↑ USB Device Class Specification for Device Firmware Upgrade, Version 1.1, (available at http://www.usb.org/developers/docs): https://www.usb.org/sites/default/files/DFU_1.1.pdf
  3. ↑ 3.0 3.1 https://en.wikipedia.org/wiki/GUID_Partition_Table
  4. ↑ 4.0 4.1 https://en.wikipedia.org/wiki/Universally_unique_identifier
  5. ↑ https://wiki.archlinux.org/index.php/persistent_block_device_naming


Flash memories combine high density and cost effectiveness of EPROMs with the electrical erasability of EEPROMs. For this reason, the Flash memory market is one of the most exciting areas of the semiconductor industry today and new applications requiring in system reprogramming, such as cellular telephones, automotive engine management systems, hard disk drives, PC BIOS software for Plug & Play, digital TV, set top boxes, fax and other modems, PC cards and multimedia CD-ROMs, offer the prospect of very high volume demand.

Universal Asynchronous Receiver/Transmitter

Das U-Boot -- the Universal Boot Loader (see U-Boot_overview)

Linux® is a registered trademark of Linus Torvalds.

Microprocessor Unit

First Stage Boot Loader

Second Stage Boot Loader

Firmware Image Package is a packaging format used by TF-A

Flash memory shortened to gain space in titles, tables and block diagrams

SD memory card (https://www.sdcard.org)

MultimediaCard

GUID Partition Table

Embedded Display Port (VESA standard). See http://www.displayport.org/ for more details

Read Only Memory

Trusted Firmware for Arm® Cortex®-A

Random Access Memory (Early computer memories generally hadserial access. Memories where any given address can be accessed when desired were then called "random access" to distinguish them from the memories where contents can only be accessed in a fixed order. The term is used today for volatile random-acces ssemiconductor memories.)

Trusted Execution Environment

Cortex®

One Time Programmed

Secure Secret Provisioning

Secure secrets provisioning

Power Management Integrated Circuit

Non Volatile Memory, like a flash memory

Device Firmware Upgrade

Memory Technology Device

Unsorted block images

Elliptic curve cryptography

Error Correction Capability

Doubledata rate (memory domain)

Logical Block Addressing

Secure digital

Original Equipment Manufacturer

Boot Loader stage 2

Open Portable Trusted Execution Environment

Flash memories combine high density and cost effectiveness of EPROMs with the electrical erasability of EEPROMs. For this reason, the Flash memory market is one of the most exciting areas of the semiconductor industry today and new applications requiring in system reprogramming, such as cellular telephones, automotive engine management systems, hard disk drives, PC BIOS software for Plug & Play, digital TV, set top boxes, fax and other modems, PC cards and multimedia CD-ROMs, offer the prospect of very high volume demand.

Universal Asynchronous Receiver/Transmitter

Das U-Boot -- the Universal Boot Loader (see U-Boot_overview)

Linux® is a registered trademark of Linus Torvalds.

Microprocessor Unit

First Stage Boot Loader

Second Stage Boot Loader

Firmware Image Package is a packaging format used by TF-A

Flash memory shortened to gain space in titles, tables and block diagrams

SD memory card (https://www.sdcard.org)

MultimediaCard

GUID Partition Table

Embedded Display Port (VESA standard). See http://www.displayport.org/ for more details

Read Only Memory

Trusted Firmware for Arm® Cortex®-A

Random Access Memory (Early computer memories generally hadserial access. Memories where any given address can be accessed when desired were then called "random access" to distinguish them from the memories where contents can only be accessed in a fixed order. The term is used today for volatile random-acces ssemiconductor memories.)

Trusted Execution Environment

Cortex®

One Time Programmed

Secure Secret Provisioning

Secure secrets provisioning

Power Management Integrated Circuit

Non Volatile Memory, like a flash memory

Device Firmware Upgrade

Memory Technology Device

Unsorted block images

Elliptic curve cryptography

Error Correction Capability

Doubledata rate (memory domain)

Logical Block Addressing

Secure digital

Original Equipment Manufacturer

Boot Loader stage 2

Open Portable Trusted Execution Environment

Video Electronics Standards Association

Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. Arm logo.png

Retrieved from "https://wiki.stmicroelectronics.cn/stm32mpu-ecosystem-v3/index.php?title=STM32CubeProgrammer_flashlayout&oldid=80793"