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

[Wolfgang Denk <wd@denx.de>]

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made the integers; all else is the work of Man.       - Kronecker