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