Hi guys,

I've been looking at the patches Matthew Garrett wrote for loading a UEFI stub kernel through GRUB, and noticed one thing that may require updates to the stub code: it uses GRUB to load the initrd. Doing this of course means the initrd does not need to go into the EFI System Partition, which is a lot nicer from the distros' position.

Now, in x86 land GRUB just passes the stub a bootparam structure, and I assume it just keeps filling the same structure in before passing it on to the kernel .

On ARM*, we would need to get this information over "some other way", where the obvious candidate would be FDT.

GRUB could register an empty devicetree, with only the initrd information in it, as a UEFI configuration table. (Getting a UUID for this was discussed in New Orleans.) Or, on systems using FDT for hardware description, once firmware becomes mature enough to do this themselves - add this information to the system-provided one.

The stub would then need to look for this devicetree, and if present, copy the initrd nodes across into the one it loads itself.

Alternatively, we could define a special protocol for passing additional parameters to the stubbed kernel ... or a special protocol to pass a special FDT but I'm not sure we want yet another interface.

Thoughts?

/ Leif