[LinuxBIOS] ELF loader in v3

Patrick Georgi 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 
there.

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

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 
memory range.
> 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
> there)
>
> 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 
modules)
Sorry, if I didn't separate the two issues enough.


Regards,
Patrick Georgi





More information about the coreboot mailing list