RFC: EFI Support

RFC: EFI Support

[Darren Hart]

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?

Thanks,

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

Re: 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,
> 

Re: 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

Re: RFC: EFI Support

[Richard Purdie]

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