On Oct 6, 2009, at 9:01 AM, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254830475.22896.43.camel@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.
Where is BSS on 44x boards? I dont see any reason we shouldn't be able to put it at the same location.
- k