please quote properly in your replies
==> Mailers can't quote properly when mails are sent as a text attachement. Also quoting does not work when people are sending non-compliant mails allowing long lines.
On Tuesday 29 January 2008, Ulf Samuelsson wrote:
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.
sorry, i didnt mean to imply i thought this limitation was something to be written in stone. i understand perfectly why you would want this flexibility, so i can take a look. rather than making general statements, can you please provide a concrete list of all relevant examples you know of.
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.
uhh, what ? you're telling me that customers do a SPI write in u-boot everytime they boot up ? that just sounds stupid and your customers need to rethink their system. "critical boot time" and "spi flash writing" dont belong in the same sentence :P
==> Should have been a line break there, the sentence belongs to the statement below.
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.
then i'm afraid your implementation is wrong. DMA is board/cpu-specific and there's no way that can be represented in a general framework. in fact, when i was researching how to support SPI dataflash originally, i saw the dataflash code in u-boot and found it to be worthless in terms of re-use. as Haavard points out though, by using a more general SPI transfer layer, you can still (wrongly imo) do DMA transfers.
==> If a customer measures the boot speed, then slow non-DMA code is wrong and fast code using DMA is right. It may be that this should be in an Atmel specific driver location.
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.
providing sector protection is a different topic from removing functionality. nand flash provides the ability to erase the whole flash, so are you going to lobby them to drop that too ?
==> If you store the U-boot and environment in the NAND flash then allowing users to destroy the functionality of the board with a simple command is stupid. NAND flash need partitioning and protection as well.
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.
what features ? checksums is not the domain of the flash layer unless the flash media itself requires it (like NAND and ECC/bad-blocks). parallel/SPI flash provide no such thing, so adding a completely software checksum layer is inappropriate. if you want checksums, add them yourself in your board code.
==> It is your opinion that it is inappropriate, others may disagree. I believe that this should be a user choice. I have seen this problem numerous times and users invariably look in the wrong place to solve the problem, wasting their time and eventually my time as well.
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.
==> 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 volumeproduction so if you can avoid booting Linux, this is probably a good thing.
not relevant to the thread. please drop any further comments on the topic. if you want to re-architect u-boot, start a new thread.
==> 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.
do you not understand how the software development process works ? i post a new framework, asking for feedback. that doesnt mean it is perfect the first time through and that everyone should start using it RIGHT NOW. please exercise some patience.
==> I *am* providing feedback, and the feedback is that the proposed code will limit functionality compared to the current implementation, and introduce dangerous features which I prefer not having in any boards that I have to support. It is moving u-boot in a direction which I belive is a dead end due to the emergence of huge flash memories. I do not mind that code like this is added to u-boot as long as you do not build this in by default and that the current implemention is available until the deficiencies in the proposed implementation is fixed.
-mike
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
Technical support when I am not available: AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com AVR32 Applications Group mailto:avr32@atmel.com http://www.avrfreaks.net/; http://avr32linux.org/ http://www.at91.com/ ; ftp://at91dist:distrib@81.80.104.162/ ----- Original Message ----- From: "Mike Frysinger" vapier@gentoo.org To: "Ulf Samuelsson" ulf.samuelsson@atmel.com Cc: u-boot-users@lists.sourceforge.net Sent: Tuesday, January 29, 2008 3:07 PM Subject: Re: [U-Boot-Users] [rfc] new spiflash subsystem