[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