In message <45BC0099.3070706 at 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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't mind criticism. You know me. I've never been one to take
offence at criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
- Terry Pratchett, _Witches Abroad_