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

[J. William Campbell]

Peter Tyser wrote:
> On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote:
>   
>> 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.
>>     
>
> Hi Bill,
> What's the advantage of having the bss not be located next to U-Boot?
> The big disadvantage of picking an arbitrary address for the bss is that
> there's now 1 more magical section of SDRAM that the user needs to know
> shouldn't be used.  I already field enough question from people that
> corrupt their exception vectors or stack/malloc pool/u-boot code, I
> don't want to add more bss questions:)
>   
Hi Peter,
      The point is that the address chosen for the ld step is NOT the 
address in ram where the bss will reside anyway. This address can 
overlap the exception vectors, stack, or even the u-boot code itself and 
it wouldn't matter (other than possible confusion). The actual physical 
address where the bss and u-boot itself resides is COMPUTED by u-boot 
after it sizes memory. u-boot only needs to know how big the section is 
in order to allow enough room. All references to the bss will then be 
re-located correctly. Where the bss actually ends up is a function of 
u-boot code. It may be on some processors that the computation of bss 
start is done assuming the bss is adjacent to u-boot in the original 
memory map, but if so, it is an un-necessary restriction. All that is 
required is a "safe" chunk of ram, which is also what is needed for 
stack and malloc area and should be chosen in a similar manner. So at 
run time, bss probably ends up adjacent to u-boot in ram because that's 
how it was coded, but at ld time it shouldn't matter.

Best Regards,
Bill Campbell
> Best,
> Peter
>
> PS. please keep the original email recipients on CC
>
>
>
>