Subject: MTD devices in NetBSD
To: None <tech-kern@NetBSD.org, core@NetBSD.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 03/21/2006 23:36:24
Okay, I'm ready to start getting *serious* about supporting MTD (flash!)
devices in NetBSD.

I've been doing a lot of research.   I want to sum it up here, along
with my thoughts.  I'm *particularly* interested in what core@ has to
say, so that perhaps we can move to actually implementing something
"real".  I am aware that others are starting to work on this problem,
but I think there is a lack of hard technical direction, and I think it
is important to get the "framework" right:

MTD devices differ from regular "block" devices in some important aspects:

   1. you have to erase a block before you write it (read-modify-write
      cycle)
   2. They need wear-leveling (writes "wear" the bits out) to prolong
      device life
   3. Many NOR devices can map directly into system memory while in read
      mode
   4. Generally NAND devices cannot do this, and usually need special
      handling
   5. You may have to to do bad block management (some block devices
      have to do this)
   6. Generally, most filesystems designed for use with block devices
      won't work so well
   7. Some devices support "execute in place", while some do not
   8. CompactFlash doesn't count, because it looks like an IDE disk. :-)


Now, here's the Linux approach  (as I understand it) to this problem,
which I think is generally right, though certain bits of their
implementation may or may not be suboptimal:

   1. There is a general MTD framework.  Think of this as a block-device
      like framework, except with different operations.
   2. Each flash device driver implements operations to hook into the
      MTD framework
   3. The MTD framework exports "block" and "character" emulations for
      stuff that needs it.
   4. The best way to use MTD devices is with a filesystem like JFFSv2,
      that avoids the translation layers and accesses the "raw" MTD
      operations.


Now, here's what I'm thinking:

   1. Start with a definition of what ops an MTD must export, probably
      following Linux in this regard
   2. Implement MI NOR flash driver using "CFI" (Common Flash Interface,
      found on many NOR ports)
   3. Implement bus-specific stuff for one or more platforms.
   4. Implement MTD stuff as an "mtdbus" for lack of a better abstraction
   5. Implement "mtd" (block/char compat) driver on top of mtdbus
   6. Eventually, look at a rewrite of JFFS2 or YAFFS.


I'm willing to take on points 1 thru 4 at least, and possibly also 5,
because more or less I need this in order to complete work I'm already
obligated to perform.  However, I don't want to bikeshed on this, so I
need to get approval on the technical direction fairly quickly.

The resulting driver tree would look like (using alchemy as an example)

mainbus -> aubus -> cfiflash (via cfiflash_arbus.c) -> mtdbus -> mtd 
(and maybe ffs mounted on top of mtd)


Given this, it would then be possible for someone else to write a JFFS2,
or drivers for NAND flash, or e.g. attachment drivers for other kinds of
flash devices.

What do people think?  And more importantly, what does core@ think?

(And I'm especially interested in ideas from folks with experience with
MTD devices, either under Linux or under either OS'.  I confess I've not
looked into OpenBSD or FreeBSD yet, but I'm planning on doing that
tomorrow.)

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191