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