3mdeb has submitted the code needed to move its Phoenix AM5 firmware work from a downstream Dasharo build toward upstream AMD openSIL and coreboot, but the patch sets are under review, not merged. For Windows users, the immediate practical change is smaller: Dasharo v0.9.0 already runs Windows 11 25H2 on one MSI PRO B850-P WIFI configuration with Phoenix-based Ryzen 8000 desktop APUs; upstream acceptance is what could turn that one-board achievement into a maintainable base for other firmware projects.
Phoronix reported on August 4 that 3mdeb engineer Michał Żygowski opened the openSIL pull request and a series of coreboot changes after the company released its first modern Ryzen AM5 Dasharo firmware on July 30. The primary records show openSIL pull request 58 is still open, contains 27 commits, has no assigned reviewers, and targets AMD’s
The code is significant because it fills in parts of the original Phoenix openSIL proof of concept that were sufficient for a mobile-oriented bring-up but not for a desktop AM5 motherboard with a B850 chipset, integrated graphics, full USB and storage connectivity, and Windows ACPI requirements.
The openSIL pull request adds Phoenix AM5 desktop handling across CPU-core bring-up, memory-mapped I/O allocation, chipset initialization, the System Management Unit, USB, graphics, IOMMU configuration, and ACPI-facing CPU performance data. It also introduces a Promontory21 IP block, the AMD companion chipset used by B850 and X870-class desktop boards to supply much of their extra USB, SATA, PCIe, and GPIO connectivity.
That is more consequential than a routine board port. 3mdeb’s own engineering reports document that its early Phoenix work could reach the operating system only after it wrote missing USB initialization, desktop-specific PCIe and chipset logic, and graphics initialization that the proof-of-concept code lacked. The team also found that a CXL block was present in Phoenix openSIL even though CXL is not available on the Phoenix AM5 silicon it was targeting; 3mdeb treated that code as an apparent carryover from a server-oriented implementation and redirected the work toward graphics support.
The pull request’s contents support that account. Among its listed commits are fixes for application-processor launch, a second MMIO region below 4GB, SMU initialization after CPU and chipset setup, missing FCH initialization, Phoenix graphics initialization, and Promontory21 initialization. It also adds APIs to expose CPPC minimum and nominal CPU frequencies so host firmware can construct the ACPI tables used by modern operating systems for processor performance management.
For desktop firmware, the Promontory work is the linchpin. A system that can start a CPU but cannot reliably initialize the chipset’s downstream ports is not a viable workstation or Windows endpoint. The implementation is therefore aimed at enabling the unglamorous essentials: storage controllers, USB controllers, PCIe devices, network interfaces, and the board-specific wiring that makes them visible to the OS.
That is an important distinction for administrators evaluating alternative firmware. A Windows desktop reaching the installer, or even reaching the desktop once, is not proof that the firmware implements the platform contract Windows expects. Windows consumes ACPI tables for processor idle behavior, interrupt routing, devices, TPM exposure, thermal reporting, and boot services. Missing or inaccurate firmware descriptions can produce symptoms far removed from their cause: intermittent wakes, unexplained unknown devices, power-management failures, or instability after idle.
3mdeb’s July validation report says the final Dasharo configuration also provides AMD fTPM through the Platform Security Processor, so Windows 11’s TPM 2.0 requirement does not require a discrete TPM module. That is relevant to BitLocker, Windows Hello, measured boot, and management deployments that check for a TPM during provisioning. Its implementation combines fTPM with AMD ROM Armor 3, which gates SPI flash writes through authorization paths involving the PSP and System Management Mode.
The Windows claim remains a single-vendor validation result. 3mdeb says its test system used a Ryzen 5 8600G and that Windows 11 installed without workarounds or Device Manager errors; Phoronix independently reported the company’s stated success but did not publish its own Windows test results before this patch series appeared. The upstream code review is useful precisely because it exposes the implementation to maintainers who can test it beyond one lab and one mainboard.
3mdeb states that its release supports Phoenix Zen 4 AM5 processors: Ryzen 8000 desktop APUs such as the Ryzen 7 8700G, Ryzen 5 8600G, Ryzen 5 8500G, and related Phoenix parts. The company says it validated the release specifically with a Ryzen 5 8600G. Raphael-based Ryzen 7000 CPUs and Granite Ridge Ryzen 9000 CPUs are outside the release scope and will not boot because the submitted code is based on the
That limitation changes the story from “open-source firmware arrives for AM5” to “open-source firmware arrives for a narrowly defined AM5 processor family on a single retail board.” It is still a notable milestone: mainstream AMD desktop firmware has long been dominated by opaque AGESA-based vendor images. But it is not a replacement BIOS for the typical B850 owner running a Ryzen 7 9800X3D, Ryzen 9 9950X, or Ryzen 9 9950X3D.
The distinction also explains why the company’s upstream submission matters more than its release alone. Upstream Phoenix support would establish reusable infrastructure in coreboot and openSIL. It does not automatically bring Raphael or Granite Ridge support; AMD would need to publish and maintain appropriate silicon-initialization support for those SoC families.
This is not a semantic nitpick. AMD’s PSP remains responsible for functions that coreboot and openSIL cannot simply replace, including portions of early platform bring-up and security services such as the firmware TPM. The practical win is that more of the board policy and initialization logic becomes inspectable and modifiable: coreboot, openSIL code, the EDK2 payload integration, ACPI tables, device configuration, and parts of the build chain. The processor’s deepest trusted components remain outside owner control.
There is another operational caveat for anyone considering deployment. Dasharo v0.9.0 documents that staged UEFI capsule updates do not survive a reset, so only immediate Capsule-on-Disk updates are supported. It also lists unreliable restoration of the previous power state after AC loss, occasional Ubuntu boot hangs when serial-console redirection is enabled, and an intermittent onboard Wi-Fi enumeration issue that 3mdeb says also occurs with the vendor BIOS.
Those are manageable issues for a firmware development machine, a lab system, or a purpose-built appliance. They are not the profile most IT departments want for a standard desktop fleet, particularly where unattended recovery, predictable AC-loss behavior, and conventional vendor update workflows are requirements.
What they do not yet establish is merge timing, release timing, support for more MSI boards, or support for the AM5 CPUs that dominate enthusiast and high-end desktop builds. Neither openSIL pull request 58 nor the public coreboot review submissions currently represent a stable upstream release.
For Windows users with the exact board and a supported Phoenix APU, Dasharo v0.9.0 is already the usable artifact, with fTPM, Secure Boot, Windows 11 boot validation, and the ACPI work needed for CPU power management. Everyone else should treat August 4’s submissions as the beginning of upstream review—not as a signal to flash an AM5 system that is running an unsupported Ryzen 7000 or Ryzen 9000 processor.
phoenix_poc branch rather than openSIL’s main development line. That status matters: a public pull request is a request to merge, not evidence that AMD or coreboot have accepted responsibility for maintaining the code.The code is significant because it fills in parts of the original Phoenix openSIL proof of concept that were sufficient for a mobile-oriented bring-up but not for a desktop AM5 motherboard with a B850 chipset, integrated graphics, full USB and storage connectivity, and Windows ACPI requirements.
The upstream patch set fills real desktop firmware gaps
The openSIL pull request adds Phoenix AM5 desktop handling across CPU-core bring-up, memory-mapped I/O allocation, chipset initialization, the System Management Unit, USB, graphics, IOMMU configuration, and ACPI-facing CPU performance data. It also introduces a Promontory21 IP block, the AMD companion chipset used by B850 and X870-class desktop boards to supply much of their extra USB, SATA, PCIe, and GPIO connectivity.That is more consequential than a routine board port. 3mdeb’s own engineering reports document that its early Phoenix work could reach the operating system only after it wrote missing USB initialization, desktop-specific PCIe and chipset logic, and graphics initialization that the proof-of-concept code lacked. The team also found that a CXL block was present in Phoenix openSIL even though CXL is not available on the Phoenix AM5 silicon it was targeting; 3mdeb treated that code as an apparent carryover from a server-oriented implementation and redirected the work toward graphics support.
The pull request’s contents support that account. Among its listed commits are fixes for application-processor launch, a second MMIO region below 4GB, SMU initialization after CPU and chipset setup, missing FCH initialization, Phoenix graphics initialization, and Promontory21 initialization. It also adds APIs to expose CPPC minimum and nominal CPU frequencies so host firmware can construct the ACPI tables used by modern operating systems for processor performance management.
For desktop firmware, the Promontory work is the linchpin. A system that can start a CPU but cannot reliably initialize the chipset’s downstream ports is not a viable workstation or Windows endpoint. The implementation is therefore aimed at enabling the unglamorous essentials: storage controllers, USB controllers, PCIe devices, network interfaces, and the board-specific wiring that makes them visible to the OS.
Windows 11 support depended on ACPI work, not merely a successful boot
3mdeb reports that Windows 11 can install and run on its Dasharo build without Device Manager errors. The company says the decisive repair was the addition of ACPI_LPI low-power-idle objects for Phoenix AM5 CPUs. Without those descriptions, Windows reportedly surfaced missing CPU power-management functionality and could become unresponsive after the system idled.That is an important distinction for administrators evaluating alternative firmware. A Windows desktop reaching the installer, or even reaching the desktop once, is not proof that the firmware implements the platform contract Windows expects. Windows consumes ACPI tables for processor idle behavior, interrupt routing, devices, TPM exposure, thermal reporting, and boot services. Missing or inaccurate firmware descriptions can produce symptoms far removed from their cause: intermittent wakes, unexplained unknown devices, power-management failures, or instability after idle.
3mdeb’s July validation report says the final Dasharo configuration also provides AMD fTPM through the Platform Security Processor, so Windows 11’s TPM 2.0 requirement does not require a discrete TPM module. That is relevant to BitLocker, Windows Hello, measured boot, and management deployments that check for a TPM during provisioning. Its implementation combines fTPM with AMD ROM Armor 3, which gates SPI flash writes through authorization paths involving the PSP and System Management Mode.
The Windows claim remains a single-vendor validation result. 3mdeb says its test system used a Ryzen 5 8600G and that Windows 11 installed without workarounds or Device Manager errors; Phoronix independently reported the company’s stated success but did not publish its own Windows test results before this patch series appeared. The upstream code review is useful precisely because it exposes the implementation to maintainers who can test it beyond one lab and one mainboard.
Phoenix AM5 does not mean ordinary AM5 support
The most easily missed limitation is CPU scope. The MSI PRO B850-P WIFI is an AM5 motherboard and can ordinarily host a broad range of Ryzen 7000, Ryzen 8000, and Ryzen 9000 processors under MSI’s vendor BIOS. Dasharo v0.9.0 does not inherit that broad compatibility.3mdeb states that its release supports Phoenix Zen 4 AM5 processors: Ryzen 8000 desktop APUs such as the Ryzen 7 8700G, Ryzen 5 8600G, Ryzen 5 8500G, and related Phoenix parts. The company says it validated the release specifically with a Ryzen 5 8600G. Raphael-based Ryzen 7000 CPUs and Granite Ridge Ryzen 9000 CPUs are outside the release scope and will not boot because the submitted code is based on the
phoenix_poc openSIL branch.That limitation changes the story from “open-source firmware arrives for AM5” to “open-source firmware arrives for a narrowly defined AM5 processor family on a single retail board.” It is still a notable milestone: mainstream AMD desktop firmware has long been dominated by opaque AGESA-based vendor images. But it is not a replacement BIOS for the typical B850 owner running a Ryzen 7 9800X3D, Ryzen 9 9950X, or Ryzen 9 9950X3D.
The distinction also explains why the company’s upstream submission matters more than its release alone. Upstream Phoenix support would establish reusable infrastructure in coreboot and openSIL. It does not automatically bring Raphael or Granite Ridge support; AMD would need to publish and maintain appropriate silicon-initialization support for those SoC families.
“Open-source firmware” still carries AMD’s closed PSP foundation
Dasharo’s release is more open than the MSI firmware it replaces, but it is not fully open firmware. 3mdeb calculates a 79.1% reduction in closed-source firmware code versus MSI BIOS version E7E56AMSI.2A92, while acknowledging that AMD PSP firmware and other required silicon components remain proprietary binaries.This is not a semantic nitpick. AMD’s PSP remains responsible for functions that coreboot and openSIL cannot simply replace, including portions of early platform bring-up and security services such as the firmware TPM. The practical win is that more of the board policy and initialization logic becomes inspectable and modifiable: coreboot, openSIL code, the EDK2 payload integration, ACPI tables, device configuration, and parts of the build chain. The processor’s deepest trusted components remain outside owner control.
There is another operational caveat for anyone considering deployment. Dasharo v0.9.0 documents that staged UEFI capsule updates do not survive a reset, so only immediate Capsule-on-Disk updates are supported. It also lists unreliable restoration of the previous power state after AC loss, occasional Ubuntu boot hangs when serial-console redirection is enabled, and an intermittent onboard Wi-Fi enumeration issue that 3mdeb says also occurs with the vendor BIOS.
Those are manageable issues for a firmware development machine, a lab system, or a purpose-built appliance. They are not the profile most IT departments want for a standard desktop fleet, particularly where unattended recovery, predictable AC-loss behavior, and conventional vendor update workflows are requirements.
Upstream review is the real test from here
The openSIL patch set gives upstream maintainers a concrete 27-commit implementation rather than a vague request for Phoenix desktop support. The parallel coreboot submissions include Phoenix SoC changes, Promontory21 handling, and an initialMS-7E56 mainboard tree for the MSI PRO B850-P WIFI. Together, those series capture the hardware-specific work that transformed a mobile-focused proof of concept into firmware capable of booting a desktop B850 platform.What they do not yet establish is merge timing, release timing, support for more MSI boards, or support for the AM5 CPUs that dominate enthusiast and high-end desktop builds. Neither openSIL pull request 58 nor the public coreboot review submissions currently represent a stable upstream release.
For Windows users with the exact board and a supported Phoenix APU, Dasharo v0.9.0 is already the usable artifact, with fTPM, Secure Boot, Windows 11 boot validation, and the ACPI work needed for CPU power management. Everyone else should treat August 4’s submissions as the beginning of upstream review—not as a signal to flash an AM5 system that is running an unsupported Ryzen 7000 or Ryzen 9000 processor.