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@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:
- OR in an offset to the bss address and leave some good comments in
the linker script and commit message
- Make the bss the last section like other PPC boards which would
result in the bootpg sometimes being overwritten
- 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