Hi Graeme,
Le 29/02/2012 23:41, Graeme Russ a écrit :
Hi Mike,
On Thu, Mar 1, 2012 at 9:29 AM, Mike Frysinger<vap...@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().
Regards,
Graeme
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
