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.ca...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
