On Oct 6, 2009, at 9:01 AM, Wolfgang Denk wrote: > 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.
Where is BSS on 44x boards? I dont see any reason we shouldn't be able to put it at the same location. - k _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
