[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
Kumar Gala
galak at kernel.crashing.org
Tue Oct 6 16:07:32 CEST 2009
On Oct 6, 2009, at 9:01 AM, Wolfgang Denk wrote:
> 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.
Where is BSS on 44x boards? I dont see any reason we shouldn't be
able to put it at the same location.
- k
More information about the U-Boot
mailing list