[U-Boot] RFC: Aligning arch initialisation sequences

[Graeme Russ]

On 14/11/10 11:35, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4CDF2C8B.3060401 at gmail.com> you wrote:
>>
>>> You cannot and must not touch SDRAM in board_early_init_f(). And even
>>> more, you must not at all run relocate_code() there!
>>>
>>
>> See:
>>  arch/powerpc/lib/board.c
>>  arch/m68k/lib/board.c
>>  arch/arm/lib/board.c
>>
>> They all malloc the final global data structure, memcpy the temporary
>> global data to the malloc'd global data, and call relocate_code passing a
>> pointer to the new global data all at the very end board_init_f() and
>> therefore after SDRAM has been initialised
> 
> Yes, and this is correct. board_init_f != board_early_init_f
> 

Ah, I see...

board_early_init_f() is (in most cases) the very first entry in the
init_sequence[]

So if global data is defined on the stack in board_init_f() and copied to
the heap at the end of board_init_f() we should be OK. Is global data
needed prior to board_init_f()?

For x86, I allocate global data in asm and set three members. The sticking
point for me is the single ulong parameter to board_init_f() which does not
present enough flexibility to pass all the information I need.

I could create a stub x86_board_init_f which has all the parameters I need,
allocate global_data on it's stack, setup global data based on the
parameters and call board_init_f() passing the pointer to global data. x86
could then do the same as the other arches and copy global data to a
malloc'd version.

One step closer to unification.

One nit-pick is that, in reality, the stack space used by board_init_f() is
never reclaimed because it never returns. What we could do is reset the
stack pointer prior to calling board_init_r()

I still have no way to globalise gd prior to relocation though :( (still
thinking)

Regards,

Graeme