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

[Ulf Samuelsson]

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.

==> And this is not a good approach, you want the S/W to use the
        first 256 kB to store initial boot, U-boot and environment.
        The AT91SAM9 chips will use the first 8 kB sector
        for the AT91bootstrap, and that should have protection separate from U-Boot code.
        AVR32 boot ROM will boot from a higher address and use the 
        8 kB sector at address zero as environment.
        Both will need to have a S/W partitioning scheme added with
        separate protection for each partition.
        This partioning scheme exists today.

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

==> Which means that you want to impose an arbitary limit which
        currently does not exist in U-Boot.
        You also increase startup time, which is a critical parameter for many customers.

> 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 not how the dataflash support is implemented in U-Boot today.
        Current implementation is using DMA.

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

==> 
        No, but U-Boot should make them aware of consequences,
        so they do not do this by mistake.
        You normally can't remove the bootloader from a parallel flash
        without unprotecting it first.

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

==> Exactly my point

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

==> Just pointing out that the user interface is missing features.


> 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

==> Yes, it is a basic design decision, and with huge flash memories,
        it is becoming flawed. Thats why I think we should rethink how
        we do things, before we rewrite the code.

        Programming the internal flash memory in an efficient 
        way is really the core of a bootloader, not an extended feature.
        Programming time is a critical parameter for large volume production
        so if you can avoid booting Linux, this is probably a good thing.

==> My conclusion remains, that I do not see why anyone using
        dataflash in the current U-boot would want to switch to the proposed
        implementation, which will reduce performance and functionality,
        and increase risk of errors.

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavallerivägen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57