[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

[Peter Tyser]

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