[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
Wolfgang Denk
wd at denx.de
Tue Oct 6 16:01:36 CEST 2009
Dear Peter Tyser,
In message <1254830475.22896.43.camel at 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
More information about the U-Boot
mailing list