[U-Boot] U-Boot proper(not SPL) relocate option

[Wolfgang Denk]

Dear Kever Yang,

In message <fd0bb500-80c4-f317-cc18-f7aaf1344fd8 at rock-chips.com> you wrote:
> 
> I can understand this feature, we always do dram_init_banks() first,
> then we relocate to 'known' area, then will be no risk to access memory.
> I believe there must be some historical reason for some kind of device,
> the relocate feature is a wonderful idea for it.

This is actuallyu not so much a feature needed to support some
specific device (in this case much simpler approahces would be
possible), but to support a whole set of features.  Unfortunately
these appear to get forgotten / ignored over time.

>      many other SoCs should be similar.
> - Without relocate we can save many step, some of our customer really
>      care much about the boot time duration.
>      * no need to relocate everything
>      * no need to copy all the code
>      * no need init the driver more than once

Please have a look at the README, section "Memory Management".
The reloaction is not done to any _fixed_ address, but the address
is actually computed at runtime, depending on a number features
enabled (at least this is how it used to be - appearently little of
this is tested on a regular base, so I would not be surprised if
things are broken today).

The basic idea was to reserve areas of memory at the top of RAM,
that would not be initialized / modified by U-Boot and Linux, not
even across a reset / warm boot.

This was used for exaple for:

- pRAM (Protected RAM) which could be used to store all kind of data
  (for example, using a pramfs [Protected and Persistent RAM
  Filesystem]) that could be kept across reboots of the OS.

- shared frame buffer / video memory. U-Boot and Linux would be able
  to initialize the video memory just once (in U-Boot) and then
  share it, maybe even across reboots.  especially, this would allow
  for a very early splash screen that gets passed (flicker free) to
  Linux until some Linux GUI takes over (much more difficult today).

- shared log buffer: U-Boot and Linux used to use the same syslog
  buffer mechanism, so you could share it between U-Boot and Linux.
  this allows for example to 
  * read the Linux kernel panic messages after reset in U-Boot; this
    is very useful when you bring up a new system and Linux crashes
    before it can display the log buffer on the console
  * pass U-Boot POST results on to Linux, so the application code
    can read and process these
  * process the system log of the previous run (especially after a
    panic) in Lunux after it rebootet.

etc.

There are a number of such features which require to reserve room at
the top of RAM, the size of which is calculatedat runtime, often
depending on user settable environment data.

All this cannot be done without relocation to a (dynmaically
computed) target address.


Yes, the code could be simpler and faster without that - but then,
you cut off a number of features.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
The flow chart is a most thoroughly oversold piece of  program  docu-
mentation.              -- Frederick Brooks, "The Mythical Man Month"