We also have board with NAND FLASH only and the number of those boards will grow in the near future. The NAND command interface of course need a little more typing, but I always configure a few environment variables to update the images in the NAND FLASH. Something like:
=> setenv nload 'tftp 200000 board/u-boot.bin' => setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000' => setenv nupd 'run nload nupdate'
Yes, yes :-) Here I agree with Wolfgand and Stefan. U-Boot should provide commands which reflect principle of device without any abstraction. Knowing principle means usually less bad surprises coming out from some hidden abstraction implementation details. That's good for power users.
=> OK, then tell me how to compare a 6 MB file in flash with a 6MB file in SDRAM when your SDRAM is 8 MB.
We are *not* running on PC's.
There is nothing that stops "power users" from copying from dataflash to SDRAM and then doing a compare. Power Users are limited by implementations which waste enormous resources.
I would have more respects for exhibited views if writes to parallel flash is removed from cp.b... Parallel flash is clearly not "memory" for write purposes, only for read purposes. Its existence in cp.b will force endless #ifdefs or support for parallel flash will have to remain and bloat code.
You could then argue that support for parallel flash should be removed from all commands to remove inconsistencies...
I do not think this will happen because it is *useful* and because this affects boards which people that makes decisions works with this. They do not work with dataflash and do not care about people that wants this.
I think that consistency in argumentation is a reasonable demand.
* BYTE WRITE
Why should you waste time on copying dataflash to SDRAM when you can do operations inside the internal SRAM.
It is not desirable to transfer 20,000 bits between CPU and dataflash when 100-200 are sufficient. Personally I would like everyone that did not bother to read and under stand the AT45 dataflash datasheets to do so before sending comments about how the internal implementation should look like.
Best Regards Ulf Samuelsson