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

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

[Jagan Teki]

Hi All,

I'm running u-boot from u-boot prompt, just like a standalone
application with CONFIG_SYS_TEXT_BASE address.

Cache were turned off
#define CONFIG_SYS_DCACHE_OFF
#define CONFIG_SYS_ICACHE_OFF

Log:
u-boot# tftp 0x0 u-boot.bin
u-boot# go 0x0
## Starting application at 0x00000000 ...


U-Boot 2015.07-rc3-00054-g891b487-dirty (Jul 08 2015 - 03:18:18 +0530)

Board: ARM64 Reference Board
I2C:   ready
DRAM:
"Synchronous Abort" handler, esr 0x96000061
ELR:     14880
LR:      14838
x0 : 00000043ffffffff x1 : 0000000000000000
x2 : 0000000000000020 x3 : 0000000000000001
x4 : 000000001d0e2dc0 x5 : 0000000000000000
x6 : 00000000ffffffc8 x7 : 00000000ffffffff
x8 : 0000000000000073 x9 : 00000000ffffffff
x10: 0000000000000002 x11: 0000000000000030
x12: 0000000000000001 x13: 000000001d0ecae8
x14: 0000000000000006 x15: 000000000003f7a0
x16: 0000000000001d4c x17: 0000000000003a98
x18: 000000001d0efea8 x19: 000000001d0e97c8
x20: 0000000000000000 x21: 000000000002fe5b
x22: 0000004000000000 x23: 000000000002f000
x24: 000000001d0ef7c8 x25: 000000001d0e3070
x26: 000000001d0efdd0 x27: 0000000000000000
x28: 000000000002fe42 x29: 000000001d0e3000

Resetting CPU ...

Has any one tried the same before, please let me know for any inputs?

thanks!
-- 
Jagan.

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

[Wolfgang Denk]

Dear Jagan,

In message <CAD6G_RQnrBWyPp1CyiDxkZ4vme4PB5fNHDX-f2Sf=9CvrodcWg@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.
...
> 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

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
"The POP3 server service depends on the SMTP  server  service,  which
failed to start because of the following error: The operation comple-
ted successfully."                         -- Windows NT Server v3.51

[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@denx.de> wrote:
> Dear Jagan,
> 
> In message <CAD6G_RQnrBWyPp1CyiDxkZ4vme4PB5fNHDX-f2Sf=9CvrodcWg@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.

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

[Jagan Teki]

On 8 July 2015 at 12:16, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Wolfgang,
>
> On Wed, 08 Jul 2015 00:36:52 +0200, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Jagan,
>>
>> In message <CAD6G_RQnrBWyPp1CyiDxkZ4vme4PB5fNHDX-f2Sf=9CvrodcWg@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.

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

[Wolfgang Denk]

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.

> 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

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

[Wolfgang Denk]

Dear Jagan,

In message <CAD6G_RSKRy4QcjdHz6GtOwcWbDvYfFWCwJd2X3k91UVXSFf+uQ@mail.gmail.com> you wrote:
>
> 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?

It may work (and very often does), but there are subtle things to keep
in mind (like write-once registers) which are good for nasty
surprises sometimes.

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
"Have you lived in this village all your life?"        "No, not yet."

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

[Albert ARIBAUD]

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.