In message 45BC0099.3070706@comcast.net you wrote:
understand this command. This way, it is possible to read/write from any "device" to system ram. A driver to treat system ram as a device could also be compiled into u-boot.
It certainly could. BUt IMHO it does not ake sense to require a driver to access RAM (!) when a "*pointer" is all that's needed. We're talking aboth the difference between a single machine instruction versus calls to several complex functions here!
Please let's keep the code as small, and as simple, as possible.
If the user wants to maintain the ability to operate with memory commands on bus-addressed memory of any kind, it is simple to initialize the mmapped address table appropriately.
Folks, please, do me a favour: before you continue, go and read the U-Boot code and make a list what needs to be done on all the different boards even before we have a working C environment.
Be aware, that your rewrite (1) will have to support all these features, too, (2) must not (significantly) increase the memory footprint for existing configurations which don't need any features added, and (2) will have to run in such a restricted environment, where you probably cannot even allocate a 512 byte buffer for I/O.
I don't want to stop you, but please keep the environment in mind where your code has to fit in.
dynamically. If the user does not want this type of support, it can be completely omitted from the u-boot build and all memory type commands will be executed using the CPU ram read/write routines and addresses.
??? I don;t see how this would be possible if I understand hwta GRand and you have in mind. At least not without adding yet another #ifdef maze.
I think this approach gives everybody what they want. In cases where "normal" ram and device access to a few devices is all that is desired, u-boot would probably be slightly smaller than it is now. If mmapped support is included, it might be very
I can't see how you would get the standard configuration (just RAM and NOR flash support) smaller with such a change?
Comments welcome. I don't think this is really a big change from the current system, it is just a formalization of what has always been desired.
Umm... "always been desired" - by whom? :-)
You probably remember our old discussion about ENV_IS_EMBEDDED from a year or so ago - do you? This is another similar area. The current code is not flexible and ugly, but all the configuration and code selection is done at compile time, which means we have a minimal memory footprint.
U-Boot is a boot loader. Keep is small and simple.
Best regards,
Wolfgang Denk