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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hello Wolfgang,

On Thu, 09 Jul 2015 22:38:48 +0200, Wolfgang Denk <wd@denx.de> wrote:
> Dear Albert,
> 
> In message <20150708084625.5a18e9a5@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.

All of the above is right: there is no 100% guarantee that this will
work, not even "close-enough" guarantee; and yes, there is hardware out
there that is write-once-per-power-cycle, which may or may not prevent
resetting it to a known state.

> > Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader
> > cases?
> 
> It's a wiki, all contributions are welcome.

OK -- I was not so much asking for someone to do it than asking whether
the general direction of the proposed edit would be fine. :)

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.