On 19:41 Mon 28 Jan , Mike Frysinger wrote: > 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.
I disagree on some product you use a spi flash to store other code and not nessarely store u-boot in it? (you can have 2 falsh) > > 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. I also disagree you may need the optimal performance, in some project I need it. Best Regards, J. > -mike > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
