On Sunday 04 May 2008, Baruch Cochavy wrote:
Many thanks for the quick reply/comments. Please allow me to explain: I try to bootelf from ELF bits residing in a region of memory (address range) that partially overlaps the loaded code .bss (the ELFs bits just happen to reside in that specific memory region that will eventually become the .bss by pure coincidence of address selection.)
converting the ELF into a bootable U-Boot image may work better ...
Of course, a section of memory outside the reach of the application can be found to hold the ELF bits. Unfortunately, this also wastes valuable RAM bits (the Elf bits get downloaded; they are at no stage ROM resident), or will otherwise require some run-time memory layout calculation trickery I would rather avoid.
as soon as you say "load an ELF", you've already agreed to waste space. the ELF itself is full of information that is not needed at all. this is why we have the bootable U-Boot format. or you convert it to binary using objcopy, and just execute that.
And a final note: try as I may, I could find no specific reference (ABI or otherwise) to indicate whose responsibility is it to clear the .bss. As for u-boot, I assume any change here would break things working today. Possibly, a bootelf invocation option would be nice....
i would be willing to bet that there is no document anywhere. there are general guidelines, but really the only requirement as i mentioned is that as soon as you do start executing C, the C runtime environment must have been fully initialized. some people think the crt objects (either from the toolchain or hand written) should do it. others think the ELF loader should be doing it. -mike