Wolfgang Denk wrote:
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.
I guess I am OK with either implementation.
I think just because BDI is not capable of handling any address space besides the processor address space should not mean we should so restrictive of command line of U-Boot. I think address space tags that I proposed yesterday could remove the confusion of what address the command is referring to and it is easy to explain that a BDI could only access untagged address space directly and everything else are indirectly accessible memory. This would also enable us to use paged memory mapped to a small window in processor address space seamlessly.
Anyway, I think either approach is valid and usable. There are pros and cons with either scheme.
I think it might be easier to educate the user with one set of commands as opposed to user having to decide which one of several <dev> read/write commands should be applicable.
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.
I see your point. However, with a hardware debugger you are not currently able to mmc data directly and so you could not be able to access mmc:0x00112233 either because "mmc:0x00112233" is not an address that would be valid for BDI. So, I see no difference. It is really mostly a matter of style rather than function.
Having the capability of u-boot memory commands to access different address spaces is a convenience feature. When such feature is not available the read/write commands will bring a chunk to ram and it will be processed using memory commands again so first one would allow the two operations combined but not a huge gain or loss either way.
Having said all that, I will concluded that either way is OK for me as long as we maintain consistent architecture.
Tolunay