mtd information

Note, you can find Ukranian translation of this page by Alyona Lompar (alyona.lompar@consultant.com) here. We have not assessed the contents, though.

Table of contents

1. Is an MTD device a block device or a char device?
2. I'd like to add/change/fix information on this Web-site - how?
3. What are the differences between flash devices and block drives?
4. Can I mount ext2 over an MTD device?
5. What are the point() and unpoint() functions used for?
6. Why do I keep getting errors whenever I try to write to or erase my MTD device?
7. How do I compile the mtd-utils tree?
8. How do I report bugs?

Is an MTD device a block device or a char device?

First off, an MTD is a "Memory Technology Device", so it's just "MTD". An "MTD device" is a pleonasm. Of course, at the time of this edit (Thu Aug 4 15:36:10 PDT 2011) "MTD device" was found at least 520 times in the Linux source tree, 189 times in the mtd-utils source, and even 119 times in the source for this website...

Unix traditionally only knew block devices and character devices. Character devices were things like keyboards or mice, that you could read current data from, but couldn't be seek-ed and didn't have a size. Block devices had a fixed size and could be seek-ed. They also happened to be organized in blocks of multiple bytes, usually 512.

Flash doesn't match the description of either block or character devices. They behave similar to block device, but have differences. For example, block devices don't distinguish between write and erase operations. Therefore, a special device type to match flash characteristics was created: MTD.

So MTD is neither a block nor a char device. There are translations to use them, as if they were. But those translations are nowhere near the original, just like translated Chinese poems.

I'd like to add/change/fix information on this Web-site - how?

The sources of this Web-site are available at git://git.infradead.org/mtd-www.git. Just do your modifications and send the patch to the MTD mailing list.

What are the differences between flash devices and block drives?

The following table describes the differences between block devices and raw flashes. Note, SSD, MMC, eMMC, RS-MMC, SD, mini-SD, micro-SD, USB flash drive, CompactFlash, MemoryStick, MemoryStick Micro, and other FTL devices are block devices, not raw flash devices. Of course, hard drives are also block devices.

Block device	MTD device
Consists of sectors	Consists of eraseblocks
Sectors are small (512, 1024 bytes)	Eraseblocks are larger (typically 128KiB)
Maintains 2 main operations: read sector and write sector	Maintains 3 main operations: read from eraseblock, write to eraseblock, and erase eraseblock
Bad sectors are re-mapped and hidden by hardware (at least in modern LBA hard drives); in case of FTL devices it is the responsibility of FTL to provide this	Bad eraseblocks are not hidden and should be dealt with in software
Sectors are devoid of the wear-out property (in FTL devices it is the responsibility of FTL to provide this)	Eraseblocks wear-out and become bad and unusable after about 103 (for MLC NAND) - 105 (NOR, SLC NAND) erase cycles

So as one sees flashes (MTD devices) are somewhat more difficult to work with.

Can I mount ext2 over an MTD device?

Ext2, ext3, XFS, JFS, FAT and other "conventional" file systems work with block devices. They are designed this way. Flashes are not block devices, they are very different beasts. Please, read this, andthis FAQ entries.

Please, do not be confused by USB stick, MMC, SD, CompactFlash and other popular removable devices. Although they are also called "flash", they are not MTD devices. They are out of MTD subsystem's scope. Please, read this FAQ entry.

In order to use one of conventional file systems over an MTD device, you need a software layer which emulates a block device over the MTD device. These layers are often called Flash Translation Layers(FTLs).

There is an extremely simple FTL layer in Linux MTD subsystem - mtdblock. It emulates block devices over MTD devices. There is also an mtdblock_ro module which emulates read-only block devices. When you load this module, it creates a block device for each MTD device in the system. The block devices are then accessible via /dev/mtdblockX device nodes.

But in many cases using mtdblock is a very bad idea because what it basically does if you change any sector of your mtdblockX device, it reads the whole corresponding eraseblock into the memory, erases the eraseblock, changes the sector in RAM, and writes the whole eraseblock back. This is very straightforward. If you have a power failure when the eraseblock is being erased, you lose all the block device sectors in it. The flash will likely decay soon because you will wear few eraseblocks out - most probably those ones which contain FAT/bitmap/inode table/etc.

