TF-A - Flash memory configuration

Revision as of 09:34, 21 April 2020 by Registered User

1. Article purpose[edit source]

This article explains how to configure the QUADSPI internal peripheral and FMC internal peripheral connected to a flash device when it is assigned to the TF-A BL2. In that case, it is controlled by new TF-A frameworks:

  • SPI NOR
  • SPI NAND
  • SPI MEM
  • FMC NAND

These frameworks represents the memory access organisation.

If the peripheral is assigned to another execution context, refer to How to assign an internal peripheral to a runtime context article for guidelines on peripheral assignment and configuration.

2. Framework overview[edit source]

BL2 MTD v2.0.0.png

2.1. Components description[edit source]

  • IO_Storage

The IO storage provides an abstraction layer to access storage devices.

  • Boot device configuration

The Boot device configuration is a platform specific ad-dons to specify memory specific settings.

  • MTD core

The MTD core provides an abstraction layer for raw Flash memories.

  • Raw NAND subsystem

The Raw NAND protocol is used in the MTD subsystem for interfacing NAND Flash memories.

  • SPI-MEM subsystem

The SPI-MEM protocol is used in the MTD subsystem for interfacing all kinds of SPI memories (NORs, NANDs)

  • SPI-NAND subsystem

The SPI-NAND protocol is used in the MTD subsystem for interfacing SPI NAND Flash memories.

  • SPI-NOR subsystem

The SPI-NOR protocol is used in the MTD subsystem for interfacing SPI NOR Flash memories.

  • FMC driver / FMC (Hardware)

Please refer to the FMC internal peripheral.

  • QUADSPI driver / QUADSPI (Hardware)

Please refer to the QUADSPI internal peripheral.

3. Configuration[edit source]

These frameworks use two different configurations:

3.1. DT configuration[edit source]

This hardware description is a combination of the STM32 microprocessor device tree files (.dtsi extension) and board device tree files (.dts extension). See the Device tree for an explanation of the device tree file split.

Pinctrl device tree configuration (and optionally to Pinctrl overview) must be added in #DT configuration (board level).

TF-A shares the same bindings as Linux kernel with some device limitation.

  • TF-A device tree only allow using a single device node per controller.
  • All the properties are not used by TF-A.


STM32CubeMX can be used to generate the board device tree. Refer to How to configure the DT using STM32CubeMX for more details.

3.1.1. Raw NAND Flash memory[edit source]

For the DT bindings, refers to FMC_device_tree_configuration.

For the DT configuration (STM32 level), refers to FMC DT Configuration at STM32 level.

For the DT configuration (board level), refers to FMC DT Configuration at board level.

Warning white.png Warning
Only the required device used to load images must be declared as a child node

3.1.2. SPI NOR/NAND Flash memory[edit source]

For the DT bindings, refers to the QUADSPI_device_tree_configuration.

For the DT configuration (STM32 level), refers to QUADSPI DT Configuration at STM32 level.

For the DT configuration (board level), refers to QUADSPI DT Configuration at board level.

Warning white.png Warning
Only the required device used to load images must be declared as a child node

3.2. Device configuration[edit source]

3.2.1. Raw NAND Flash memory[edit source]

Some additional parameters are required by the raw NAND framework to address the memory:

  • Page size
  • Block size
  • Blocks number in device
  • NAND width (8 or 16 bits)
  • ECC : Supported algorithm (BCH8/BCH4/Hamming are available). The default ECC framework configuration is no error correction.

Some memories are ONFI[1] compliant. In that case, required parameters can be directly read from the parameter description table.

For the others, user must properly fill out OTP configuration.

3.2.1.1. Platform examples[edit source]
  • 8bit NAND with 4KB paged / 256KB erase size / 1024MB size, ECC BCH8
OTP Word 9 : 0xA0218000
Param in OTP Page size Block size Block numbers (N * 256) Width ECC
1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  • Raw Nand ONFI with ECC override (Default from parameter table is BCH8, force to BCH4).
OTP Word 9 : 0x8000
Param in OTP Page size Block size Block numbers (N * 256) Width ECC
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  • 16bit NAND with 2KB paged / 512KB erase size / 2048MB size, with On die ECC
OTP Word 9 : 0x90460000
Param in OTP Page size Block size Block numbers (N * 256) Width ECC
1 0 0 1 0 0 0 0 0 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

3.2.2. SPI NAND memory configuration[edit source]

Some additional parameters are required by SPI NAND and SPI MEM frameworks to address the memory:

  • Page size
  • Block size
  • Blocks number in device
  • Plane number


3.2.3. SPI NOR memory configuration[edit source]

Some additional parameters are required by SPI NAND and SPI MEM frameworks to address the memory:

  • Device size


The framework use a SPI memory framework that defined a structure to control transaction flow between controller and device.
The standard transaction mode (legacy mode) is defined inside the framework [2][3] It is also possible to override these default settings using the platform functions.
There are two different functions, one for NOR device, one for SPI nand devices.

Framework requires:

  • Device size
  • Read operation properties
3.2.3.1. Platform examples[edit source]

Here is the platform defined content for a NOR memory Quad SPI compatible:

	device->size = SZ_64M;                                --> Device size

	zeromem(&device->read_op, sizeof(struct spi_mem_op)); --> SPI read operation parameters
	device->read_op.cmd.opcode = SPI_NOR_OP_READ_1_1_4;
	device->read_op.cmd.buswidth = SPI_MEM_BUSWIDTH_1_LINE;
	device->read_op.addr.nbytes = 3U;
	device->read_op.addr.buswidth = SPI_MEM_BUSWIDTH_1_LINE;
	device->read_op.dummy.nbytes = 1U;
	device->read_op.dummy.buswidth = SPI_MEM_BUSWIDTH_1_LINE;
	device->read_op.data.buswidth = SPI_MEM_BUSWIDTH_4_LINE;
	device->read_op.data.dir = SPI_MEM_DATA_IN;

Here is the platform defined content for a nand memory Quad SPI compatible:

	zeromem(&device->spi_read_cache_op, sizeof(struct spi_mem_op)); --> SPI read operation parameters
	device->spi_read_cache_op.cmd.opcode = SPI_NAND_OP_READ_FROM_CACHE_4X;
	device->spi_read_cache_op.cmd.buswidth = SPI_MEM_BUSWIDTH_1_LINE;
	device->spi_read_cache_op.addr.nbytes = 2U;
	device->spi_read_cache_op.addr.buswidth = SPI_MEM_BUSWIDTH_1_LINE;
	device->spi_read_cache_op.dummy.nbytes = 1U;
	device->spi_read_cache_op.dummy.buswidth = SPI_MEM_BUSWIDTH_1_LINE;
	device->spi_read_cache_op.data.buswidth = SPI_MEM_BUSWIDTH_4_LINE;
	device->spi_read_cache_op.data.dir = SPI_MEM_DATA_IN;

	return get_data_from_otp(device->nand_dev, false);    --> Reuse NAND OTP settings

4. How to configure the DT using STM32CubeMX[edit source]

The STM32CubeMX tool can be used to configure the STM32MPU device and get the corresponding platform configuration device tree files.
The STM32CubeMX may not support all the properties described in the above DT bindings documentation paragraph. If so, the tool inserts user sections in the generated device tree. These sections can then be edited to add some properties and they are preserved from one generation to another. Refer to STM32CubeMX user manual for further information.

5. References[edit source]

Please refer to the following links for additional information: