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

[Peter Tyser]

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:)

Best,
Peter

PS. please keep the original email recipients on CC