分类: LINUX
2010-08-10 14:39:09
See for the official MTD Frequently Asked Questions.
How is the flash partition layout specified?
Most programmers are used to dealing with hard disks. The hard disk partition table resides in a reserved sector on the hard disk. In an IBM-PC, all system software reads the partition layout from the partition table on the disk.
If a flash device emulates a hard disk, the partition table method may still be used. For example, CompactFlash flash modules look like an IDE hard drive to the Linux kernel.
In most embedded system, the flash device is used directly with no hard disk emulation. The MTD mapping driver provides accessor functions to read and write flash memory. The mapping driver can either specify a hard-coded partition layout, read the partition layout from the kernel command line passed in from the boot loader (i.e. U-Boot), or read the partition layout from flash storage (i.e. Redboot boot loader).
Even without partition support, the MTD layer provides
access to the entire flash chip as an MTD device. With partition
support, each MTD partition will be exported as a separate MTD device.
Each device has a descriptive name which can viewed using the following
command:
cat /proc/mtd
What filesystem types are suitable for flash?
For a conventional NOR flash, the MTD block device provide a crude block device similar to a hard disk. Traditional hard drives use a 512-byte sector. The MTD block device emulates this sector layout, but there is a severe performance penalty for writes. Since most flash device sectors are >= 64KiBytes in size, updating a 512-byte sector requires a read-modify-write sequence for the entire flash sector! This kind of write is slow and causes many extra erase cycles on the flash - typically a flash sector is rated for 100K – 1 million erase cycles over the device lifetime, so it is wise to limit erase cycles.
Because of this write performance issue, the MTD block device is suitable for read-on
CRAMFS
has the advantage of compressing each 4Kbyte cluster, providing 2:1
compression. Read-write capability is possible using flash-oriented
filesystems such as JFFS2.
JFFS2 is a journaling flash filesystem
(hence the name) – the ‘2’ distinguishes JFFS2 from the JFFS filesystem,
a largely defunct predecessor. JFFS2 bypasses the block device layer
(with its associated buffer cache) and writes directly to the underlying
flash device. Naturally, JFFS2 supports both read-write and read-on
For a NAND flash, the filesystem MUST be NAND-aware because both reads and writes must implement ECC error detection/correction. The JFFS2 and YAFFS filesystems are NAND-compatible.
What is the purpose of the MTD character device?
The MTD devices come in two flavors: MTD block device drivers, and MTD character device drivers. The block devices provide a 512 bytes-per-sector layout, for use by the filesystems (HYPERLINK TO What filesystems are suitable for flash?). The character device provides a linear view of a MTD device or an MTD partition. You can read this device as you would any file. Standard UNIX utilities may be used to read the flash. Assuming MTD device 0 is the entire flash, the following command will dump the entire flash image to a file:
cat /dev/mtdchar0 > /tmp/flash.bin
Writing
the flash is different. What happens if you run the following commands
on a flash partition that already contains valid da
cat /dev/mtdchar0 < new.bin
cmp /dev/mtdchar0 new.bin
/dev/mtdchar0 new.bin differ: char n, line x
The MTD character device will write the da
MTD provides user-space applications to automate the erasing process. The following commands will correctly write the new image to flash. We assume that the flash does not support locking, or the sectors are already unlocked; otherwise the flash_unlock could be used to unlock the appropriate sectors.
flash_eraseall /dev/mtdchar0
cat /dev/mtdchar0 < new.bin
Table 1: MTD IOCTL commands
Name Description Argument
MEMGETINFO Get layout and capabilities struct mtd_info_user *
MEMERASE Erase flash blocks struct erase_info_user *
MEMLOCK Lock flash blocks to disallow changes struct erase_info_user *
MEMUNLOCK Unlock flash to allow changes struct erase_info_user *
MEMGETREGIONCOUNT Return number of erase block regions int *
MEMGETREGIONINFO struct region_info_user *
MEMWRITEOOB NAND on
MEMREADOOB NAND on
MEMSETOOBSEL NAND on
How do I access the flash from user-space applications?
If
the flash is mounted as a filesystem, the normal open/close/read/write
system calls will work (obviously write() will not function on a read-on
Otherwise, the flash may be accessed using the MTD character device (HYPERLINK TO What is the purpose of the MTD character device?)
How do I upgrade the boot loader or kernel or root filesystem?
Each
component (boot loader, kernel, root filesystem) usually has its own
MTD device partition, which can be accessed by the MTD character device.
Usually the kernel is executing instructions from RAM – although some
handheld computers do execute in flash, a.k.a. XIP (execute-in-place).
When the kernel is executing from RAM, the kernel flash partition may be
updated freely. The root filesystem is a special case – if files are
open in the root filesystem (i.e. executables) during the update,
confusion will result. Even without open files, a root JFFS2 filesystem
would get its internal da
Upgrading the root filesystem usually is done on a file-by-file basis. Sometimes it is convenient to package the upgrade as a .tar or .tar.gz archive.
How much redundancy or error recovery do I need for my upgrade procedure?
Most redundancy schemes require some support from your boot-loader. At a minimum, you should store the image in RAM or a ramdisk and verify the image before writing it into flash. The amount of redundancy needed depends on your application reliability and cost requirements. Many inexpensive Linux devices, such as the Linksys WRT54G, do not have redundant images due to cost concerns.
How should I create an empty JFFS2 partition?
As noted in the JFFS2 FAQ, the JFFS2 filesystem uses marks erased blocks with ‘cleanmarkers’. The cleanmarker was introduced to address the scenario where the device powers down during a flash block erase. If the cleanmarker or another node type is not present in the block, JFFS2 will redo the erase operation and write the cleanmarker at the beginning of the block.
The ‘-j’ option to the flash_eraseall command
inserts the cleanmarker at the beginning of each block, so that the
JFFS2 won’t redo the erase operation.
How much overhead space does JFFS2 use for its own book-keeping?
JFFS2 requires five spare erase blocks to implement garbage collection. On a two bit-per-cell device such as Intel StrataFlash or Spansion MirrorBit, the erase block size is 128KiB, so the wasted space is more than half a megabyte.
The spare erase blocks requirements are defined in fs/jffs2/nodelist.h. The JFFS2_RESERVED_BLOCK_BASE parameter is 3 by default. If you change this value to 1, you’ll save two erase blocks. If you change this value, you should do some stress testing to verify nothing was broken – the default has been left at 3 to maximize reliability.
Should I provide any options when I mount a JFFS2 filesystem?
A
useful mount option for a read-write JFFS2 filesystem is ‘noatime’. The
‘noatime’ option turns off the updating of file access times, which
would cause a flash write every time a file is read. If the filesystem
is the root filesystem, the option can be supplied on
1) Pass the following parameter to the kernel command line:
rootflags=noatime
2) Remount the root filesystem with the noatime option:
mount –t jffs2 –o remount,noatime /dev/mtdblock3 /
Is flash chip X supported?
Most NOR flash chips are supported. In the old JEDEC drivers, you had to add an entry for each new flash to specify the sector layout and programming algorithms. The entry was indexed by the Manufacturer and Device ID numbers.
The MTD CFI driver uses the Common Flash Interface (CFI). The following description of CFI is excerpted from the latest CFI 2.0 standard []:
The Common Flash Interface (CFI) specification outlines device and host system
software interrogation handshake that allows specific vendor-specified software
algorithms to be used for entire families of devices. This allows device-independent,
JEDEC ID-independent, and forward- and backward-compatible software support for the
specified flash device families. It allows flash vendors to standardize their existing
interfaces for long-term compatibility.
The MTD CFI support probes the hardware for the CFI da
How do I add support for my platform?
In the kernel source, the drivers/mtd/maps directory contains the mapping drivers. You may be able to use the generic physmap.c driver. Specify the base address, chip size, and bus width in the kernel configuration, and the physmap.c driver will probe the flash type. Generic memory accesses are used to read the flash. The physmap.c driver can even handle several flash chips in the contiguous memory area.
Some
flashes do not use straightforward memory mappings, due to external bus
addressing limitations. Or you may have more than on