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

Graeme Russ
2011-12-26T05:18:39Z

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