[U-Boot] RFC: Aligning arch initialisation sequences

[Graeme Russ]

On 13/11/10 17:38, Reinhard Meyer wrote:
> On 13.11.2010 07:31, Reinhard Meyer wrote:
>> Dear Graeme Russ, Dear All,
>>> On 10/11/10 10:35, Mike Frysinger wrote:
>>>> On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote:
>>>>> Should all architectures strive to look as much like one another as
>>>>> possible? Should we accept that maybe this particular issue be thrown in
>>>>> the too hard basket?
>>>>
>>>> imo, we should strive to have these things in one common place and not
>>>> just
>>>> have the different files look the sam
>>>
>>> I was afraid someone would say that. I've been having a look and a think
>>> about the situation for x86, and I cannot come up with a sane way to
>>> emulate the way the global data pointer is handled by the other arches.
>>>
>>> I essence, the gd pointer is a unique global variable available prior to
>>> relocation. On all other arches, this is achieved by using a reserved
>>> register which I do not have the luxury of on x86 :(
>>>
>>> Unless I can resolve this, I cannot move x86 in line with the other arches
>>> (i.e. init functions can only be done after relocation).
>>
>> <Ducks><Flame shield>
>> I *personally* prefer code without tool-chain specific, out of "C"
>> constructs. So I would be fine with passing gd as a parameter to all
>> pre-relocation functions. The way they are called with a function array
>> that would probably only marginally increase code size. And instead of
>> all the funky stack calculations to get the space for gd, it could be
>> achieved in a much simpler way:
>>
>> in asm: set stack to end (or begin) of SRAM (or whatever)
>>
>> in c:
>> board_early_init(void)
>> {
>>     gd_t    auto_gd;
>>     ...
>>     call all pre-relocation functions with&auto_gd as parameter
>>     ...
>>     relocate and fixup (preferably in C) - would probably
>>     have arch-specific parts in the ELF fix-up
>>     ...
>>     memcpy (&static_gd,&auto_gd, sizeof auto_gd);
>>     ...
>>     setup final stack and jump to relocated code...
>>     that should be a *small* assembly helper function
>> }
>>
>> You get the idea ;)
>>
>> </Flame Shield></Ducks>
> 
> Ok, ok, I forgot the hitch that some functions called from
> the pre-relocation functions also would need the auto_gd passed on,
> *if* they need to use gd. That might become ugly, but x86 has solved
> that somehow?
> 

Yes, by declaring gd as a global (static) variable and only referencing it
after relocation (well actually, it is passed as a parameter to
board_init_f (in lieu of boot_params) where the relocation is performed

Regards,

Graeme