Что такое mtd linux

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 of ioctl calls for erasing eraseblocks, marking them as bad or checking if an eraseblock is bad, getting information about MTD devices, etc.
• The sysfs interface 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 the sysfs interface instead of older ioctl or /proc/mtd interfaces, when possible. The sysfs interface for the mtd subsystem is documentated in the kernel, and currently can be found at Documentation/ABI/testing/sysfs-class-mtd .
• The /proc/mtd proc 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 API

The MTD subsystem API is defined in include/linux/mtd/mtd.h . The methods and data structures in this file are used by higher layer kernel code such as flash file systems to access and control the mtd devices, and also by device driver authors to interface their device to the mtd subsystem. The various methods by which a driver provides access to the device are defined within struct mtd_info . Prior to kernel version 3.4, higher layers called the driver methods directly by way of a pointer to struct mtd_info . As of kernel 3.4, these methods are implemented within the mtd subsystem core code, which then calls the corresponding driver methods. Users of kernel 3.4 and later should not call the driver methods directly, but instead use those prototyped in mtd.h outside of struct mtd_info . These methods include mtd_read() , mtd_write() , etc.

Absent an error, the API methods will return zero, with two notable exceptions. mtd_read() and mtd_read_oob() may return -EUCLEAN in some circumstances. This return code is applicable mainly to NAND flash devices, and is used to indicate that some bit errors were corrected by the device’s ECC facility. Prior to kernel version 3.4, -EUCLEAN was returned if one or more bit errors were corrected during the read operation. As of kernel 3.4, the meaning is more nuanced, and can be broadly interpreted to mean «a dangerously high number of bit errors were corrected». The -EUCLEAN return code is intended to help higher layers detect degradation of erase blocks. The conditions by which mtd_read() and mtd_read_oob() return -EUCLEAN can be tuned using the bitflip_threshold element of the sysfs interface. Please see the kernel documentation for the MTD sysfs interface (referenced above) before adjusting this value.

MTD tests

The mtd-utils include a set of test programs which you may run to verify your flash hardware and drivers. The programs have only been recently ported to user space and are also available as kernel modules.

In contrast to the modules, the user space tests also offer more fine grained options for controling their behaviour, such as only using specific erase blocks or pages.

The user space tests are compiled automatically when compiling mtd-utils, but are not installed by default. To install the tests through make install , the configure option —enable-install-tests has to be set.

The kernel module 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:

The MTD test-suite contains the following tests:

• nandbiterrs: relevant only for NAND flashes, introduces bit errors and tests for multi-bit error recovery on a NAND page. This mostly tests the ECC controller / driver. The kernel module version is called mtd_nandbiterrs.
• flash_speed: measures and reports read/write/erase speed of the MTD device. The kernel module version is called mtd_speedtest.
• flash_stress: performs random read/write/erase operations and validates the MTD device I/O capabilities. The kernel module version is called mtd_stresstest.
• flash_readtest: this tests reads from an 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. The kernel module version is called mtd_readtest.
• nandpagetest: 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. The kernel module version is called mtd_pagetest.
• mtd_oobtest: currently only exists as a kernel module. Relevant only for NAND flashes, tests that the OOB area I/O works properly by writing data to different offsets and verifying it.
• nandsubpagetest: relevant only for NAND flashes, tests sub-page I/O. The kernel module version is called mtd_subpagetest.
• flash_torture: 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! 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 kernel module version is called mtd_torturetest and also supports a number of options (see modinfo mtd_torturetest ).
• mtd_nandecctest: a simple test that checks correctness of the built-in software ECC for 256 and 512-byte buffers; this test is not driver-specific but tests general NAND support code. This tests only exists as a kernel module, as it tests the internal software ECC implementation.

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 or bit-flips handling.

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, mainly for use with uCLinux where the extra RAM requirement was considered too large. However, just like the R/W version of the driver, there is no wear-levelling and bit-flips handling.

Instead of using this old driver, you may check the R/O block device emulation provided by UBI useful. Please refer to the UBI section for more details.

Old MTD documentation

Old MTD web site and old MTD documentation is available here. Old NAND flash interface description is available here.

Источник

Русские Блоги

Введение во встроенную файловую систему (1) -Linux MTD Device File System

Введение в файловую систему

Файловая система — это метод хранения и организации компьютерных данных, который облегчает доступ к ним и их поиск.Файловая система использует абстрактную логическую концепцию файлов и древовидных каталогов вместо концепции блоков данных, используемых физическими устройствами, такими как жесткие диски и оптические диски. Пользователи используют файловую систему для сохранения данных, не заботясь о блоке данных, где данные фактически хранятся на жестком диске (или CD-ROM). Просто запомните каталог и имя файла файла. Перед записью новых данных пользователю не нужно заботиться о том, чтобы адрес блока на жестком диске не использовался.Функция управления (выделения и освобождения) дискового пространства на жестком диске автоматически выполняется файловой системой. Пользователю нужно только запомнить, в какой файл записаны данные. дюйм

Файловые системы обычно используют устройства хранения, такие как жесткие диски и оптические диски, и поддерживают физическое расположение файлов в устройстве. Однако фактически файловая система может быть только интерфейсом для доступа к данным. Фактические данные предоставляются через сетевые протоколы (такие как NFS, SMB, 9P и т. Д.) Или в памяти, и может даже не быть соответствующих файлов (таких как proc). Файловая система).

Строго говоря, файловая система — это набор абстрактных типов данных, которые реализуют такие операции, как хранение данных, иерархическая организация, доступ и получение.

2. Связь между устройствами хранения и файловыми системами

