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. -mike