[U-Boot] [RFC 00/14] x86 touch-ups (Includes new init sequence!)

[Graeme Russ]

On 23/12/11 23:25, Graeme Russ wrote:

[snip]

> So a quick overview of the new sequence and it's associated elegance (IMHO)
> (keep in mind this is x86 centric)
>  - CPU boots and runs the reset vector code
>  - early_board_init performs any insanely-low-level init that is needed
>  - car_init sets up Cache-As-RAM (and clears it so gd is zero'd)
>  - set up a stack in CAR
>  - call board_init_f() passing the address of gd in CAR[1][2]
>  - board_init_f() runs the 'init_sequence_f' functions which should
>    initialise console and SDRAM
>  - board_init_f() calls back into the assembler routine
>    board_init_f_r_trampoline - This routine is very simple - It creates a
>    new stack in SDRAM and calls back into board_init_f_r
>  - board_init_f_r is running in Flash, but with SDRAM initialised. It
>    runs an init loop which copies gd from CAR to SDRAM, initialises the
>    CPU cache (which destroys all data in CAR, but that is all safely in
>    RAM by now), copies U-Boot to RAM, clears BSS and jumps to the in-RAM
>    version of board_init_r which finishes the initialisation and enters
>    the main loop
> 
> The memory layout for x86 is pretty simple right now - gd is at top-of-RAM
> and the stack sits just below it. U-Boot .text, .data, .bss etc are below
> the stack and the heap is below U-Boot. I understand that other arch's are
> more complex (LCD frame buffers in top-of-RAM for example) - I think this
> can all be dealt with elegantly with this code as well, but I have not
> attempted to do so
> 
>  [1] The board_init_f() has different meanings for different arch's already
>  [2] This parameter is not used, but could be in future to remove the 'gd
>      pointer in a fixed register' hack

This will not work as printf() and friends require a functional Global Data
pointer

Passing a Global Data pointer to board_init_f_r() like I do is also
problematic - I move Global Data to RAM and trash the in-cache copy, but
the gd still points to the (now trashed) cache copy until we jump to RAM
(quite frankly, I don't know how it worked in the first place...)

The only way this can work is if I either:
 1) Reserve a register, or
 2) Reserve a writeable location in some memory location which is available
    prior to SDRAM init

x86 is the only arch that does not use a reserved register for the global
data pointer, but I have proved previously that x86 is capable of this
construct:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88462

So I'll adjust this patch set accordingly

Regards,

Graeme