[LinuxBIOS] ELF loader in v3
patrick at georgi-clan.de
Fri Jun 29 22:03:26 CEST 2007
Stefan Reinauer wrote:
> You read the option table in grub2? Why? (sorry I think we talked about
> it but it slipped away in the patch orgies of the recent days.
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
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 this is the same on v2's compressed payload, is it?
I have no idea how v2 does it, sorry!
>> This complicates ELF loading as now there is a risk that the raw ELF
>> file and the ELF image overlap. (Right now, I just use an address that I
>> know is beyond the ELF's range)
> Can we use the very low or very high memory for this?
Could still be claimed by the ELF image.
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.
Of course, that would happen on every boot, so maybe a default address
at some harmless location, with the option to override it somehow
(normal/elf-position in lar containing the address?) is to be preferred.
> should think carefully about this stuff. Will any OS ever claim to be
> copied into the low 1M?
lbgrub2 right now is copied to 64k - though I can change that.
> Is this going to replace int elfboot_mem(struct lb_memory *mem, void
> *where, int size)?
> I am not really sure I understand the issue completely yet.
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
The goal is to still have simple to read code.
Of course, the easiest way would be to require the payload to leave a
defined chunk of memory alone, and that the ELF image fits into that
> Could you create a lar-fs for grub2 that is always compiled in for
> LinuxBIOS? Then the modules could be easily loaded from there (plus a
> kernel, a menu.lst and all the other stuff that we might want to put
> Would such an FS solve your specific problem? Would we still need to
> solve the generic problem?
This (getting the modules somewhere) is actually a separate problem: The
problem above is that we have to copy a compressed ELF image somewhere
before elfboot_mem can parse it, which could collide with the memory
ranges claimed by the ELF sections.
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
Sorry, if I didn't separate the two issues enough.
More information about the coreboot