Mu-Silicium: Project Mu UEFI firmware for ARM64 devices
Project Mu UEFI Ports for ARM64-Based Devices
At a glance
- What is it?
- Mu-Silicium is a port of Microsoft's Project Mu UEFI firmware aimed at ARM-based hardware, so devices like Windows on ARM laptops can boot an operating system from custom firmware. It ships as firmware source with a status page, a build guide and a device porting guide, and it is the kind of project where device support is a checklist rather than a promise.
- Who is it for?
- Adopt Mu-Silicium if you are working on ARM64 hardware that has no working UEFI firmware, or if you are porting Project Mu to a new SoC and want a base that already handles several boards. Do not adopt it for a device that already boots a modern UEFI, for x86 hardware, or if you need a production firmware you can sign with your own key without doing additional work first.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Assembly, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Firmware for ARM boards that cannot boot on their own
Mu-Silicium exists to solve a hardware-level problem: making ARM-based devices boot operating systems such as Windows or Linux using custom UEFI firmware. That is a different job from writing a bootloader for a device where the vendor firmware is missing or broken. The project description is explicit that the focus is on getting ARM devices to boot operating systems through custom UEFI firmware.
The audience is therefore narrow and technically deep. The obvious users are people bringing up ARM64 hardware in the Windows on ARM space, where the WOA-Project topic tag and the mu_andromeda_platforms base make the lineage clear, and developers porting a new board to Project Mu. It is not a general embedded firmware project and not something a web developer would pick up on a weekend.
The primary language of the repository is Assembly, which is what you would expect for the low-level half of a UEFI implementation. The repository also contains directories such as Silicon, Platforms, BootShim, Common and Silicium-ACPI, which together describe the shape of the work: platform glue, boot-time shims, shared code and ACPI tables.
A note on expectations. The project ships a status page as a first-class resource, and the FAQ sends every device question to it. That is a good sign about honesty and a warning about coverage: support here is per-board, and the list is the contract.
Building on Microsoft Project Mu and two platform bases
The credit section explains the architecture better than any single file could. Microsoft is credited for Project Mu, which the README says powers this project, meaning the core UEFI implementation comes from the upstream Microsoft project and this repository is a port layer on top of it.
Two other platform bases are named. The WOA-Project is credited for mu_andromeda_platforms, which is used as the base for this project, and Project Aloha is credited for mu_aloha_platforms, which is used as a reference for some SoCs. Open Surface RT is credited for help on Tegra related work, and two individual contributors are credited for work on Exynos related pieces.
This inheritance pattern is the key mechanism to understand. Writing a UEFI implementation from scratch is a multi-year effort, and this project avoids it by tracking upstream Project Mu and layering platform-specific code on top. The cost of that choice is a dependency on upstream moving, and the benefit is that board bring-up work focuses on the parts that actually differ per device: the SoC support, the board description, the ACPI tables and the display and input plumbing.
For a porter, the practical sequence is to take an existing board as the starting point rather than an empty tree, and to work from the status page to see which boards are already done.
The status page decides whether your board is usable
The most important document in the repository is Status.md, and the project makes no attempt to hide it. The FAQ asks whether your device is supported and answers by telling you to look at the status page referenced above. The second question asks what to do if your device is not supported, and the answer points to the guides that explain how to port a device.
That structure, a definitive list plus a porting path, is what separates this from a hobby firmware project with a README full of optimism. There is no claim of general ARM64 coverage, and no expectation that an unsupported board will work after some configuration. A board is either listed with a known state or it is a porting project.
The porting guides live in a separate repository, the Project-Silicium Guides repository, linked from the resources section along with the status page and a Discord server. A Discord is a reasonable channel for firmware bring-up questions, where the failure modes are board-specific and hard to write down.
For an engineer evaluating this, the status page is the artifact to read first. It costs one click and it tells you whether the project is a solution for your hardware or a starting point for a port.
Building the firmware from source with the provided scripts
The build is documented in Building.md, and the repository root carries the tooling to do it. There is setup_env.sh for preparing the environment, pip-requirements.txt listing the Python dependencies that install step will pull, build_uefi.py as the main build entry point, and build_active_devices.sh to drive the builds for the boards that are marked as active in the project.
The directory layout reinforces the structure. Binaries holds build outputs, Resources holds pictures and similar assets, and the top level also carries a .gitmodules file, which is the expected signal that some dependencies are pulled in as submodules rather than vendored. Silicon and Platforms hold the hardware-specific work, BootShim holds the code that runs in the pre-UEFI phase, Common holds shared pieces, and Silicium-ACPI holds the ACPI side.
The primary language of the repository is Assembly, so a large part of what you are building is assembly and platform glue rather than application code. The README does not document a single command that builds every supported board from a clean checkout, and Building.md is the authoritative source for the exact sequence. Anyone with a real porting task should treat Building.md as the first document to read end to end, since the ordering of environment setup, submodule initialisation and per-board build is where a first attempt usually goes wrong.
Two licences in one tree, and why the split matters
The licence section is specific and worth reading closely. All code except drivers in the GPLDrivers, GPLApplications and GPLLibrary directories is licensed under BSD-2-Clause, while the GPL drivers are licensed under GPLv2 or later. The repository carries a LICENSE file at the root alongside a .gitignore and the other top-level entries.
The split exists for a practical reason. A UEFI implementation needs binary drivers, and closed-source binary drivers are a normal part of the platform, while the surrounding firmware code is the part that can be permissively licensed. Keeping the copyleft directories separate makes it possible for the firmware itself to stay BSD-2-Clause while still shipping drivers that carry their own obligations.
For a commercial adopter this is the fact to weigh. BSD-2-Clause places no obligation on you to publish a modified version, which is the difference that matters for anyone embedding this work in a product. The GPL-licensed driver directories, by contrast, carry the copyleft terms of GPLv2 or later, and the README does not describe a clean way to exclude them from a build, so if you need a fully permissive tree you have to find out for yourself which drivers the build actually pulls in.
A BSD-2-Clause project with a copyleft island is not a contradiction, but it is a boundary, and a build that drags in a GPL driver changes the obligations on the result.
What Mu-Silicium does not do for you
There are limits here that a first-time reader is likely to miss, and they are structural rather than fixable with effort.
First, this is firmware, so the work is gated on hardware access. If you do not have the board, its serial console, and a way to flash it, you cannot validate a port. The project provides the code and the guides; it cannot provide the device. That is the single biggest difference between this and a software library you can adopt in an afternoon.
Second, support is a per-board status, not a general capability. An ARM64 device that is not on the status page will not boot because this project exists. It has to be ported, and a port is measured in weeks of hardware bring-up, not hours.
Third, there is no signing story described. The repository lists no keys, no signing configuration and no update mechanism, so producing firmware a device will accept on a locked-down platform, or that will pass an OEM update chain, is work outside what the documentation covers.
Fourth, the lineage cuts both ways. Tracking Microsoft Project Mu upstream means upstream changes arrive and can break a board-specific patch. There is no published compatibility matrix between Project Mu revisions and specific boards, so the real work is testing your device after every upstream move.
A release cadence that tracks upstream
The project ships tagged versions on a steady monthly rhythm: v4.0 on 2026-10-01, v3.9 on 2026-09-01 and v3.8 on 2026-08-01, and the last push to the repository was on 2026-10-19. A version 4.0 alongside monthly minors tells you two things. The project is being versioned deliberately, and the major number gets used when something in the port layer changes in a way that a porter has to act on.
That cadence is consistent with a project whose upstream moves often. Project Mu itself evolves, and the platform ports in this repository have to be rebased onto those changes. A monthly release is a reasonable interval for a firmware port where each release is a rebase plus per-board fixes, and it is short enough that a board not patched for several months is likely to be broken against current upstream.
The main upgrade cost lands on whoever owns a board. A new Mu-Silicium version is a new firmware image to flash, a new build to validate, and a retest of the devices in the field. There is no indication in the repository of an over-the-air update path, so the release stream is a source of new images for manual flashing rather than a channel that updates deployed hardware.
Editorial conclusion
Adopt Mu-Silicium if you are working on ARM64 hardware that has no working UEFI firmware, or if you are porting Project Mu to a new SoC and want a base that already handles several boards. Do not adopt it for a device that already boots a modern UEFI, for x86 hardware, or if you need a production firmware you can sign with your own key without doing additional work first. Verify first that your exact board appears on the status page with the state the project lists, and read Building.md for the environment setup, since the repository ships setup_env.sh and pip-requirements.txt rather than a one-line installer.
Frequently asked questions
Is my ARM64 device supported by Mu-Silicium?
The project directs device questions to its status page, Status.md, which lists the supported boards and their state. If a device is not listed, the answer is that it has to be ported.
What is the difference between Project Mu and Mu-Silicium?
Microsoft's Project Mu provides the UEFI core that powers the project, and Mu-Silicium is the ARM64 port built on top of it. The port layer uses the WOA-Project's mu_andromeda_platforms as its base and refers to Project Aloha's mu_aloha_platforms for some SoCs.
How do I build the Mu-Silicium UEFI firmware?
The build documentation is in Building.md in the repository. The root contains setup_env.sh, pip-requirements.txt, build_uefi.py and build_active_devices.sh, and the repository uses .gitmodules, so dependencies come in as submodules.
What licence applies to the Mu-Silicium code?
All code except drivers in the GPLDrivers, GPLApplications and GPLLibrary directories is licensed under BSD-2-Clause, while those GPL driver directories are licensed under GPLv2 or later.
Can I port Mu-Silicium to a device that is not listed?
Yes, the project publishes a separate Guides repository that explains how to port a device, and it maintains a Discord for technical discussion. The status page is the place to check first whether a board is already supported.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/project-silicium-mu-silicium)Was this useful?