some Q&A; about the Nand Flash and MTD device

Table of contents

1. Is an MTD device a block device or a char device?
2. What are the differences between flash devices and hard drives?
3. Can I mount ext2 over an MTD device?
4. What are the point() and unpoint() functions used for?
5. I keep getting errors whenever I try to write or erase to my MTD device

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.

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.

What are the differences between flash devices and hard drives?

The following table describes the differences between hard drives and flashes.

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, and this FAQ entries.

Please, do not be confused by USB sticks, MMCs 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 you 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 more. 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.

I keep getting errors whenever I try to write or erase to 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 the flash_unlock tool to unlock the MTD device(s). If you are using the MTD device as aw rite-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: