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

[Mike Frysinger]

On Monday 28 January 2008, Ulf Samuelsson wrote:
> Unfortunately, this code seems useless, at least for the combination AT91 +
> SPI flash. Some issues:
>
> I believe that the AT45 is not using the same command set as other
> SPI flash memories. I think the commands need to be separated.

i already accounted for different command sets based on part family.

> AT45 is much more advanced than other SPI flash.

yes, but it still has a basic subset which can be used.

> Did you really test your code on the AT45 series?

it was the part i developed the code on originally (the 64mbit one).

> You assume, incorrectly, that all sector sizes are the same size.

that depends on what level you look at it.  sector 0 can be accessed in 
pieces, but it can also be treated as one big sector the same as all the 
others.  this is how i treated it.

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

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

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

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

yes, protection of pages (hardware and software) is missing.

> Typically you want to store data with a checksum,since relying
> on the boot of the linux kernel to produce the error, will in my experience
> make people confused and they will spend a lot of time barking up the wrong
> tree.

ok ?  not sure how this is relevant to the topic at hand.

> There is a general problem with U-Boot which seems to assume
> that there is more RAM than flash in the system.
> How do you easily copy 256 MB from an SD-Card to an onboard 256 MB NAND
> flash when the SDRAM is 64 MB?
>
> Today, you have to use 10 lines (U-Boot occupies 1 MB) and that is really
> bad.
>
> The vanilla way of supporting storage devices is really wasteful in
> resources, and you cannot compare two memory areas if the memory area is
> larger than half the SDRAM size.

ok ?  u-boot is designed as a monitor to get the system bootstrapped and 
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 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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080128/df5c772b/attachment.pgp