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

[Peter Tyser]

On Tue, 2009-10-06 at 09:32 +0200, Wolfgang Denk wrote:
> Dear Peter Tyser,
> 
> In message <1254783670-21301-1-git-send-email-ptyser at xes-inc.com> you wrote:
> > It looks like the 85xx platform is the only one which has boards
> > with the bss at 0x0.  It uses a slightly different linker script
> > format which puts the bss after the reset vector, which is
> > 0xfffffffc + 4 for a number of boards.  Other platforms don't put
> > their bss in a similar location, so they don't have this issue.
> > I verified this by running MAKEALL and printing the bss address
> > as well.
> > 
> > A few bytes of RAM are wasted for boards which used to have the
> > bss at 0x0 FWIW.
> 
> I never understood how this is supposed to work at all.
> 
> We have two phases of operation:
> 
> 1) before relocation to RAM. Here we actually do not have a working
>    bss segment at all, no mater what the linker may think.

Agreed.

> 2) after relocation to RAM. Here we reserve space for the BSS at the
>    end (well, more or less) of the RAM.

Agreed.

> 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.

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...


FWIW, it looked like non-85xx PPC boards seem to do something like:
0xfff00000 text
0xfff50000 data
0xfff60000 bss
0xffff0000 "boot page"/reset vectors

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
bootpage and wasn't sure what the ramifications of having the bss
address wrap back around to 0x0 were (or if the wrapping is even a
concern) so didn't use this memory layout.  Other arches seem to do this
though...

Anyway, this patch just adds 0x10 to boards that already have their bss
at 0x0.  But maybe those boards already have issues:)  I'll investigate
at bit and follow up.

Best,
Peter