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