Hi Graeme, On Sun, Dec 25, 2011 at 9:18 PM, Graeme Russ <graeme.r...@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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot