On Tue, 2009-10-06 at 09:07 -0500, Kumar Gala 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.
My concern was that we use __bss_start and _end to calculate the size of the bss to zero out. If the bss wraps, I'd be concerned about what gets cleared as _end would be truncated to a low memory address while __bss_start would be a high memory address. Or other similar problems - I didn't investigate what would really happen, I was just worried what could happen:) > Where is BSS on 44x boards? I dont see any reason we shouldn't be > able to put it at the same location. >From the XPedite1000: [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .resetvec PROGBITS fffffffc 03f2e4 000004 00 AX 0 0 1 [ 2] .bootpg PROGBITS fffff000 03e2e8 000250 00 AX 0 0 1 [ 3] .text PROGBITS fff80000 000094 0303b0 00 AX 0 0 4 [ 4] .rodata PROGBITS fffb03b0 030444 00a14c 00 A 0 0 4 [ 5] .reloc PROGBITS fffba500 03a594 002280 00 WA 0 0 4 [ 6] .data PROGBITS fffbc780 03c814 00088c 00 WA 0 0 4 [ 7] .data.rel.local PROGBITS fffbd00c 03d0a0 000a98 00 WA 0 0 4 [ 8] .data.rel.ro.loca PROGBITS fffbdaa4 03db38 0000b0 00 WA 0 0 4 [ 9] .data.rel PROGBITS fffbdb54 03dbe8 000100 00 WA 0 0 4 [10] .u_boot_cmd PROGBITS fffbdc54 03dce8 000600 00 WA 0 0 4 [11] .bss NOBITS fffbe300 03e2e8 011c44 00 WA 0 0 4 I shied away from this for the 2 reasons above - the bootpg section will be wiped out when the bss is cleared for images near their maximum size and I wasn't sure if there were any ramifications about the bss wrapping around to 0. Other arches must have a similar issue which would somewhat imply: 1. No one cares if their bootpg/reset vector is cleared 2. U-Boot works even if the bss wraps around to 0. If everyone is OK with the limitation of #1 above I can make the 85xx act like the other PPC boards. The only downside I see is that we could never put any non-reset related code in the bootpg. Best, Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot