[RFC] 'EFI' machine feature

[RFC] 'EFI' machine feature

[Koen Kooi]

Hi,

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.

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

* Mask non-EFI configs like grub-pc/grub-uboot
* allow PACKAGECONFIG instead of distro/arch/machine overrides in grub2
* Activate logic in image classes to create a GPT EFI System Partition

Further steps to address EFI support would be:

* integrate gummiboot into OE-core (meta-intel has an old version)
* deprecate grub-(not really)native
* 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.
* postinst magic to update bootloader config on kernel upgrade

Opinions/Flames/ACPI rants?

-- 
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs

Re: [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

Re: [RFC] 'EFI' machine feature

[Koen Kooi]

On 02/01/2014 05:44 PM, Darren Hart wrote:
> 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?

Ehm yes. When I asked on #oe I was told there isn't such a feature, but 
I stand corrected :)


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

I had dismissed this usecase, but it seems people are actually using it, 
so I'll have to rethink this a bit.

>> * 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?

Due to the above this is moot now, but the idea was to check for the efi 
MACHINE_FEATURE and pass --target=efi to grub configure. But if we can't 
merge the recipes then this isn't an option.


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

This is a big problem and I haven't found a nice way to repair the GPT 
during install or afterwards. Adding gptfdisk to OE would be a big step 
forward since parted is being less than helpful here.

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

I have a working recipe for that, I just need to find time to clean it 
up and submit it, since that is a spare-time project.

>> * deprecate grub-(not really)native
>
> In favor of what? gummiboot? I'm all in favor of that!

For EFI grub-native isn't really needed, since it's just 'copy to ESP, 
create conf' and as you say, bootimg.bbclass already knows how to 
generate the grub config.

>> * 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.... ?

I hadn't looked at bootimg.bbclass, but it seems it does most of what I 
need.
Someone told me that fedora has patches that teach grub to use f.d.o 
bootloader spec files (aka gummiboot configs), that could reduce 
codepaths in bootimg.bbclass, but I don't know if it's a good idea to 
patch grub that way. I guess I should look at that and send an RFC :)

>
>> * postinst magic to update bootloader config on kernel upgrade

I sent a seperate RFC for that.

>> Opinions/Flames/ACPI rants?
>>
>
> Generally speaking, this looks like the right approach.

Thanks for the feedback!

-- 
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs