>>> 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.
This is an artificial limitation based on your _opinion_. How, why, or what someone chooses to write into spi flash should not be constrained by design. >>> 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 also an opinion -- that I happen to disagree with. >> >>> 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. >> I have valid reasons, better _requirements_, for erasing an entire spi flash and have done so many times. I never realized that I was stupid ... and for all these years! ;-) >>> 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) Ditto -- I also disagree. >> 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 it's _supposed_ to support can be debated. But I'm quite sure that preventing extended features is not a good thing to design into a subsystem from the outset. >> 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. The pot is calling the kettle black here -- WRT basic design decisions. If I want optimal performance, I shouldn't have to find an alternative to u-boot simply because a subsystem prevents me from doing so by design. I think many of the comments/suggestions in this email topic have been sound and raise some valid issues/concerns -- this is a good thing. Regards, --Scott ------------------------------------------------------------------------- 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
