Ulf Samuelsson wrote:
If it can be decided that the only devices that will be supported by the memory commands in cmd_mem.c are those devices that can be read directly as ram without a read routine, I think that would help clarify the intent of the commands.
Why limit to "read". Why not say that any memory which can be read or *written* without a driver will be supported by the cmd_mem.c ?
There are at least two very good reasons why adding the "written" constraint is not practical: First, as he has stated several times in this thread, Mr. Denk believes that users regard NOR flash as just like ram and therefore expect ram commands to work on it. This point of view certainly has merit, and while we may not all totally agree with it, it is, and must be, Mr. Denk's u-boot. He is the final determining person on what will be accepted. The second, and perhaps even better reason to not remove NOR flash from the memory commands is that it will break just about 100% of all existing u-boot configurations. Ok, maybe it's 95%, but its real large. This doesn't even take into account how many README files out there describe copying things into flash with the cp command. This type of support is not going away for these reasons. My main goal in this thread is to create/keep the "read" constraint intact so that we don't have constant additions of #ifdefs to the cmd_mem.c to support any arbitrary non-memory bus devices that people decide they want to use like memory, or that if we were going to do that we would create a way to do it that didn't result in an #ifdef maze. Mr. Denk has solved this concern on my part. We aren't going to add devices that require read routines.
Best Regards, Bill Campbell