Hardware fault my ass, Microsoft/AMD dropped the ball hard here.
I have the same CPU on a GA-F2A88XN-WIFI, and I could manage to boot Windows (not the installed system, but the very ISO itself) only up to 1909. Starting from 2004 everything I got was a full system reboot as soon as the spinning wheel animation should have appeared under the windows logo (alternatively, every now and then the screen hanged there while the image slowly started to corrupt).
After banging my head blindly for 4 days, I found the culprit: mcupdate_AuthenticAMD.dll. You simply have to delete this file from boot.wim (or replace it with an older one) and that’s it.
(or well, I also found out boot to fail with a ACPI_BIOS_ERROR BSOD if I disable the SATA controllers, but that’s a very minor problem probably specific to gigabyte DSDT)
I then used MCExtractor to compare the two versions, and indeed it seems like they are shipping microcode for 660F01 (the Carrizo CPUID) since 20H1. And I’m wondering some things now.
It is allegedly something to handle Spectre (it was authored on 2018-01-26 after all), but I couldn’t find it in any linux repository. Only windows seems to ship it. Or some bioses, even though they seem to apply and note the same mystical 0600611A revision for Bristol Ridge instead (which is so different it has a totally different AGESA).
So, is there some relatively mundane bug in the microcode that QA missed, or could it be they are matching the actually damn wrong cpu to it? (it’s not even the first time they mix up the various excavator cores “subgens”)