[LinuxBIOS] ELF loader in v3

Stefan Reinauer stepan at coresystems.de
Fri Jun 29 22:55:25 CEST 2007


* Patrick Georgi <patrick at georgi-clan.de> [070629 22:03]:
>  I don't. At some point in _LinuxBIOSv3_, some code searches for option_table 
>  and returns a pointer to ROM for further use.
>  Of course, this mechanism won't work if the option_table is compressed 
>  there.

Ah! In this case I think the file needs to be in rom uncompressed all
the time because we want to read cmos options before ram is up.

>  Right now, my solution is to mark it nocompress:, before that, I just 
>  decompressed it to a fixed location for experimentation.
>  It has to be done one way or the other.

I think the uncompress: marker is fine.

>  My proposal would be to decompress the ELF image to some location, look if 
>  that location overlaps with the places the data is copied to, and if so, 
>  determine a large-enough chunk of memory and decompress it to there again, 
>  and work from there.

So the program will not live at the address it asked for? 

>  lbgrub2 right now is copied to 64k - though I can change that.

If it gets your trouble done for the moment, please move it, until we
really figured the ELF stuff out.

>  My idea would be to let copy_elf be a wrapper around elfboot_mem (with some 
>  refactorings to more easily look at the ranges the ELF requires), with 
>  elfboot_mem still available in case "other" loading mechanisms are devised.
 
we could maybe redo some parts of what we aready have, instead of
creating a layer around it? 

>  lar-fs would solve having an additional chunk of data somewhere in memory 
>  where grub2 can find its modules. It would be some extra trouble with regard 
>  to finding the LAR, providing the decompression routines again, _having to 
>  freeze or version the lar format_ (because there's an external user), ... so 
>  I'd rather go with the current solution (just creating a large, zeroed array 
>  in the grub2 kernel and fill it up with modules)

I think we really want to freeze lar in the long or even short run. we
should get this finished within the next few weeks. Lets not freeze or
version the format during development. If early versions stop working at
some point, that is not an issue. We dont run on any hardware, yet. 
Decompression is the only issue I see with this at the moment. :( It
will make us have several copies of the same stuff again :(


-- 
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