Difference between revisions of "STM32MP15 Flash mapping"

[quality revision] [quality revision]
m (eMMC memory mapping)
m (Flash partitions)
 


1 Supported Flash memory technologies[edit]

The STM32MP15 boards support different kind the following types of Flash memoriesmemory:

  • SD card on the SDMMC interface that is present on EVAL and DISCO boards.
  • e•MMC on the SDMMC interface that is present on EVAL board only.
  • Serial NOR Flash memory on the Dual QSPI interface , that is present on EVAL board only.
  • NAND Flash memory on the FMC interface , that is present on EVAL board only.

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

2 Flash partitions[edit]

The tables below list the partitions defined for STMP32MP15 boards.

2.1 Minimal[edit]

Size Component Comment
Remaining area userfs The user file system contains user data and examples
768 MBMbytes rootfs Linux root file system contains all user space binaries (executable, libraries, and so on), and kernel modules
16 MBMbytes vendorfs This partition is preferred to the rootfs to put for third parties -party proprietary binaries, and ensure ensures that they are not contaminated by any open source licence, such as GPL v3
64 MBMbytes bootfs
or
boot (NAND)
The boot file system contains:
  • (option) the init ram RAM file system, that 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 but the except for NOR: the boot loader splash screen image, displayed by U-Boot
  • U-Boot distro config file extlinux.conf (can be in a Flattened Image Tree – FIT)
2 MB ssbl The
2 * 256 Kbytes (*) env
or uboot_config / uboot_config_r (NAND)
This partition is used to store the U-Boot environment while booting from NOR Flash. The information is stored twice, for redundancy.

For all other Flash devices, the U-Boot environment is stored either in an EXT4 bootfs partition (e•MMC, SD card), or UBI volumes (NAND).

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

OpenSTLinux FIP contains:

  • the second stage boot loader (SSBL)
is
  • :
    • U-Boot
, with its
    • binary
    • U-Boot device tree blob
(dtb) appended at the end 256 KB to 512 KB
  • optionally, the OP-TEE binaries:
    • OP-TEE header
    • OP-TEE pageable code and data
    • OP-TEE pager
256 Kbytes to 512 Kbytes (*) fsbl The first stage boot loader is Arm Trusted Firmware (TF-A) or U-Boot Secondary Program Loader (SPL), with its device tree blob (dtb) appended at the end. At least two copies are embedded.

Note: due to ROM code RAM needs, the FSBL payload is limited to 247 KBKbytes.

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

