SysadminNews

AMD Lands RDNA 4m Firmware in linux-firmware Before Launch

On this page
  1. What landed, and what it reveals
  2. Firmware is the part that arrives first
  3. The three parts that have to line up
  4. What we would take from this
  5. Sources and further reading

AMD has published the firmware binaries that the open source graphics stack needs to initialise RDNA 4m, its GFX 11.7 graphics IP, to linux-firmware.git. Phoronix spotted the commits on Saturday, August 22, 2026, and the list covers GFX 11.7.0 and 11.7.1 plus PSP 15.0.0 and 15.0.9 security firmware, SDMA 6.1.4 and the VPE 2.0.0 video processing engine. The hardware these blobs serve has not launched: RDNA 4m is expected in the Zen 6 Ryzen 500 Medusa Point APUs. For anyone who runs Linux on new laptops, the useful part is knowing which kernel and Mesa versions will actually make that silicon work.

The short answer

AMD upstreamed the firmware binaries required to initialise RDNA 4m graphics into linux-firmware.git, covering GFX 11.7.0 and 11.7.1, PSP 15.0.0 and 15.0.9, SDMA 6.1.4 and the VPE 2.0.0 video processing engine, with DCN 4.2 display support in tow. The hardware is expected in the Zen 6 Ryzen 500 Medusa Point APUs, which have not launched. Linux 7.3 paired with Mesa in the 26.2 to 26.3 range is the combination described as a good baseline.

GFX 11.7the new graphics IP, between 11.5 and 12.0
7.3the kernel version with the driver support
26.3the Mesa release carrying GFX1171
Answer card: AMD published RDNA 4m firmware to linux-firmware.git on August 22 2026, covering GFX 11.7.0 and 11.7.1, PSP 15.0.0 and 15.0.9, SDMA 6.1.4 and VPE 2.0.0, with DCN 4.2 display support, ahead of the Zen 6 Ryzen 500 Medusa Point APUs, and Linux 7.3 with Mesa 26.3 as the working baseline.
Firmware first, hardware later. That order is the point. PNG

You can usually tell what a chip contains months before anyone announces it, provided you read the right git repository.

What landed, and what it reveals

The commits add firmware for GFX 11.7.0 and GFX 11.7.1, which is the first time either version appears in linux-firmware.git. Alongside them come PSP 15.0.0 and PSP 15.0.9, the platform security processor images that bring the graphics block up, SDMA 6.1.4 for the DMA engines, and VPE 2.0.0 for the video processing engine. DCN 4.2, the display core generation, follows in the same window.

Uploading all of it at once is what makes the set informative. A new graphics IP version on its own says little. A new graphics IP arriving with a new video processing engine and a new display core generation says that the whole media and display side of the design moved forward, not only the shader engine. That is a bigger jump than the version number 11.7 suggests on paper.

RDNA 4m itself sits in an awkward place in the naming. AMD compiler documentation identifies it as GFX 11.7, between RDNA 3.5 at GFX 11.5 and RDNA 4 at GFX 12.0. Reporting describes it as RDNA 3.5 with a selection of RDNA 4 instruction additions, including FP8 and BF8 conversion support and updated matrix operations. It is not RDNA 4, despite the name, and the m is generally read as mobile.

The target is the Zen 6 Ryzen 500 series, known by the Medusa Point codename. None of it has been announced.

Firmware is the part that arrives first

There is a reliable order to how AMD graphics support reaches Linux users, and firmware sits near the front of it. LLVM compiler enablement goes in early, because the compiler has to know the instruction set before anything can target it. Kernel amdgpu support follows. Mesa work for RadeonSI and RADV runs alongside, with GFX1171 support reaching Mesa 26.3 during August 2026. Firmware goes to linux-firmware.git, which distributions then package.

The reason to publish months ahead is distribution lead time. The linux-firmware package ships on a distribution schedule, not a product launch schedule. A blob committed in August 2026 has a chance of being in the firmware package that a distribution freezes for a release in early 2027, which is when a buyer might unbox a Medusa Point laptop and install Linux on it. Publish at launch instead and those first buyers meet a machine that cannot initialise its graphics.

