edk2-platforms holds the board support code, not the firmware core

A collection of platforms and drivers, kept building on purpose

This branch of the edk2-platforms repository holds the platforms and drivers that are actively maintained against the default branch of edk2, and the README asks that an issue be raised when a platform or driver fails to build against current edk2 and, where applicable, edk2-non-osi. That last sentence is the whole purpose of the repository stated plainly. The EDK II ecosystem is split across several projects, and the platform code is where the churn happens, because every new board, every new silicon family and every firmware update lands here. The top level listing shows how much is covered, with a Platform directory, a Drivers directory, a Silicon directory and a Features directory, alongside the governance files. The generic information about the repository and the process by which stable and devel branches can be added for individual platforms lives on a separate about branch, which is worth reading before you plan to maintain a platform long term, because the branch structure is how the project separates platforms that track the moving target from platforms that have settled.

The build needs three repositories and a package path

The workspace setup is the first thing to get right, and it is easy to misread. You create a workspace directory on your machine, and the example in the README uses a path under work and git and tianocore.

$ export WORKSPACE=/work/git/tianocore
$ mkdir -p $WORKSPACE
$ cd $WORKSPACE

Into that folder you clone edk2, edk2-platforms and, if you are building platforms that need it, edk2-non-osi, updating the submodules of the first two as you go.

$ git clone https://github.com/tianocore/edk2.git
$ git submodule update --init
$ git clone https://github.com/tianocore/edk2-platforms.git
$ git submodule update --init
$ git clone https://github.com/tianocore/edk2-non-osi.git

Then you point a PACKAGES_PATH environment variable at the three directories, in this order.

$ export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi

The order matters because the build system resolves packages by walking that list. Sourcing the setup script and building BaseTools are the next two steps, and both are short.

$ . edk2/edksetup.sh

make -C edk2/BaseTools

The setup script step depends on the workspace variable having been set first, which is the one ordering constraint worth remembering when a build fails immediately.

One cross toolchain prefix per target architecture

Building firmware for a different architecture than the machine you are on needs a cross compiler, and the README gives the prefix for each supported target. AARCH64 uses aarch64-linux-gnu-, X64 uses x86_64-linux-gnu-, RISCV64 uses riscv64-unknown-elf-, LOONGARCH64 uses loongarch64-unknown-linux-, IPF uses ia64-linux-gnu, and IA32 uses an i386, i486, i586 or i686 prefix or the x86_64 one. The note that x64 compilers also support IA32 but the reverse may not always be true is a practical warning, because it means the choice of host compiler is a decision about your targets rather than about your machine. Where the toolchains come from is also documented. Arm publishes a GCC toolchain for the aarch64-linux-gnu target, compiled to run on x86 or i686 Linux and on i686 Windows, the RISC-V community provides the riscv64-unknown-elf toolchain, and Loongson provides the loongarch64 one. Clang is the alternative, and it does not need separate cross compilers, but it does need target specific binutils, which come with a prepackaged GCC toolchain or can be built separately.

Four options decide what you build

Once the environment is set, the build options are a short list, and the table in the README pairs each target.txt setting with its command line equivalent. The active platform, given with the platform flag, is the description file of the platform to build, and the target, given with the build flag, is one of DEBUG, RELEASE or NOOPT. The architecture flag selects the architecture to build for, and the tool chain tag selects the toolchain profile, with GCC for gcc version 5 or later, GCC4x for earlier versions, and CLANGPDB or CLANGDWARF as appropriate when building with clang. There is also a maximum concurrent thread number option, described as roughly equivalent to make with a parallel flag. The default values live in the target configuration file inside the edk2 repository, and the README makes a practical suggestion: if you are only working on a single platform, updating that file is more sensible than passing everything on the command line. The build flag can be repeated to build several targets in sequence, and after a successful build the images appear under a path keyed by the platform name and the target and toolchain combination.

Ownership is written down, and the mailing list is the channel

The governance files are unusually visible, and they tell you how to interact with the project. CODEOWNERS and REVIEWERS say who owns code in which parts of the repository, CONTRIBUTORS.md lists names and email addresses, and the README states a rule that surprises newcomers: you should not privately email a maintainer, you should email the edk2-devel list and copy the area maintainers and reviewers. The reasoning is about process rather than politeness, since a public list keeps the discussion discoverable for the next person with the same problem. The README also documents how a maintainer hands over a role, which is a pull request updating CODEOWNERS, REVIEWERS and CONTRIBUTORS.md with the new maintainer, reviewed and approved by that new maintainer. Contributions go through GitHub pull requests. For a platform that needs extra image processing beyond the standard build, the expectation is that the steps are documented as a Readme inside the platform directory and that any helper scripts live there too, which keeps the platform self describing rather than dependent on tribal knowledge.

A permissive licence with a note on its classification

Licensing in the EDK II project is mostly a single licence, with the majority of the code in the open source project released under a BSD 2-Clause Plus Patent licence, and the project says so in the README of this repository as well. It also states that the EDK II Platforms open source project contains no components covered by additional licences, which is a stronger claim than most platform repositories can make, since it means a platform built from this tree is not a patchwork of third party terms. The repository listing at the platform level, however, classifies the licence as a custom one that GitHub cannot classify and points to the LICENSE file, so the file rather than the metadata is the document to check. There is also a License-History.txt in the tree, which records how the licensing of the project has changed over time, and that history is worth a look for anyone who needs to know the terms under which an older revision of a platform was shipped.

Editorial conclusion

edk2-platforms is the right starting point for anyone bringing up EDK II on a board, because the platform description files, the drivers and the silicon support are all in one place, and the build documentation tells you exactly which repositories and which toolchain to use. It is the wrong repository for learning how EDK II itself works, since the core services and the build system live in the edk2 project, and the wrong choice if you want a single clone, because the build expects a workspace containing three repositories and a PACKAGES_PATH pointing at all of them. Verify three things before you start: that a platform for your board already exists in the Platform directory, because many boards need a description file written from scratch, that the toolchain prefix for your target architecture is one you can install, and that any image processing your board needs is documented in the platform directory, since the project requires extra steps to be described there rather than left in a wiki. The last push was on 2026-10-16.

Frequently asked questions

Official sources

1. Issues
2. README
3. tianocore/edk2-platforms on GitHub