The Linux® MTD (Memory Technology Device) subsystem provides an abstraction layer for raw Flash memories. It makes it possible to use the same API when working with different Flash types and technologies, e.g. SLC NAND, SPI NOR, and so on.
1. Framework purpose[edit | edit source]
The purpose of this article is to introduce the MTD Linux subsystem:
- General information
- Main components/stakeholders
- How to use the MTD API
2. System overview[edit | edit source]
2.1. On STM32MP1 series[edit | edit source]
2.2. On STM32MP2 series[edit | edit source]
2.3. Component description[edit | edit source]
- User space applications that perform file I/O need to view the Flash memory as if it was a disk, whereas programs that wish to accomplish raw I/O access the memory as if it was a character device.
- VFS (Kernel space)
Virtual File System. Please refer to the VFS documentation [1].
- mtdchar (Kernel space)
Usually referred to as /dev/mtdX. For MTD character devices, please refer to the MTD overview documentation [2].
- mtdblock (Kernel space)
Usually referred to as /dev/mtdblockX. Do not use mtdblock unless you know exactly what you are doing.
For MTD block devices, please refer to the MTD block documentation [3].
- JFFS2 (Kernel space)
Journally Flash File System. Please refer to the MTD JFFS2 documentation [4].
- UBI (Kernel space)
Unsorted Block Images. Please refer to the MTD UBI documentation [5].
- UBIFS (Kernel space)
UBI File System. Please refer to the MTD UBIFS documentation [6].
- MTD core (Kernel space)
The MTD core provides an abstraction layer for raw Flash memories.
- Raw NAND subsystem (Kernel space)
The Raw NAND protocol is used in the MTD subsystem for interfacing NAND Flash memories.
- SPI-MEM subsystem (Kernel space)
The SPI-MEM protocol is used in the MTD subsystem for interfacing all kinds of SPI memories (NORs, NANDs)
- SPI-NAND subsystem (Kernel space)
The SPI-NAND protocol is used in the MTD subsystem for interfacing SPI NAND Flash memories.
- SPI-NOR subsystem (Kernel space)
The SPI-NOR protocol is used in the MTD subsystem for interfacing SPI NOR Flash memories.
- CFI subsystem (Kernel space)
The Common Flash Interface protocol is used in the MTD subsystem for interfacing HYPERFLASH NOR Flash memories.
- FMC driver (Kernel space) / FMC (Hardware)
Please refer to the FMC internal peripheral.
- QUADSPI driver (Kernel space) / QUADSPI (Hardware)
Please refer to the QUADSPI internal peripheral.
- OCTOSPI driver (Kernel space) / OCTOSPI (Hardware)
Please refer to the OCTOSPI internal peripheral.
- HyperBus driver (Kernel space) / OCTOSPI (Hardware)
Please refer to the OCTOSPI internal peripheral.
2.4. API description[edit | edit source]
For the Linux MTD API description, please refer to the MTD API documentation [7].
3. Configuration[edit | edit source]
3.1. Kernel configuration[edit | edit source]
MTD is activated by default in ST deliveries. Nevertheless, if a specific configuration is needed, this section indicates how MTD can be activated/deactivated in the kernel.
Activate MTD in the kernel configuration with the Linux Menuconfig tool: Menuconfig or how to configure kernel.
3.1.1. SLC NAND Flash memory[edit | edit source]
Device Drivers --->
<*> Memory Technology Device (MTD) support --->
NAND --->
<*> RAW/Parallel NAND Device Support --->
<*> Support for NAND controller on STM32MP Socs.
3.1.2. SPI NOR/NAND Flash memory[edit | edit source]
Device Drivers --->
<*> Memory Technology Device (MTD) support --->
NAND --->
<*> SPI NAND device Support
<*> SPI-NOR device support
[*] SPI support --->
-*- SPI memory extension
<*> STMicroelectronics STM32 QUAD SPI controller
<*> STMicroelectronics STM32 OCTO SPI controller
3.1.3. HYPERFLASH NOR Flash memory[edit | edit source]
Device Drivers --->
<*> Memory Technology Device (MTD) support --->
RAM/ROM/Flash chip drivers --->
-*- Detect flash chips by Common Flash Interface (CFI) probe
-*- Support for CFI command set 0002 (AMD/Fujitsu/Spansion chips)
<*> HyperBus support --->
--- HyperBus support
<*> STM32 HyperBus driver
3.2. Device tree configuration[edit | edit source]
The DT configuration can be done thanks to STM32CubeMX.
3.2.1. NAND Flash memory[edit | edit source]
Please refer to the FMC device tree configuration.
3.2.2. SPI NOR/NAND Flash memory[edit | edit source]
3.2.2.1. On STM32MP1 series[edit | edit source]
Please refer to the QUADSPI device tree configuration.
3.2.2.2. On STM32MP2 series[edit | edit source]
Please refer to the OCTOSPI device tree configuration.
3.2.3. HYPERFLASH NOR Flash memory[edit | edit source]
Please refer to the OCTOSPI device tree configuration.
4. How to use the framework[edit | edit source]
A file system, which handles read/write/erase operations, can be used over the MTD Framework. Please refer to the UBIFS support through MTD.
You can also interact with the MTD subsystem using the MTD utilities. The MTD utilities[8] are a set of tools that can be used to perform operations on Flash memories through the MTD character interface.
The most common utilities used are:
- mtdinfo
- flash_erase
- flashcp
- nandwrite
- nanddump
root:~# mtdinfo -a Count of MTD devices: 9 Present MTD devices: mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7, mtd8 Sysfs interface supported: yes
mtd0 Name: fsbl Type: nand Eraseblock size: 262144 bytes, 256.0 KiB Amount of eraseblocks: 8 (2097152 bytes, 2.0 MiB) Minimum input/output unit size: 4096 bytes Sub-page size: 4096 bytes OOB size: 224 bytes Character device major/minor: 90:0 Bad blocks are allowed: true Device is writable: true
mtd1 Name: ssbl Type: nand Eraseblock size: 262144 bytes, 256.0 KiB Amount of eraseblocks: 8 (2097152 bytes, 2.0 MiB) Minimum input/output unit size: 4096 bytes Sub-page size: 4096 bytes OOB size: 224 bytes Character device major/minor: 90:2 Bad blocks are allowed: true Device is writable: true
mtd2 Name: UBI Type: nand Eraseblock size: 262144 bytes, 256.0 KiB Amount of eraseblocks: 4078 (1069023232 bytes, 1019.5 MiB) Minimum input/output unit size: 4096 bytes Sub-page size: 4096 bytes OOB size: 224 bytes Character device major/minor: 90:4 Bad blocks are allowed: true Device is writable: true
mtd3 Name: fsbl1 Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 4 (262144 bytes, 256.0 KiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:6 Bad blocks are allowed: false Device is writable: true
mtd4 Name: fsbl2 Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 4 (262144 bytes, 256.0 KiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:8 Bad blocks are allowed: false Device is writable: true
mtd5 Name: ssbl Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 32 (2097152 bytes, 2.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:10 Bad blocks are allowed: false Device is writable: true
mtd6 Name: logo Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 4 (262144 bytes, 256.0 KiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:12 Bad blocks are allowed: false Device is writable: true
mtd7 Name: nor_user Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 980 (64225280 bytes, 61.2 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:14 Bad blocks are allowed: false Device is writable: true
mtd8 Name: 58003000.qspi Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 1024 (67108864 bytes, 64.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:16 Bad blocks are allowed: false Device is writable: true
5. How to trace and debug the framework[edit | edit source]
5.1. How to monitor[edit | edit source]
The sysfs interface provides detailed information for each mtd device.
root:~# cat /sys/class/mtd/mtd0/name fsbl root:~# cat /sys/class/mtd/mtd0/type nand root:~# cat /sys/class/mtd/mtd0/erasesize 262144 root:~# cat /sys/class/mtd/mtd0/ecc_strength 8 root:~# cat /sys/class/mtd/mtd0/bad_blocks 0 root:~# cat /sys/class/mtd/mtd0/ecc_failures 0
5.2. How to trace[edit | edit source]
A detailed dynamic trace is available here How to use the kernel dynamic debug.
root:~# echo "file drivers/mtd/* +p" > /sys/kernel/debug/dynamic_debug/control
6. Source code location[edit | edit source]
The MTD framework is here .
7. To go further[edit | edit source]
Please refer to the MTD FAQs documentation [9].
8. References[edit | edit source]
Please refer to the following links for full descriptions: