Hello all.
For a while now, I’ve been working on coreboot for Asrock X370 Killer Sli/AC, with a ryzen 3200g cpu (while I know more people are interested in the non-apu ryzen cpus, at the moment their only exists FSP binaries for the APUs, so no choice at the moment).
The initial work was easy enough, getting it to even try to boot. Later on, various issues arose from my use of fsp meant for Fp5 socs (the soldered-on kind you’ll find in laptops) on Am4. for want of these reasons I popped the efi modules into ghidra and did some digging, and discovered some function calls that very much look like printf/printk. Digging into that a bit showed the function in question searched for a PPI by a guid ({0x8663e771, 0x52f6, 0x49fb, {0xb3, 0x45, 0xdb, 0x93, 0x96, 0x5e, 0x6c, 0xab}}) and called a function from it. Checking older firmware versions found me a pair of modules, AmdIdsDebugPrint{Pei,Dxe}, which contained the code which would be executed. Alas, the versions in the old firmware images do not actually install the PPI so I can’t just insert the ffs from the old firmware into the new one.
A bit of ghidraing later and I managed to put together a PEI module which should replicate the functionality, sending those debug strings to the serial port at 0x3f8. After inserting this (had to remove some fch modules to make room [don’t worry, I was able to confirm which of the many modules was actually used via serialice, a topic for another day/thread, maybe; a 3200g uses FchSandstone* and a 2700x uses FchTaishan*) and inserting the right guid into the AprioriPei file, it worked, with a caveat. At some point, bootup halts entirely.
I can’t think of anything I’ve done that would cause this boot failure specifically, unless the bios image has very specific file location and alignment requirements.
The reason this is ‘important’ is with these debug prints restored, one can obtain information about the system configuration in question for use in coreboot. For instance, the following part of the log allowed me to make the x370 chipset (mostly; the usb ports require some firmware to be loaded; to be written in future) and primary gpu pcie slot work (nvme is still fucky but I think that’s solvable as well):
Platform Descriptor for Die 0
Number of Engines is 3
Engine Type - PCIe Port # GPU Slot
Start Phy Lane - 8
End Phy Lane - 15
Hotplug - 0
GpioGroupId - 1
PortPresent - 1
maxLinkSpeedCap - 0
MacPortID - 0
Engine Type - PCIe Port # M.2 Slot
Start Phy Lane - 0
End Phy Lane - 3
Hotplug - 0
GpioGroupId - 1
PortPresent - 1
maxLinkSpeedCap - 0
MacPortID - 0
Engine Type - PCIe Port # X370 Chipset
Start Phy Lane - 4
End Phy Lane - 7
Hotplug - 0
GpioGroupId - 1
PortPresent - 1
maxLinkSpeedCap - 1
MacPortID - 0
Sending this Platform Descriptor to SMU...
00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
01 00 08 0F 01 00 00 00 00 00 00 00 09 00 00 00
01 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00 03 01 00 00 00
00 00 00 00 0E 00 00 00 01 00 18 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 04 07 01 00 00 00 00 00 00 00 0A 00 00 00
13 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Due to a standstill on the 3200g port (while it is capable of booting linux from either usb or sata or the x370’s nvme, it does so incredibly slowly, and I’m not certain why at this moment), I decided to give popping a spare 2700g I had into the x370 killer sli board and extract the same debug information:
Platform Descriptor for Die 0
Number of Engines is 3
Engine Type - PCIe Port # GPU Slot
Start Phy Lane - 20
End Phy Lane - 35
Hotplug - 0
GpioGroupId - 1
PortPresent - 1
maxLinkSpeedCap - 0
MacPortID - 0
Engine Type - PCIe Port # M.2 Slot
Start Phy Lane - 0
End Phy Lane - 3
Hotplug - 0
GpioGroupId - 1
PortPresent - 1
maxLinkSpeedCap - 0
MacPortID - 0
Engine Type - PCIe Port # X370 Chipset
Start Phy Lane - 4
End Phy Lane - 7
Hotplug - 0
GpioGroupId - 1
PortPresent - 1
maxLinkSpeedCap - 1
MacPortID - 0
Sending this Platform Descriptor to SMU...
00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
01 00 14 23 01 02 00 00 00 00 00 00 19 00 00 00
01 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00 03 01 07 00 00
00 00 00 00 09 00 00 00 01 00 18 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 04 07 01 03 00 00 00 00 00 00 0B 00 00 00
1B 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
If anyone who’s more skilled in this field than I could give a hand up I’d appreciate (and I’m sure all those desiring coreboot on ryzen will as well).
Moved to requests. Didn’t know I could do that (not all forums can).
Effectively, I’d like a rom produced from the attached X370KLA6.00 file and the two Ffs images.
One is the apriori pei file, patched to put the debug module in, and the other is my recreated debug module. There’s basically no room in the final Fv (3mb from the end), so you can remove FchKernPei
and FchMultiFchPei, neither of which is relevant to any hardware configuration I have.
X370KLA6.00.zip (8.3 MB)
