[U-Boot] hang: ARM64/Relocating u-boot from u-boot

[Albert ARIBAUD]

Hello Wolfgang,

On Wed, 08 Jul 2015 00:36:52 +0200, Wolfgang Denk <wd at denx.de> wrote:
> Dear Jagan,
> 
> In message <CAD6G_RQnrBWyPp1CyiDxkZ4vme4PB5fNHDX-f2Sf=9CvrodcWg at mail.gmail.com> you wrote:
> > 
> > I'm running u-boot from u-boot prompt, just like a standalone
> > application with CONFIG_SYS_TEXT_BASE address.
> ...

(note: the board here identifies itself as "ARM64 Reference Board",
which does not exist in the current U-Boot source code, so this is
obviously a non-mainline(-yet?) port for which we could hardly give
assistance anyway.)

> > Has any one tried the same before, please let me know for any inputs?
> 
> Actually this is even a FAQ:
> 
> http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

If I may, this FAQ is slightly outdated, in that chainloading U-Boot is
not only possible but actually made possible by design, at least for
many ARM (and possibly some ARM64) targets, and I suspect for many
non-ARM targets too, as long as they use SPL.

First off: the FAQ is perfectly true if applied to running SPL from
SPL.

But you can easily run U-Boot from SPL -- that's actually the point of
SPL in the first place -- and this is done, usually, by having SPL
reset the hardware to the extent of getting external RAM working, and
conversively having U-Boot reset the hardware in (OS) booting condition
*except* for the external RAM part which U-Boot could not do anyway.

IOW, on targets with SPL, U-Boot starts with the guarantee that all
initializations needed for external RAM to work have been done, and
it guarantees that it will not perform these external RAM inits again.

And since an SPL-chainloaded U-Boot runs with external already
initialized and does not initialize it again, it follows that this
U-Boot is a valid environment for running another instance of itself,
provided the new instance and current instances do not overwrite each
other.

And U-Boot relocates itself to the highest possible address, thereby
freeing up its load address. Provided this load address was chosen low
in external RAM, and provided the board has enough external RAM (which
any board aiming to chainload a big Linux kernel from a smaller U-Boot
should have), this allows loading U-Boot to its link-time address from a
running U-Boot instance without any trashing of either instance.

All of this makes it nont only perfectly possible for (SPL-run) U-Boot
to chainload (SPL-run) U-Boot, it pretty much guarantees it.

And while chainloading ans SPL-run U-Boot is useless in bringing up a
board (where the effort is in SPL itself), it becomes very useful in
adding or modifying all the rest of U-Boot, for instance tweaking the
performance of a network driver.

(on an OT note, I'd even say that a SPL-supported U-Bot which cannot
chainload itself probably does not completely and/or properly reset the
hardware into booting condition, but that's slightly beside the point.)

Note that the above description applies to any target in which U-Boot
starts from external RAM rather than IRAM or FLASH; not only those
targets with SPL, but also those with a ROM bootloader capable to
initialize the external RAM and chain to its payoad there, e.g.
kirkwood.

Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader
cases?

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.