On Mar 21, 11:36pm, garrett_damore@tadpole.com ("Garrett D'Amore") wrote:
-- Subject: MTD devices in NetBSD

| 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.)
| 

I am not an expert but all this sounds very reasonable to me.

christos