I did not have any encounters with ES CPUs from AMD. I just remember my experience with Intel ES CPUs, which used a different set of keys for blob signing. I connected the dots and assumed that this is also true for AMD.
It is not about the configuration but rather a key burned into the CPU silicon that is used to verify the key used in blobs and the signatures of the blobs.
It is not so easy on servers. The AMD servers platforms perform RAM training on each boot, even before the CPU starts execution the firmware. So no matter of your BIOS/coreboot performance, you have a guaranteed 2min++ boot time (depending on amount of RAM and CPU sockets), because of memory training... There is no concept of fastboot from the cold boot like on Intel silicon.
Memory training or memory testing leading to the minutes long time spent in firmware?
I haven't used the most recent AMD server platforms, but on earlier Epyc generations the memory training and PCIe link training were noticed durations but measured in seconds, not minutes. Turning on debug for the PSP could turn this into minutes but would also show all the results of the memory training sequences. The memory testing would take minutes but was easily disabled to reduce the boot time. Has this changed in the newer Epyc generations?
Memory training taking minutes on AMD systems isn't unusual. On my desktop with a 7800X3D and 64 GB of RAM, I get scared whenever the system needs to do the training again. Because it just sits there at a black screen for a couple minutes while it does the training. I have to just wait and hope that it's doing something and not that my system is dead.
> Strange, but it is missing support for 9005 Turin. How can this be (except of 400W+ models)?
I'm not a board design specialst, but it is not uncommon that boards get newer revisions to support next gen CPUs with compatible sockets. I suspect ASUS K14PA-U12 is Turin PCU eligible, but the vendor possibly chose not to support Turin CPUs on the board. If there was a new revision of the board, then it possibly could support new CPUs.
> What do you think, could there be some true hardware issue making it impossible to workaround it in BIOS and thus no chance for coreboot either?
May be hardware incompatibility, if there are some modifications required to the design to support both Genoa and Turin. On the BIOS/coreboot side, it is possible to support both Genoa and Turin, even with a single flash image (only if the flash size is at least 32MB). It is software that needs board porting and testing.
EDIT: ASUS K14PA-U12 has only 16MB flash, so it can run only one firmware type at a time. I.e. if you plug Genoa CPU, you have to flash Genoa compatible FW. If you plug Turin CPU, you would have to flash Turin compatible FW.
That's true. The PCIe lanes on EPYC server CPUs are divided into the main Gen5 links on the SERDES (like I explained in the post) and the other lower speed lanes (Gen3/Gen4) come from the Bonus links. It is shown on the figures in the post. These Bonus links are often used for devices with lower bandwidth, like BMC. This is also true for Gigabyte MZ33-AR1, so the NVMe M.2 disk is connected to the Bonus links working at Gen3 speeds, despite the board manual says: 1 x M.2 @Gen4 (which must be a vendor's mistake).
It is not about the configuration but rather a key burned into the CPU silicon that is used to verify the key used in blobs and the signatures of the blobs.