In message 1170285215.21572.20.camel@elrond.sweden.atmel.com you wrote:
I disagree here. You are talking about storage devices, not memory. Can we agree that "memory" shall be considered something which is directly addressable in the processors address space?
Can you explain why you need to have the memory commands at all?
To access memory.
Then please continue to explain why, when you are doing exactly the same manouvers, but use a serial flash, you do not need the commands.
Because these devices are not directly addressable in the processors address space, i. e. they are not memory.
Everything is fine as long as the "md" command in U-Boot and the "md" command at my BDI2000's telnet prompt show the same results for the same address ranges. When this is NOT the case, something is broken. Here, it is the U-Boot implementation.
Why do you think it is not neccessary to compare the written dataflash with the SDRAM?
Nobody is going to take away the function from you. Just the inter- face will have to cahcne, as the current implementation is broken.
Why do you think dataflash users will appreciate to have to copy to SDRAM every time they do something?
But they are already doing this all the time, right?
And how do you explain to a user, that the "cp" or "md" command can read valid data from some magic address, while accessing the same addresses in a JTAG debugger does not work at all?
The concept to map an address is not at all hard to explain. Even so, I have never had the question in over 100 projects.
For me this is a very important issue: when U-Boto and a hardware debugger start behaving differently, I consider this a serious problem. U-Boot is a boot loader, and as such mostly a hardware debug tool.
There is a very big difference in "cleaning" something up and removing most of the functionality,because You dont use it, and find it irritating to see it in the code.
You can keep the function, but not in the context of the memory commands.
Best regards,
Wolfgang Denk