Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:
Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE
Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.
Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.
Alexander Graf of SuSE has submitted a new patch to his EFI payload for U-Boot, adding PXE boot support!
[PATCH 0/4] efi_loader: PXE boot support
One of the most common boot cases with EFI on arm64 is to boot from the network using PXE boot. While TianoCore implements that just fine, we were lacking support for it in U-Boot so far. But no longer! Here is a patch set, enabling PXE booting of EFI payloads. With this patch set, I was successfully able to automatically boot our normal (usually used with TianoCore based systems) environment to boot and run grub2 and a kernel from there with U-Boot.
* efi_loader: Add network access support
* bootp: Move vendor class identifier set to function
* net: Move the VCI and client arch values to Kconfig
* distro: Add efi pxe boot code
For more information, see the U-Boot list:
Alexander Graf of SuSE has updated his EFI patch for U-Boot, adding the ability to boot from El Torito-style ISOs:
efi_loader: Support loading from El Torito isos
Some distributions still provide .iso files for installation media. To give us greatest flexibility, this patch set adds support for El Torito booting with EFI payloads.
iso: Make little endian and 64bit safe
iso: Start with partition 1
iso: Allow 512 byte sector size
efi_loader: Split drive add into function
efi_loader: Add el torito support
efi_loader: Pass file path to payload
efi_loader: Increase path string to 32 characters
distro: Enable iso partition code
For more information, see the full patch:
Alexander Graf of SuSE has been adding EFI support to U-Boot. He also just added a new boot loader command, ‘bootefi’, as well:
[PATCH v6 19/30] efi_loader: Add “bootefi” command
In order to execute an EFI application, we need to bridge the gap between U-Boot’s notion of executing images and EFI’s notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do
# load mmc 0:1 $loadaddr grub.efi
# bootefi $loadaddr
which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload.
Tom Rini of the U-Boot project also just posted a message saying that the EFI patches have been mostly applied:
EFI loader support largely enabled
What I mean by the subject is that with the EFI loader patches enabled U-Boot itself (not SPL) now includes the EFI loader and required bits on ARM/aarch64. This is in general I think a good thing. I’ve however disabled it on a few boards due to size constraints. This is an average gain of ~12KiB in U-Boot proper. I fully expect a number of platform patches opting out of this support due to it just not being a real usecase and I am agreeable to talking about making it not enabled by default. So, lets kick things off.
For more information, see the U-Boot sources or mailing list archives: