[OE-core] [RFC] 'EFI' machine feature

[Darren Hart]

On Thu, 2014-01-23 at 13:17 +0100, Koen Kooi wrote:
> Hi,
> 

Hi Koen,

> While working on the ARM support for GRUB I noticed that the EFI support 
> in OE-core is a mess. A lot of it is due to GRUB insisting on its 
> byzantine config/install/skynet system and the rest is due to the 
> EFI==x86 assumption.

Some of the horrible not-really-native grub recipe wreakage was recently
improved. But it is still rather arcane, agreed. The x86-ism was just a
relic for that being where support was done first. So yes, all good
stuff to see improved.

> 
> To improve this I'd like to start with adding an 'efi' MACHINE_FEATURE, 
> which will:

There is an efi MACHINE_FEATURE - so you want to extend that one right?

> 
> * Mask non-EFI configs like grub-pc/grub-uboot

We need to be careful here. It is valid to build hybrid images which
support both EFI and legacy PC boot (for example). We do this now with
the EFI and PCBIOS MACHINE_FEATURES - see bootimg.bbclass. So on this
one point, I'd say no, don't mask them. You can make them need to
specify their own MACHINE_FEATURE though.

> * allow PACKAGECONFIG instead of distro/arch/machine overrides in grub2
> * Activate logic in image classes to create a GPT EFI System Partition

I'm not following this - but this isn't my area of expertise. How does
PACKAGECONFIG help us here?

Also, keep in mind that while good for use on the actual device, GPT is
problematic on disk images as the spec requirs the backup table on the
last LBA of the disk, so using a disk image of even a slightly different
size on a physical disk will result in irritating errors on boot. MSDOS
partition tables are better for disk images (unfortunatley).  GPT is
appropriate for tools like wic, however, which do deal with the physical
device.

> 
> Further steps to address EFI support would be:
> 
> * integrate gummiboot into OE-core (meta-intel has an old version)

Yes please. Take that recipe, bump the SRCREVs, and submit it to
oe-core. We've made some improvements to gummiboot recently for cross
compilation and such, it would be nice to see these incorporated.

> * deprecate grub-(not really)native

In favor of what? gummiboot? I'm all in favor of that!

> * create an efi bbclass that does the above ESP dance and knows how to 
> populate it further e.g. grub.cfg and bootloader-spec entries for gummiboot.

The bootimg.bbclass does something along these lines and abstracts the
various calls out to syslinux, grub, grub-efi, etc. Are you looking to
expand this, replace it.... ?

> * postinst magic to update bootloader config on kernel upgrade
> 
> Opinions/Flames/ACPI rants?
> 

Generally speaking, this looks like the right approach.

-- 
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center