TF-A - Flash memory configuration

Revision as of 10:55, 31 March 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 a new TF-A framework. This framework support:

  • SPI NOR devices
  • SLC NAND devices
  • SPI NAND devices

The configuration is performed using the device tree mechanism that provides a hardware description of the FMC and QSPI peripheral.

The framework also requires memory devices configuration:

  • SLC NAND : Device configuration for non-ONFI devices.
  • SPI NOR/NAND : Device configuration and supported command.

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]

Flash memories use this new framework.
This framework is currently limited to the read operations.

2.1. Framework description[edit source]

<TODO>

3. Configuration[edit source]

The framework uses both configuration management, one is managed using device tree, the other part is platform code specific.

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.2. NAND Flash memory[edit source]

3.2.1. DT bindings documentation[edit source]

Refers to FMC_device_tree_configuration.

Warning white.png Warning
The algorithm choice is not manage at device tree level for TF-A. For non-ONFI memories, a hardware configuration must be done, described in Rom code Overview

.

3.2.2. DT configuration (STM32 level)[edit source]

Refers to FMC DT Configuration at STM32 level.

Warning white.png Warning
This device tree part is related to STM32 microprocessors. It must be kept as is, without being modified by the end-user.

3.2.3. DT configuration (board level)[edit source]

Refers to FMC DT Configuration at board level.

Warning white.png Warning
Only the boot device must be declared as a child node

3.2.4. DT configuration examples[edit source]

The below example shows how to configure the FMC controller when a SLC 8-bit NAND Flash memory device is connected.

&fmc {
	pinctrl-names = "default";
	pinctrl-0 = <&fmc_pins_a>;
	status = "okay";
	#address-cells = <1>;
	#size-cells = <0>;

	nand@0 {
		reg = <0>;
		nand-on-flash-bbt;
		#address-cells = <1>;
		#size-cells = <1>;
	};
};

3.2.5. Platform code configuration[edit source]

Some SLC NAND Flash memory doesn't provide the ONFI description table.
Some properties must be set into the hardware to allow TF-A framework properly read the device. STM32MP15 TF-A platform reuses the Rom Code properties to find the correct settings. This settings are parsed in a platform device function to retrieve[1]:

  • Device size (Page size/Block size)
  • ECC minimum corrected bit / 512
3.2.5.1. Platform examples[edit source]

Here is the platform defined content for a SLC NAND memory:

	device->nand_dev->ecc.mode = NAND_ECC_HW;         --> Default settings
	device->nand_dev->ecc.size = SZ_512;              --> ECC default correction size

	return get_data_from_otp(device->nand_dev, true); --> Other settings are read from OTP

3.3. QUADSPI NOR/NAND Flash memory[edit source]

3.3.1. DT bindings documentation[edit source]

Please refer to the QUADSPI_device_tree_configuration.

3.4. DT configuration (STM32 level)[edit source]

Refers to QUADSPI DT Configuration at STM32 level.

Warning white.png Warning
This device tree part is related to STM32 microprocessors. It must be kept as is, without being modified by the end-user.

3.5. DT configuration (board level)[edit source]

Refers to QUADSPI DT Configuration at board level.

Warning white.png Warning
Only the boot device must be declared as a child node

3.6. DT configuration examples[edit source]

The below example shows how to configure the QUADSPI peripheral when 1 SPI-NAND Flash memory is connected and used as boot device.

&qspi {
	pinctrl-names = "default";
	pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a &qspi_bk2_pins_a>;
	reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

       flash0: mt29f2g01abagd@0 {
           compatible = "spi-nand";
           reg = <0>;
           spi-rx-bus-width = <4>;
           spi-tx-bus-width = <4>;
           spi-max-frequency = <133000000>;
           #address-cells = <1>;
           #size-cells = <1>;
       };
};

3.6.1. Platform code configuration[edit source]

Memories over SPI bus are using some specific bus parameters.

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.[1].
There are two different functions, one for NOR device, one for SPI nand devices.

Framework requires:

  • Device size
  • Read operation properties
3.6.1.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: