Dear Peter Tyser, In message <1254830475.22896.43.ca...@ptyser-laptop> you wrote: > > > This whole "bss at 0x0" is a myth to me. > > Do a readelf on most MPC8548 boards, eg MPC8548CDS. __bss_start is also > located at 0x0 for these boards, which is the issue this patch attempted > to address.
I know that this _is_ the case. My questions meant: _why_ is this the case? My speculkation is that it's just by accident, because the bss was located just after the instruction allocated for the reset vector; this being at 0xFFFFFFFC on most 8xxx systems, the address counter wrapped around on 32 bit tool chains, resulting in 0x0. > The current U-Boot code is already relocating this bss address higher up > in SDRAM during relocation, all this patch does is add 0x10 bytes to > that address. I had assumed the current code was working, but perhaps > there's a bigger issue... I don;t think it's an issue. The code seems to work. But I wonder if we could not simplify all this buy defining an arbitrary, non-zero address. > I shied away from this since as the text/data/bss grow at some point the > bss is going to overlap with the boot page. I think ld would > intelligently wrap the bss around the boot page, but U-Boot won't be so > intelligent when the bss is zeroed out:) The bss address range would > also wrap back around to 0x0. I didn't feel good about zeroing out the But bss is NOLOAD, and the actual location in the flash is just a fiction - we never use anything of this but the start address. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God made the integers; all else is the work of Man. - Kronecker _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