Info white.png Information
Some boards can be equiped equipped with multiple flash Flash devices, like the EVAL board, and all those flashes where all of the Flash devices can be programmed with STM32CubeProgrammer. But However, caution must be taken for the serial NOR/NAND and SLC NAND because a static bootable MTD partitionningpartitioning is defined in U-Boot include/configs/stm32mp1.h (look for STM32MP_MTDPARTSdefault config (see MTD configuration for details), with the consequence that up to 6 MB Mbytes of space is lost at the beginning of each such devicesdevice, even if they those which are not bootable.

2.2 Optional[edit]

Size Component Comment
256 KB (*) env This partition is used to store U-Boot environment while booting on NOR flash. For all other flashes, U-Boot environment is stored whether in an EXT4 bootfs partition (e•MMC, SD card) or UBI volumes (NAND).
256 KB to 512 KB (*) teeh OP-TEE header
256 KB to 512 KB (*) teed OP-TEE pageable code and data
256 KB to 512 KB (*) teex OP-TEE pager

(*): the partition size depends on the Flash technology as it should be aligned on the block erase size of the flash present on the board (256 KB for NOR and 512 KB for NAND).

3 SD card memory mapping[edit]

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

SD card mapping.png

4 e•MMC memory mapping[edit]

The e•MMC 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 e•MMC with the layout shown below, and to populate each partition.

Info white.png Information
The boot area partition used by the e•MMC boot sequence is selected via the EXT_CSD[179] register that is inside in the e•MMC. The STM32CubeProgrammer execution is concluded with the selection of the last written partition from the flashlayout file, so the typically partition 2, typically. The other copy is never used as long as the user does not explicitely explicitly change the e•MMC EXT_CSD[179] register to select it.
EMMC mapping.png

5 NOR memory mapping[edit]

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

It is possible to use an e•MMC card or NAND rather than a SD card as second-level Flash memory. It requires to change:

the

, 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 The Linux kernel parameters, using U-Boot, in order to indicate where the rootfs and userfs have to be mounted.
NOR mapping.png

6 NAND memory mapping[edit]

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

NAND mapping.png
Warning white.png Warning
In the RAW/MTD area, the number of copies to embed and the number of blocks to reserve at the end of each partition, for future bad blocks replacement, are a critical part of NAND based product dimensioning !

The strategy has to take into account many parameters such as:

  • the binaries sizes,
  • the read accesses to those partitions during product life, that may generate read disturb effect,
  • the capability of the product to refresh the partitions content when erroneous bits are detected,
  • the number of software updates estimated on this partition,
  • the selected NAND flash characteristics

ST set foundations in the STM32MP15 device in order to allow the integration of NAND flash memories but the product definition remains the customer responsibility. Please, contact your memory provider for further advice.


__FORCETOC__
== Supported Flash memory technologies ==The STM32MP15 boards support different kind of Flash memories:
* SD card on SDMMC interface that is the following types of Flash memory:
* SD card on the SDMMC interface present on [[:Category:Getting started with STM32MP1 boards|EVAL and DISCO boards]].

* ''e''•MMC on the SDMMC interface that is present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.

* Serial NOR Flash memory on the Dual QSPI interface, that is  present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.

* NAND Flash memory on the FMC interface, that is  present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.
The next section lists all partitions used on STM32MP15 boards (size, name, and content), and the following sections showsshow how they are mapped on the different types of Flash memoriesmemory.

== Flash partitions ==
The tables below list the partitions defined for STMP32MP15 boards.=== Minimal ===<br>
{| class="st-table"
|-
! Size !! Component !! Comment
|-
| Remaining area || userfs || The user file system contains user data and examples
|-
| 768 MBMbytes || rootfs || Linux root file system contains all user space binaries (executable, libraries, …)and so on), and kernel modules 
|-
| 16 MBMbytes || vendorfs || This partition is preferred to the rootfs to put for third parties -party proprietary binaries, and ensureensures that they are not contaminated by any open source licence, such as GPL v3
|- 
| 64 MBMbytes || bootfs <br>or<br>boot (NAND)|| The boot file system contains:
* (option) the init ramRAM file system, thatwhich 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 but theexcept for NOR: the boot loader splash screen image, displayed by U-Boot
* [[U-Boot_overview#Generic_Distro_configuration|U-Boot distro config file ]] ''extlinux.conf (can be in a Flattened Image Tree – FIT)
|-
| 2 MB || ssbl  || The ''
|-
| 2 * 256 Kbytes (*) || env<br>or uboot_config / uboot_config_r (NAND) || This partition is used to store the U-Boot environment while booting from NOR Flash. The information is stored twice, for redundancy. <br>

For all other Flash devices, the U-Boot environment is stored either in an EXT4 bootfs partition (''e''•MMC, SD card), or UBI volumes (NAND).
|-
| 4 Mbytes || fip  || The [[TF-A_overview#FIP|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]].<br>

OpenSTLinux FIP contains:
* the second stage boot loader (SSBL) is:
** U-Boot, with its  binary
** U-Boot device tree blob(dtb) appended at the end
|-
| 256 KB to 512 KB* optionally, the OP-TEE binaries:
** OP-TEE header
** OP-TEE pageable code and data
** OP-TEE pager
|-
| 256 Kbytes to 512 Kbytes (*) || fsbl || The first stage boot loader is Arm Trusted Firmware ([[TF-A) or U-Boot Secondary Program Loader (SPL), with its device tree blob (dtb) appended at the end_overview#BL2|TF-A]]). At least two copies are embedded.<br>

Note: due to ROM code RAM needs, the FSBL payload is limited to 247 KB.
|}
(*): theKbytes.
|}
(*): The partition size depends on the flashFlash technology, to be aligned on to the block erase size of the flash Flash memory present on the board: NOR (256 KBKbytes) / NAND (512 KB)Kbytes).

{{Info | Some boards can be equipedequipped with multiple flashFlash devices, like the [[:Category:Getting started with STM32MP1 boards|EVAL board]], andwhere all those flashes of the Flash devices can be programmed with [[STM32CubeProgrammer]]. ButHowever, caution must be taken for the serial NOR/NAND and SLC NAND because a '''static bootable MTD partitionningpartitioning''' is defined in U-Boot {{CodeSource | U-Boot | include/configs/stm32mp1.h }} (look for ''STM32MP_MTDPARTS''default config (see [[How_to_configure_U-Boot_for_your_board#MTD_partitions|MTD configuration ]] for details), with the consequence that up to 6 MBMbytes of space is lost at the beginning of each such devicesdevice, '''even if theythose which are not bootable'''.}}=== Optional ===
{| class="st-table"
|-
! Size !! Component !! Comment
|-
| 256 KB (*) || env || This partition is used to store U-Boot environment while booting on NOR flash. For all other flashes, U-Boot environment is stored whether in an EXT4 bootfs partition (''e''•MMC, SD card) or UBI volumes (NAND).
{{ReviewsComments|GeraldB: size to be increased to 512 KB for the release 2.0.0, due to the redundancy}}
|-
| 256 KB to 512 KB (*) || teeh || OP-TEE header
|- 
| 256 KB to 512 KB (*) || teed || OP-TEE pageable code and data
|-
| 256 KB to 512 KB (*) || teex || OP-TEE pager
|}
(*): the partition size depends on the Flash technology as it should be aligned on the block erase size of the flash present on the board (256 KB for NOR and 512 KB for NAND).

== SD card 

== SD card memory mapping ==
The SD card has to be partitioned with GPT format in order to be recognized by the STM32MP15. The easiest way to achieve this is to use [[STM32CubeProgrammer]].<br />

The ROM code looks for the GPT entries whose the name begins with "fsbl": fsbl1 and fsbl2 for example.<br/>

Note: theThe SD card can be unplugged from the board and inserted into a Linux host computer for direct partitionningpartitioning with Linux utilities and access to the '''bootfs''', '''rootfs''' and '''userfs''' partitions. The file system is Linux EXT4.
[[Image:SD card mapping.png|center|link=]]

== ''e''•MMC memory mapping ==
The ''e''•MMC 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 ''e''•MMC with the layout shown below, and to populate each partition.
{{Info | The boot area partition used by the ''e''•MMC boot sequence is selected via the EXT_CSD[179] register that is inside in the ''e''•MMC. The [[STM32CubeProgrammer]] execution is concluded with the selection of the last written partition from the flashlayout file, so the typically partition 2, typically. The other copy is never used as long as the user does not explicitelyexplicitly change the ''e''•MMC EXT_CSD[179] register to select it.}}
[[File:eMMC mapping.png|center|link=]]

== NOR memory mapping ==As NOR Flash being memory is expensive, theirits size is usually limited to the minimum, allowing needed to store only the bootloaders. The system files (bootfs, rootfs and userfs) are usually stored in another Flash  memory: like , such as the SD card in OpenSTLinux distribution.<br /> [[STM32CubeProgrammer]] has to must be used to prepare the NOR Flash and the SD card with the layout shown below, and to populate each partition.<br /><br>

It is possible to use an ''e''•MMC card or NAND rather than a SD card as second level Flash memory. It requires to change:
* the 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
* theThe Linux kernel parameters, using [[U-Boot overview|U-Boot]], in order to indicate where the rootfs and userfs have to be mounted.

[[File:NOR mapping.png|center|link=]]

== NAND memory mapping ==
[[STM32CubeProgrammer]] has to be used to prepare the NAND Flash memory with the layout shown below, and to populate each partition.<br />

[[File:NAND mapping.png|center|link=]]{{Warning|In the '''RAW/MTD area''', the number of copies to embed and the number of blocks to reserve at the end of each partition, for future bad blocks replacement, are a critical part of NAND based product dimensioning !<br>

The strategy has to take into account many parameters such as:
* the binaries sizes,
* the read accesses to those partitions during product life, that may generate read disturb effect,
* the capability of the product to refresh the partitions content when erroneous bits are detected,
* the number of software updates estimated on this partition,
* the selected NAND flash characteristics
ST set foundations in the STM32MP15 device in order to allow the integration of NAND flash memories but the product definition remains the customer responsibility. Please, contact your memory provider for further advice.}}<noinclude>

[[Category:STM32MP15 platform configuration|1]]
{{PublicationRequestId | unknown | 2018-02-02 |BrunoB 14615 | 2020-01-15 |}}</noinclude>
(28 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
__FORCETOC__
 
__FORCETOC__
  +
 
== Supported Flash memory technologies ==
 
== Supported Flash memory technologies ==
The STM32MP15 boards support different kind of Flash memories:
+
STM32MP15 boards support the following types of Flash memory:
* SD card on SDMMC interface that is present on [[:Category:Getting started with STM32MP1 boards|EVAL and DISCO boards]].
+
* SD card on the SDMMC interface present on [[:Category:Getting started with STM32MP1 boards|EVAL and DISCO boards]]
* ''e''•MMC on SDMMC interface that is present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.
+
* ''e''•MMC on the SDMMC interface present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only
* Serial NOR Flash on Dual QSPI interface, that is present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.
+
* Serial NOR Flash memory on the Dual QSPI interface present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only
* NAND Flash on FMC interface, that is present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.
+
* NAND Flash memory on the FMC interface present on [[:Category:Getting started with STM32MP1 boards|EVAL board]] only.
The next section lists all partitions used on STM32MP15 boards (size, name, content) and the following sections shows how they are mapped on the different types of Flash memories.
+
The next section lists all partitions used on STM32MP15 boards (size, name, and content), and the following sections show how they are mapped on the different types of Flash memory.
   
 
== Flash partitions ==
 
== Flash partitions ==
 
The tables below list the partitions defined for STMP32MP15 boards.
 
The tables below list the partitions defined for STMP32MP15 boards.
=== Minimal ===
+
<br>
 
{| class="st-table"
 
{| class="st-table"
 
|-
 
|-
Line 17: Line 18:
 
| Remaining area || userfs || The user file system contains user data and examples
 
| Remaining area || userfs || The user file system contains user data and examples
 
|-
 
|-
| 768 MB || rootfs || Linux root file system contains all user space binaries (executable, libraries, ) and kernel modules  
+
| 768 Mbytes || rootfs || Linux root file system contains all user space binaries (executable, libraries, and so on), and kernel modules  
 
|-
 
|-
| 16 MB || vendorfs || This partition is preferred to the rootfs to put third parties proprietary binaries and ensure that they are not contaminated by any open source licence, such as GPL v3
+
| 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 MB || bootfs || The boot file system contains:
+
| 64 Mbytes || bootfs<br>or<br>boot (NAND)|| The boot file system contains:
* (option) the init ram file system, that can be copied to the external RAM and used by Linux before mounting a fatter rootfs
+
* (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 device tree (can be in a Flattened Image Tree - FIT)
 
* Linux kernel U-Boot image (can be in a Flattened Image Tree - FIT)
 
* Linux kernel U-Boot image (can be in a Flattened Image Tree - FIT)
* For all flashes but the NOR: the boot loader splash screen image, displayed by U-Boot
+
* For all flashes except for NOR: the boot loader splash screen image, displayed by U-Boot
* U-Boot distro config file extlinux.conf (can be in a Flattened Image Tree – FIT)
+
* [[U-Boot_overview#Generic_Distro_configuration|U-Boot distro config file]] ''extlinux.conf''
|-
 
| 2 MB || ssbl  || The second stage boot loader (SSBL) is U-Boot, with its device tree blob (dtb) appended at the end
 
|-
 
| 256 KB to 512 KB (*) || fsbl || The first stage boot loader is Arm Trusted Firmware (TF-A) or U-Boot Secondary Program Loader (SPL), with its device tree blob (dtb) appended at the end. At least two copies are embedded.<br>
 
Note: due to ROM code RAM needs, FSBL payload is limited to 247 KB.
 
|}
 
(*): the partition size depends on the flash technology, to be aligned on block erase size of the flash present on the board: NOR (256 KB) / NAND (512 KB)
 
{{Info | Some boards can be equiped with multiple flash devices, like the [[:Category:Getting started with STM32MP1 boards|EVAL board]], and all those flashes can be programmed with [[STM32CubeProgrammer]]. But caution must be taken for the serial NOR/NAND and SLC NAND because a '''static bootable MTD partitionning''' is defined in U-Boot {{CodeSource | U-Boot | include/configs/stm32mp1.h }} (look for ''STM32MP_MTDPARTS''), with the consequence that up to 6 MB of space is lost at the beginning of such devices, '''even if they are not bootable'''.}}
 
=== Optional ===
 
{| class="st-table"
 
|-
 
! Size !! Component !! Comment
 
 
|-
 
|-
| 256 KB (*) || env || This partition is used to store U-Boot environment while booting on NOR flash. For all other flashes, U-Boot environment is stored whether in an EXT4 bootfs partition (''e''•MMC, SD card) or UBI volumes (NAND).
+
| 2 * 256 Kbytes (*) || env<br>or uboot_config / uboot_config_r (NAND) || This partition is used to store the U-Boot environment while booting from NOR Flash. The information is stored twice, for redundancy. <br>
{{ReviewsComments|GeraldB: size to be increased to 512 KB for the release 2.0.0, due to the redundancy}}
+
For all other Flash devices, the U-Boot environment is stored either in an EXT4 bootfs partition (''e''•MMC, SD card), or UBI volumes (NAND).
 
|-
 
|-
| 256 KB to 512 KB (*) || teeh || OP-TEE header
+
| 4 Mbytes || fip  || The [[TF-A_overview#FIP|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]].<br>
|-  
+
OpenSTLinux FIP contains:
| 256 KB to 512 KB (*) || teed || OP-TEE pageable code and data
+
* the second stage boot loader (SSBL):
  +
** U-Boot binary
  +
** U-Boot device tree blob
  +
* optionally, the OP-TEE binaries:
  +
** OP-TEE header
  +
** OP-TEE pageable code and data
  +
** OP-TEE pager
 
|-
 
|-
| 256 KB to 512 KB (*) || teex || OP-TEE pager
+
| 256 Kbytes to 512 Kbytes (*) || fsbl || The first stage boot loader is Arm Trusted Firmware ([[TF-A_overview#BL2|TF-A]]). At least two copies are embedded.<br>
  +
Note: due to ROM code RAM needs, the FSBL payload is limited to 247 Kbytes.
 
|}
 
|}
(*): the partition size depends on the Flash technology as it should be aligned on the block erase size of the flash present on the board (256 KB for NOR and 512 KB for NAND).
+
(*): 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).
  +
{{Info | Some boards can be equipped with multiple Flash devices, like the [[:Category:Getting started with STM32MP1 boards|EVAL board]], where all of the Flash devices can be programmed with [[STM32CubeProgrammer]]. However, caution must be taken for the serial NOR/NAND and SLC NAND because a '''static bootable MTD partitioning''' is defined in U-Boot default config (see [[How_to_configure_U-Boot_for_your_board#MTD_partitions|MTD configuration ]] for details), with the consequence that up to 6 Mbytes of space is lost at the beginning of each such device, '''even those which are not bootable'''.}}
   
 
== SD card memory mapping ==
 
== SD card memory mapping ==
The SD card has to be partitioned with GPT format to be recognized by STM32MP15. The easiest way to achieve this is to use [[STM32CubeProgrammer]].<br />
+
The SD card has to be partitioned with GPT format in order to be recognized by the STM32MP15. The easiest way to achieve this is to use [[STM32CubeProgrammer]].<br />
The ROM code looks for the GPT entries whose the name begins with "fsbl": fsbl1 and fsbl2 for example.<br/>
+
The ROM code looks for the GPT entries whose name begins with "fsbl": fsbl1 and fsbl2 for example.<br/>
Note: the SD card can be unplugged from the board and inserted into a Linux host computer for direct partitionning with Linux utilities and access to the '''bootfs''', '''rootfs''' and '''userfs''' partitions. The file system is Linux EXT4.
+
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.
 
[[Image:SD card mapping.png|center|link=]]
 
[[Image:SD card mapping.png|center|link=]]
   
 
== ''e''•MMC memory mapping ==
 
== ''e''•MMC memory mapping ==
 
The ''e''•MMC embeds four physical partitions:
 
The ''e''•MMC embeds four physical partitions:
* Boot area partition 1: one copy of the FSBL.
+
* Boot area partition 1: one copy of the FSBL
* Boot area partition 2: 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.
+
* 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.
 
* 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 ''e''•MMC with the layout shown below and to populate each partition.
+
[[STM32CubeProgrammer]] has to be used to prepare the ''e''•MMC with the layout shown below, and to populate each partition.
{{Info | The boot area partition used by the ''e''•MMC boot sequence is selected via the EXT_CSD[179] register that is inside the ''e''•MMC. The [[STM32CubeProgrammer]] execution is concluded with the selection of the last written partition from the flashlayout file, so the partition 2, typically. The other copy is never used as long as the user does not explicitely change the ''e''•MMC EXT_CSD[179] register to select it.}}
+
{{Info | The boot area partition used by the ''e''•MMC boot sequence is selected via the EXT_CSD[179] register in the ''e''•MMC. The [[STM32CubeProgrammer]] execution is concluded with the selection of the last written partition from the flashlayout file, typically partition 2. The other copy is never used as long as the user does not explicitly change the ''e''•MMC EXT_CSD[179] register to select it.}}
 
[[File:eMMC mapping.png|center|link=]]
 
[[File:eMMC mapping.png|center|link=]]
   
 
== NOR memory mapping ==
 
== NOR memory mapping ==
NOR Flash being expensive, their size is usually limited to the minimum, allowing to store only the bootloaders. The system files (bootfs, rootfs and userfs) are usually stored in another Flash  memory: like the SD card in OpenSTLinux distribution.<br /> [[STM32CubeProgrammer]] has to be used to prepare the NOR Flash and the SD card with the layout shown below and to populate each partition.<br /><br>
+
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.<br /> [[STM32CubeProgrammer]] must be used to prepare the NOR Flash and the SD card with the layout shown below, and to populate each partition.<br /><br>
It is possible to use an ''e''•MMC card or NAND rather than a SD card as second level Flash memory. It requires to change:
+
It is possible to use an ''e''•MMC 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 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 overview|U-Boot]], in order to indicate where the rootfs and userfs have to be mounted
+
* The Linux kernel parameters, using [[U-Boot overview|U-Boot]], in order to indicate where the rootfs and userfs have to be mounted.
 
[[File:NOR mapping.png|center|link=]]
 
[[File:NOR mapping.png|center|link=]]
   
 
== NAND memory mapping ==
 
== NAND memory mapping ==
[[STM32CubeProgrammer]] has to be used to prepare the NAND Flash with the layout shown below, and to populate each partition.<br />
+
[[STM32CubeProgrammer]] has to be used to prepare the NAND Flash memory with the layout shown below, and to populate each partition.<br />
 
[[File:NAND mapping.png|center|link=]]
 
[[File:NAND mapping.png|center|link=]]
  +
{{Warning|In the '''RAW/MTD area''', the number of copies to embed and the number of blocks to reserve at the end of each partition, for future bad blocks replacement, are a critical part of NAND based product dimensioning !<br>
  +
The strategy has to take into account many parameters such as:
  +
* the binaries sizes,
  +
* the read accesses to those partitions during product life, that may generate read disturb effect,
  +
* the capability of the product to refresh the partitions content when erroneous bits are detected,
  +
* the number of software updates estimated on this partition,
  +
* the selected NAND flash characteristics
  +
ST set foundations in the STM32MP15 device in order to allow the integration of NAND flash memories but the product definition remains the customer responsibility. Please, contact your memory provider for further advice.}}
 
<noinclude>
 
<noinclude>
 
[[Category:STM32MP15 platform configuration|1]]
 
[[Category:STM32MP15 platform configuration|1]]
{{PublicationRequestId | unknown | 2018-02-02 |BrunoB }}
+
{{PublicationRequestId | 14615 | 2020-01-15 |}}
 
</noinclude>
 
</noinclude>