Terminal session checking the pieces required for RDNA 4m support on Linux: listing GFX 11.7 firmware files under /lib/firmware/amdgpu, reading the amdgpu IP discovery lines in dmesg, and confirming the Mesa version reported by glxinfo.
Three checks tell you whether a machine has the whole chain. PNG

The three parts that have to line up

Firmware on its own does nothing, and this is the practical takeaway for anyone who will support these machines.

The kernel amdgpu driver has to recognise the IP block, which is what Linux 7.3 brings. The user space driver has to know the instruction set, which is Mesa 26.2 to 26.3 depending on which piece you need, with GFX1171 landing in 26.3. And linux-firmware has to be present with the GFX 11.7, PSP 15, SDMA 6.1.4 and VPE 2.0.0 images, which depends entirely on how recent your distribution firmware package is.

Miss any one of them and the failure looks different. A missing firmware blob usually gives you a clear message in dmesg about a file the driver could not load. A kernel too old gives you an unrecognised device. A Mesa too old gives you a device that initialises and then falls back to software rendering, which is the most confusing of the three, because everything technically works and nothing is fast.

The version to remember when Ryzen 500 laptops arrive is therefore not a single number. It is a kernel of 7.3 or newer, a Mesa of 26.3 or newer, and a linux-firmware snapshot taken after August 2026.

What we would take from this

The habit worth copying here is not AMD specific. Publishing enablement early, in the order that downstream consumers actually need it, is what turns a launch into a non event for the people who package software.

It also quietly changes what a distribution freeze means. A long term support release cut before August 2026 will not carry these blobs, and no amount of installing a newer kernel on top will fix a firmware package that predates the hardware. When someone asks why a brand new laptop works on a rolling release and not on the enterprise distribution they are required to run, this is usually the answer, and it was decided months before the machine existed.

Sources and further reading

Frequently asked questions

What is RDNA 4m and how does it differ from RDNA 4?

RDNA 4m is identified in AMD compiler documentation as GFX 11.7, which places it between RDNA 3.5 at GFX 11.5 and RDNA 4 at GFX 12.0. It is closer to an extended RDNA 3.5 than to RDNA 4: the additions reported so far are RDNA 4 style instructions including FP8 and BF8 conversion support and updated matrix operations, not the full RDNA 4 architecture. The trailing m is generally read as mobile, which fits the expectation that it ships in integrated graphics rather than discrete cards.

Which firmware files were added?

Firmware binaries for GFX 11.7.0 and GFX 11.7.1, the PSP 15.0.0 and PSP 15.0.9 platform security processor images, SDMA 6.1.4 for the DMA engines, and VPE 2.0.0 for the video processing engine. DCN 4.2 display support arrives alongside them. Uploading all of these together is what makes the picture readable: a new video processing engine and a new display core generation shipping at the same time as the graphics IP tells you the whole display and media block moved, not just the shader engine.

Which kernel and Mesa versions do I need?

Linux 7.3 with Mesa in the 26.2 to 26.3 range is the baseline being described as good support. GFX1171 support landed in Mesa 26.3 during August 2026, with work continuing across RadeonSI and RADV. Firmware alone does nothing: the kernel amdgpu driver has to know the IP block, Mesa has to know the instruction set, and linux-firmware has to be packaged in your distribution. All three parts have to line up before a machine boots to a working desktop.

Why does AMD publish firmware before the hardware ships?

Because distributions need lead time. The linux-firmware package is rebuilt and shipped on distribution schedules, not on launch day schedules, so a blob that lands months early has a chance of being present in the release that users install on new laptops. Publish it at launch instead and the first buyers get a machine that fails to initialise its graphics until they manually fetch firmware, which is exactly the out of box experience AMD has spent years fixing.

Do I need to do anything right now?

No, unless you package or build distributions. There is no RDNA 4m hardware to run yet. The item worth noting is for later: when Ryzen 500 laptops appear, check that your distribution ships a linux-firmware build recent enough to include the GFX 11.7 blobs, along with a 7.3 or newer kernel and Mesa 26.3 or newer. A long term support release frozen before August 2026 will not have them.