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