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

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

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

>   
>> 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
>> tomorrow.)
>>     
>
> Last I checked (quite a while ago), neither had anything in this area.
>   

As of last night, I couldn't find any thing.  :-)

    -- Garrett
> -allen
>
>   


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