[U-Boot-Users] Atmel DataFlash hooks.

Wolfgang Denk wd at denx.de
Sun Jan 28 16:17:54 CET 2007


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_




More information about the U-Boot mailing list