> > 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.
I think I see what you're getting at. If we have a bss-specific fixup routine I don't give a hoot where the bss is located at link time. Its just that that bss-aware fixup routine doesn't exist right now:) It seems like a clean solution. Adding a bss-aware fixup routine or putting the bss after the U-Boot image both seem good to me. The bss-aware fixup routine has a clearer readelf output and slightly more complicated code while the bss-after-uboot change has a misleading readelf output and simpler code. In any case I'd give a thumbs up to either of them. Best, Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
