Hi Robert,

On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day rpjday@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@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