Last edited 6 days ago

STM32 MPU Flash mapping


This article shows the mapping used in STM32 MPU Embedded Software distribution for ST boards, that can be used as starting point for other boards.


1. Supported Flash memory technologies[edit | edit source]

STM32MP1 series and STM32MP2 series support the different types of Flash memory. The bullets below show which interfaces are supported on STMicroelectronics boards:

  • SD card on the SDMMC interface
  • eMMC on the SDMMC interface
  • NAND Flash memory on the FMC interface
  • Serial NOR Flash memory on the Dual QSPI/OCTOSPI interface
  • Serial NAND Flash memory on the Dual QSPI/OCTOSPI interface
  • not present on ST boards
  • HyperFlash memory on the OCTOSPI interface
  • not present on ST boards

The next section lists all partitions used on STM32MPU boards (size, name, and content), and the following sections show how they are mapped on the different types of Flash memory.

2. Flash partitions[edit | edit source]

2.1. STMP32MP1 and STM32MP2 boards in A35-TD flavor More info green.png[edit | edit source]

The tables below list the partitions defined for STMP32MP1 and STM32MP2 boards in A35-TD flavor More info green.png and gives typical sizes with OpenSTLinux, that can be tuned, depending on the targeted application needs.

Size Component Comment
Remaining area userfs The user file system contains user data and examples
768 Mbytes rootfs Linux root file system contains all user space binaries (executable, libraries, and so on), and kernel modules
16 Mbytes vendorfs This partition is preferred to the rootfs for third-party proprietary binaries, and ensures that they are not contaminated by any open source licence, such as GPL v3
64 Mbytes bootfs
or
boot (NAND)
The boot file system contains:
  • (option) the init RAM file system, which can be copied to the external RAM and used by Linux before mounting a fatter rootfs
  • Linux kernel device tree (can be in a Flattened Image Tree - FIT)
  • Linux kernel U-Boot image (can be in a Flattened Image Tree - FIT)
  • For all flashes except for NOR: the boot loader splash screen image, displayed by U-Boot
  • U-Boot distro config file extlinux.conf
2 * 256 Kbytes (*) u-boot-env
or uboot_config / uboot_config_r (NAND)
This partition is used to store the U-Boot environment.
uboot_config_r is used for redundancy management with uboot_config, in NAND Flash.
(2 *) 4 Mbytes fip The TF-A firmware image package (FIP) is a binary file that encapsulates several binaries, and their certificates (optionally, for authentication), that will be loaded by TF-A BL2.

OpenSTLinux FIP contains:

  • the second stage boot loader (SSBL):
    • U-Boot binary
    • U-Boot device tree blob
  • the OP-TEE binary
  • the firmware configuration file used by TF-A BL2

There are two partitions, fip-a and fip-b, when A/B (seamless) FIP firmware update is activated in TF-A BL2.

256 Kbytes to 512 Kbytes (*) metadata Metadata are used by TF-A BL2 to localize the FIP version to use, when the FIP is subject to firmware update.

Notes:

  • The metadata are not used when the FIP firmware update is not activated in TF-A BL2; these partitions can be removed or left empty in this case.
  • The metadata update is failsafe against power loss during the FIP update process with two copies.
2 * 256 Kbytes to 512 Kbytes (*) fsbla The first stage boot loader is Arm Trusted Firmware (TF-A). At least two copies are embedded (fsbla1, fsbla2).

Notes:

  • The FSBL-A payload is limited to 128 Kbytes on STM32MP13 and 247 Kbytes on STM32MP15 and STM32MP2.
  • The FSBL-A programming is failsafe against power loss during the process with two copies (see ROM code page for details).

(*): The partition size depends on the Flash technology, to be aligned to the block erase size of the Flash memory present on the board: NOR (256 Kbytes) / NAND (512 Kbytes).

2.2. STM32MP2 boards in M33-TD flavor More info green.png[edit | edit source]

The tables below list the partitions defined for STM32MP2 boards in M33-TD flavor More info green.png and gives typical sizes with OpenSTLinux, that can be tuned, depending on the targeted application needs.

