Re: RFC: EFI Support

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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?

Not one I can think of. I think this all sounds reasonable to me. I
suspect grub2 may need to stick around but certainly we can move to
syslinux being the supported/default solution if we can fit it into the
existing use cases. So the plan sounds good to me, thanks for putting it
together.

Cheers,

Richard