General MTD documentation
Table of contents
MTD overview
MTD subsystem (stands for Memory Technology Devices) provides an abstraction layer for raw flash devices. It makes it possible to use the same API when working with different flash types and technologies, e.g. NAND, OneNAND, NOR, AG-AND, ECC'd NOR, etc.
MTD subsystem does not deal with block devices like MMC, eMMC, SD, CompactFlash, etc. These devices are not raw flashes but they have a Flash Translation layer inside, which makes them look like block devices. These devices are the subject of the Linux block subsystem, not MTD. Please, refer to this FAQ section for a short list of the main differences between block and MTD devices. And the raw flash vs. FTL devices UBIFS section discusses this in more details.
MTD subsystem has the following interfaces.
- MTD character devices - usually referred to as
/dev/mtd0,/dev/mtd1, and so on. These character devices provide I/O access to the raw flash. They support a number ofioctlcalls for erasing eraseblocks, marking them as bad or checking if an eraseblock is bad, getting information about MTD devices, etc. - The
sysfsinterface is relatively newer and it provides full information about each MTD device in the system. This interface is easily extensible and developers are encouraged to use thesysfsinterface instead of olderioctlor/proc/mtdinterfaces, when possible. - The
/proc/mtdproc file system file provides general MTD information. This is a legacy interface and the sysfs interface provides more information.
MTD subsystem supports bare NAND flashes with software and hardware ECC, OneNAND flashes, CFI (Common Flash Interface) NOR flashes, and other flash types.
Additionally, MTD supports legacy FTL/NFTL "translation layers",
M-Systems' DiskOnChip 2000 and Millennium chips, and PCMCIA flashes
(pcmciamtd driver). But the corresponding drivers are very old and
not maintained very much.
MTD tests
The MTD subsystem includes a set of tests which you may run to verify your
flash hardware and drivers. The tests are available in the mainline kernels
starting from kernel version 2.6.29 and they live in the
drivers/mtd/tests directory of the linux kernel source codes. You
may compile the tests as kernel modules by enabling them in the kernel
configuration menu by marking: "Device Drivers" ->
"Memory Technology Device (MTD) support" -> "MTD tests support" (or
the MTD_TESTS symbol in the .config file).
If you have a pre-2.6.29 kernel, you may find the tests
here:
git://git.infradead.org/users/ahunter/nand-tests.git
The MTD test-suite contains the following tests:
- mtd_speedtest: measures and reports read/write/erase speed of the MTD device.
- mtd_stresstest: performs random read/write/erase operations and validates the MTD device I/O capabilities.
- mtd_readtest: this tests reads whole MTD device, one NAND page at a time including OOB (or 512 bytes at a time in case of flashes like NOR) and checks that reading works properly.
- mtd_pagetest: relevant only for NAND flashes, tests NAND page writing and reading in different sizes and order; this test was originally developed for testing the OneNAND driver, so it might be a little OneNAND-oriented, but must work on any NAND flash.
- mtd_oobtest: relevant only for NAND flashes, tests that the OOB area I/O works properly by writing data to different offsets and verifying it.
- mtd_subpagetest: relevant only for NAND flashes, tests sub-page I/O.
- mtd_torturetest: this test is designed to wear out flash
eraseblocks. It repeatedly writes and erases the same group of
eraseblocks until an I/O error happens, so be careful! The test
supports a number of options (see
modinfo mtd_torturetest) which allow you to set the amount of eraseblocks to torture and how the torturing is done. You may limit the amount of torturing cycles using thecycles_countmodule parameter. It may be very god idea to run this test for some time and validate your flash driver and HW, providing you have a spare device. For example, we caught rather rare and nasty DMA issues on an OMAP2 board with OneNAND flash, just by running this tests for few hours.
The mtdblock driver
The mtdblock driver available in the MTD is an archaic tool
which emulates block devices on top of MTD devices. It does not even have
bad eraseblock handling, so it is not really usable with NAND flashes. And it
works by caching a whole flash erase block in RAM, modifying it as requested,
then erasing the whole block and writing back the modified. This means that
mtdblock does not try to do any optimizations, and that you will
lose lots of data in case of power cuts. And last, but not least,
mtdblock does not do any wear-leveling.
Often people consider mtdblock as general FTL layer and try to
use block-based file systems on top of bare flashes using
mtdblock. This is wrong in most cases.
In other words, please, do not use mtdblock unless you
know exactly what you are doing.
There is also a read-only version of this driver which doesn't have the capacity to do the caching and erase/writeback, mainly for use with uCLinux where the extra RAM requirement was considered too large.
Old MTD documentation
Old MTD web site and old MTD documentation is available here. Old NAND flash interface description is available here.