Size Component Comment
Remaining area userfs The user file system contains user data and examples
768 Mbytes rootfs Linux root file system contains all user space binaries (executable, libraries, and so on), and kernel modules
16 Mbytes vendorfs This partition is preferred to the rootfs for third-party proprietary binaries, and ensures that they are not contaminated by any open source licence, such as GPL v3
64 Mbytes bootfs
or
boot (NAND)
The boot file system contains:
  • (option) the init RAM file system, which can be copied to the external RAM and used by Linux before mounting a fatter rootfs
  • Linux kernel device tree (can be in a Flattened Image Tree - FIT)
  • Linux kernel U-Boot image (can be in a Flattened Image Tree - FIT)
  • For all flashes except for NOR: the boot loader splash screen image, displayed by U-Boot
  • U-Boot distro config file extlinux.conf
2 * 256 Kbytes (*) u-boot-env
or uboot_config / uboot_config_r (NAND)
This partition is used to store the U-Boot environment.
uboot_config_r is used for redundancy management with uboot_config, in NAND Flash.
(2 *) 4 Mbytes fip The TF-A firmware image package (FIP) is a binary file that encapsulates several binaries, and their certificates (optionally, for authentication), that will be loaded by TF-A BL2.

OpenSTLinux FIP contains:

  • the second stage boot loader (SSBL):
    • U-Boot binary
    • U-Boot device tree blob
  • the OP-TEE binary
  • the firmware configuration file used by TF-A BL2

There are two partitions, fip-a and fip-b, when A/B (seamless) FIP firmware update is activated in TF-A BL2.

256 Kbytes to 512 Kbytes (*) metadata Metadata are used by TF-A BL2 to localize the FIP version to use, when the FIP is subject to firmware update.

Notes:

  • The metadata are not used when the FIP firmware update is not activated in TF-A BL2; these partitions can be removed or left empty in this case.
  • The metadata update is failsafe against power loss during the FIP update process with two copies.
2 * 256 Kbytes to 512 Kbytes (*) fsbla The first stage boot loader is Arm Trusted Firmware (TF-A). At least two copies are embedded (fsbla1, fsbla2).

Notes:

  • The FSBL-A payload is limited to 128 Kbytes on STM32MP13 and 247 Kbytes on STM32MP15 and STM32MP2.
  • The FSBL-A programming is failsafe against power loss during the process with two copies (see ROM code page for details).
2 * 9 Mbytes m33fw The Cortex-M33 firmware (including secure and non-secure) required to start the Fw-ST-M exosystem. At least two copies are embedded (m33fw-a, m33fw-b) to allow update firmware management.

The content of the partition is linked to the MCUboot packaging and includes;

2 * 256 Kbytes to 512 Kbytes (*) m33ddr The DDR firmware required to manage the DDR training. At least two copies are embedded (m33ddr-a, m33ddr-b).
2 * 256 Kbytes to 512 Kbytes (*) fsblm The first stage boot loader is (MCUboot). At least two copies are embedded (fsblm1, fsblm2).

Notes:

  • The FSBL-M payload is limited to 128 Kbytes on STM32MP2.
  • The FSBL-M programming is failsafe against power loss during the process with two copies (see ROM code page for details).

(*): The partition size depends on the Flash technology, to be aligned to the block erase size of the Flash memory present on the board: NOR (256 Kbytes) / NAND (512 Kbytes).

3. STMP32MP1 and STM32MP2 boards in A35-TD flavor More info green.png[edit | edit source]

3.1. SD card memory mapping[edit | edit source]

The SD card has to be partitioned with GPT format in order to be recognized by the STM32MP1 and STM32MP2 ROM code. The easiest way to achieve this is to use STM32CubeProgrammer.
The ROM code looks for the GPT entries whose name begins with "fsbl": fsbl1 and fsbl2 for example.
Note: The SD card can be unplugged from the board and inserted into a Linux host computer for direct partitioning with Linux utilities and access to the bootfs, rootfs and userfs partitions. The file system is Linux EXT4.


SD card mapping.png

3.2. eMMC memory mapping[edit | edit source]

The eMMC embeds four physical partitions:

  • Boot area partition 1: one copy of the FSBL
  • Boot area partition 2: one copy of the FSBL
  • User data area: formatted with GPT partitioning and used to store all remaining partitions
  • Replay Protected Memory Block (RPMB): not shown in the figure below, since not involved in the current boot chain.

