[U-Boot] RFC: Aligning arch initialisation sequences

[Graeme Russ <graeme.russ@gmail.com>]

On 14/11/10 20:04, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4CDF36E3.7060505@gmail.com> you wrote:
>>
>> board_early_init_f() is (in most cases) the very first entry in the
>> init_sequence[]
> 
> Right.
> 
>> 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()?
> 
> Yes, as we have no writable data segmeit before relocation. We need a
> way to pass around some data.
> 
>> 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.
> 
> Pass a pointer to a struct ?

Which is what I do (a pointer to a gd_t allocated in asm)

There are two minor perceived 'issues' with board_init_f()
 1) The parameter is defined as a 'ulong bootflag'
    - arm, blackfin, mips, and powerpc do not use the parameter at all
    - avr redefines it as 'ulong board_type'
    - x86 uses it as a gd_t *
    - m68k and sparc use it as bootflag
    - microblaze and nios2 do not even use board_init_f() (they defines
there own board_init(void)
    - sh is like microblaze and nios2 but defines sh_generic_init()

 2) At least one list member does not like the allocation of global data in
asm and suggests that it should be on the stack of board_init_f() and
copied to the heap at the end of board_init_f() (NOTE: there was some
confusion with board_early_init_f(), but I think the discussion always
intended to focus on board_init_f())

and a few other inconsistencies:
 - blackfin and avr do not use init_sequence[] (but look like they could)
 - blackfin has an interesting (read wrong) comment:
   * The requirements for any new initalization function is simple: it
   * receives a pointer to the "global data" structure as it's only
   * argument, and returns an integer return code, where 0 means
   * "continue" and != 0 means "fatal error, hang the system".
 -

Why don't we just change board_init_f(ulong bootflag) to board_init_f(gd_t
*gd)? avr would need a slight mod to add board_type to gd_t. m68k and sparc
would need similar to add bootflag

So start.S would calculate the location of the initial global data struct
(in cache, SRAM, Flash etc) and pass this to board_init_f(). A lot of
arches would just pass a constant (arm would pass CONFIG_SYS_INIT_SP_ADDR
for example)

> 
>> 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()
> 
> This is not correct. After relocation, we set up a completely new
> stack in RAM.

Ah, OK - x86 does not, but after the realignment of x86 to the other
arches, I will do this as well

Regards,

Graeme