[OE-core] RFC: EFI Support

[Tom Zanussi]

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

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?

Tom

> Thanks,
>