Injecting Radeon R9 290, R9 390, and R9 Nano in Legacy Hackintosh: Framebuffer and Device ID Spoofing

The Radeon R9 290, R9 390, and R9 Nano — all built on the Hawaii (R9 290/390) or Fiji (R9 Nano) GPU — occupy a peculiar position in legacy Hackintosh history. Apple never shipped a Mac with these exact chips, yet macOS 10.11 El Capitan through 10.14 Mojave contain native framebuffer personalities for the FirePro D300/D500/D700, which share the same GPU architecture. The challenge isn’t finding a driver — it’s forcing the system to recognise the consumer card as a supported device and assign the correct framebuffer.

Below, I’ll walk through injection techniques for these three cards across macOS 10.11 through 10.14, with specific attention to the R9 Nano’s unique power management requirements and the R9 390’s device-ID quirks. We assume a working Clover or OpenCore installation; if you are still building your bootloader configuration, the Clover Bootloader Guide for Legacy Hackintosh: Configuration and Stability provides the necessary foundation.

Device Identifiers and What Apple Expects

Here’s the core issue: macOS’s AMD graphics driver (AMDRadeonX4000.kext on 10.12+, or AMD7000Controller.kext on 10.11) contains framebuffer tables keyed by device ID and vendor ID. Apple’s FirePro D300 uses device ID 0x6799, the D500 uses 0x679A, and the D700 uses 0x679B — all Hawaii-class chips. The consumer R9 290 reports 0x67B1, the R9 290X reports 0x67B0, the R9 390 reports 0x67B1 (same as the 290), and the R9 Nano reports 0x7300 (Fiji). None of these appear in the stock kext’s IOPCIMatch dictionary.

Injection serves two purposes: first, to add the consumer device ID to the kext’s matching table (or to spoof it to an Apple-recognised ID), and second, to assign a valid framebuffer connector layout. Without injection, the system falls back to VESA mode — no acceleration, wrong resolution, no sleep.

Choosing a Spoof Strategy

Two approaches exist:

• Device-ID spoofing: Change the reported device ID in the IORegistry so the kext treats the card as a FirePro. This is reliable but can break if the kext also checks the subsystem vendor ID or the ROM revision.
• IOPCIMatch extension: Add the real device ID to the kext’s Info.plist via a kernel patch or a device property injection. This preserves the original identity but requires the framebuffer to be manually assigned.

For the R9 290/390, spoofing to 0x679A (FirePro D500) with a D700 framebuffer (6 DP connectors) is the most documented path. For the R9 Nano, spoofing to a Fiji-based device (e.g., 0x6939 for the R9 Fury X) is less common because Apple never shipped Fiji in a Mac. Instead, most users inject the real device ID and force the ‘Fiji’ framebuffer personality from AMDRadeonX4000.kext.

Clover Injection for R9 290/390 (Hawaii)

In Clover’s config.plist, navigate to Devices > Properties and add a new entry for the GPU’s PCI path (typically PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) — verify with gfxutil -f display or IORegistryExplorer).

The required properties are:

Alternative framebuffers for Hawaii include Gila (4 connectors, D500) and Kara (2 connectors, D300). If your display remains black after injection, switch to Gila — it has fewer connectors and sometimes avoids the ‘black screen on first boot’ issue.

R9 390 Specifics

The R9 390 is electrically a rebadged R9 290 with 8 GB VRAM. The same injection works, but some 390 cards have a different VBIOS that reports a subsystem ID unknown to macOS. If acceleration works but sleep fails, add the property unfair-gva (Data, value 00000000) to disable GPU-assisted video encoding — a common source of wake-from-sleep panics on Hawaii.

OpenCore Injection for R9 Nano (Fiji)

The R9 Nano uses the Fiji GPU with HBM memory. In OpenCore, add the following to DeviceProperties > Add under the correct PCI path:

The PP_DisablePowerContainment property is critical for Fiji cards. Without it, macOS’s power management may attempt to downclock the HBM controller aggressively, causing random kernel panics under load. This property disables the problematic power containment feature while leaving the rest of AGPM intact.

On macOS 10.13 High Sierra and 10.14 Mojave, the Fiji framebuffer also requires a board-ID match. If acceleration fails, add hda-gfx (Data, value embedded@0) to enable HDMI audio — but be aware that HDMI audio on Fiji is unstable past 10.14 and may cause sleep issues.

Diagnosing Injection Failures

If you’re staring at a black screen or a grey cursor, run through this checklist:

1. Verify the PCI path: Run gfxutil -f display from the OpenCore shell or Clover’s UEFI shell. The path must match exactly — a single digit off disables injection.
2. Check connector count: If your monitor uses a display port that is not mapped in the framebuffer, the port stays inactive. The ‘Baladi’ framebuffer maps 6 connectors: 2x DP, 2x HDMI, 2x DVI. If your card has a different layout, try ‘Gila’ (4 connectors) or create a custom framebuffer.
3. Disable CSM in BIOS: Legacy VBIOS initialisation conflicts with UEFI framebuffer injection. Set the BIOS to UEFI-only mode and disable legacy option ROMs.
4. Test without injection: Boot with -x (safe mode). If the display works in VESA, the injection properties are wrong; if it still fails, the card may have a hardware issue or an incompatible VBIOS.

Power Management and Sleep

Hawaii and Fiji both require proper AGPM configuration for sleep to work. The AGPM (Apple Graphics Power Management) plist in /System/Library/CoreServices/pmset stores per-board-ID power profiles. For a spoofed FirePro D500, macOS applies the MacPro6,1 profile, which is safe. For the R9 Nano with real device ID, you may need to inject a board-ID that matches a Mac that shipped with Fiji — but no such Mac exists. Instead, copy the ‘Fiji’ profile from the IOKit personality and set agpm-config in the device properties with the correct board-ID (e.g., Mac-27ADBB7B4CEE8E61 for iMac14,2).

A common workaround for sleep issues on both cards is to set darkwake=0 in the boot-args and disable GPU power gating via shikigva=80 (WhateverGreen flag). This trades a slightly higher idle power draw for reliable wake.

Framebuffer Customisation (Advanced)

If none of the stock framebuffers match your card’s port layout, you can create a custom one using the ‘FB Patcher’ method. Extract the original kext’s framebuffer with radeon_bios_decode and redsock_bios_decoder, then modify the connector table in a hex editor and inject it via Clover’s FB:connectors property or OpenCore’s framebuffer-patch-enable set.

For the R9 390, the most common customisation is swapping HDMI and DP connector types. The stock ‘Baladi’ framebuffer assigns connector type 0x400 (DP) to the first two ports and 0x800 (HDMI) to ports 2 and 3. If your card has DP on port 3, swap the connector-type bytes. Detailed steps for this process are covered in the earlier Graphics Card Injection 2 for Legacy Hackintosh: A Practical Guide, which focuses on the broader injection framework.

One final note: the R9 Nano’s single 8-pin power connector limits its TDP to 175 W. If you attempt to force a higher power limit via a VBIOS flash, the card may become unstable under macOS because the Fiji power controller expects strict adherence to the original power table. Stay with the stock VBIOS and rely on PP_DisablePowerContainment instead.