Hi Albert,
On Fri, Mar 2, 2012 at 8:57 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Graeme,
Le 29/02/2012 23:41, Graeme Russ a écrit :
Hi Mike,
On Thu, Mar 1, 2012 at 9:29 AM, Mike Frysingervapier@gentoo.org wrote:
On Wednesday 29 February 2012 17:22:26 Graeme Russ wrote:
On Thu, Mar 1, 2012 at 6:04 AM, Mike Frysinger wrote:
On Tuesday 28 February 2012 18:32:57 Graeme Russ wrote:
And this is why I dislike the implementation - You have to do all sorts of weird calucations to put things in the right place when, in fact, the location of gd and bd in memory is totally irrelavent.
right, that's why i minimized the pain for Blackfin users -- this is all handled in the arch's config-pre.h header. board porters only need to declare the size of regions they care about (monitor and heap sizes).
Ow, ouch! - And that padding makes things more fun - The memory layout is
U-Boot | gd | pad | bd | pad | heap
fwiw, i documented the Blackfin memory layout:
http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:memory-la yout
I had a look at this and noticed that you statically allocate locations for gd and bd (CONFIG_SYS_GBL_DATA_ADDR, CONFIG_SYS_BD_INFO_ADDR)
Considering that:
a) the gd pointer is in a register (P3) and thus easily locatable by a debugger, and; b) the bd pointer is in gd
Is there any reason not to have gd and bd in BSS?
in the Blackfin case, most likely not. we don't do relocation, and the bss is cleared long before board_init_f() gets called. the only reason for allowing the config to override would be if someone wanted to put gd/bd into on-chip L1 data, but i can't imagine this structure being performance critical enough to warrant that.
I thought as much - I moved gd/bd into BSS for x86 without really thinking about why everyone else calculates the location of these data structures around the stack and heap. The longer I think about it, the more I think that it was not a bad move and that maybe other arches can follow suit as part of standardising the init sequences
ARMs relocate and don't have a valid BSS until board_init_r() but require gd as early as board_init_f().
So does x86 - A temporary gd is kept in Cache-As-RAM until SDRAM is initialised.
I just noticed that for x86, only bd is in bss - I still calculate a permanent resting place for gd around the relocated U-Boot, heap and stack but I plan to change this so the init sequence will be:
- Create temporary gd and stack in CAR for board_init_f - After SDRAM is initialised and the new stack created, 'pivot' U-Boot so it is running from flash, but using SDRAM for stack - Copy gd from CAR to stack - Copy U-Boot to SDDRAM, clear BSS, do relocation fixups - Copy gd from stack to BSS - 'pivot' execution from flash to SDRAM (this may involve resetting the stack pointer, just to save a few bytes used by the no longer needed call stack and temporary gd, but this is not a neccessity) - Create heap below U-Boot
So the end memory layout is:
----------- Top Of SDRAM ----------- .bss \ .data + - U-Boot.bin .text / ------------------------------------
heap
------------------------------------
stack (grows down)
....................................
Free Memory
--- Bottom of SDRAM (0x00000000) ---
Simple :)
Regards,
Graeme