Dear Peter Tyser,
In message 1254870618.24664.3061.camel@localhost.localdomain you wrote:
I understand that the final addresses in RAM of all the sections are calculated by U-Boot during relocation based on memory size. However,
True. And nothing is ever written to the bss addresses as recorded in the linked image as running from flash, may thei be 0x0 0r 0x10 or any other random address.
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)
Right, that's the current situation.
My suggestion was NOT to put the bss at a fixed _offset_ to the U-Boot image, but to a fixed absolute address. My hope is that this might simplify the linker scripts at the cost of adding a little code to the relocation routine - for addresses in the bss we would have to add a different relocation offset.
Best regards,
Wolfgang Denk