Unfortunately it is a rather difficult task to create a good FTL layer and nobody still managed to implement one for Linux. But now when we have UBI (see here) it is much easier to do it on top of UBI.

It makes sense to use mtdblock_ro for read-only file systems or read-only mounts. For example, one may use SquashFS as it compresses data quite well. But think twice before using mtdblock in read-write mode. And don't try to use it on NAND flash as it is does not handle bad eraseblocks.

What are the point() and unpoint() functions used for?

Mainly for NOR flash. As long as the flash is only read, it behaves just like normal memory. The read() function for NOR chips is essentially a memcpy(). For some purposes the extra memcpy() is a waste of time, so things can be optimized.

So the point() function does just that, it returns a pointer to the raw flash, so callers can operate directly on the flash.

But of course, things are a little more complicated than that. NOR flash chips can be in several different modes and only when in read mode will the above work. Therefore point() also locks the flash chip in addition to returning a pointer. And while locked, writes to the same flash chips have to wait. So callers have to call unpoint() soon after to release the chip again.

Why do I keep getting errors whenever I try to write to or erase my MTD device?

Some NOR chips power on with all of the eraseblocks in a locked state. The MTD layer doesn't unlock these devices by default. If you are accessing these devices from user-space, you can use theflash_unlock tool to unlock the MTD device(s). If you are using the MTD device as a write-able root file-system you will either need to have the boot loader unlock the eraseblocks before booting the kernel, or add code to the MTD map driver for your board to unlock them.

Some chips that are known to have this behavior:

Manufacturer	Part Number
Intel	28FxxxP30
	GE28F256L30T

How do I compile the mtd-utils tree?

The MTD and UBI user-space tools are available from the the following git repository:

git://git.infradead.org/mtd-utils.git

Source tar balls of the release versions are available from the following ftp directory:

ftp://ftp.infradead.org/pub/mtd-utils/

To compile, first you have to install libraries the tools depend on. You can find the information about mkfs.jffs2 dependencies here and the the information about mkfs.ubifs dependencies here.

The mtd-utils use an autotools based build system. For the release tar balls, simply run the configure script from the mtd-utils root directory followed by make to build the mtd-utils.

If you are working on the mtd-utils git-tree, you have to generate the configure script by running the autogen.sh script first.

How do I report bugs?

First, you need to figure out what you're reporting a bug against. This website (and its accompanying mailing list) supports several related aspects of Linux, from the MTD kernel subsystem to its user-space utilities, including the generic MTD and NAND interface layers, several MTD hardware drivers, the UBI volume management system, several flash filesystems (e.g., JFFS2, UBIFS), and the user-space MTD utils.

Now, bug reports for any of the above areas are more than welcome on the MTD mailing list, provided you include sufficient information for reproducing and debugging your problem. This means:

• include all kernel 'oopses', stack traces, debug messages, or relevant logs along with a clear description of the problem you're having, what system(s) are affected, and anything else you think might help people understand your issue;
• include information about flash parameters found from "mtdinfo -a" (or the less useful info from "cat /proc/mtd");
• specify which kernel version you are using;
• specify which mtd-utils version you are using, if applicable. In past releases of mtd-utils, different tools had different versions, so be sure to check the relevant tool (e.g., use "nanddump --version" when reporting bugs involving the nanddump tool); newer releases give the same version to most/all the tools.

Please, do not send private e-mails to MTD maintainers; always CC the mailing list!

You may also want to read one of the other related FAQs:

• How do I send an UBIFS bug report?
• How do I send an UBI bug report?

The MTD community may help support the YAFFS/YAFFS2 filesystems; however, YAFFS has its own dedicated website and mailing list, and its code is not kept in the mainstream Linux kernel tree. Thus, any support you receive here will be limited, and you should contact YAFFS maintainers with real YAFFS bug reports.

连接：http://www.linux-mtd.infradead.org/faq/general.html#L_mtd_vs_hdd