So far I have been staying out of this thread. But I felt maybe my $0.02 could be useful in this discussion.
I personally feel like existing commands should work on future devices. However, assuming not every memory can be mapped to processor memory space directly I propose prefixing the addresses with an a"ddress space tag" or simply tag (expanding from original similar suggestion).
For example,
cp.b 0xfff00000 tag:0x00002000 2000
The tag would be defined by board designer as appropriate for the particular board. For example, it could be "sd1", "sd2", "eeprom", "hdd". In this case, "sd1", "sd2" could be referring different instances of the same type of device (say sd/mmc memory).
I am envisioning associated with the "tag" the board designer maps a technology driver "dataflash", "mmc", "ide", etc. This approach could even give us the opportunity to use window mapped flash devices (i.e. flash is mapped into memory smaller than total device size) etc. This approach would also not modify the user experience significantly. U-Boot commands could be developed cleanly and the commands would uniformly use a limited number of accessors provided by the technology drivers. This could help eliminate the #ifdef maze and remove inconsistencies between commands which have been mentioned in the previous posts of this thread. I think in addition to ram, we can support regular nor flash that is directly mapped to address space as before (grandfathered).If a command could not be supported on a device (like protect on/off) the command would issue an error if issued for incompatible device/memory space.
What do you think?
Tolunay