Skip to content

RFC x86 touch-ups (Includes new init sequence!)

Graeme Russ u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest0 of 14 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 14 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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

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

[snip]

Quoted 26 lines

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

Quoted 3 lines

[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

Read the cover letter in its thread