.png){kind=small}
Introduction
This blog post continues the MSI PRO B850-P coreboot porting series. In Part
1 we brought up
the bootblock and romstage and mapped all USB, SATA, and PCIe ports. In Part
2 we added the
USB and PCIe devicetree descriptors and integrated Phoenix openSIL as a
submodule. In Part
3 we ported the
MPIO, SMU, NBIO, FCH, and RcMgr IP blocks, bringing the platform to the verge
of booting Linux. In Part
4 we added
~1000 lines of missing USB initialization code, ported the CCX IP block, and
integrated automated test infrastructure. In Part
5 we completed
GFX initialization in openSIL, added full Promontory21 chipset support, enabled
AMD P-state CPPC, and improved ACPI tables - bringing Linux to a fully graphical
boot, albeit still requiring nomodeset as a temporary workaround for an
amdgpu kernel driver hard fault.
This post covers the next phase: fixing the amdgpu hard fault so that
nomodeset is no longer needed, integrating AMD firmware TPM (fTPM) support
with ROM Armor 3 flash protection, improving the Promontory21 configuration to
match the vendor BIOS, adding EZ Debug LED support, enabling fast boot through
AMD memory context save/restore, and completing the cross-OS boot and bug-fix
campaign that confirms Linux and Windows 11 are fully operational.
The relevant coreboot changes are tracked in pull request 928 on the Dasharo coreboot downstream repository. The openSIL Promontory21 fixes are in the 3mdeb/openSIL repository. Several of the AMD fTPM driver commits were cherry-picked from upstream coreboot Gerrit and are not described individually here; this post focuses on the Dasharo-specific integration work.
The milestones covered in this post are:
Task 8. Validation & stabilization:
-
Milestone a. Cross-OS boot & bug-fix campaign
Run exhaustive Linux, Windows and hypervisor test suites; fix remaining firmware defects and submit test reports.
Executive summary
This post covers the sixth phase of the MSI PRO B850-P coreboot port:
-
GFX fix - ACPI VFCT published by AMD GOP driver: The
amdgpukernel driver hard fault was fixed by letting the AMD GOP driver publish the ACPI VFCT table with the in-RAM VBIOS copy.nomodesetis no longer required. -
AMD fTPM with ROM Armor 3: Integrated AMD PSP firmware TPM support backported from upstream coreboot, with fixes to cooperate with ROM Armor 3 SMM flash protection. The platform now provides TPM 2.0 through the PSP without a discrete TPM chip.
-
Promontory21 improvements: Fixed PCIe target speed configuration for all ports, corrected secondary PT21 GPIO MMIO base address, added GPIO driver support in coreboot, and updated board configuration to match the vendor BIOS.
-
EZ Debug LEDs: Added GPIO API to the NCT6687D Super I/O driver and wired the DRAM/CPU/VGA/BOOT LEDs to indicate firmware initialization progress.
-
Power button SMI: Enabled power button press handling in pre-OS environment for clean system shutdown.
-
SMBIOS memory information: Added openSIL APOB-based SMBIOS type 17 memory device entry generation, enabling correct DIMM information reporting.
-
iPXE with Realtek UNDI: Included the Realtek UNDI EFI driver in the firmware image to enable network boot via the on-board RTL8126 controller.
-
Fast boot via APOB memory context restore: Disabled APOB hashing to allow the PSP to accept saved memory training data on warm boots, reducing PSP initialization time by nearly 20 seconds.
-
CPU
_LPIstructures: Added ACPI Low Power Idle object generation for Phoenix AM5 CPUs, required for correct Windows power management. -
ROM3 caching, EDK2 stable-202602, SBOMs, thermal zone, HDA verbs, and other minor fixes.
-
Cross-OS boot campaign complete (Task 8 Milestone a): Linux boots with full
amdgpuacceleration; Windows 11 installs and runs without Device Manager errors. -
Validation started: First release candidate tagged, automated test suite running.
GFX fix: AMD GOP driver publishes ACPI VFCT
The most visible improvement in this phase is the resolution of the amdgpu
kernel driver hard fault that forced nomodeset since Part 5. The root cause
was that the AMD GOP driver was not publishing the ACPI VFCT (Video BIOS
Firmware Table) with an updated VBIOS copy from RAM. The ACPI VFCT is
AMD-specific table thus it is not standardized by ACPI specification. There is
no public specification for the table, nor how it is supposed to be created.
Its format can be found in the Linux kernel
sources
for amdgpu driver, for example.
The VFCT table is how the UEFI firmware communicates a copy of the video BIOS
to the operating system. The amdgpu driver reads the VFCT at boot to obtain
VBIOS data for initializing the GPU from scratch under the OS. On the MSI PRO
B850-P, the VBIOS image in SPI flash is generic. After the VBIOS is copied to
RAM, executed and graphics initialized, its content may change according to
the detected hardware and configured display settings. AMD GOP driver copies
the modified VBIOS into the VFCT table, so that OS may use VBIOS functions to
initialize graphics properly.
The fix is in
device/pci_rom.c:
coreboot now skips generating its own VFCT entry for the AMD iGPU when the
EDK2 AMD GOP driver is enabled (CONFIG_AMD_PLATFORM_GOP). Instead, the GOP
driver itself publishes the VFCT with the updated in-RAM VBIOS content. This
avoids a conflict where coreboot was generating a stale VFCT pointing at the
cbmem-based VBIOS while the GOP driver had already a different copy of the
VBIOS in RAM allocated by the EDK2 UEFI Payload.
Linux now boots with a fully accelerated amdgpu driver. The nomodeset
workaround is no longer required.
AMD fTPM support with ROM Armor 3
A significant portion of the work in this phase was integrating AMD firmware TPM (fTPM) support into the MSI PRO B850-P firmware. The fTPM is a TPM 2.0 implementation that runs inside the AMD PSP (Platform Security Processor), emulating a CRB (Command Response Buffer) TPM interface over MMIO. This eliminates the need for a discrete TPM chip while providing full TPM 2.0 functionality for features like Microsoft Windows installation, BitLocker, measured boot, and platform attestation.
The upstream fTPM driver stack was cherry-picked into the Dasharo branch as backports. The focus of the work specific to the MSI PRO B850-P was integrating these drivers with the ROM Armor 3 feature and adapting them to the Phoenix platform.
ROM Armor 3: SMM-gated flash protection
ROM Armor 3 is AMD’s SMM flash protection mechanism. When enabled, all writes to the SPI flash must be authorized through the PSP, and only SMM code can submit those authorization requests. This prevents unauthorized flash writes from ring-0 code and is an important layer of firmware security.
The challenge is that the AMD fTPM also needs to write to SPI flash - for example, to store TPM state in a dedicated flash region. These two subsystems must cooperate: when a flash write is needed and ROM Armor 3 is active, PSP will update the flash regions by itself. However, if ROM Armor 3 is runtime disabled by setup option, the write request comes from the PSP via SMI and the SMM code must write the requested data to the relevant flash region. The fTPM and ROM Armor 3 SMM handlers must not conflict, so it was necessary to put a check on the state of ROM Armor 3 (SMM BWP) variable and decide whether to enable PSP SMIs or not.
fwupd HSI
From a security standpoint, the combination of fTPM and ROM Armor 3 gives the MSI PRO B850-P a meaningful firmware security posture: TPM-backed measurements from romstage onward, and flash write protection that requires PSP authorization for any modification. The fwupd security report below confirms the platform’s security feature status:
|
|
Why only HSI1?
The platform currently reaches HSI1 level. And, if not due to the update of fwupd adding Platform Secure Boot check, it would reach HSI2, like for Gigabyte with older fwupd version.
Platform Secure Boot
Platform Secure Boot (PSB) is a Static Root of Trust of AMD processors rooted in PSP, which enforces verification of the early boot firmware by PSP. It has a side-effect of binding a CPU to a given key, or mainboard firmwares which use the given key. In short, it takes away the possibility of reusing the CPUs across mainboards, even for testing purposes on your own devices. This security feature was very disliked. The article even describes the surprise of the author that the CPU suddenly stopped working after it was plugged into one vendor board, then to another. It clearly shows how advertisement of critical security features and its impact is not communicated properly.
On the other hand, vendors may have their own implementations of Root Of Trust, which does not rely on AMD Platform Secure Boot. Those implementations might even be better than PSB in certain aspects. Yet, it won’t count in HSI level…
In this article it is shown how vendors approach to enabling PSB. Some are reluctant to enable it, some consider it optional.
However, the worst part is that the security of PSB is centralized around AMD issuing keys/certificates signed by AMD root key, so that PSP can properly authorize the BIOS signing key for PSB. This is explained in the following article. This kind of enforced trust is not what 3mdeb would like to do in Dasharo. We value transparency and ownership. Until PSB becomes a user-controllable feature with key revocation, reownership, or multiple key hierarchy, like Intel Boot Guard offers, we will not pursue enabling PSB to take away the freedom from our end users. We also value implementations like Caliptra and OpenTitan.
Where the secure and trustworthy transfer of ownership is part of the design, not an afterthought or promotional value-preserving of the ecosystem. Tooling for performing those operations is open and auditable. The same perspective is closely related to the Right to Repair mission and vision, which 3mdeb and the Dasharo Team believe in and are aligned with. So, despite the fact that we disagree with the way HSI is framing it, we disagree, inform the community, and commit.
We are looking forward to partnering with organizations and all ecosystem entities towards changing that reality. Designs that promote centralization of power are bad for security, and we will support distributed systems and cryptographically proven ownership transfers.
RAM encryption
Encrypted RAM cannot be enabled, unfortunately. Due to AMD policy, memory encryption is not “supported” on non-PRO Ryzen processors. However, this is going to change soon, according to reports, but only for Ryzen 9000, which is not Phoenix unfortunately.
The community feedback probably means complaints of the many users who suddenly lost a security feature on their processors by a mere software/firmware change, while the capability in the processor is still there. It is difficult to find proper words for such moves. And again, we are locked out of a high HSI score.
We have committed a change in the APCB (AGESA PSP Configuration Block) that enables TSME (Transparent Total Memory Encryption) feature, with the hope that one day, the RAM encryption will be back.
Suspend to idle
Suspend-to-idle - not yet supported. It would require a significant amount of work in ACPI. Also, it would require a deep understanding of the board design itself. Without schematics, it is very difficult to figure out which GPIOs control the power and reset of the devices, which is required for modern standby.
But on the other hand, let’s turn the situation around a bit. While suspend to RAM in itself could be a security vulnerability (buggy vendor implementations of resume in UEFI firmware happened a lot of times in the past), so having a check for it is desirable; is suspend to idle even a security feature? Let’s think about how suspend to idle works.
- The silicon IP firmware may gate power and clock from certain IP block that are idling to save power.
- OS may opportunistically gate power and clock from peripheral devices, such as PCI Express endpoints using the ACPI the firmware exposes. It requires a GPIO to control the power applied to the device and its reset signal. Also, to gate the clock of the PCI Express port, support from the silicon is also required. If the device is idling, the OS may turn the device off using the instructions encoded in ACPI to put the device in the D3 cold state.
- Once all possible devices and IP blocks in the system have their power and
clocks gated, the CPU enters modern standby state indicated by a low level on
the
SLP_S0pad of the CPU. Modern standby also has its substates depending on how deep the power savings are.
Alright, everything seems to be all about power savings. So why suspend-to-idle, a.k.a. modern standby, is considered a security feature and is required by HSI3? I decided to open a discussion on fwupd with the hope of getting more insight.
SPI replay protection
As we explained in the release post for Gigabyte MZ33-AR1:
SPI replay protection is not supported because the flash chip used in the design does not support it. If the flash chip supported RPMC, coreboot could enable RPMC via PSP; the support for it is in upstream. Replacing a chip with a more secure part would be the solution.
Call to vendors: Choose your HBOMs carefully, as it may impact the security of your system. Having an SPI flash chip with RPMC would slightly increase the cost of a single board, but the security gain from it should be higher.
Pre-boot DMA Protection
Pre-boot DMA protection is not yet supported by coreboot, openSIL, and EDK2 stack. We wish to implement it in the future, as it just takes configuring the IOMMU in coreboot, openSIL and EDK2. Here is a Dasharo issue for tracking the implementation progress.
Runtime checks
-
CET OS support
This one is tricky because its results are not consistent. If fwupd is invoked with sudo, the check fails. But without sudo, it can pass. I have created an issue for inconsistent results of this check. Apparently, to check the CET support in OS, the test runs a binary and it returns the 0/1 result. On Gigabyte MZ33-AR1, the test did not fail if run without sudo, but on MSI PRO B850-P it fails without sudo. Given that the test does not seem reliable, we are reluctant to trust its result.
-
Encrypted swap
This failure seems to be a false positive because the Ubuntu installation, on which the
fwupd securitywas run, did not have any swap partitions. So it seems that the lack of swap partitions results in the test failure. Meaning : the non-existent swap is not encrypted and gives a false sense of insecurity.
HSI summary
In the light of above analysis and arguments, the HSI does not seem to give an objective view on system’s security. While some checks are desirable and justified, some are not related to security, or give a subjective view on the system’s insecurity.
A low HSI level does not necessarily mean that the system’s security is low. It just says that some features that apply well for their system, did not pass on your system. Some of these checks are also not giving accurate results. It is hard to trust such metrics.
Promontory21 configuration updates and GPIO support
Part 5 introduced the Promontory21 IP block from scratch. This phase brings several correctness fixes and configuration improvements based on comparison with the vendor BIOS behavior.
Promontory fixes in openSIL
The openSIL submodule was bumped (commit vc/amd/opensil/phoenix_poc/opensil: Bump for Promontory fixes) to pull in three bug fixes in the PROM21 subsystem:
-
PCIe target speed applied to all ports (
Prom21.c): A hardcoded0was passed as the port number when configuring the target PCIe link speed, so only port 0 was being configured regardless of the loop iteration. The fix passes the actualPortNumloop variable, ensuring all ports receive the correct speed setting. -
Secondary PT21 GPIO MMIO base address (
Prom21Init.c): The secondary Promontory21 chip’s GPIO MMIO base address (0xFEC50000) was being written to array index[0], overwriting the primary chip’s entry. The fix corrects the index to[1]. -
Debug output hygiene (
Prom21PreInit.c,Prom21Gpio.c): Format specifiers corrected from%xto0x%xand from%dto%u, and a missing variadic argument was added to trace macros to avoid undefined behavior.
Promontory21 GPIO driver in coreboot
Commit drivers/amd/promontory21: Add support for Promontory
GPIO adds a Promontory21
GPIO driver to src/drivers/amd/promontory21/. The GPIO pins on the
Promontory21 chip are exposed through a dedicated MMIO interface. The driver
provides an API to configure individual GPIO pins as inputs or outputs and to
read/drive their values.
Commit vc/amd/opensil/phoenix_poc/prom21: Set the GPIO table from
chip wires the GPIO
table from the coreboot chip config struct into the openSIL PROM21 parameter
block (prom21 opensil wrapper), so that board-specific GPIO pin assignments
defined in devicetree.cb are passed to openSIL initialization.
Configuration matching the vendor BIOS
Commits mainboard/msi/ms7e56/devicetree.cb: Update PROM21 config and mb/msi/ms7e56/devicetree.cb: Enable PROM21 DSP ports 4-8 update the MSI PRO B850-P devicetree to match the Promontory configuration observed in the vendor BIOS. This includes correcting PCIe port parameters and enabling Promontory DSP ports 4-8, which provide the additional USB 3.x and SATA connectivity on the rear panel.
The board’s ACPI namespace for the Promontory21 was also cleaned up: commit
mb/msi/ms7e56/acpi/mainboard.asl: Remove buggy and incorrect
ACPI removes
incorrect and buggy ACPI code in mainboard.asl that was causing resource
conflicts.
EZ Debug LED support
MSI boards include four LEDs on the board labeled DRAM, CPU, VGA, and BOOT (collectively called EZ Debug LEDs). These LEDs indicate which initialization phase the firmware is currently in, providing a visual diagnostic when the system fails to POST. Each LED corresponds to a stage: DRAM lights up during memory initialization, CPU during CPU init, VGA during graphics init, and BOOT when control is about to be handed to the bootloader.
The LEDs are driven by one CPU GPIO pin and three GPIO pins on the Nuvoton
NCT6687D Super I/O chip. Commit superio/nuvoton/nct6687d: Add API to drive
GPIOs adds a GPIO API to
the superio/nuvoton/nct6687d/ driver, allowing individual GPIO pins to be
configured and driven.
Commit mb/msi/ms7e56: Drive DRAM EZ Debug led wires the DRAM EZ Debug LED to the memory initialization path - the LED turns on at the start of DRAM init automatically via board circuitry, and turns off when memory training completes successfully. Commit mb/msi/ms7e56: Update SIO config and enable EZ Debug LED updates the SIO configuration to reflect the GPIO pin assignments for all four LEDs and enables the full EZ Debug LED subsystem.
Power button SMI
Commit soc/amd/{turin_poc,phoenix}: Enable power button SMI enables the power button SMI for both Phoenix and Turin platforms. Before this change, pressing the power button while the system was in the pre-OS firmware environment (e.g., during POST or in the UEFI setup menu) had no effect - the system would not respond.
With power button SMI enabled, the firmware registers an SMI handler that catches the power button release event and performs a clean system shutdown. This matches the expected behavior on production systems.
SMBIOS memory information from openSIL
The SMBIOS (System Management BIOS) type 17 (Memory Device) table entries describe the physical memory installed in the system to the operating system. On platforms using openSIL for memory initialization, the memory information (DIMM size, type, speed, channel mapping) is available through openSIL output data structures after memory training.
Commit vc/amd/opensil/phoenix_poc: Add code to populate SMBIOS memory info adds code to the Phoenix openSIL wrapper in coreboot to extract memory information from the openSIL APOB (AGESA PSP Output Block) and populate the SMBIOS memory data structures. Commit mainboard/msi/ms7e56: Add support for SMBIOS memory info with openSIL wires this into the MSI PRO B850-P mainboard code, enabling the board to generate accurate SMBIOS type 17 entries based on the openSIL-provided memory training results.
Operating systems and tools like dmidecode can now correctly report the
installed DDR5 DIMMs, their speed, and channel placement.
iPXE network boot with Realtek UNDI driver
Commit configs/config.msi_ms7e56: Add Realtek LAN UNDI driver adds the Realtek UNDI (Universal Network Driver Interface) EFI driver to the MSI PRO B850-P firmware image configuration. This enables network boot via iPXE using the board’s on-board Realtek RTL8126 controller.
iPXE does not have native support for the RTL8126 chip, and the MSI PRO B850-P does not have an Option ROM programmed in the NIC’s flash. Therefore, the only way to enable network boot is to include the Realtek UNDI EFI driver directly in the firmware image. The driver is loaded by the UEFI payload and registered with the UEFI network stack, making the Ethernet interface available for iPXE boot.
This is particularly useful for automated test infrastructure, where PXE boot is a common mechanism for deploying OS images to test systems.
Fast boot: disabling APOB hashing
Commit soc/amd/phoenix/Kconfig: Use APOB hashing with FSP disables APOB hashing for the Phoenix platform (when not using FSP). The APOB (AGESA PSP Output Block) is a data structure that the PSP populates with information about memory training results, hardware configuration, and other platform state. On subsequent boots, coreboot can pass the saved APOB back to the PSP to skip full memory retraining - a feature called memory context save/restore.
However, the memory context restore was not working because the PSP was rejecting the saved APOB, probably due to the hash presence in APOB region. The APOB region in SPI flash gets modified when the BIOS writes updated memory training data, which invalidates any hash that was computed over the entire region at build time.
Disabling APOB hashing removes the validation that was blocking context restore. With this change, the PSP accepts the saved APOB on warm boots and skips the full DDR5 memory training sequence. The result is a nearly 20-second reduction in the time spent in PSP initialization on subsequent boots, making the platform feel dramatically more responsive.
The cbmem timestamp log comparison below illustrates the time spent in PSP (1.5 seconds):
|
|
The rest of the firmware also has the following boot time:
|
|
With fast boot option enabled in the firmware, it is even faster (boot time reduced nearly by half):
|
|
For comparison, the vendor BIOS v2.A92 has the following boot time:
|
|
This feature also required reducing the APOB region size in flash (commit soc/amd/phoenix,mainboard/msi/ms7e56: Reduce APOB size) to match the actual APOB data size for the Phoenix desktop platform, recovering flash space that was previously over-allocated.
Other changes and fixes
CPU C-state and _LPI support
Commit soc/amd/{phoenix,turin_poc}: Separate the C-state control from CPU control separates the CPU C-state control from the CPU control block in ACPI I/O space on Phoenix and Turin PoC. Previously both were mapped to the same I/O region, which could cause conflicts when the OS tried to access them independently.
Commit amdblocks/acpi,soc/amd/phoenix: Add support for generating CPU
_LPI adds ACPI _LPI
(Low Power Idle) structure generation for Phoenix AM5. Windows 10/11 requires
_LPI objects for each CPU core to enable modern standby and CPU idle state
management. Without these structures, Windows reports errors about missing CPU
power management features and can become unresponsive after the system idles
for a period of time. The _LPI objects describe the power states available
to each CPU core, allowing Windows to use the platform’s full C-state
hierarchy correctly.
ROM3 caching for faster boot
Commit soc/amd/common/block: Cache ROM3 (backported from upstream CB:86620) adds ROM3 region caching to the memory controller configuration. The ROM3 region in the SPI flash address space contains flash regions above legacy 16MB. By enabling caching for this region, flash reads during early boot execute at cache speed rather than SPI bus speed, noticeably reducing the time spent loading firmware components.
HDA verb table update
Commit mainboard/msi/ms7e56/hda_verb.c: Uncomment ALC897 coefficient verbs uncomments the ALC897 coefficient verbs in the MSI PRO B850-P HDA verb table. These additional initialization verbs configure the Realtek ALC897 audio codec for the specific impedance and routing requirements of the MSI PRO B850-P’s audio jacks. They were previously commented out as a conservative default; enabling them corrects the audio output levels and ensures headphone jack detection works correctly. The coefficients were dumped via Linux using the following guide and compared against vendor BIOS.
CPU temperature sensor in ACPI
Commit soc/amd/phoenix/acpi/soc.asl: Add Thermal Zone for CPU
temperature adds a
Thermal Zone to the Phoenix SoC ACPI code that exposes the CPU temperature via
the ACPI thermal interface. Operating systems and system monitoring tools can
read the CPU temperature through the standard ACPI _TMP method, enabling
thermal management policies and user-space temperature monitoring. It is
especially needed for testing the CPU temperature under Windows.
EDK2 payload updated to stable-202602
Commit configs/config.msi_ms7e56: Update
config updates the EDK2
UEFI payload base to the stable-202602 release. This brings in upstream EDK2
stability fixes and aligns the payload version with the rest of the Dasharo
release infrastructure. Also a major benefit from bringing a newer EDK2 base
is the integration of UEFI Capsule Updates
V2 also funded by NLnet
Foundation.
SBOM generation enabled
Commit configs/config.msi_ms7e56: Update video blobs paths and enable SBOM enables SBOM (Software Bill of Materials) generation for the MSI PRO B850-P firmware build. The SBOM documents all software components included in the firmware image, their versions, and licenses - a requirement for supply chain transparency and security auditing. The SBOM produced by the coreboot build is in uSWID format and we publish the human readable SBOM JSON files along with released binaries. However, there are still some improvements needed to describe additional components, like the VBIOS, GOP driver and the LAN driver used by EDK2 UEFI Payload.
eSPI initialization timing fix
Commits soc/amd/phoenix/early_fch.c: Move eSPI init a bit further and soc/amd/common/block/lpc/lpc.c: Fix programming eSPI decoding fix the eSPI bus initialization sequence on Phoenix. The eSPI initialization is moved slightly later in the early FCH init sequence, and the eSPI decode register programming is corrected to properly apply the decode configuration. These fixes resolve intermittent issues with eSPI and Super I/O device initialization during early boot after adding the ROM3 caching. The speed up probably caused the eSPI initialization to happen too quickly and the eSPI registers were not being programmed for some reason. Moving the code a bit further helped to resolve the problem.
MRC cache size fix
Commit mainboard/msi/ms7e56/Kconfig: Fix MRC cache size fixes the MRC (Memory Reference Code) cache size in the MSI PRO B850-P Kconfig. The previously configured size was larger than necessary for the actual APOB data, wasting flash space and making the boot time longer when saving the APOB. This is aligned with the APOB size reduction in commit soc/amd/phoenix,mainboard/msi/ms7e56: Reduce APOB size.
Linux and Windows 11 fully operational
With all the above changes in place, the MSI PRO B850-P running Dasharo firmware based on coreboot reaches a major milestone: both Linux and Windows 11 boot and operate without issues.
Linux
Linux now boots with the amdgpu kernel driver fully active - the nomodeset
workaround is no longer required. The iGPU is fully initialized and display
output works through the native kernel driver. USB, SATA, Ethernet, audio, and
all other peripherals function correctly. The AMD P-state CPU frequency
scaling driver operates as expected.
Windows 11
Windows 11 can be installed on the MSI PRO B850-P without any workarounds. After installation, the Device Manager reports no errors or unknown devices. All platform devices are correctly enumerated and their drivers load successfully.
The key enabler for flawless Windows operation was the ACPI _LPI support
added in this phase. Without _LPI structures, Windows reported errors about
missing CPU power management features and could become unresponsive after
idling. With the complete CPU low power state description in place, Windows
power management operates correctly.
Bugfix summary
All the above presented fixes and results prove that the following milestone has been fulfilled:
Task 8. Validation & stabilization:
- Milestone a. Cross-OS boot & bug-fix campaign - 100% complete
Validation process and upstreaming roadmap
Task 8 Milestone c: Automated test results
We have tagged the first release candidate of the MSI PRO B850-P Dasharo firmware and started the validation process using our automated test suites. The test infrastructure was integrated in Part 4 of this series; the automated runs are now executing against the release candidate firmware.
The initial results can be found here:
There are still lots of failures, mainly due to unpolished test environment and configuration. The configuration inherited from MSI platforms with Intel processors enable additional test results that are not eligible on AMD paltforms, e.g. Intel Management Engine tests, etc. The configuration will be fixed before the release comes out and all possible failures retested for test environment instability, which could also potentially cause some false negatives.
The above results fulfill the requirements of the following milestone:
Task 8. Validation & stabilization:
-
Milestone c. Test results for MSI PRO B850-P
Provide test results from automated testing of MSI PRO B850-P platform.
Task 9: Upstreaming
With the platform stable and both major OSes operational, we will start the upstreaming process for both the coreboot and openSIL changes as part of:
Task 9. Upstreaming:
-
Milestone a. Initial patch series to coreboot Gerrit
Submit SoC changes and mainboard port; pass CI.
-
Milestone b. OpenSIL contribution
Submit Phoenix-specific changes back to AMD’s OpenSIL, track acceptance, and update documentation links.
This involves preparing the Phoenix AM5 SoC code and the MSI PRO B850-P mainboard port for submission to the coreboot upstream repository, and submitting the Phoenix-specific openSIL changes back to AMD’s openSIL project.
Summary
We have completed the following milestones
Task 8. Validation & stabilization:
- Milestone a. Cross-OS boot & bug-fix campaign - 100% complete
- Milestone c. Test results for MSI PRO B850-P
We are approaching the release the Dasharo firmware compatible with MSI PRO B850-P.
Boot Security Mastery Conference
If topics like secure boot chains, roots of trust, and owner-controlled firmware resonate with you, join us at the Boot Security Mastery Conference.
A five-day event on September 21-25, 2026 in Gdańsk, Poland, combining three days of hands-on training with two days of technical talks, research presentations, and community networking focused on the full boot chain across x86, ARM, POWER, and RISC-V.
For OEMs & ODMs
If you are an OEM or ODM and see the value in AMD openSIL support for your
products, our team can help make it a reality. Reach out to us via our
contact form or email us at
contact<at>3mdeb<dot>com to start the conversation.
Unlock the full potential of your hardware and secure your firmware with the
experts at 3mdeb! If you’re looking to boost your product’s performance and
protect it from potential security threats, our team is here to help.
Schedule a call with
us
or drop us an email at contact<at>3mdeb<dot>com to start unlocking the
hidden benefits of your hardware. And if you want to stay up-to-date on all
things firmware security and optimization, be sure to sign up for our
newsletter:
Huge kudos to the NLnet Foundation for sponsoring the project.
