[LinuxBIOS] ELF loader in v3

Stefan Reinauer stepan at coresystems.de
Sat Jun 30 17:26:51 CEST 2007

* Patrick Georgi <patrick at georgi-clan.de> [070630 07:47]:
>  Anyway: The proposal is to decompress the ELF image (the file generated by 
>  the linker) a second time, if the default location where it is compressed to 
>  collides with the memory used by the payload. When doing it the second time, 
>  all information is available to avoid another collision.

Ok. Then we have two seperate issues that might happen, that are not yet
handled in v3:

* loaded Payload gets into conflict with uncompressed payload
* loaded payload gets into conflict with LinuxBIOS.

Any way to solve these in 1 step? We could enhance the memory space used
by linuxbios by the space used by the decompressed image, and relocate
that space completely on demand when loading the payload wants to use
that area.

>  Moving it only helps if we decide on a memory layout. I need a place where I 
>  can decompress the ELF image to - either dynamically using a method like the 
>  one above or fixed, and reserved for that purpose.
I suggest putting the decompress buffer right behind the memory used by

>  As for my "trouble of the moment", I can just go on uncompressing the 
>  payload to 0x80000 (which I hardcoded) and move on with grub. That's not a 
>  permanent solution, though.

Yes, but its fine for the moment.

We could also make the uncompression space configurable in linuxbios,
hidden behind "Advanced user options" or so? So we choose a default
position for every known payload at this time (Filo/Grub/OFW/Linux/?)
and if someone wants to use a payload that breaks this, it can be
changed in the config, in case we have no control over the payload
source to change it there.


coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/

More information about the coreboot mailing list