Linux Memory Technology Devices(MTD)

1562阅读　0评论2009-04-09　nlchjian
分类：LINUX

Linux Memory Technology Devices(MTD)

=========================================================================
from:

Design aims

We're working on a generic Linux subsystem for memory devices, especially Flash devices.

The aim of the system is to make it simple to provide a driver for new hardware, by providing a generic interface between the hardware drivers and the upper layers of the system.

Hardware drivers need to know nothing about the storage formats used, such as FTL, FFS2, etc., but will only need to provide simple routines for read, write and erase. Presentation of the device's contents to the user in an appropriate form will be handled by the upper layers of the system.

News


=========================================================================
from:

struct mtd_info {

  char name[32];

Name of the device. Rarely used, but presented to the user via the /proc/mtd interface.

  u_char type;

Type of memory technology used in this device. Choose from: 
#define MTD_ABSENT              0
#define MTD_RAM                 1
#define MTD_ROM                 2
#define MTD_NORFLASH            3
#define MTD_NANDFLASH           4
#define MTD_PEROM               5
#define MTD_OTHER               14
#define MTD_UNKNOWN             15

  u_long flags;

Device capabilities. Bitmask. Choose from: 
#define MTD_CLEAR_BITS          1       // Bits can be cleared (flash)
#define MTD_SET_BITS            2       // Bits can be set
#define MTD_ERASEABLE           4       // Has an erase function
#define MTD_WRITEB_WRITEABLE    8       // Direct IO is possible
#define MTD_VOLATILE            16      // Set for RAMs
#define MTD_XIP                 32      // eXecute-In-Place possible
#define MTD_OOB                 64      // Out-of-band data (NAND flash)
#define MTD_ECC                 128     // Device capable of automatic ECC

  loff_t size;

Total size in bytes.

  u_long erasesize;

Size in bytes of the "erase block" of this memory device - the smallest area which can be erased in a single erase command.

  u_long oobblock;

  u_long oobsize;

Some memory technologies support out-of-band data - for example, NAND flash has 16 extra bytes per 512-byte page, for error correction or metadata. oobsize and oobblock hold the size of each out-of-band area, and the number of bytes of "real" memory with which each is associated, respectively. As an example, NAND flash, would have oobblock == 512 and oobsize == 16 to show that it has 16 bytes of OOB data per 512 bytes of flash.

  u_long ecctype;

  u_long eccsize;

Some hardware not only allows access to flash or similar devices, but also has ECC (error correction) capabilities built-in to the interface. The ecctype field is an enumeration - currently you have a choice of: 
#define MTD_ECC_NONE            0       // No automatic ECC available
#define MTD_ECC_RS_DiskOnChip   1       // Automatic ECC on DiskOnChip
The eccsize holds the size of the blocks on which the hardware can perform automatic ECC.

  struct module *module;

When a driver is a kernel loadable module, this field is a pointer to the struct module of the module. It is used to increase and decrease the module's usage count as appropriate.

The user modules are responsible for increasing and decreasing the usage count of the driver as appropriate, for example by calling __MOD_INC_USE_COUNT(mtd->module); in their open routine.

  int (*erase) (struct mtd_info *mtd, struct erase_info *instr);

This routine adds a struct erase_info to the erase queue for the device. This routine may sleep until the erase had finished, or it may simply queue the request and return immediately.

The struct erase_info contains a pointer to a callback function which will be called by the driver module when the erase has completed.

For more information, see the page.

  int (*point) (struct mtd_info *mtd, loff_t from, size_t len, u_char **mtdbuf);

  void (*unpoint) (struct mtd_info *mtd, u_char * addr);

For devices which are entirely memory-mapped and which can be mapped directly into user-space page tables, we may support execute-in-place (XIP) mapping of data on the flash. The precise semantics of this are yet to be defined, so it's probably best just not to either implement or attempt to use these two functions right at the moment.

