Hello Wolfgang, On Thu, 09 Jul 2015 22:38:48 +0200, Wolfgang Denk <w...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
