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

J. William Campbell jwilliamcampbell at comcast.net
Tue Oct 6 22:34:02 CEST 2009


Peter Tyser wrote:
> On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
>   
>> Dear Peter Tyser,
>>
>> In message <1254843932.24664.2083.camel at localhost.localdomain> you wrote:
>>     
>>> I personally like the current implementation of putting the bss after
>>> the entire U-Boot image.  It keeps U-Boot's code, malloc pool, stack,
>>> bss, etc all in the same general area which is nice, and has the side
>>> benefit that the bootpg won't be overwritten.
>>>       
>> OK, if you think so...
>>
>>     
>>> I know ORing in 0x10 is a bit ugly, but what's the real downside of
>>> doing it?
>>>       
>> Nothing. I just hate to allocate the bss at 0x0, because this is
>> actually incorrect - it's the result of an address overflow /
>> truncation, and pretty much misleading to someone trying to read and
>> understand the code. For the linked image, it does not _look_ as if
>> the bss was located _after_ the U-Boot image, it looks detached and
>> allocated in low RAM.
>>     
>
> Do you have a preference Kumar?  You're probably going to be the first
> in line to have to deal with any resulting confusion:)
>
> I personally would rank the options:
> 1. OR in an offset to the bss address and leave some good comments in
> the linker script and commit message
>
> 2. Make the bss the last section like other PPC boards which would
> result in the bootpg sometimes being overwritten
>
> 3. Put the bss at an arbitrary address
>   
FWIW, I think an arbitrary address disjoint from the u-boot addresses is 
best. While u-boot is in ROM, you can't use the bss anyway. The bss will 
actually be located at an address selected by the u-boot code itself 
after memory is sized. All references to the bss will be re-located by 
subtracting the arbitrary start address and adding the run-time chosen 
start address. So the linked start address is not important, except that 
is cannot be NULL or it may confuse the relocation code that doesn't 
want to re-locate NULL pointers. Some of the confusion in this 
discussion probably stems from the fact that the linker scripts make the 
bss look like "part of u-boot", when it is really not. It is just a 
chunk of "zero'ed" ram, located anywhere the u-boot code decides to put 
it. An arbitrary strange address would make this more apparent.

Best Regards,
Bill Campbell
> Best,
> Peter
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>   



More information about the U-Boot mailing list