  int (*read) (struct mtd_info *mtd, loff_t from, size_t len, u_char *buf);

  int (*write) (struct mtd_info *mtd, loff_t to, size_t len, const u_char *buf);

Read and write functions for the memory device. These may sleep, and should not be called from IRQ context or with locks held.

The buf argument is assumed to be in kernel-space. If you need to copy to userspace, either use a kiobuf to lock down the pages first, or use a bounce buffer.

  int (*read_ecc) (struct mtd_info *mtd, loff_t from, size_t len, u_char *buf, u_char *eccbuf);

  int (*write_ecc) (struct mtd_info *mtd, loff_t to, size_t len, const u_char *buf, u_char *eccbuf);

For devices which support automatic ECC generation or checking, these routines behave just the same at the read/write functions above, but with the addition that the write_ecc function places the generated ECC data into eccbuf, and the read_ecc function verifies the ECC data and attempts to correct any errors which it detects.

  int (*read_oob) (struct mtd_info *mtd, loff_t from, size_t len, u_char *buf);

  int (*write_oob) (struct mtd_info *mtd, loff_t to, size_t len, const u_char *buf);

For devices which have out-of-band data, these functions provide access to it.

The from/to address is the address of the start of the real page of memory with which the OOB data is associated, added to the offset within the OOB block.

Example: To specify the 5th byte of the OOB data associated with the NAND flash page at 0x1000 in the device, you would pass address 0x1005

  void (*sync) (struct mtd_info *mtd);

This routine will sleep until all pending flash operations have completed.

  void *priv;

This is used for data private to the MTD driver.

};

Notes

All the MTD driver functions may be sleep. You may not call any of them from an IRQ or timer context, or with locks held.

Nothing may modify the data in the struct mtd_info after it is registered with the MTD system.

The read, write and erase routines are mandatory. Also read_oob and write_oob if the MTD device indicates that it has such capability.

The sync routine is not mandatory, and users should check that the vector is non-NULL before attempting to use it.

$Id: mtd_info.html,v 1.1 2005/03/12 13:43:49 gleixner Exp $
=========================================================================
from:

MTD internal API documentation

Some JFFS documentation

$Id: index.html,v 1.1 2005/03/12 13
=========================================================================
from:

Memory Technology Device (MTD) Subsystem for Linux

Design aims

We're working on a generic Linux subsystem for memory devices, especially Flash devices.

The aim of the system is to make it simple to provide a driver for new hardware, by providing a generic interface between the hardware drivers and the upper layers of the system.

Hardware drivers need to know nothing about the storage formats used, such as FTL, FFS2, etc., but will only need to provide simple routines for read, write and erase. Presentation of the device's contents to the user in an appropriate form will be handled by the upper layers of the system.

Mailing list and IRC

Download and CVS

Very occasionally, I make snapshot releases. Now that the MTD code is in the 2.4 kernel, it's become even rarer. Your best option is to obtain the latest code from CVS, by following the instructions below. We do break the CVS build occasionally, but we're also fairly good at fixing it quickly when we do so.

Note: Due to the Red Hat IS department on the machines without notice, CVS is currently accessible via IPv6 only.

Getting IPv6 isn't hard. If you have an IPv4 address on a network interface (e.g. eth0), and a version of Red Hat Linux newer than RHL7, it's this simple: 

	echo NETWORKING_IPV6=yes >> /etc/sysconfig/network
	echo IPV6_DEFAULTDEV=tun6to4 >> /etc/sysconfig/network
	echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0
	echo IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0
	/sbin/service network restart

If you have a firewall you need to make it let IP protocol #41 (IPv6 in IPv4) in and out. Other distributions and other operating systems also support . Even can do it.

Assuming you have IPv6, access to CVS is done over SSH rather than pserver:

          export CVS_RSH=`which ssh`
          cvs -d :ext:anoncvs@cvs.infradead.org:/home/cvs co mtd

