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

[Simon Glass]

Hi Graeme,

On Sun, Dec 25, 2011 at 9:18 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> 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

I have a unified board series for ARM and x86 so will see if I can send it.
Still needs work on x86.

Regards,
Simon

>
> Regards,
>
> Graeme