Hello Thomas,
On Thu, 12 Nov 2015 16:28:38 +0800, Thomas Chou thomas@wytron.com.tw wrote:
Hi Albert,
On 2015年11月12日 15:17, Albert ARIBAUD wrote:
diff --git a/common/init/board_init.c b/common/init/board_init.c index 8839a4a..703e6d8 100644 --- a/common/init/board_init.c +++ b/common/init/board_init.c @@ -46,6 +46,7 @@ void board_init_f_gd(struct global_data *gd_ptr) for (ptr = (int *)gd_ptr; ptr < (int *)(gd_ptr + 1); ) *ptr++ = 0; #endif
- arch_setup_gd(gd_ptr);
Correct -- in ARM (Thumb-1 at least) we cannot use arch_setup_gd() so we set GD (in r9) from within arch/arm/lib/crt0.S, but for NIOS2 it might (and apparently does) work. Where is GD stored in NIOS2?
It is a register, r26 "gp".
Ok. In ARM it is r9, and gcc is prevented from ever using r9 by adding the compiler option -ffixed-r9 to the compiler command lines. I guess the same goes for NIOS2 -- maybe the NIOS2 gcc does not even need an option, and always leaves gp/r26 alone.
I have another question. Will it be simpler to have two calls instead of four?
get size of gd plus malloc.
init gd and malloc.
I'd hinted at reducing the number of functions, but not the number of calls, in my reply to Simon Glass in this thread, see here: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/240520
Your proposal might indeed help reducing the number of calls as well.
The first function would receive the current top of the stack and would subtract the (aligned) gd then the (aligned) malloc arena size, and return the new top-of-stack, which the C runtime code would enforce in sp (or whatever the equivalent is in each arch) -- BUT it would not write anything in that space as it would not be reserved at that point.
The second function would receive this new top-of-stack again, this time as a base of the reserved space (or it could receive the old top-of-stack and work its way downward) and would be able to safely write whatever it wants inside this space.
The only caveat is, we need to be sure that the second function can reconstruct the base addresses of all allocated chunks (gd, malloc, whatever they'll be wanting to add later) just like the first function computed them (it could still be a single function called twice as I'd suggested, BTW).
Thanks for the suggestion! I'll consider it for v3.
Best regards, Thomas
Amicalement,