[U-Boot] why does "board_init_r()" accept a second arg of "ulong dest_addr"?
Simon Glass
sjg at chromium.org
Fri Apr 12 13:09:28 UTC 2019
Hi Robert,
On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
>
>
> was tracing the ARM-based boot sequence and ended up at the call to
> board_init_r():
>
> void board_init_r(gd_t *new_gd, ulong dest_addr)
> {
> /*
> * Set up the new global data pointer. So far only x86 does this
> * here.
> * TODO(sjg at chromium.org): Consider doing this for all archs, or
> * dropping the new_gd parameter.
> */
> ... snip ...
>
> but as i read board_init_r(), it's not clear what that routine is
> doing with that second argument, "dest_addr".
>
> there is no explicit reference to that argument in that routine that
> i can see. i backtracked to arch/arm/lib/crt0.S to see the setup for
> the call:
>
> /* call board_init_r(gd_t *id, ulong dest_addr) */
> mov r0, r9 /* gd_t */
> ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
> /* call board_init_r */
> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)
> ldr lr, =board_init_r /* this is auto-relocated! */
> bx lr
> #else
> ldr pc, =board_init_r /* this is auto-relocated! */
> #endif
> /* we should not return here. */
> #endif
>
> so i can see the assignment to registers r0 and r1, and thought maybe
> there's something down the road that expects that argument explicitly
> in r1 but i can't tell.
>
> i'm currently reading doc/README.arm-relocation to see if i've
> overlooked something trivially obvious, but is there a simple
> explanation as to the purpose of that second argument being passed to
> board_init_r()?
I believe this is not used. The value is available in gd->dest_addr
and we now read it from there.
So perhaps this argument could be dropped.
Regards,
Simon
More information about the U-Boot
mailing list