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

[Jagan Teki]

On 8 July 2015 at 12:16, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
> 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.

So, SPL-capable u-boot will have capable to chainload itself from external
RAM is that correct? and for verifying any u-boot by running from external-RAM
should be SPL-driven, is that correct?

On that note, I have tried the same by loading u-boot on external-RAM with
TEXT_BASE and it ran very feasibly. the design is like the SOC has ROM with
first stage bootloader and second stage is u-boot and external-RAM got
initialized
in first stage bootloader(not in u-boot). this design works fine?

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

thanks!
-- 
Jagan | openedev.