[U-Boot] arm: pRAM support?

[Wolfgang Denk]

Dear Holger,

In message <4A671863.9040303 at keymile.com> you wrote:
>
> > Well, if you want to do it Right (TM) that means we would take this
> > chance and fix the ARM memory map, which implies to implement
> > relocation to a dynamicalle detemined relocation address.
> > 
> can you explain this a little bit more in detail? Sounds like, that this is a larger chunk of work? 

The ARM port of U-Boot is seriously broken in several respects.  When
the  ARMBoot  project  was forked off the PPCBoot (as it was caled by
then), the implementors did not care for compatibility,  and  decided
in  fevour for minimal porting effort by giving up some features that
we considered essential when designing PPCBoot / U-Boot on PowerPC.

Just to give one  example:  on  PowerPC,  we  normally  use  code  to
automatically determine the memory sizes on a board. One binary image
of  U-Boot  can  run  unchanged  on boards with for example different
sizes of flash and RAM. U-Boot will always relocate itself to the end
of the available RAM, thus leavin the maximum possible amount of  RAM
available  for  the  user,  for example to load Linux kernel and root
file system.

If we need to reserve memory, like for protected RAM, or for a  frame
buffer  we  can  shared  between  U-Boot and Linux (so you can have a
splash screen right after power-on which does not even  flicker  when
Linux  boots),  or  for  a  shared log buffer (so you can for example
process U-Boots Power-On Self Test messages in Linux  using  standard
syslog  tools, or you can use U-Boot to dump the Linux kernel's crash
messages post mortem in  U-Boot  or  in  Linux  after  rebooting  the
system),  we just shift the relocation address for U-Boot down by the
required amount.

If you need a different amount of  pRAM,  just  "setenv"  the  "pram"
environment variable, and U-Boot will auto-adjust at the next reboot.


On ARM, we don't do any such relocation, we  link  the  image  for  a
fixed address in RAM. So assum you have a board that can come with 32
MB  or  with  64 MB of RAM. You will have to link U-Boot close to the
end of the 32 MB border - say to run at 31 MB. On a 64 MB board  this
means  it  sits  right in the middle of availabel RAM - you have some
63+ MB of RAm free, but you cannot find more than  32  MB  contiguous
space.  If  you need pRAM or framebuffer or log buffer, you will have
to configure sizes at compile time, and then you cannot change it  at
run time. Systems with variable RAM sizes will always suffer from the
same   restrictions   like   on  the  board  with  the  smallest  RAM
configuration.

And so on and on...

That's why I think that the ARM memory map needs to be put  from  top
on  it's  feet  where we can make use of many of the nice features we
have in U-Boot.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.