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

[Wolfgang Denk]

Dear Albert,

In message <20150708084625.5a18e9a5 at lilith> you wrote:
> 
> > 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.

I agree that the documentation could need some dditional explanations,
but it is not exactly outdated nor incorrect.

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

Right.  This is the part that needs to be explained:  You cannot (at
least not in general, there are always some exceptions) run the code
that is supposed to "run first" again from an already running U-Boot.

With Non-SPL versions this is the plain U-Boot binary, with SPL it's
the SPL, etc.

> 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.

This is true, but not always sufficient.  There may still be
initializations that cannot be done 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.

This is often the case, but not necessarily always.  There are systems
with components that can be initialized just once after a reset - for
example, the watchdog on some systems.  If your first U-Boot
configures the watchdog on such a system to run, and you try and load
another U-Boot image which tries to disable the watchdog, it will not
work, and the new U-Boot will crash as it fails to trigger toe
watchdog.

> 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.

The point is, this guarantee is a one-time-only guarantee.  There is
no guarantee that you can do exactly the same twice, without a reset
inbetween.

Yes, I agree, it will just work in most of the cases.  But this is
_not_ guaranteed, and we should at least warn potential users of such
methods that they really have to understand _exactly_ what they are
doing, and even if it's working now it may be broken in the next
version of U-Boot.

> (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.)

Not all hardware can be reset by software actions alone.  There are
things like write-once registers.  Once written, you MUST perform a
reset to write any different values.

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

It's a wiki, all contributions are welcome.

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
If you can't explain it to a six year old, you  don't  understand  it
yourself.                                           - Albert Einstein