Difference between revisions of "STM32CubeProgrammer flashlayout"

[quality revision] [quality revision]
m
 
m
 

Template:ArticleMainWriter Template:ArticleApprovedVersion

Contents

1 Article purpose[edit]

Here will be explained This article describes the FlashLayout file format.

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

  1. define the flash Flash memory partitions (see STM32MP15_Flash_mapping)
  2. select the files used to boot (see Boot chains 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 Flash memory.
It This is done by the stm32prog command in U-Boot. This command is automatically performed executed for USB boot, but a serial boot (on USB or UART). However you can start launch it manually in U-boot console.

In the next chapter we

describe the #FlashLayout

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 and SSBL definitions can be found in the Boot chains chain overview.

2 FlashLayout file format[edit]

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

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

The last column "Binary" last column is not used by U-Boot but . 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 of columns in the editor, they . They are ignored by STM32CubeProgrammer and by U-Boot.

Empty field is fields are not allowed; the . The FlashLayout file format supports the none reserved word 'none'.

2.1 Examples[edit]

Some Below some valid FlashLayout files are:

#opt	Id	Name	Type		Device	Offset		Binary
P	0x01	fsbl1	Binary		mmc0	0x00004400	fsbl.stm32
P	0x02	fsbl2	Binary		mmc0	0x00044400	fsbl.stm32
P	0x03	ssbl	Binary		mmc0	0x00084400	ssbl.stm32
P	0x10	bootfs	System		mmc0	0x00284400	bootfs.ext4.bin
P	0x11	rootfs	FileSystem	mmc0	0x08284400	rootfs.ext4.bin
PE	0x12	userfs	FileSystem	mmc0	0x28284400	none

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

-	0x01	fsbl_boot	Binary		none	0x0	fsbl.stm32
-	0x03	ssbl_boot	Binary		none	0x0	ssbl.stm32
P	0x32	sdcard		RawImage	mmc0	0x0	sdcard.bin

2.2 Field1: Options[edit]

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

  • '-' : none option = , the partition or the device is not modified (mandatory for 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 Flash device.
On the block devices (SD card or eMMC e•MMC), the GPT partitioning is performed if all partitions of the device are selected with 'P'.
For the 'P' caseoption, 2 two optional modifiers can be added:
  • 'E' : Empty partition or device, update will is not be requested (associated "Id" is skipped)
  • 'D' : Delete partition or device

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

  • '-'  : do nothing no action
  • 'P'  : update = program the partition or the flash device
  • 'PE'  : do not update (also 'EP'{{HighlightParam|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]

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

  • ROM code and FSBL: binary loaded in RAM
  • SSBL = (U-Boot): binary populated in flashFlash memory

The FlashLayout supported ranges are :

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

The Id 0x01 and 0x03 are reserved respectively for FSBL and SSBL, respectively. They are loaded in RAM by ROM code and by FSBL.

2.3.1 Reserved Id[edit]

For information, the The reserved values are the following:

Code Partition
0x00 FlashLayout (used internally, cannot be used in FlashLayout file)
0x01 FSBL (first copy) : used by ROM code (load in RAM)
0x03 SSBL : used by FSBL=TF-A (load in RAM)
0xF1 to 0xFD "virtual partition": used internally
0xF1 Command GetPhase
0xF2 OTP
0xF3 SSP
0xF4 PMIC NVM
0xFE End of operation
0xFF Reset

2.3.2 Using Id for boot partition[edit]

In normal use case, the The same FSBL and SSBL binaries are can be loaded in RAM and programmed in flash; we are using the Flash memory. Then a simple mapping is used:

Code Partition
0x01 (reserved) FSBL (first copy)
0x02 (default) FSBL (second copy)
0x03 (reserved) SSBL

But However, in the FlashLayout file, any other Id < lower than 0x10 (boot partition with STM32 header) can identify the FSBL and SSBL binaries to be programmed in flashFlash memory.
It allows to have enables having different binaries loaded in RAM and programed programmed in flashFlash memory, for example when an updated feature is deactivated in the binaries to be flashed programmed in flashFlash memory.

Then you You can then use the boot partitions : (see example in #Load and program different binaries)

Code Partition
0x01 (reserved) FSBL to boot :
load
loaded by ROM code
0x03 (reserved) SSBL to boot : loaded by FSBL
0x02 FSBL to program in
flash
Flash memory (first copy)
0x04 FSBL to program in
flash
Flash memory (second copy)
0x05 SSBL to program in
flash
Flash memory

This behavior is needed for the STM32 MPU boot chain with Trusted Firmware-A (TF-A) as FSBL and U-Boot as SSBL; The used mapping is:

Code File Description
0x01 (reserved) tf-a-serialboot.stm32 FSBL to boot : TF-A with serial load support
0x03 (reserved) u-boot.stm32 SSBL to boot and to program
0x02 tf-a.stm32 FSBL to program: first copy
0x04 tf-a.stm32 FSBL to program: second copy

2.4 Field3: Name[edit]

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

It This is also the name of the #GPT partition of block deviceBlock device GPT partition: SD card / eMMC e•MMC.

Requirements The requirements for these the GPT partition names partitions are:

  • FSBL for SD card boot: need to the name must start with '"fsbl'"= fsbl, fsbl1, fsbl2... (ROM code requirement)
  • SSBL for eMMC e•MMC/SD card boot: need to be 'ssbl' the name must be "ssbl" (TF-A requirement)
These 2
  • 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"
  • a partition named "rootfs", see specific behavior described in #GPT partuuid of rootfs partition.

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

2.5 Field4: Type[edit]

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

The supported values are:

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

2.5.1 Block device GPT partition of block device: SD card / eMMC e•MMC[edit]

See Refer to GPT standard for details . [43].

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

  • Binary Binary : raw data / linux reserved
    (GUID = 8DA63339-0007-60C0-C436-083AC8230908)
  • FileSystem FileSystem : Linux filesystem data
    (GUID = 0FC63DAF-8483-4772-8E79-3D69D8477DE4)
    ext2/ext4/fat file system
  • System System : it is a 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 'P' (full update).

2.5.2 MTD partition of raw flash devices: Raw Flash device (NAND/NOR Flash memories) MTD partition[edit]

The supported values are:

  • Binary: raw data, skip bad block (partition erase is not needed)
  • Binary(N): raw data, skip bad block and the . The loaded binary is repeated N times.
    it It is only supported for NAND and it Flash memories. It is used to avoid disturbance in disturbances during the first boot stage (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 block blocks following the last data in the MTD partition to avoid mount errors.

2.5.3 Hardware device[edit]

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

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

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

2.5.4 RAM device (DDR)[edit]

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]

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
eMMC
  • 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
or
  • .
  • spi-nand + instance : spi-nand0
    It is used for serial NAND Flash memories on
QUADSPI
  • QSPI.
  • none for partition only used to load the binary programming service in RAM
it
  • It is allowed only for the reserved
boot
  • bootloaders partition (FSBL=0x1 and SSBL=0x3
; in
  • ). In this case, the only allowed fields
are 
  • 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]

Supported The supported values are:

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

See Refer to #Partition sizes for offset constraints.

2.8 Field7: Binary[edit]

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 by option 'E'. For the with the E option. In all other cases, this file is sent to U-Boot to update the flash Flash memory only for the partitions selected partitions ( with option 'P').

2.9

the P option.

2.9 GPT partuuid of rootfs partition[edit]

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]

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 '-';.
to To update ssbl partttionpartition:

-	0x01	fsbl1	Binary		mmc0	0x00004400	fsbl.stm32
-	0x02	fsbl2	Binary		mmc0	0x00044400	fsbl.stm32
P	0x03	ssbl	Binary		mmc0	0x00084400	ssbl.stm32
-	0x10	bootfs	System		mmc0	0x00284400	bootfs.ext4.bin
-	0x11	rootfs	FileSystem	mmc0	0x08284400	rootfs.ext4.bin
-	0x12	userfs	FileSystem	mmc0	0x28284400	userfs.ext4.bin

To delete only delete one partition, add the DE option 'DE' on the needed corresponding line;.
To delete ssbl partttionpartition:

-	0x01	fsbl1	Binary		mmc0	0x00004400	fsbl.stm32
-	0x02	fsbl2	Binary		mmc0	0x00044400	fsbl.stm32
PDE	0x03	ssbl	Binary		mmc0	0x00084400	ssbl.stm32
-	0x10	bootfs	System		mmc0	0x00284400	bootfs.ext4.bin
-	0x11	rootfs	FileSystem	mmc0	0x08284400	rootfs.ext4.bin
-	0x12	userfs	FileSystem	mmc0	0x28284400	userfs.ext4.bin

2.1011 Partition sizes[edit]

Each partition continues until the next one on the device The partitions are contiguous (no holes in the flashFlash memory).
The last partition continue continues until the end of the selected flash Flash memory.

To reduce the size of the last partition, you can use an 'Empty' partition which will be 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 (eMMC e•MMC or SD card)
  • predefined partitioning for MTD devices (NOR and NAND): see mtdparts environment variable in U-Boot for more information.

If you have a In case of partition size error, you need to compare the existing partition size in U-Boot with the offset in the FlashLayout file.

2.1011.1 GPT partition sizes[edit]

Each GPT partition needs to must be aligned on to:

  • 512 bytes (LBA)
  • eMMC e•MMC erase group sizethe

The first partition

start

starts after

17kB

17 Kbytes (default size of GPT header for 128 entries in U-Boot)

For partition updates .

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:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	type:	data
	guid:	8ef917d1-2c6f-4bd0-a5b2-331a19f91cb2
  2	0x00000222	0x00000421	"fsbl2"
	attrs:	0x0000000000000000
	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	type:	data
	guid:	77877125-add0-4374-9e60-02cb591c9737
  3	0x00000422	0x00001821	"ssbl"
	attrs:	0x0000000000000000
	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
	type:	data
	guid:	b4b84b8a-04e3-48ae-8536-aff5c9c495b1
  4	0x00001822	0x00021821	"bootfs"
	attrs:	0x0000000000000004
	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
	type:	linux
	guid:	35219908-c613-4b08-9322-3391ff571e19
  5	0x00021822	0x00029821	"vendorfs"
	attrs:	0x0000000000000000
	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
	type:	linux
	guid:	8e123a33-e3d3-4db9-92f4-d3ebd9b3224f
  6	0x00029822	0x001a9821	"rootfs"
	attrs:	0x0000000000000000
	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
	type:	linux
	guid:	02a90af2-5d1c-4a29-9177-97a513e3cae4
  7	0x001a9822	0x003a9fdc	"userfs"
	attrs:	0x0000000000000000
	type:	0fc63daf-8483-4772-8e79-3d69d8477de4
	type:	linux
	guid:	3d5088db-a534-413e-836d-c757cb682814

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

To check the eMMC e•MMC erase group size in U-Boot, you need to 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 SDMMC2
 Manufacturer ID: 11
 OEM: 100
 Name: 004G6 
 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

2.1011.2 MTD Partition partition sizes[edit]

Each MTD partition needs to must be aligned on 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 ). Execute the U-Boot command mtparts to known the current value, for example when NOR and NAND are supported: mtdparts

SF: Detected mx25l51235f with page size 256 Bytes, erase size 64 KiB, total 64 MiB device nor0 <nor0>, # parts = 5 #: name size offset mask_flags 0: fsbl1 0x00040000 0x00000000 0 1: fsbl2 0x00040000 0x00040000 0 2: ssbl 0x00200000 0x00080000 0 3: logo 0x00040000 0x00280000 0 4: nor_user 0x03d40000 0x002c0000 0 device nand0 <nand0>, # parts = 4 #: name size offset mask_flags 0: fsbl 0x00200000 0x00000000 0 1: ssbl1 0x00200000 0x00200000 0 2: ssbl2 0x00200000 0x00400000 0 3: UBI 0x3fa00000 0x00600000 0 active partition: nor0,0 - (fsbl1) 0x00040000 @ 0x00000000 defaults: mtdids  : nor0=nor0,nand0=nand0 mtdparts: mtdparts=nor0:

with the ST configs:

  • 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(
logo
  • teeh),
-(nor_user);nand0:
  • 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: u-

(UBI)

The last partition on nor, boot, 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 MTD MTP partitioning on NOR and NAND Flash memories, you need to update this variable in update these configurations in your U-Boot defconfig as explained in U-Boot or override this behavior in your board.

3 Typical FlashLayout file[edit]

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

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

In the examplenext examples, we are using the trusted 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
  • SSBL = u-boot.stm32

But it is the same for the basic boot chain with the files:

  • FSBL = u-boot-spl.stm32
    • (TF-A with STM32CubeProgrammer support)
    • FSBL to program = tf-a.stm32 (TF-A without OP-TEE support)
  • SSBL = u-boot.imgstm32

3.1 NOR Flash memory and SD card[edit]

NOR Flash memory in RAW: Bootloaders=FSBL uses 2 copies , containing the bootloaders. It uses two copies for FSBL (for failsafe update) and one copy for SSBL.
SD card using GPT: several user EXT4 partitions.

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

The PartId 0x20 is empty/free deleted in nor0, no logo is providedthe U-Boot environment is cleared.

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

3.2 NOR and NAND[edit]

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

Opt Part Name Type Device Offset Binary
P 0x01 fsbl1 Binary nor0 0x0 tf-a.stm32
P 0x02 fsbl2 Binary nor0 0x40000 tf-a.stm32
P 0x03 ssbl Binary nor0 0x80000 u-boot.stm32
PE 0x20 logo Binary nor0 0x280000 none
PE 0x21 unused Binary nor0 0x2C0000 none
P 0x10 UBI FileSystem nand0 0x0 ubi.bin

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

Warning: for compatility with NAND-only use case and U-Boot configuration, on ST board, the offset of UBI in nand0 is set to 0x00600000

3.3 NAND

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

The partition named "rootfs" has a specific PARTUUID.

3.2 NAND Flash memory[edit]

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

3.3.1

FSBL

:RAW & SSBL:UBI[edit]

FSBL (TF-A) uses 2 two RAW copies to avoid NAND disturbance in Flash memory disturbances inside one partition.

SSBL (U-Boot) is present in a RAW volume of the UBI partition.
The binary is also present in FlashLayout file to be loaded in RAM (Opt='-', Part=0x3, Device='none'). 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, boot, rootfs, vendorfs, and userfs.

For parallel NAND, the MTD device is nand0:

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

Warning: need to change the MTD partitioning in U-Boot.

3.3.2 FSBL+SSBL:RAW[edit]

FSBL (TF-A) uses 2 copy to avoid NAND disturbance and in two partitions (for failsafe update).

SSBL (U-Boot) uses 2 copy in 2 partitions (and not in a UBI volume).

One MTD partition for UBI with several volumes: boot, rootfs and userfs.

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

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

3.4 eMMC3 e•MMC[edit]

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

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

The userfs partition is other partitions are pre-populated with ext4 partition.

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

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.

3.4 SD card[edit]

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

The other partitions are pre-populated with ext4 partition.

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

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 Typical FlashLayout file with TEE[edit]

In this chapter, we described This chapter describes the Layout file with TEE partitions for the trusted typical boot use case based on STM32MP15_Flash_mapping.

The Since TF-A binary for OPTEE does not have yet programmer support STM32CubeProgrammer, so we are using 2 two different FSBL binaries are used:

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

4.1 NOR Flash memory and SD card with TEE[edit]

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
PE
PED 0x20
logo
env Binary nor0 0x280000 none
P 0x05 teeh Binary nor0
0x002C0000
0x00300000 tee-header.stm32
P 0x06 teed Binary nor0
0x00300000
0x00340000 tee-
pageablee
pageable.stm32
P 0x07 teex Binary nor0
0x00340000
0x00380000 tee-pager.stm32
PE 0x21 unused Binary nor0
0x380000
0x400000 none
P 0x10 bootfs System mmc0 0x00004400 bootfs.ext4
.bin
P 0x11 vendorfs FileSystem mmc0 0x04284400 vendorfs.ext4
.bin
P 0x12 rootfs FileSystem mmc0 0x05284400 rootfs.ext4
.bin
P 0x13 userfs FileSystem mmc0 0x35284400 userfs.ext4
.bin

4.2 NOR and NAND Flash memory with TEE[edit]

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)
nor0
nand0 0x0 tf-a-optee.stm32
P
0x04
0x03
fsbl2
ssbl1 Binary
nor0
nand0
0x40000
0x200000
tf
u-
a-optee
boot.stm32
P
0x03
0x04
ssbl
ssbl2 Binary
nor0
nand0
0x80000
0x400000 u-boot.stm32
PE 0x20 logo Binary nor0 0x280000 none
P 0x05 teeh Binary
nor0
nand0
0x002C0000
0x600000 tee-header.stm32
P 0x06 teed Binary
nor0
nand0
0x00300000
0x680000 tee-
pageablee
pageable.stm32
P 0x07 teex Binary
nor0
nand0
0x00340000
0x700000 tee-pager.stm32
PE 0x21 unused Binary nor0 0x380000 none
P 0x10 UBI FileSystem nand0
0x0
0x780000 ubi.bin

4.3 NAND with TEE[edit]

4.3.1 FSBL:RAW & SSBL:UBI with TEE[edit]
Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a.stm32
P 0x02 fsbl Binary(2) nand0 0x0 tf-a-optee.stm32
- 0x03 ssbl Binary none 0x0 u-boot.stm32
P 0x10 UBI FileSystem nand0 0x00200000 ubi.bin
4.3.2 FSBL+SSBL:RAW with TEE[edit]

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

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
0x05P
0x02 fsbl1 Binary(2) spi-nand0 0x0 tf-a-optee.stm32
P
0x04 fsbl2 Binary(2) nand0 0x100000 tf-a-optee..stm32
0x03 ssbl1 Binary spi-nand0 0x200000 u-boot.
bin
stm32
P
0x02
0x04 ssbl2 Binary spi-nand0 0x400000 u-boot.
bin
stm32
P
0x06
0x05 teeh Binary spi-nand0 0x600000 tee-header.stm32
P
0x07
0x06 teed Binary spi-nand0 0x680000 tee-pageable.stm32
P
0x08
0x07 teex Binary spi-nand0 0x700000 tee-pager.stm32
P 0x10 UBI FileSystem spi-nand0 0x780000 ubi.bin

4.4 eMMC 3 e•MMC with TEE[edit]

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
P
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
.bin
P 0x12 rootfs FileSytem mmc1 0x05400000 rootfs.ext4
.bin
P 0x13 userfs FileSytem mmc1 0x35400000 userfs.ext4
.bin

4.54 SD card with TEE[edit]

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

5 FlashLayout file to load and start kernel[edit]

Load programming service with Device=none.

bin 5

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

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a-serialboot.stm32
- 0x03 ssbl Binary none 0x0 u-boot.stm32
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.

6 Using provided FlashLayout files[edit]

The binary and the associated pre-defined FlashLayout file files are provided by ST in the Discovery kit.

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

#Opt	Id	Name		Type	IP	Device	Offset		Binary
P-	0x01	fsbl1-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157f-ev1-serialboot.stm32
-	0x03	ssbl-boot	Binary	none	0x0	bootloader/u-boot-stm32mp157f-ev1-trusted.stm32
P	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp15cstm32mp157f-ev1-trusted.stm32
P	0x020x05	fsbl2		Binary		mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp15cstm32mp157f-ev1-trusted.stm32
PPD	0x030x06	ssbl		Binary		mmc0	0x00084400	bootloader/u-boot-stm32mp15cstm32mp157f-ev1-trusted.stm32
P	0x100x21	bootfs		System		mmc0	0x002944000x00284400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P	0x110x22	vendorfs	FileSystem	mmc0	0x002944000x04284400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P	0x120x23	rootfs		FileSystem	mmc0	0x022944000x05284400	st-image-coreweston-openstlinux-weston-stm32mp1.ext4
P	0x130x24	userfs		FileSystem	mmc0	0x222958000x33C84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

You can use these FlashLayout files as a starting point for your operation by and simply modify the filethem:

56.1 Update Updating partitions[edit]

To update one partitiononly some partitions, you change the FlashLayout and only "select" the partitions that you want need to updatebe updated:
Options field inside the FlashLayout is kept to 'P' for partition(s) you want to update, other are change to '-'. Then you can 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 fsbl1-boot Binary none 0x0 arm-trusted-firmware/tf-a-stm32mp157f-ev1-serialboot.stm32
- 0x03 ssbl-boot Binary none 0x0 bootloader/u-boot-stm32mp157f-ev1-trusted.stm32
- 0x04 fsbl1 Binary mmc0 0x00004400 arm-trusted-firmware/tf-a-
stm32mp15c
stm32mp15f-ev1-trusted.stm32
-
0x02
0x05 fsbl2 Binary mmc0 0x00044400 arm-trusted-firmware/tf-a-
stm32mp15c
stm32mp15f-ev1-trusted.stm32
P
PD
0x03
0x06 ssbl Binary mmc0 0x00084400 bootloader/ u-boot-
stm32mp15c
stm32mp15f-ev1-trusted.stm32
P 0x10 bootfs System mmc0
0x00304400
0x00284400 st-image-bootfs-openstlinux-weston-stm32mp1.ext4
- 0x11 vendorfs FileSystem mmc0
0x04304400
0x04284400 st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
- 0x12 rootfs FileSystem mmc0
0x05304400
0x05284400 st-image-core-openstlinux-weston-stm32mp1.ext4
- 0x13 userfs FileSystem mmc0
0x35304400
0x33C84400 st-image-userfs-openstlinux-weston-stm32mp1.ext4

The associated text file becomes :

#Opt	Id	Name		Type	IP	Device	Offset		Binary
-	0x01	fsbl1-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp157f-ev1-serialboot.stm32
-	0x03	ssbl-boot	Binary	none	0x0	bootloader/u-boot-stm32mp157f-ev1-trusted.stm32
-	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp15cstm32mp157f-ev1-trusted.stm32
-	0x020x05	fsbl2		Binary		mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp15cstm32mp157f-ev1-trusted.stm32
PPD	0x030x06	ssbl		Binary		mmc0	0x00084400	bootloader/u-boot-stm32mp15cstm32mp157f-ev1-trusted.stm32
P	0x100x21	bootfs		System		mmc0	0x002944000x00284400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
-	0x110x22	vendorfs	FileSystem	mmc0	0x002944000x04284400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
-	0x120x23	rootfs		FileSystem	mmc0	0x022944000x05284400	st-image-coreweston-openstlinux-weston-stm32mp1.ext4
-	0x130x24	userfs		FileSystem	mmc0	0x222958000x33C84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

56.2 Update Updating partitions with using official ST bootloaders[edit]

If bootloader, FSBL or SSBL , are modified, and the STM32CubeProgrammer support is lost for any reason (for example if the stm32prog command stm32prog is removed for exmaple),
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 flashFlash, 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
fsbl1-boot Binary none 0x0 arm-trusted-firmware/tf-a-
stm32mp15c
stm32mp157f-ev1-
trusted
serialboot.stm32
- 0x03 ssbl-boot Binary none 0x0 bootloader/u-boot-
stm32mp15c
stm32mp157f-ev1-trusted.stm32
P
0x02
0x04
fsbl2
fsbl1 Binary mmc0 0x00004400 <Customer-tf-a>.stm32
P
0x04
0x05
fsbl1
fsbl2 Binary mmc0 0x00044400 <Customer-tf-a>.stm32
P
PD
0x05
0x06 ssbl Binary mmc0 0x00084400 <Customer-u-boot>.stm32
P 0x10 bootfs System mmc0
0x00304400
0x00284400 st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P 0x11 vendorfs FileSystem mmc0
0x04304400
0x04284400 st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P 0x12 rootfs FileSystem mmc0
0x05304400
0x05284400 st-image-core-openstlinux-weston-stm32mp1.ext4
P 0x13 userfs FileSystem mmc0
0x35304400
0x33C84400 st-image-userfs-openstlinux-weston-stm32mp1.ext4

The associated text file becomes :

#Opt	Id	Name		Type	IP	Device	Offset		Binary
-	0x01	fsbl1-boot		Binary		none	0x0		arm-trusted-firmware/tf-a-stm32mp15cstm32mp157f-ev1-trustedserialboot.stm32
-	0x03	ssbl-boot		Binary		none	0x0		bootloader/u-boot-stm32mp15cstm32mp157f-ev1-trusted.stm32
P	0x020x04	fsbl1		Binary		mmc0	0x00004400	tf-a.stm32
P	0x040x05	fsbl2		Binary		mmc0	0x00044400	tf-a.stm32
PPD	0x050x06	ssbl		Binary		mmc0	0x00084400	u-boot.stm32
P	0x100x21	bootfs		System		mmc0	0x002944000x00284400	st-image-bootfs-openstlinux-weston-stm32mp1.ext4
P	0x110x22	vendorfs	SystemFileSystem		mmc0	0x002944000x04284400	st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
P	0x120x23	rootfs		FileSystem	mmc0	0x022944000x05284400	st-image-coreweston-openstlinux-weston-stm32mp1.ext4
P	0x130x24	userfs		FileSystem	mmc0	0x222958000x33C84400	st-image-userfs-openstlinux-weston-stm32mp1.ext4

6 7 Other FlashLayout examples[edit]

6.1 SD card 7.1 NOR and NAND Flash memories[edit]

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

Opt Part Name Type Device Offset Binary
P 0x01 fsbl1 Binary nor0 0x0 tf-a.stm32
P 0x02 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 UBI FileSystem nand0 0x0 ubi.bin

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

Or with TEE support:

Opt Part Name Type Device Offset Binary
- 0x01 fsbl Binary none 0x0 tf-a.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
PE 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 0x003C0000 tee-pager.stm32
PE 0x21 unused Binary nor0 0x400000 none
P 0x10 UBI FileSystem nand0 0x0 ubi.bin

7.2 NAND with SSBL in UBI[edit]

FSBL (TF-A) uses two partitions (for failsafe update), with two copies in each partition .

SSBL (U-Boot) is present in a RAW volume of the UBI partition.
The binary is also present in FlashLayout file to be loaded in RAM (Opt=-, Part=0x3, Device=none).

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

As it is not the ST default configuration, the MTD partitioning must be changed in U-Boot.

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 0x04 fsbl Binary(2) nand0 0x00100000 tf-a.stm32
- 0x03 ssbl Binary none 0x0 u-boot.stm32
P 0x10 UBI FileSystem nand0 0x00200000 ubi.bin

For OPT-TEE support, program tf-a-optee.stm32 with OP-TEE support and add the needed optee UBI volumes: teeh, teed, teex.

Warning: UBI is not supported in TFA

7.3 SD card: FAT[edit]

Example 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
P 0x01 fsbl1 Binary mmc0 0x0 tf-a.stm32
P 0x02 fsbl2 Binary mmc0 0x40000 tf-a.stm32
P 0x03 ssbl Binary mmc0 0x80000 u-boot.stm32
P 0x10 bootfs System mmc0 0x200000 bootfs.vfat
.bin
PED 0x11 userfs Empty mmc0 0x400000 none

67.24 Load and program different binaries[edit]

Same example as above with the 2 first two partitions (name named "2boot"): they are . They are not programmed and only loaded in RAM, not programmed.

Userfs is empty but not deleted.

Opt Part Name Type Device Offset Binary
- 0x01 fsbl2boot Binary none 0x0 tf-a2boot.stm32
- 0x03 ssbl2boot Binary none 0x0 u-boot2boot.stm32
P 0x02 fsbl1 Binary mmc0 0x40000 tf-a.stm32
P 0x04 fsbl2 Binary mmc0 0x0 tf-a.stm32
P 0x05 ssbl Binary mmc0 0x80000 u-boot.stm32
P 0x10 rootfs System mmc0 0x200000 rootfs.vfat
.bin
PE 0x11 userfs FileSytem mmc0 0x400000 none

67.3 RAWImage5 RawImage[edit]

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 Binary none 0x0 tf-a.stm32
- 0x03 ssbl Binary none 0x0 u-boot.stm32
P 0x10 sdcard RawImage mmc0 0x0 image.sdcard

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

6.4 Delete content of devices7.6 Deleting device content[edit]

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

Opt Part Name Type Device Offset Binary
- 0x01 fsbl none none 0x0 tf-a.stm32
- 0x03 ssbl none none 0x0 u-boot.stm32
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 of eMMC, useproceed as follows:

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

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

#Opt	Id	Name		Type		Device	Offset		Binary
-	0x01	fsbl_boot	Binary		none	0x0		fsbl.stm32
-	0x03	ssbl_boot	Binary		none	0x0		ssbl.stm32
#delete ALL devices
EPD	0x10	sdcard		RawImage	mmc0	0x0		none
PED	0x02	emmc_b1		Binary		mmc1	boot1		none
PED	0x04	emmc_b2		Binary		mmc1	boot2		none
PED	0x20	emmc		RawImage	mmc1	0x0		none
PED	0x30	nand		RawImage	nand0	0x0		none
# on NOR (slow device): delete ALL used partitions
PE	0x40	nor		RawImage	nor0	0x0		none
PED	0x41	fsbl1_nor	Binary		nor0	0x00000000	none
PED	0x42	fsbl2_nor	Binary		nor0	0x00040000	none
PED	0x43	ssbl_nor	Binary		nor0	0x00080000	none
PED	0x44	logoenv_nor	Binary		nor0	0x00280000	none
PE	0x45	unused		Binary		nor0	0x002C0000	none

67.57 Complex use case[edit]

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

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

Opt Part Name Type Device Offset Binary
P 0x01 fsbl1 Binary mmc0 0x04400 tf-a.stm32
P 0x02 fsbl2 Binary mmc0 0x44400 tf-a.stm32
P 0x03 ssbl Binary mmc0 0x84400 u-boot.stm32
P 0x10 bootfs System mmc0 0x284400 bootfs.stm32
P 0x11 rootfs FileSytem mmc0 0x08284400 rootfs.ext4
.bin
DEP 0x12 userfs FileSytem mmc0 0x28284400 none
PED 0x60 emmc_boot1 Binary
mmc0
mmc1 boot1 none
DPE 0x61 emmc_boot2 Binary
mmc0
mmc1 boot2 none
EPD 0x62 emmc RawImage
mmc0
mmc1 0x0 none
D 0x10 nand RawImage nand0 0x0 none

7 8 Reference list[