Во встроенных системах к устройствам хранения, связанным с файловой системой, относятся жесткие диски, флэш-память и т. Д. Флэш-память делится на устройство с микросхемой Flash (устройство Raw Flash, также называемое устройством MTD) и устройство с контроллером Flash (устройство уровня трансляции Flash, устройство FTL). Ключевое различие между ними заключается в том, иметь ли контроллер Flash. Он напрямую определяет, что файловая система делится на две разные категории.

карта2.1 Сравнение оборудования MTD и оборудования FTL

Среди них устройства MTD включают NOR Flash, NAND Flash и т. Д., FTL-устройства включают SD, eMMC, SSD, запоминающие устройства USB и т. Д. Как показано на рис. 2.1 и рис. 2.2, JFFS2, YAFFS2, UBIF и LogFS поддерживают устройства MTD, а FAT, EXT3 / 4, XFS и Btrfs поддерживают устройства FTL и жесткие диски (HDD). Файл устройства, соответствующий устройству MTD, представляет собой / dev / mtd, а файл устройства, соответствующий устройству FTL, может быть / dev / mtdblock.

Рисунок 2.2. Схема модуля программного обеспечения файловой системы Linux

3. MTDФайловая система устройства

3.1.1 JFFS2

JFFS расшифровывается как «Журналируемая файловая система Flash», файловая система на основе флэш-памяти, разработанная шведской компанией Axis Communications. В 1999 году компания выпустила первую версию файловой системы JFFS для GNU / Linux, а затем разработала компанию Redhat для выпуска второй версии JFFS2. JFFS2 — это файловая система с лог-структурой, которая хранит данные и необработанные данные файловой системы на флэш-памяти в виде узлов. Он в основном используется для флэш-памяти NOR-типа, основанной на уровне драйвера MTD.Особенности: чтение и запись, сжатие данных и файловая система журналирования на основе хэш-таблиц, а также обеспечивает защиту при сбое / отключении питания и «баланс записи». Поддержка и т. Д. Недостатком является то, что когда файловая система заполнена или почти заполнена, скорость работы JFFS2 сильно замедляется из-за сборки мусора.

К недостаткам JFFS2 относятся: слишком большое время монтирования, чтение и запись блока памяти чипа не сбалансированы, плохая масштабируемость. JFFS2 не подходит для флэш-памяти NAND, поскольку емкость флэш-памяти NAND, как правило, велика, что приводит к быстрому увеличению объема памяти, занимаемой JFFS2, для поддержки узлов журнала. Кроме того, файловой системе JFFS2 необходимо сканировать весь контент FLASH при подключении. Чтобы найти все узлы журнала и установить файловую структуру, потребуется много времени для флэш-памяти NAND большой емкости. Расширенная информацияhttps://www.ibm.com/developerworks/cn/linux/l-jffs2/。

3.1.2 YAFFS2

YAFFS / YAFFS2 — файловая система журналирования, разработанная для встроенных систем, использующих флэш-память типа NAND. По сравнению с JFFS2 он уменьшает некоторые функции (например, не поддерживает сжатие данных), поэтому он быстрее, время монтирования очень мало и занимает меньше памяти. Кроме того, это кроссплатформенная файловая система.

YAFFS / YAFFS2 поставляется с драйвером для чипа NAND и предоставляет API для встроенной системы для прямого доступа к файловой системе.Пользователи могут напрямую управлять файловой системой без использования MTD и VFS в Linux. Конечно, YAFFS также можно использовать с драйверами MTD. Это облегчает его кроссплатформенное портирование.

Основное различие между YAFFS и YAFFS2 заключается в том, что первый поддерживает только флэш-память NAND небольшого размера (512 байт), а последний может поддерживать флэш-память NAND большого размера (2 КБ). В то же время YAFFS2 значительно улучшился с точки зрения использования пространства памяти, скорости сбора мусора и скорости чтения / записи.

3.1.3 UBIFS

UBIFS (Unsorted Block Image File System) была первоначально разработана инженерами IBM и Nokia Томасом Гляйкснером и Артемом Битюцким в 2006 году специально для устранения узких мест, с которыми сталкиваются устройства MTD (устройства с технологией памяти). Из-за стремительной скорости NAND Flash, YAFFS и другие больше не могут контролировать пространство NAND Flash. UBIFS обрабатывает действия с устройствами MTD через подсистему UBI. Как и JFFS2, UBIFS построен на устройстве MTD и поэтому не совместим с обычными блочными устройствами.

UBIFS больше подходит для NAND Flash, чем YAFFS2 и JFFS2 с точки зрения дизайна и производительности. Например: UBIFS поддерживает обратную запись. Записанные данные кэшируются. Они не записываются во Flash до тех пор, пока не возникнет необходимость записи, что уменьшает количество разбросанных небольших блоков. И улучшить эффективность ввода / вывода. Каталог файловой системы UBIFS хранится во Flash. Монтированию UBIFS не требуется сканировать все данные Flash, чтобы воссоздать каталог файлов. Поддержка сжатых данных файлов во время полета и выборочное сжатие некоторых файлов. Кроме того, UBIFS использует журналы, которые могут уменьшить частоту обновления Flash-индекса. Дальнейшее чтениеhttps://blog.csdn.net/younger_china/article/details/12651909。

3.1.4 Резюме

Текущий основной выбор — UBIFS и YAFFS 2. Если это не система Linux, вы можете выбрать YAFFS2 с лучшей переносимостью. Конкретное сравнение показано на рисунке 3.1 и рисунке 3.2. Дальнейшее чтениеhttps://elinux.org/images/7/7e/ELC2009-FlashFS-Toshiba.pdf。

карта3.1 Сравнение файловой системы устройства MTD

карта3.2 Рекомендации по выбору файловой системы устройства MTD

Источник