Allen Briggs wrote:
> [ core@ removed ]
>
> On Wed, Mar 22, 2006 at 08:28:30AM -0800, Garrett D'Amore wrote:
>   
>>> 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.
>>     
>
> It's not too bad--you usually just issue the commands in parallel, so if
> you have two 16-bit devices on a 32-bit bus, you set the command in the
> lower 16 bits and copy to the upper 16 bits before the write.  Or
> something like that.  This does seem to be rare these days.  4-5 years
> ago, I worked on a board that used 4 8-bit devices on a 32-bit bus.  I
> think it's mainly those wacky hardware guys trying to save money...
>   

Yeah, I've heard hardware guys propose this on new designs recently, but
I have been successful at my company in convincing them to just use
bigger parts (or parts with bigger busses).  :-)

>   
>>> 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 not sure I quite grok what you mean here.  I was thinking that
> it would be nice if the system, in a default scenario, could recognize
> the loader's partitioning scheme (if any) and have the different parts
> show up as different wedges/partitions in BSD as well as, perhaps,
> maintaining read-only bits.
>   

Hmmm... the problem is that I don't know if there are standard
partitioning schemes.  I think that might be MD, though there are
probably some well known variants.  If it is easy to recognize and
handle this for the common cases, then I could do it.  But I still want
to enable MD code to pass this kind of info to the flash driver via
device properties, because e.g. the fact that I've got some boot sectors
that are RO may be very board-specific.  device_register() is a nice
MD-bit of code that runs that can populate this info, so we can minimize
MD code creeping into otherwise "generic" flash devices.

> Oh...  That reminds me.  Were you thinking about honoring / exposing
> or punting on sector protection?
>   

I think we need to honor & expose it.  The upper level filesystem code
may be able to take advantage of this knowledge.

>   
>>> Could we please avoid the term bikeshed?  Especially as a verb?
>>>       
>> Got a proposal for a different word? :-)
>>     
>
> "get into discussions about irrelevant bits" ?
>   

bikeshed is a much more compact way to say it.  :-)  I'm optimizing. 
:-)  Lets not bikeshed about the term bikeshed anymore, okay?

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

Yeah, well I expect if I invent something particularly useful they'll
pick it up.  :-)

    - 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