[U-Boot] [PATCH v2] Fix board init code to use a valid C runtime environment

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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?
> 
> 1. get size of gd plus malloc.
> 
> 2. 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,
-- 
Albert.