UEFI on ARM
Within Linaro, there have been (at least) three phases of UEFI development/involvement, which has tended to confuse people just starting out on ARM/AArch64. One necessary clarification is that at no point has there been a "fork" of the upstream edk2 - at most there was layering some bits on top, for features not yet upstream, or for changing default behaviours to simplify CI or integrating with not-really-UEFI-enabled operating systems.
At this point we are well on the way towards full integration in the main TianoCore project - but the phases we've gone through are:
(Each described in more detail below.)
Originally, the ARM landing team started making binary releases based on the upstream edk2 support, with additional patches for bringing in not-yet-upstream features, and validated with Android/OpenEmbedded images. This evolved into a collaboration between ARM-LT and LEG, who had members who wanting up-to-date releases for their own platforms. Since the number of platforms started growing, the release mechanism (based around merging per-platform topic-branches) reached a breaking point, and some things needed to change.
The preferred method for resolving this would have been to get all of these platforms merged into upstream edk2, but a few things got in the way:
- Although all of our revision control was in git, edk2 was hosted in Subversion (with git mirrors). (see also below)
- The current method of adding new platforms to edk2 was a new top-level package. And we were hoping/expecting to be adding enough new platforms for this to grow unpalatable pretty quickly.
- Some of the platform we needed to support had a number of binary-only drivers, which would not be acceptable to include in edk2.
At this point in time the TianoCore project did not have a clear governance model. A migration to git had been in the works for a long time, but there was not really any person or group of persons who could make the call on when to flip the switch.
To resolve the issue, LEG decided to move the platform support into a separate repository from core edk2. This had a few benefits:
We could have full control over the repository, letting us prototype layouts and workflows, preparing to find a solution to get officially adopted by TianoCore in the long term.
- We could keep binary-only-drivers. (Which while not optimal is a lot better than having no way of rebuilding the firmware for a platform.)
- We automatically had a git-based master repository.
Working with EDK2
The Readme.md of edk2-platforms contains all information about how to work with this development environment.
Developing with UEFI
If you are writing UEFI code and want to know how to interact with the UEFI/EDK2 community, you will want to read our developers' guidelines.
More information about UEFI
The Unified EFI Forum is a very good place to start for information about UEFI and the specification.
For information about the EDK2 implementation of UEFI, their wiki pages are a useful resource:
UEFI LEG Related Activities
These days, there is feature parity across the architectures - most of the Linaro effort goes into maintainership, including bringing in new platform support.
UEFI Runtime Services support
Linux EFI stub
The EFI stub makes the ARM zImage file be a PE/COFF executable that UEFI can load directly. A single binary is both a zImage and a PE/COFF exectutable, and can be loaded either way. The EFI stub will replace the Linux loader currently in UEFI as the supported way to load the kernel on UEFI.
UEFI Network Booting Documentation
UEFI Network Driver Documentation
The following wiki page provides a guide on how to write a UEFI network driver
LEG/ServerArchitecture/UEFI (last modified 2017-08-24 14:35:51)