Good news — your GOP upgrade was the right move, and I think I found the actual blocker.
The stock GOP couldn’t do it at all
I pulled both EFI images out of a reference RX 6800 VBIOS from TechPowerUp (GOP AMD REV: 000.000.000.020.001, x64 at 0xAA00 and ARM64 at 0x14000). The x64 one has no 600 MHz path whatsoever — the constant 0xEA60 doesn’t exist in the binary. At 0x3FDE:
cmp r10b, 3 ; HDMI
mov eax, 0x84D0 ; 340 MHz - unconditional
Hard cap, no alternative branch.
The new GOP 3.9.x can — but it’s gated
The upgraded GOP does have the 600 MHz path. At .text:0x4A17:
mov ecx, 0x1B ; ATOM table dce_info
call sub_5EDC
cmp byte [rax+2], 4 ; content_rev >= 4?
mov edi, [rax+4] ; display_caps
bt edi, 8
jae use_340
...
mov eax, 0xEA60 ; 600 MHz
mov eax, 0x84D0 ; 340 MHz
And in the reference VBIOS that bit is zero:
dce_info : 0x710, fmt 4 / content 4 -> revision PASSES
display_caps : offset 0x714, value 0x00000000
bit 8 = 0 -> falls back to 340 MHz
Revision check passes, bit 8 fails, you get 340 MHz.
Important: I only had a reference dump to work with — display_caps is board-specific, so an AIB card or a newer VBIOS may well have a different value.
Also: you don’t need FRL. You’re right that it’s not in the driver — it also never looks for the HDMI Forum VSDB (C4-5D-D8), only the legacy HDMI 1.4 one. But 4K60 8-bit RGB is 594 MHz, so 600 MHz TMDS covers it.
Two caveats: bit 8 of display_caps isn’t publicly documented (dce_info_caps_def in atomfirmware.h only goes up to 0x40), and I can’t confirm the silicon actually drives 600 MHz on that port. If AMD left it at 0 deliberately, you may get a black screen instead of 4K60.
