Replacing a whole PSP

[SebastiaanDirks]

So me and another guy have been testing AMD EPYC on TRX40 (with an EPYC bios) and it works. After digging into a whole bunch of research done by you guys I successfully replaced the PSP in the TRX40 bios with the EPYC PSP. But there's a catch: it detects properly in PSPTool, but it does not work on the board (post code 00). Note that both the AMD public key and OEM public key are the same in both bioses.

Are there any checksums, hashes, etc that PSPTool ignores but the actual boot procedure doesn't? Is it even possible to replace a whole PSP?

PS. This might not be the right environment to ask this question but I couldn't find any other way to contact you guys.

[RobertBuhren]

I'm a bit surprised that the EPYC PSP Firmware and the ThreadRipper FW are signed with the same public key. Could you tell me which images you are using?

[SebastiaanDirks]

Ofcourse, I'm using the 0302 bios of the ASUS KRPA-U16 and the 0902 bios of the ASUS Prime TRX40-Pro.

The microcode updates are also the same for the latest Threadrippers and EPYC Rome chips, so that might explain the overlap there.

[RobertBuhren]

Thanks. Indeed the public keys seem to be the same for EPYC and TR systems. However, don't expect to be able to boot a TR system with an EPYC PSP FW or vice versa. Even if the signature check succeeds, the firmware components probably still do some sanity check to ensure they're not executed on a different CPU model.

If you have a logic analyzer, you could try to use psptrace in order to find out which firmware component prevents booting.

Regards,

Robert

[SebastiaanDirks]

We've actually booted a Threadripper board with an EPYC bios, so it does indeed work. It's only when I try to replace the whole PSP in the Threadripper bios that it throws a 00. I'm leaning towards a mistake on my end because all I did was replace the PSP paddings in UEFITool and then update the registers with the correct addresses. Is there anything else the PSP checks that isn't included in PSPTool but necessarily to boot?

[RobertBuhren]

Nice! Do you still have this setup available? Could you check if SEV is then available on the Threadripper board when using an Epyc UEFI image?

Could you be a bit more specific regarding the two replacement types you tested?

1. You replaced the entire flash content of an TR system with an Epyc image? -> This setup does boot.

2. You only replaced the UEFI padding that contains the PSP FW inside the TR flash image -> this setup does not boot?

Is that correct?

It would be really helpful to have an SPI trace of the 2nd. setup. I'm not aware of any additional "checks", but the UEFI FW running on the x86 does interact with the PSP FW. So my guess would be, that now there's a mismatch between a component of the PSP FW and the UEFI FW.

Regards,

Robert

[SebastiaanDirks]

Yes, it's still here. Because the bios is not intended for the board some stuff obviously doesn't work eg. I haven't been able to boot into windows (did boot into a live ubuntu via usb). I'll try SEV once I can actually boot into windows.

As for the replacement types, nr. 1 is correct. The second one is correct except I did edit the PSP to correctly show up in PSPTool.

I'll try to get you an SPI trace asap. The mismatch does actually make sense and hopefully that is indeed it.

[SebastiaanDirks]

I couldn't get my logic analyzer to work, so I instead replaced both the PEI and the DXE/SMM in the bios. The result was the same: a 00 post code. It could obviously still be my fault or something else, but this tells us it's atleast not the DXE/PEI modules. I could send the file I replaced the PSP in for you to verify I indeed did not mess something up if you'd be willing to take a look.

Thanks for the effort!
Sebastiaan

[RobertBuhren]

Sure, let me know where I can find the file.

Regards,

Robert

[SebastiaanDirks]

Ofcourse, I forgot to send it. My bad.

Here's the link to the TRX40 Prime bios with a KRPA PSP

[RobertBuhren]

I don't see anything obvious. If possible, I'd compare an SPI trace of the orginal image with a trace of the patched image.

Regards,

Robert

[SebastiaanDirks]

So my cheapo logic analyzer can't properly analyze the SPI, so that's not an option unfortunately

[SebastiaanDirks]

So my cheapo logic analyzer can't properly analyze the SPI, so that's not an option unfortunately

Which logic analyzer would work with a SPI on a modern motherboard? I know you used the logic pro 16, but that's a bit expensive for this usecase

[RobertBuhren]

Sorry, I only have used the logic pro. I don't know anything about other devices.

[RobertBuhren]

Hey, were you able to produce an SPI trace? I'm curious about the result.

Btw, I just stumbled upon your SMU Debug Tool. I was wondering if there is any documentation available from AMD regarding the SMU? Is there any way to contact you? You can reach me via: robert.buhren AT sect.tu-berlin.de

[SebastiaanDirks]

Unfortunately I haven't been able to trace the SPI using my logic analyzer. I have gotten some help from RageBone. As for the SMU, there's isn't any info available publicly, we had to do some digging ourself to find out the command structure. I'll send you an email to get in touch

[Ragebone]

Got my hands on a Giglebyte TRx40 board and a good logic-analyzer from a friend that can do the minimum of 2x16MHz.
Just need to solder adapters to actually interface that with the Bus.

I can't promise anything, but hopefully, i can provide traces in the distant future.