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