On Tue, Mar 21, 2006 at 11:36:24PM -0800, Garrett D'Amore wrote:
> 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)

I'd add that the flash device "block" is often far larger than what we
normally think of as a device "block."  I.e., an 8MB flash device might
have 64 blocks of 128K each.  So you can only erase in 128K chunks.  And
you don't actually have to erase before writing.  For a number of
devices, "erased" means all bits set.  You can clear bits without
erasing again, but you can only set bits by erasing the whole flash.
I think some devices are the opposite--erase clears all bits and you
can only set bits without erasing the whole thing, but I haven't seen
such in practice.

This may be more interesting for a filesystem design than for the block
device.

Also, there are flash parts that don't have even-sized blocks.  These
are sometimes called "boot flashes" and usually have the first or last
block subdivided into smaller power-of-two block sizes.  Like maybe:
512, 512, 1k, 2k, 4k, 8k, 16k, 32k, 64k, 128k, 128k....

You can also find systems where the devices are set up in parallel,
so two 8-bit devices live on a 16-bit bus (or 4 8-bit devices on
a 32-bit bus or 2 16-bit devices on a 32-bit bus, etc.) where one
device uses bit 0-7 and the other uses 8-15.  Something to keep in
mind, perhaps.

>    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

How would you handle flash partitioning?  For example, devices using
RedBoot have a "standard" partitioning scheme where you can put files
using the boot ROM (through the 'fis' commands -- 'fis init', 'fis
create', etc.).  Other ROMs probabaly have similar abilities.  But
in any case, I'd probably want to have a way to define in a kernel
configuration file that the area containing the ROM is read-only.
Or at least separate from the region that I want to scribble on.

> 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

Could we please avoid the term bikeshed?  Especially as a verb?

I'm glad you're willing to take this on.  It's been lacking for a while.

> The resulting driver tree would look like (using alchemy as an example)
> mainbus -> aubus -> cfiflash (via cfiflash_arbus.c) -> mtdbus -> mtd 

[ Modulo Simon's comments about mainbus vs. obio, which I can't
  comment on...]

Do you see the mtdbus as basically a carrier for the interface between
the mtd (or whatever) and cfiflash?  So cfiflash fills out a set of
function pointers, etc., in a mtdbus_attach_args or some such and then
calls config_found() with a pointer to that as 'aux' or similar?

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

Last I checked (quite a while ago), neither had anything in this area.

-allen

-- 
                  Use NetBSD!  http://www.NetBSD.org/