Hi Robert, On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day <rpj...@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(s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot