.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 - bringing the platform close to the login prompt but still blocked by the uninitialized Promontory B850 chipset.
This post covers the work that resolves those final blockers: completing
integrated graphics initialization in openSIL, adding full Promontory21 I/O
chipset support in both openSIL and coreboot, enabling AMD P-state CPPC
support, integrating the AMD GOP driver in EDK2, and a wide range of ACPI,
eSPI, and PCIe improvements. Linux is now booting with a working display -
though the amdgpu kernel module still triggers a hard fault, so nomodeset
is currently required as a temporary workaround.
The relevant coreboot changes are tracked in pull request 883 on the Dasharo coreboot downstream repository. The openSIL changes are spread across three pull requests: GFX, Promontory21, and CPPC. The EDK2 AMD GOP integration is in pull request 281, which has already been merged.
The milestones covered in this post are:
Task 5. Port configuration in coreboot:
-
Milestone c. Graphics initialization
Add board-specific DDI port configuration and initialize graphics; verify with display tests.
Task 6. Port Phoenix AM5 specific code to openSIL:
-
Milestone a. Port Promontory I/O expansion chipset support to openSIL
The Phoenix OpenSIL support only covers mobile Phoenix CPUs. Board designs with desktop CPUs also use the Promontory chipset to provide additional I/O expansion on the board. The goal is to add Promontory 21 initialization to Phoenix openSIL by adding a new IP block and a Kconfig option to differentiate between mobile and desktop Phoenix CPUs.
-
Milestone c. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (NBIO, SMU, GFX)
Most of the code is similar or identical between desktop and mobile parts. However, care must be taken for possible small differences. The goal is to analyze and compare the desktop and mobile differences. This milestone covers NBIO, SMU and GFX blocks.
This milestone was previously covered at the NBIO and SMU level. The missing GFX initialization is completed with this post.
Task 7. Platform-feature enablement:
-
Milestone a. Phoenix desktop-specific ACPI tables
Extend coreboot ACPI code for Phoenix to support AM5 socket desktop parts.
The two milestones from part 4 that had budget redirected to GFX are now also fully completed:
- Task 6 Milestone e (MPIO, CXL) - budget shifted from CXL to GFX
- Task 6 Milestone d (DF, RcMgr, APOB) - budget shifted from DF and APOB to GFX
Integrated graphics initialization in openSIL
The problem with Phoenix PoC GFX code
The Phoenix PoC openSIL shipped with a GFX IP block that essentially did nothing useful beyond dumping PHY tuning values. None of the actual hardware initialization sequence was present. As we noted in Part 3 and Part 4, every attempt to bring up the iGPU hit a wall: the GPU BAR was allocated but the display engine was never powered, the VGA Enable register was never programmed, and the UMA framebuffer region remained inaccessible. The VBIOS execution path via Yabel/x86emu also failed silently.
The solution required implementing the missing initialization from scratch, guided by AMD register documentation, analysis of the VBIOS behavior on the vendor firmware, and cross-referencing with what AMD had implemented for other openSIL platforms.
GFX changes
The GFX pull request (phoenix_gfx
branch) adds the core initialization logic that was absent from the PoC.
Roughly 2K new lines of code.
The initialization of integrated graphics comes into 4 parts:
-
openSIL: Programming northbridge registers related to graphics.
Mostly these are registers saying where is RAM or MMIO and the boundary between them. How the legacy VGA memory should behave using the VgaEn register.
-
openSIL: Gathering and setting up graphics information in UMA memory
The UMA memory contains blocks of various information about the system in the ATOMBIOS-specific format. The data varies from fixed configuration values, to patchable settings with openSIL input parameters. The PHY tuning parameters also copied to the UMA memory.
-
coreboot and openSIL: Creating DDI descriptors and parsing them to UMA information.
Each board may use different connectors and display pipes. It has to be overridable from outside of openSIL. Thus openSIL takes a list of DDI descriptors, parse them, enumerates all connectors and translates to ATOMBIOS structures, placing the information at proper offset.
On the coreboot side, the key addition is the DDI (Display Digital Interface) port configuration. The coreboot PR 883 adds the board-specific DDI descriptors to the MPIO configuration structure, describing the physical display outputs available on the MSI PRO B850-P: the HDMI and DisplayPort outputs routed from the Phoenix iGPU through the board’s display output circuitry.
The GFX IP block parameters are set in the Phoenix openSIL wrapper in coreboot (
src/vendorcode/amd/opensil/phoenix_poc/), including the UMA size and the audio endpoint enable flags. A newCONFIG_PHOENIX_GFX_INITKconfig option gates the entire GFX initialization path, allowing it to be disabled for bring-up builds without a display. -
coreboot and EDKII: Launching AMD GOP driver
Once UMA memory is populated with all the required information, the AMD GOP driver can be used to initialize the display in firmware. Note, that we could not use the VBIOS directly, due to UMA memory being above 4G. Also AMD GOP driver is an EFI driver, so it can only be launched in EFI environment, such as UEFI Payload. Thus the support for launching the AMD GOP had to be integrated there. Firstly the driver had to be added to the UEFI FFS (Firmware File System) together with the VBIOS binary.
1 2 3 4 5 6 7 8 9 10!elseif $(USE_AMD_PLATFORM_GOP) == TRUE !if "X64" in $(ARCH) FILE DRIVER = $(AMD_GOP_DRIVER_GUID) { SECTION PE32 = DasharoPayloadPkg/AmdGopDriver.efi SECTION UI = "AmdGopDriver" } FILE FREEFORM = $(AMD_GOP_VBIOS_GUID) { SECTION RAW = DasharoPayloadPkg/Vbios.bin } !endifThen the VBIOS had to be hooked up to the
EFI_PCI_IO_PROTOCOLas an OptionROM, so that AMD GOP can find it if needed.
When all the pieces were put together, we could observe the Dasharo logo during boot on the HDMI port on MSI PRO B850-P WIFI.
Current state: Linux boots, amdgpu hard faults
Linux now boots on the MSI PRO B850-P with display output available through
the GOP driver in the UEFI phase. However, the amdgpu kernel graphics driver
triggers a hard fault when it attempts to take over the display from the GOP.
The workaround for now is to boot Linux with the nomodeset kernel parameter,
which disables kernel-mode setting and leaves the display in the framebuffer
console mode initialized by the GOP driver.
Fixing this driver-level fault will be addressed as part of:
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.
A video demonstrating Linux booting with a working
display (with nomodeset) is
provided as proof that GFX and GOP are functional. This proves that the
following milestones are completed:
Task 5. Port configuration in coreboot:
- Milestone c. Graphics initialization - 100% complete
Task 6. Port Phoenix AM5 specific code to openSIL:
- Milestone c. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (NBIO, SMU, GFX) - 100% complete (GFX finished)
Also, the following milestones are being completed, because of the budget shift to GFX:
Task 6. Port Phoenix AM5 specific code to openSIL:
- Milestone d. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (DF, RcMgr, APOB) - 100% complete (budget redirected from DF/APOB to GFX, which is now done)
- Milestone e. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (MPIO, CXL) - 100% complete (budget redirected from CXL to GFX, which is now done)
Promontory21 chipset support
Background: what is Promontory21?
The Promontory21 (PROM21) is AMD’s I/O expansion chipset used on desktop AM5 boards with the B850 and X870 chipsets. It is a companion chip connected to the Phoenix SoC via PCIe. The chip provides additional USB 3.x and USB 2.0 ports, SATA ports, and PCIe connectivity that exceed what the Phoenix SoC alone can provide. On the MSI PRO B850-P, the Promontory21 is responsible for most of the rear-panel USB and SATA connectivity.
Without Promontory21 initialization, all devices behind it appear as PCIe switches with broken links - exactly the error messages seen at the end of Part 4:
|
|
However, even after adding Promontory 21 initialization, these errors appear (even with official MSI firmware). But somehow, it does not affect the devices connected behind those PCI Express brides (Ethernet and WiFi).
openSIL: new PROM IP block
The Promontory21 pull request introduces PROM21 as a first-class IP block in openSIL. This is a significant addition - Promontory support was entirely absent from the Phoenix PoC, and the new code had to be written from scratch based on register documentation and reference implementations from other AMD platform codebases.
New IP block structure
The new xUSL/PROM/PROM21/ directory contains the full initialization stack:
Prom21PreInit.c- power sequencing and PCIe link check before the main initProm21LoadFw.c- downloads the Promontory21 firmware blob over PCIe to the chip; the chip requires a firmware update to be operationalProm21Init.c- main initialization sequence: PCIe link training, endpoint configurationProm21Gpio.c- GPIO pin configuration for Promontory21 signalsProm21Sata.c- SATA controller configuration within the chipProm21Xhci.c- xHCI (USB 3.x) controller configuration within the chip
A new SilId_PromClass was added to the SIL_DATA_BLOCK_ID enum in
xSIM-api.h, registering PROM as a known IP block ID. The Promontory21 init
function InitializePromTp1 is hooked into the SoC IP initialization table in
IpBlkListF19M70Tp1.c, so it runs as part of the F19M70 Timepoint 1 sequence
alongside the other IP blocks.
Firmware loading mechanism
The Promontory21 chip requires a firmware blob to be loaded at runtime. The
Prom21LoadFw.c module handles the PCIe-based firmware download from a
host-provided buffer. On the coreboot side, a new
psp_load_promontory_fw_from_efs() function in
src/soc/amd/common/block/psp/psp_efs.c locates the Promontory firmware
within the Embedded Firmware Structure (EFS) in the SPI flash and passes it to
openSIL. A dedicated 256 KiB region in early reserved DRAM is allocated to
hold the firmware during loading.
The amdfwtool utility was also extended to embed the Promontory firmware
blob into the AMD firmware image during build time, so the binary lands in the
correct EFS location in the final flash image.
MPIO early link config API
The Promontory21 initialization needs to know the PCIe link state (speed,
width, active slots) that was established during early boot before ramstage
runs. A new GetEarlyLinkConfig Xfer API was added to the MPIO IP block. The
implementation in MpioInitPhx.c queries the MPIO engine descriptors to
retrieve the link information. PROM21 init uses it to verify that the PCIe
link to the Promontory chip is actually up before proceeding.
coreboot side: PROM21 driver, devicetree, ACPI, and amdtool
The coreboot side of Promontory21 support is equally substantial. A new
src/drivers/amd/promontory21/ driver directory was added:
chip.h- chip config struct defining PCIe bus/device/function, port speed, and tuning parameterschip.c- driver implementation with device enable and scan callbacksKconfig- newDRIVER_AMD_PROMONTORY21toggleacpi/prom21_gpio.asl- ACPI ASL file defining the Promontory21 GPIO device, with GPIO methods and OpRegion for ACPI-controlled GPIO access
The MSI PRO B850-P devicetree (devicetree.cb) was updated to add the PROM21
node with board-specific PCIe configuration and tuning parameters. A new
translation layer prom21/chip_to_opensil.c maps the coreboot chip config
struct fields to the openSIL PROM21 IP block parameter structure for easier
portability across different boards.
The amdtool utility in util/amdtool/ was extended with a new dump command
--dump-prom, which dumps Promontory21 configuration registers.
The tool was used to capture the Promontory21 configuration from the vendor
BIOS, which then informed the board-specific settings in the MSI PRO B850-P
devicetree.cb. Without this, matching the vendor BIOS behavior for
Promontory USB and SATA port configuration would have required a lot of
guesswork.
B850 USB and SATA descriptors
With Promontory initialization in place, the full set of B850 chipset USB descriptors and PCIe slot descriptors were added to the MSI PRO B850-P devicetree. The board now correctly describes all physical USB 3.2 Gen2 ports provided by the Promontory chip, matching the port numbering and speed capabilities visible in the vendor BIOS.
Promontory chipset summary
The Promontory chipset support was added from scratch and required nearly 6400 new lines of code in openSIL, and nearly 2000 lines of code in coreboot spread across many files. These changes fulfill the requirements of the following milestone:
Task 6. Port Phoenix AM5 specific code to openSIL:
- Milestone a. Port Promontory I/O expansion chipset support to openSIL - 100% complete
AMD P-state CPPC support
The CPPC pull request adds CPU frequency query APIs needed to populate the CPPC (Collaborative Processor Performance Control) ACPI objects. CPPC is part of the AMD P-state driver framework that modern Linux kernels use for fine-grained CPU power management.
New openSIL APIs
Two new public API functions were added to Include/xPRF-api.h:
xPrfGetCppcMinFrequency- reads the CPPC minimal frequency from the SMUxPrfGetCppcNomFrequency- reads the CPPC nominal frequency from the SMU
The implementation in xPRF/CCX/xPrfCcx.c sends SMU service requests using
two new message IDs:
|
|
Each function follows the established pattern: zero-initialize the SMU
argument struct, set the message ID, call SmuServiceRequest(), and extract
the result from the response register. These frequency values are then used by
coreboot to fill the _CPC (Continuous Performance Control) ACPI objects that
the Linux amd-pstate driver reads to configure its performance states.
Similar changes were done during Turin server project to make the Linux driver happy.
The PR also reduces debug verbosity in SmuInitPhx.c by consolidating the SMU
response polling log statements, reducing log spam during firmware boot.
ACPI improvements
A significant portion of the coreboot changes are dedicated to ACPI table generation for the AM5 Phoenix platform (Task 7 Milestone a). The changes are spread across multiple files but form a coherent improvement to interrupt routing and device description.
Interrupt routing for PCI bus 0 devices
A new
c1d611a
commit adds an IOAPIC interrupt routing function that generates the _PRT
(PCI Routing Table) for the host bridge and PCI bus 0 devices. Previously,
interrupt routing for on-board PCI devices was handled entirely by the legacy
PIC (Programmable Interrupt Controller) path, which is not sufficient for
modern ACPI-compliant systems. The new code adds proper IOAPIC routing entries
for all devices on bus 0.
ACPI _PIC method and NAPE for IOAPIC switching
The DSDT was updated to implement the ACPI _PIC notification mechanism. When
the OS calls _PIC(1) to indicate it will use IOAPIC mode, the NAPE method
is invoked to switch the platform’s interrupt routing from PIC to IOAPIC. This
is the standard ACPI mechanism for platforms that support both interrupt
routing modes, and is required for correct interrupt delivery to ACPI devices.
Super I/O ACPI code
The superio.asl file was added to describe the Nuvoton Super I/O chip on the
MSI PRO B850-P. This provides ACPI descriptions for the UART, hardware
monitoring, and other SIO functions, enabling the OS to properly manage power
and resources for these devices.
ACPI events code and MSI utilities installer
The 0b2a3b2 commit adds an ASL namespace entry for the MSI utilities installer - the background software component that MSI’s platform tools use to communicate with the firmware. While not strictly required for boot, this ACPI infrastructure is necessary for full compatibility with MSI’s Windows platform software stack.
The 7bfdff3 commit adds ACPI event handling code specific for the mainboard.
Missing PHX AM5 IRQs and interrupt routing update
Commit
a34f7e7
adds the missing IRQ entries for PHX AM5 platform devices to
src/soc/amd/phoenix/acpi.c. The companion commit 6ebf308 updates the
interrupt routing in mainboard.c to correctly assign interrupts to all the
B850 PCIe slots and on-board devices, matching the interrupt assignments
visible in the vendor BIOS ACPI tables.
ACPI summary
New systems always require a lot of ACPI code to describe the devices and their interaction. As you can see, to streamline the porting, the ACPI is generated dynamically in many places, to reduce the burden of adding custom mainboard ACPI code. Where possible, existing coreboot facilities to generate ACPI code were used. Where there was no need to dynamically generate the ACPI code, the static ACPI table code was added to common places, where appropriate.
All above changes fulfill the requirement of:
Task 7. Platform-feature enablement:
- Milestone a. Phoenix desktop-specific ACPI tables - 100% complete
Other chanegs and fixes
NBIO: fixed GNB IOAPIC address
A related fix in the NBIO IP block adds the ability to program a fixed GNB
IOAPIC MMIO address. When the host firmware sets CfgGnbIoapicAddress to a
non-zero value, the NBIO code programs the IOAPIC at that specific address
rather than relying on whatever the Resource Manager chose. This is required
for correct interrupt routing on desktop AM5 platforms where the IOAPIC
address must match the ACPI MADT and DSDT tables. The address 0xfec01000 is
the standard address for GNB IOAPIC on client systems with 2 IOAPICs.
SMBIOS type 41 entries
The 7bb685d commit adds SMBIOS type 41 (On-Board Devices Extended Information) entries for the MSI PRO B850-P. These entries describe the on-board devices (LAN, audio, USB controller, etc.) to the operating system’s hardware enumeration layer, improving device identification in system management tools.
HDA verb tables for iGPU and external codec
The aaf4c40 commit adds HDA (High Definition Audio) verb tables for both the Phoenix iGFX HDA endpoint and the external Realtek audio codec. These verb tables program the audio codec hardware to the correct pin configurations for the MSI PRO B850-P’s audio jacks, HDMI audio output, and display audio endpoint. Without correct verb tables, audio output defaults to muted or incorrect routing.
eSPI bus initialization fix
Commit
eb8b3cf
fixes the eSPI (Enhanced Serial Peripheral Interface) bus initialization in
src/soc/amd/common/block/lpc/espi_util.c by adding proper IRQ configuration
and masking options. The eSPI bus is used to communicate with the Super I/O
chip and other platform devices. Without the correct IRQ mask configuration,
the interrupt routing for eSPI-attached devices did not work properly, causing
failures in Super I/O device initialization and potentially causing spurious
interrupt delivery.
The fix adds IRQ masking during eSPI initialization to prevent premature
interrupt delivery before the interrupt routing tables are fully configured.
Additional eSPI registers were also added to the amdtool dump output
(e849288)
to make debugging eSPI issues easier.
PCIe bridge enumeration fix for internal GPP
Commit
ac59f8b
fixes an important PCIe enumeration bug: the internal GPP (General Purpose
Port) bridges were not using PCIe bridge scan, causing them to fall back to
the generic PCI bus scan path. The consequence was that PCIe capabilities were
not being properly set for these bridges, leading to MaxPayload mismatches
between devices and their parent bridges. These mismatches can cause device
malfunctions, particularly for devices that support or require larger payload
sizes (common in PCIe 4.0 and 5.0 devices).
The fix in src/soc/amd/phoenix/root_complex.c ensures that the internal GPP
bridges use the proper pciexp_scan_bridge() path, which correctly enumerates
PCIe capabilities and sets MaxPayload consistently across the hierarchy.
NBIO parameter improvements and IOMMU
Commit 5979fdb fills in the missing NBIO parameters for IOMMU and APIC initialization. The NBIO IP block in openSIL requires the host firmware to pass several platform-specific parameters, and the PoC integration left some fields at their zero defaults. The fixes bind the IOMMU enable flag and APIC configuration to the devicetree, making them configurable per-board.
The d380efe commit enables IOAPIC 8-bit IDs and IPU (Interrupt Processing Unit) configuration, which is required for correct interrupt delivery with more than 8 IOAPICs - a situation that can arise on desktop platforms with multiple GPUs or PCIe expansion cards.
Additionally,
bf7eb9c
sets predefined IOAPIC IDs via the CfgGnbIoapicAddress mechanism added in
the openSIL Promontory PR, ensuring the GNB IOAPIC is always at a known
address that matches the ACPI MADT table.
openSIL parameter passing: other improvements
Several additional openSIL parameter passing improvements were made:
- fd8ffc1 limits MMIO allocation to 1 TB, preventing the Data Fabric from trying to map MMIO space beyond what Phoenix silicon can handle
- d91bedf updates NBIO and FCH settings based on SoC config, binding more parameters from the devicetree to the openSIL IP blocks
- 28b1883 adds IRQ mask configuration via the devicetree, allowing per-board override of the default interrupt mask settings
- 435193b
sets
FORCE_STPCLK_RETRY, a power management setting needed to avoid clock gating issues on the desktop Phoenix platform
MSI FlashBIOS support
Commit 2f148a4 adds support for the MSI FlashBIOS button feature. MSI boards include a physical button on the rear I/O panel that allows flashing the BIOS from a USB drive without a CPU or RAM installed. This is a useful recovery feature that is platform-specific in its implementation.
The necessary changes include modifications to util/msi/romholetool/ to add
the MS-7E56 (MSI PRO B850-P WIFI) board entry, and updates to the build and
flash tooling to support the MSI FlashBIOS region layout. Without this
support, the FlashBIOS button would not function with the Dasharo firmware
image.
AMD memory context save/restore
Commit 1426f95 enables AMD memory context save/restore. This feature allows coreboot to save the trained memory configuration to SPI flash, dramatically reducing cold boot time on subsequent boots by skipping the full memory training sequence. On Phoenix desktop platforms with DDR5 memory, cold boot memory training can take 30-60 seconds; with context save/restore, subsequent boots skip training almost entirely.
Summary
This post covered the fifth and most feature-complete phase of the MSI PRO B850-P coreboot port:
-
GFX initialization in openSIL: Added
GfxInitPhx()to initialize the iGPU UMA framebuffer region,GfxProgramVgaEn()to program the VGA Enable register in the Data Fabric, and cleaned up the GFX configuration defaults. Combined with the DDI port descriptors in coreboot, integrated graphics now initialize correctly. -
AMD GOP driver in EDK2 (merged PR 281): Integrated the official AMD GOP binary driver and VBIOS into the Dasharo payload package, enabling graphical UEFI output through the initialized iGPU. Also includes AMD server platform fixes for root bridge enumeration, memory map handling, and shutdown.
-
Promontory21 support in openSIL: Added a complete new PROM IP block with firmware loading, PCIe link management, SATA and xHCI configuration, GPIO setup, and MPIO early link config API. Also fixed NBIO IOMMU programming and added the fixed GNB IOAPIC address capability.
-
Promontory21 support in coreboot: New
drivers/amd/promontory21/driver directory with chip config struct, device operations, and ACPI GPIO device. Extendedamdtoolwith Promontory config dumping. Added B850 chipset USB and PCIe slot descriptors. Extendedamdfwtoolto embed Promontory firmware in the flash image. -
AMD P-state CPPC support: Added
xPrfGetCppcMinFrequency()andxPrfGetCppcNomFrequency()openSIL APIs, implemented via SMU service requests, and wired them into coreboot’s ACPI table generation for the Linuxamd-pstatedriver. -
ACPI improvements (Task 7 Milestone a): Interrupt routing for PCI bus 0 devices, IOAPIC switching via
_PIC/NAPE, Super I/O ACPI description, ACPI events and MSI utilities installer namespace, missing PHX AM5 IRQ entries, SMBIOS type 41 on-board device entries, and HDA verb tables. -
eSPI initialization fix: Added proper IRQ configuration and masking to eSPI bus init, fixing interrupt routing for eSPI-attached devices.
-
PCIe bridge enumeration fix: Internal GPP bridges now use PCIe bridge scan, ensuring correct MaxPayload configuration and preventing device malfunctions.
-
openSIL parameter improvements: MMIO limit, IOMMU/APIC binding, IRQ masks, IOAPIC IDs, FORCE_STPCLK_RETRY, and various other parameter fixes.
-
MSI FlashBIOS support: Added MS-7E56 board entry to
romholetooland the necessary tooling changes for the physical BIOS recovery button. -
AMD memory context save/restore: Enabled fast boot via trained memory context caching.
The milestone completion status is as follows:
Task 5. Port configuration in coreboot:
- Milestone c. Graphics initialization - 100% complete
Task 6. Port Phoenix AM5 specific code to openSIL:
- Milestone a. Port Promontory I/O expansion chipset support to openSIL - 100% complete
- Milestone c. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (NBIO, SMU, GFX) - 100% complete (GFX initialization completes this milestone)
- Milestone d. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (DF, RcMgr, APOB) - 100% complete (budget redirected from DF/APOB to GFX, which is now done)
- Milestone e. Cover Phoenix mobile and desktop silicon initialization differences in openSIL (MPIO, CXL) - 100% complete (budget redirected from CXL to GFX, which is now done)
Task 7. Platform-feature enablement:
- Milestone a. Phoenix desktop-specific ACPI tables - 100% complete
The platform now boots Linux with a working display (via nomodeset). The
remaining known issue is the amdgpu kernel driver hard fault, which will be
addressed in:
Task 8. Validation & stabilization:
- Milestone a. Cross-OS boot & bug-fix campaign - scheduled for the next phase
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.
