Subject: Re: MTD devices in NetBSD
To: Garrett D'Amore <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/22/2006 08:28:30
Allen Briggs wrote:
> 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
> 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.
Yeah, I've only seen the parts where erase sets the bytes to 0xff. I've
dealt with parts with sector sizes of both 64K and 4K.
> This may be more interesting for a filesystem design than for the block
> 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....
Yes, I'm aware of these, I've run into them lately.
> 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.
Hmm... never run into that before. For read it wouldn't matter, but it
could have significant complications for write, because you've got to
command each flash part separately.
>> 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.
That's a good idea, though I'd probably use properties for it. Then
device_register() can define whatever properties are appropriate for the
>> 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?
Got a proposal for a different word? :-)
> 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?
Yes. More or less exactly.
>> 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
> Last I checked (quite a while ago), neither had anything in this area.
As of last night, I couldn't find any thing. :-)
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191