please quote properly in your replies 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 > > 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. > > 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 ? > > 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. > > 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 volume > production 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. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ U-Boot-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/u-boot-users
