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