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.
Please read also the section about kernel versions below
Full archives are available at http://lists.infradead.org/pipermail/linux-mtd/.
NOTE: DO NOT SEND YOUR SUBSCRIPTION REQUEST TO THE LIST ITSELF.
SEND IT TO email@example.com AS THE ABOVE SAYS.
There is a CVS log mailing list to keep you informed of CVS commits. To subscribe, go here
NOTE: THIS LIST IS READ ONLY. DO NOT POST TO THIS LIST
There is also an IRC channel: #mtd on irc.ipv6.freenode.net or irc.freenode.net
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 pulling the plug 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 6to4. Even Windows 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:firstname.lastname@example.org:/home/cvs co mtd
If you can't access anoncvs for some reason, daily snapshots are also available at ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/
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.
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:
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.
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 mtd-jffs-HOWTO is now also available under CVS. Not all topics are covered yet, but it's a start.
5th May 2002: A NAND Flash document is now available. It covers some technical topics about NAND and filesystems and contains a FAQ.
1st June 2004: A NAND Flash API document is now available.
15th Feb 2005: A MTD FAQ is now available.
You can now replace the firmware on the DiskOnChip 2000, and possibly also the DiskOnChip Millennium, with a version of GNU Grub 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.
These are the modules which provide interfaces that can be used directly from userspace. The user modules currently planned include:
These provide physical access to memory devices, and are not used directly - they are accessed through the user modules above.
There is some activity to create the third generation of the JFFS file
We are mainly discussing JFFS3 design issues now. A summary of the discussion is available in the JFFS3 design issues document (pdf, html).