STM32CubeProgrammer has to be used to prepare the eMMC with the layout shown below, and to populate each partition.

EMMC mapping.png

3.3. NOR memory mapping[edit | edit source]

As NOR Flash memory is expensive, its size is usually limited to the minimum needed to store only the bootloaders. The system files (bootfs, rootfs and userfs) are usually stored in another Flash memory, such as the SD card in OpenSTLinux distribution.
STM32CubeProgrammer must be used to prepare the NOR Flash and the SD card with the layout shown below, and to populate each partition.

NOR mapping.png

It is possible to use an eMMC card or NAND as second-level Flash memory, rather than an SD card. This requires the following aspects to be changed:

  • The Flash memory layout, using STM32CubeProgrammer in order to write the rootfs and userfs to the targeted Flash memory
  • The Linux kernel parameters, using U-Boot, in order to indicate where the rootfs and userfs have to be mounted.

3.4. NAND memory mapping[edit | edit source]

STM32CubeProgrammer has to be used to prepare the NAND Flash memory with the layout shown below, and to populate each partition.

NAND mapping.png

4. STM32MP2 boards in M33-TD flavor More info green.png[edit | edit source]

Using STM32MP2 series in M33-TD flavor More info green.png, the memory mapping depends on the STM32_MPU_ROM_code_overview#Boot_device_selection_on_STM32MP2_seriessupported boot device configuration:

  • Dual boot storage device: Each Arm® Cortex® core uses its own an dedicated storage.
  • Single boot storage device: All the boot images are stored in a single storage which remains used by the Arm® Cortex®-A (secondary boot core).

4.1. SD card memory mapping[edit | edit source]

4.1.1. Dual boot storage (Used a dedicated storage by Arm® Cortex®-A)[edit | edit source]

The SD card is used as dedicated storage device for the OpenSTLinux. It only embeds the Arm® Cortex®-A images, same as the A35-TD flavor More info green.png. In that case, another device is required for the Arm® Cortex®-M images.

SD card mapping.png

4.1.2. Single boot storage[edit | edit source]

The SD card is used as boot storage for both Arm® Cortex®-A and Arm® Cortex®-M images. It embeds the boot images for both core and the filesystem for OpenSTLinux ecosystem.

SD card mapping M33TD.png

4.2. eMMC memory mapping[edit | edit source]

4.2.1. Dual boot storage (Used as dedicated storage by Arm® Cortex®-A)[edit | edit source]

The eMMC is used as dedicated storage device for the OpenSTLinu. It only embeds the Arm® Cortex®-A images. It uses the same partitions as defined in the A35-TD flavor More info green.png. In that case, another device is required for the Arm® Cortex®-M images.

EMMC mapping.png

4.2.2. Single boot storage[edit | edit source]

The eMMC is used as boot storage for both Arm® Cortex®-A and Arm® Cortex®-M images. It embeds the boot images for both core and the filesystem for OpenSTLinux ecosystem.

Due to boot partitions in eMMC, the FSBL-M will be located in that partitions as they are used by the ROM code as primary image to boot the ARM Cortex-M33.

EMMC mapping M33TD.png

4.3. NOR memory mapping[edit | edit source]

NOR device is recommended as boot device using M33-TD flavor More info green.png.

When using the NOR device in a dual boot storage mode, the NOR device remains allocated to the Arm® Cortex®-M and allow the Protected Storage service to be enabled.

4.3.1. Dual boot storage (Used as dedicated storage by Arm® Cortex®-M)[edit | edit source]

The NOR is used as dedicated storage device for the FwST-M. It only embeds the Arm® Cortex®-M images and the associated partitions. A second device must be used for the other Arm® Cortex®-A images.

NOR mapping M33TD Dual.png


4.3.2. Single boot storage[edit | edit source]

As NOR Flash memory is expensive, its size is usually limited to the minimum needed to store only the bootloaders. The system files (bootfs, rootfs and userfs) are usually stored in another Flash memory, such as the SD card in OpenSTLinux distribution.
STM32CubeProgrammer must be used to prepare the NOR Flash and the SD card with the layout shown below, and to populate each partition.

NOR SD mapping M33TD.png

4.4. NAND memory mapping[edit | edit source]