Subject: Re: MTD devices in NetBSD
To: Garrett D'Amore <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 03/22/2006 08:57:06
On Mar 21, 11:36pm, firstname.lastname@example.org ("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
| 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
| 4. Generally NAND devices cannot do this, and usually need special
| 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
| 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
I am not an expert but all this sounds very reasonable to me.