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.


Eventually, and made possible by the governance change, a process was agreed on and pushed as a Readme.md in a branch of the TianoCore edk2-platforms github repository.

UEFI LEG Related Activities

Linaro hosts and supports a repository that combines various upstream repositories and patches to provide a reference UEFI implementation on various ARM platforms.

Building Linaro UEFI

There are many ways to build UEFI. We have a wiki page dedicated to the topic:


Developing with UEFI

If you are writing UEFI code and want to know how to interact with the Linaro UEFI community, you will want to read our developers' guidelines.

UEFI Runtime Services support

UEFI Runtime Services

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.

EFI stub

UEFI Network Booting Documentation

UEFI Network Driver Documentation

The following wiki page provides a guide on how to write a UEFI network driver

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:

LEG/Engineering/Kernel/UEFI (last modified 2017-06-28 16:53:14)