[U-Boot-Users] u-boot BOOTELF clearing SHT_NOBITS sections

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080504/5fbb8685/attachment.pgp