[OE-core] RFC: EFI Support

[Darren Hart]

On 11/21/2011 02:15 PM, Tom Zanussi wrote:
> On Wed, 2011-11-16 at 17:22 -0800, Darren Hart wrote:
>> I'm working to provide EFI boot support for the BSPs in the meta-intel
>> layers for the Yocto Project. There are several points to consider and
>> before I start work on an implementation, I would appreciate a review of
>> this proposal. I'll present the various points to consider, and then
>> follow with my proposed solution.
>>
>> Booting on a pure UEFI system requires an EFI loader. This can currently
>> be one of GRUB2, elilo, efilinux, or even a Linux bzImage with the
>> experimental EFI_STUB patches applied. Many targets can boot with the
>> legacy BIOS services or will need to support both legacy and EFI
>> booting, depending on which firmware version is installed on the target.
>> This decision is complicated by license issues (GRUB2 is GPLV3),
>> functionality issues (efilinux has no UI), and complexity issues (I'd
>> rather not introduce yet another bootloader - elilo - into oe-core).
>>
>> Supporting EFI boot has two meanings in my estimation. First, we need a
>> recipe for an EFI capable bootloader which can be specified with
>> EXTRA_IMAGEDEPENDS in the machine config, in the same way uboot is
>> specified by beagelbaord.conf. Second, the live (hddimg) images need to
>> be constructed to support EFI. We could build EFI for every live image
>> and build universal live images with support for both legacy and EFI
>> boot, or we could provide a mechanism to indicate if one or the other
>> (or both) mechanisms are required for a given BSP.
>>
>> As for the selection of an EFI bootloader. For the IA32 BSPs, I intend
>> to move to an all Syslinux set of bootloaders eventually. They provide
>> all the necessary functionality and are much less complex than GRUB2.
>> Unfortunately, Syslinux does not yet support EFI boot. The efilinux
>> project does, and I now have working recipes for it, but it does not
>> have a UI, and requires either a script, built-in kernel command line,
>> or nvram changes in order to boot a kernel with kernel parameters. It
>> also has no UI, which would break the existing live image "boot or
>> install" boot options. For the time being, I propose building GRUB2 with
>> EFI support for BSPs that support it. That limits live images for EFI
>> BSPs to GPLV3. When Syslinux has EFI support, I propose switching to
>> Syslinux, removing the GPLV3 requirement. This will simplify the images
>> as Syslinux can be used for the ISO images, the legacy boot, the EFI
>> boot, and the boot after installed to the harddisk. A common menu format
>> can be used and provide a much more consistent experience for these BSPs.
>>
>> As to the mechanism for building the live images, I propose using a set
>> of MACHINE_FEATURES values to indicate the type of boot, for example:
>> PCBIOS and EFI. Machines wishing to construct live images for both,
>> would specify both. The grub2 recipe would then be modified to build the
>> efi option if EFI is set. The bootimg and image-live classes would be
>> modified to test for PCBIOS and EFI, and prepare the FAT32 hddimg
>> accordingly, with either or both boot mechanisms in place. If an
>> EFI-only BSP assumes a custom image needs to be created, they add grub2
>> to the EXTRA_IMAGEDEPENDS, specify EFI in MACHINE_FEATURES, and drop
>> live from the image types.
>>
>> I believe this approach holds true to the intent of the live images and
>> enables EFI systems in the most compatible way, while being minimally
>> invasive to oe-core.
>>
>> Have I overlooked anything? Would I break some use case that I haven't
>> thought of? Is there a better mechanism than MACHINE_FEATURES for the
>> EFI and PCBIOS flags?
>>
> 
> Hi Darren,
> 
> This all looks reasonable to me...
> 
> But just curious, when do you think syslinux will support EFI? - it
> seems unfortunate to spend a lot of time implementing the above scheme
> only to back it out the day syslinux gets EFI support...

Given the state of efilinux, I'd guess sometime next year - but I can't
for sure. I plan to make the implementation generic enough that it would
be fairly straightforward to swap out one EFI loader for another.

> 
> Also, the bzImage with EFI_STUB looks really interesting - I could
> imagine some dedicated applications wanting to install such that they'd
> boot directly into the kernel and get the fastest boot times possible.
> Does that make sense, and if so would there be any support for that?

Right now I don't plan to do anything special here. The idea being that
these use cases will be sufficiently custom that a manual copy of
bzImage to bootia32.efi will be acceptable - or a custom bootimg type
class will be needed for the platform anyway.

That said, this could be made a bit more generic by a linux-efi recipe
which the user could select instead of grub-efi. I'm hoping to do some
kind of "virtual/efi-loader" variable which makes it easier to swap
between loaders. I haven't fleshed all that out yet.


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