[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