edk2-msm: a UEFI firmware port for Qualcomm Snapdragon phones

What edk2-msm actually replaces on a Snapdragon phone

A retail Snapdragon phone ships with a vendor boot chain that expects the vendor's Android image. edk2-msm swaps the UEFI layer of that chain for an EDK2 build, so the phone exposes a UEFI environment instead of the usual Android fastboot and bootloader menus. The README states the goal plainly: provide a usable EDK2 UEFI environment for modern Qualcomm SoCs, and use it as a boot manager for multi-booting mainline Linux, Android and optionally Windows on certain SoCs. That last qualifier matters. Windows on ARM support is per-SoC, not universal, and the repository topics list windows-on-arm as one interest among several rather than a promise. The audience is narrow: people porting mainline Linux to a specific handset, people experimenting with Windows on Snapdragon hardware, and developers who need a UEFI shell on a phone for driver or ACPI work. If you are not willing to open the device and risk it, this project is not aimed at you.

How the EDK2 tree is split across Platform, Silicon and GPLDrivers

The repository is an EDK2 platform tree, and its layout follows the usual EDK2 convention. Platform/ holds per-device or per-SoC packages, Silicon/ holds the shared SoC-level code, and Common/ holds pieces used across platforms. ACPI tables live in ASL, which is why ASL is the primary language by file count rather than C. Drivers that cannot be shipped under a permissive licence sit in GPLDrivers/, kept apart so the rest of the tree stays under BSD-2-Clause. The build entry point is build.sh at the top level, with configs/ and tools/ alongside it, and .gitmodules indicates external dependencies are pulled in as submodules rather than vendored. In practice this means a port is assembled from a generic SoC package plus a device package, and the device package is where the board-specific ACPI, memory map and peripheral wiring live. The README does not describe this architecture itself; it points to the Renegade Project wiki, and the directory names are what the repository layout shows.

Building edk2-msm from the repository

The README gives no build steps, no prerequisites and no example commands. It says only: please visit the Renegade Project Wiki, linking to wiki.renegade-project.cn. So the honest first step is to clone with submodules, since .gitmodules is present at the top level, and then read the wiki page for your device before running anything. The repository does expose build.sh and a configs/ directory, so the build is driven from the tree rather than from a separate toolchain repository, but the flags and the expected environment are not documented in the README. The release tags in the repository (2302.1-mh2lm, 2301.1, 2210.1) are from early 2023, while the last push to master was on 2026-03-07, so the tagged releases are not a current snapshot of the tree. Treat the tags as historical artifacts and build from master if you want the current state. A clone with submodules is the only command that can be stated with confidence from the repository:

git clone --recurse-submodules https://github.com/edk2-porting/edk2-msm.git
cd edk2-msm

After that, the wiki is the source of truth for your device. Nothing in the README tells you which config under configs/ applies to which phone, and guessing is how people brick handsets.

The limitations the README admits, and the one it does not

The repository description calls the project a broken edk2 port for Qualcomm platforms. That is the maintainers' own wording, not a critic's, and it should set expectations before anything else. The README itself carries no compatibility matrix, no list of supported devices, no flashing instructions and no recovery procedure. Windows support is described as optional and limited to certain SoCs, without naming which ones in the README. The release tags stop in February 2023 while development continued on master into 2026, so there is no tagged build that matches the current tree, and anyone pinning to a release is pinning to something three years old. The split between BSD-2-Clause code and GPLDrivers/ also means the licence of your final firmware image depends on which drivers your device package pulls in. If your model needs a GPLv2 driver, your redistributed image is not BSD-only, and the README does not map devices to drivers for you.

Where edk2-msm stops and a mainline Linux port begins

It is easy to expect edk2-msm to make a phone run Linux. It does not. It provides the UEFI environment and the boot manager; the operating system, its kernel, its device tree and its drivers are separate work, usually tracked by the mainline Linux community or by device-specific projects. The same separation applies to Windows on ARM: edk2-msm supplies the firmware side, and the OS image and its drivers come from elsewhere. That distinction decides whether this project is useful to you. If you already have a working Linux or Windows bring-up for your handset and you need a UEFI layer to boot it, edk2-msm is the piece you are missing. If you have no OS image and no kernel support for your device, edk2-msm will boot you into a UEFI shell and nothing more.

edk2-msm against edk2-rk3588 and vendor bootloaders

The closest comparison people search for is edk2-rk3588, another EDK2 port, but for Rockchip SoCs. The difference is not cosmetic. Rockchip boards are commonly documented single-board computers with public schematics and a relatively open boot chain, so an EDK2 port there mostly replaces a vendor U-Boot. Qualcomm phones are the opposite: closed boot chains, signed firmware stages, per-model ACPI and peripheral differences, and a vendor stack that assumes Android. edk2-msm therefore spends much of its effort on device packages and ACPI tables rather than on a generic board port, and the result is device-specific in a way an RK3588 image is not. Against the stock Qualcomm bootloader, the trade is capability for support: you gain a UEFI shell and multi-boot, and you give up the vendor's tested flashing and recovery path. The Renegade Project wiki, not the repository, is where that trade is documented per device.

Maintenance, releases and what the licence split means for you

The last push to master was on 2026-03-07, so the tree has moved since the February 2023 tags, but the gap between tagged releases and current development is wide. Anyone building from a tag is building old code; anyone building from master is building something with no release label attached. Budget for that: you are tracking a branch, not upgrading between versions. On licensing, the README states that all code except drivers in the GPLDriver directory is licensed under BSD 2-Clause, and that GPL drivers are licensed under GPLv2. If you redistribute a firmware image that includes a GPLv2 driver, the BSD-2-Clause header on the rest of the tree does not cover that driver. The README does not say which devices require GPLDrivers/, so that is a question to answer from your device package before you ship anything. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt edk2-msm only if you have a specific Snapdragon device, a way to recover it from a bad flash, and the patience to work from the Renegade Project wiki rather than the README. It is the wrong choice for anyone who wants a supported bootloader on a daily driver, and for x86 or non-Qualcomm ARM boards. Before flashing anything, verify that your exact SoC and device have a Platform/ directory in the repository, check whether your model depends on a driver under GPLDrivers/, and read the wiki page for your device end to end.

Frequently asked questions

Official sources

1. edk2-porting/edk2-msm on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases