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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
