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

[Peter Tyser]

On Tue, 2009-10-06 at 15:34 -0700, J. William Campbell wrote:
> 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.

Hi Bill,
I understand that the final addresses in RAM of all the sections are
calculated by U-Boot during relocation based on memory size.  However,
the section addresses are the same relative to each other at link time
as well as after relocation.  Eg before relocation I print out:

(408) &_start = fff80000
(409) &__bss_start = (null)
(410) &_end = 00008184
Now running in RAM - U-Boot at: 7ff70000 (After relocation)
(665) &_start = 7ff70000
(666) &__bss_start = 7fff0000
(667) &_end = 7fff8184

The values all changed and are dependent on RAM size, but their
relationship to one another didn't - they all just increased by
0x7fff0000.  So practically speaking, we do need to know where the bss
is at link time - its address is not dynamic like the malloc pool or
stack - its tied directly to the address of the other sections at link
time.  (Unless we added some bss-specific fixups I imagine)

Am I missing something?  Is there an example that would make things
clearer?

Best,
Peter