In message 45BD21D7.20203@comcast.net you wrote:
I can't see how you would get the standard configuration (just RAM and NOR flash support) smaller with such a change?
There are presently quite a few #ifdefs involved in cmd_mem.c and cmd_load.c to take different memory types into consideration. These would mostly go away. That is why I think a ram + flash configuration
OK, so the *source* code may become smaller indeed. But I'd expect the memory footprint on the target system to grow instead, or you lose functionality.
configuration. Naturally, you loose the ability to dump flash data with md, compare to flash data with cmp, copy flash data with cp.b, load data directly to flash with loadb, etc. so it is not free, just a bit smaller.
Arghhh... Indeed, that's not free. I guess for such a price there are other, more efficient ways to reduce the code size.
current system, it is just a formalization of what has always been desired.
Umm... "always been desired" - by whom? :-)
Well, as I understood it, at least partially by you. :-) The ability to use memory oriented commands on memory other than simple ram seems to be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
considered a plus by many u-boot community members. However, this does
Read what you wrote: "use memory oriented commands on memory". That's exactly what I really expect to be able to do, indeed.
Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash contents?
add some complexity and size to the associated memory manipulation commands. As the object being addressed differs more and more from
Not really. Normally only writing may need special handling.
I can't say if Dataflash really fits into this szenario; I never used this feature myself.
simple ram, more and more people seem to accept "new" commands to read and write these objects, and to forgo the advantages/features of the memory commands. This becomes especially true when the size of the object to be read/written exceeds the size of the CPU address space.
Do you have an example where this happens in U-Boot context?
What my goal in this proposed design is to allow users to choose at compile time what features are desired for the u-boot memory commands a) without an ifdef maze and b) without needing to inject new code into cmd_mem.c and cmd_load.c for every different memory technology that will use memory access type commands. If somebody wants to use the memory commands on a serial EEPROM, this can be made to work if desired, or not
I feel that would be not natural. And EEPROM (like on a I2C bus) does not have any natural adresses in the CPU's address space. Same for IDE or USB devices. These are storage devices on some form of I/O bus, but certainly NOT memory.
made to work if not considered necessary, without changing cmd_mem.c. How possible/good this goal is remains to be seen, I agree. The current
IMHO we should provide a user inteface which is powerful, yet easy to use - this requires it must be intuitive to the end user. For most f them, (NOR) flash *is* memory, while and IDE or USB disk and even an EEPROM is not.
I completely agree with small and simple, and making feature choices at compile time. I think these attributes can be preserved, or perhaps
Ther eis another thing that is important to me: U-Boot on different systems, boards and architectures shall always behave as similar as possible. Having the "cmp" command (if configured into U-Boot) work on flash memory on one system and failing to do so on another one seems unacceptable to me.
Best regards,
Wolfgang Denk