RFC: EFI Support
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,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 51 lines · 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_STUBpatches 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_IMAGEDEPENDSin 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_FEATURESvalues 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 theEXTRA_IMAGEDEPENDS, specify EFI inMACHINE_FEATURES, and drop live from the image types.
Quoted 8 lines
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_FEATURESfor 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
Quoted 2 lines
Thanks,
Quoted 61 lines · Tom Zanussi
Quoted 51 lines · 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_STUBpatches 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_IMAGEDEPENDSin 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_FEATURESvalues 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 theEXTRA_IMAGEDEPENDS, specify EFI inMACHINE_FEATURES, and drop live from the image types.Quoted 8 lines
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_FEATURESfor the EFI and PCBIOS flags?
Quoted 7 lines
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.
Quoted 5 lines
Also, the bzImage with
EFI_STUBlooks 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.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 51 lines · 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_STUBpatches 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_IMAGEDEPENDSin 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_FEATURESvalues 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 theEXTRA_IMAGEDEPENDS, specify EFI inMACHINE_FEATURES, and drop live from the image types.
Quoted 7 lines
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_FEATURESfor 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