[U-Boot-Users] [rfc] new spiflash subsystem

[Scott McNutt]

>>> How do you do "byte writes" which is an important feature of the  AT45?
>> simple: i dont.  spi flash writing isnt something to be done constantly nor is 
>> it fast, so i dont sweat getting maximum performance.

This is an artificial limitation based on your _opinion_.
How, why, or what someone chooses to write into spi flash
should not be constrained by design.

>>> Your code does not support DMA transfers, while the current dataflash code
>>> runs DMA up to 50 Mbps.
>> so ?  the point of u-boot is to do everything in PIO mode.

This is also an opinion -- that I happen to disagree with.

>>
>>> Erasing the entire SPI flash is generally stupid, since you store the
>>> environment there. You typically also store the initial bootloader and
>>> U-Boot.
>> so the user is stupid if they erase the entire flash ?  you could say the same 
>> thing about any flash type.
>>

I have valid reasons, better _requirements_, for erasing an
entire spi flash and have done so many times. I never realized
that I was stupid ... and for all these years!  ;-)

>>> Very rarely you want to erase the complete flash ,and a protection
>>> mechanism is needed to avoid accidental overwrites.
>>> The current solution allows dataflash pages to be protected.
> 
> I disagree on some product you use a spi flash to store other code and
> not nessarely store u-boot in it? (you can have 2 falsh)

Ditto -- I also disagree.

>> execute something else.  it isnt an operating system, it doesnt get maximal 
>> performance, and it isnt supposed to support all sorts of extended features.  

What it's _supposed_ to support can be debated. But I'm quite
sure that preventing extended features is not a good thing to
design into a subsystem from the outset.

>> what you describe as deficiency doesnt apply to the topic at hand and really 
>> sounds like a basic design decision for u-boot.  if you want optimal 
>> performance, use Linux.

The pot is calling the kettle black here -- WRT basic design decisions.
If I want optimal performance, I shouldn't have to find an alternative
to u-boot simply because a subsystem prevents me from doing so by
design.

I think many of the comments/suggestions in this email topic have been
sound and raise some valid issues/concerns -- this is a good thing.

Regards,
--Scott