If you can't access anoncvs for some reason, daily snapshots are also available at

The MTD code in the linux kernel is updated from MTD CVS in kernel version 2.6.newest only.

The MTD CVS works most of the time with kernels from the 2.4 series too. The MTD code which is available in the 2.4 series kernel source is maintainence only and will not be updated, except for bug fixes. If you need functionality from the current MTD code for your 2.4 kernel and for whatever reason, you can use the CVS code and patch your kernel yourself. You need at least kernel version 2.4.26. Kernels below 2.4.26 are considered as outdated and obsolete.

The MTD community is neither able nor interested to provide support for ancient kernels. Either move yourself and update to a recent kernel. If you use a vendor supplied kernel, please get support from your kernel vendor. Do not ask on the mailinglist for help with such problems. You are either ignored or you get a pointer to this text. Please save the bandwidth and our time to sort out such questions.

The MTD support for 2.4 will be moved to a maintainence only mode in the near future. This will relieve us from a lot of compatibility crap and lets us concentrate on the further development in the 2.6 series.

Installation

Check out sources from CVS or download a snapshot and untar it. Change to the top directory and read INSTALL. Change to subdir patches. There you find a script patchin.sh. It is highly recommended to use this script, as it is aware of different kernel versions, pristine or already patched kernels. This script applies all the neccecary changes to your kernel source including the often discussed shared zlib patches. Your kernel source must be configured already, as the script retrieves information from Makefile in your kernel source.
The script takes following options:
-c copy files into kernel tree instead of linking files
-j include jffs(2) filesystems
 As last argument you have to give the path of your kernel tree. This must be an absolute path.

The difference between linking and copying files into the kernel tree is, that copying gives you a modified kernel tree, which can be handled by CVS as it contains no symlinks. Linking the files has two advantages.
1. All your kernel trees can share the same MTD source.
2. You can have more than one MTD source eg. a stable and an unstable and use it with your kernel tree(s) by changing the link to the directories. Assumed you have two MTD versions (stable and unstable) and those are located in source, then the directory listing of source shows:
mtd->/source/mtd.stable
mtd.stable
mtd.unstable
 If you want to build with your stable MTD source, set the mtd link to mtd.stable else to mtd.unstable. Don't forget to make clean, if you switch the links.

Documentation

There is now some MTD API documentation available. It's a little out of date - the API has been evolving over the last few months as we encounter strange pieces of hardware that we hadn't anticipated, and occasionally when I'd just overlooked something blatantly obvious. Volunteers to update the docs are welcome.

13th Feb 2001: A is now also available under CVS. Not all topics are covered yet, but it's a start.

5th May 2002: A document is now available. It covers some technical topics about NAND and filesystems and contains a FAQ.

1st June 2004: A document is now available.

15th Feb 2005: A is now available.

Booting

You can now replace the firmware on the DiskOnChip 2000, and possibly also the DiskOnChip Millennium, with a version of which runs directly from the flash.

The patches to make Grub aware of the DiskOnChip and the NFTL format used on it, along with a first-stage loader to load Grub itself into memory from the DiskOnChip, are in the CVS repository.

MTD User modules

These are the modules which provide interfaces that can be used directly from userspace. The user modules currently planned include:

MTD hardware device drivers

These provide physical access to memory devices, and are not used directly - they are accessed through the user modules above.

JFFS3 (Journalling Flash File System Version 3)

There is some activity to create the third generation of the JFFS file system.
We are mainly discussing JFFS3 design issues now. A summary of the discussion is available in the JFFS3 design issues document (, ).

JFFS3 FAQ



$Id: index.html,v 1.1 2005/03/12 13:43:48 gleixner Exp $
=========================================================================

=========================================================================


=========================================================================

=========================================================================

=========================================================================


=========================================================================

=========================================================================

=========================================================================


上一篇：C struct
下一篇：我的 emacs 配置文件