Re: [RFC] 'EFI' machine feature

[Koen Kooi <koen.kooi@linaro.org>]

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