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.
Best Regards, Bill Campbell > Best, > Peter > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot