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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
