[U-Boot] RFC: Aligning arch initialisation sequences

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

Hi All,

I've been looking at how x86 does things compared to other arches, and it
seems to have one big difference - Very little is initialised prior to
relocation. The general order for x86 is:

 - ultra-low level board initialisation
 - DRAM controller initialisation
 - DRAM sizing
 - low-level board initialisation
 - Relocation
 - init_sequence[] (including timers, serial console

Now ARM, m68k and PPC all call relocate_code well after init_sequence[]

Now I'm wondering if I should change x86 to align with these other arch's.
I think it can be done, but there are a few technicalities that make it a
non-trival task. Two big problems I foresee are timers and the global data
pointer.

Timers for x86 use interrupts which use function hooks for the interrupt
handlers - I can change all the call-back functions to use global data, and
I will have to 're-hook' the call-back functions after relocation.

The global data pointer is worse - x86 does not have a spare register to
effectively use as a global variable. I would have to do all sorts of
trickery probably involving putting the global data pointer at the very top
of the stack segment and doing some very fancy shuffling of registers which
will make global data suffer a pretty severe performance hit.

On the other hand, if I leave things the way they are, there is beauty to
be uncovered in board_init_r() - At the moment, board_init_r() consists of
the init_sequence[] loop, followed by a whole raft of function calls
wrapped around #idefs. That whole mess could all be converted to a unified
init_sequence[]. Along with current discussions on weak functions, I think
this might be a cleaner solution.

So the question is, what does everyone think I should do?
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?

Regards,

Graeme