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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
