Und ich ging hier von dem Umstand aus das durch das Flashen was an dem jeweiligen Slots verändert wurde, wenn das was @Erklärbär vermutet könnte das wie die Faust aufs Auge passen.
Meine Vermutung: Das A52 Bios hat ein AGESA-Update der Area(s) mit geflasht! Die Bios Versionen vor den Flash hatten ja scheinbar eine andere AGESA, siehe:
Ich bin nach wie vor am Rätseln, dass dies unmittelbar nach dem Flashen auf das A52, vom A40 kommend, UEFI losging und seitdem mit keiner UEFI-Version wieder stabil war. Nicht mit A40, A42, A50 oder A52.
Fazit: Wenn diese AGESA mit Bios A52 einmal diese Area mit einer anderen AGESA beschrieben hat und die Biosse zuvor kein AGESA Update bekommen hatten, dann wird diese Area natürlich auch nicht wieder bei Backflash älterer Biosse neu beschrieben, bleibt also selbst mit A50, A42 usw. auf Stand A52. Und selbst wenn zb. A40, denke das ist das first_Bios, logischerweise dann auch das erste AGESA include hat, muss das nicht bedeuten das mit dieser dann Register neu beschrieben bzw. umgeschrieben oder gecancelt werden die erst mit AGESA aus A52 dazu kamen. Hier wäre es aus meiner Sicht die zuverlässigste Lösung man macht den CUT -> heißt, Rechner stromlos, Jumper setzen, Batterie raus! Danach dann Jumper wieder raus, Batterie rein und halt via USB Stick das First_Release A40 Bios flashen. Sauberste und sicherste Lösung. Sind danach die Probleme weg -> Fall gelöst, A52 erst einmal meiden aber dennoch MSI das Problem melden.
Das Bios musst du dir ungefähr so vorstellen -> Area1-4 / UEFI / Sonstiges (Profile usw.) | bei einen normalen Biosupdate wird meist nur der mittlere Block, also das UEFI beschrieben, die Änderungen betreffen da meist nur die AMITSE und PE32_Dateien. Die Areas sind die Blöcke die Safe sind und nur von AMD/Intel genutzt werden für zb. MC, IMEI/AGESA usw., da wird niemals ein UEFI Update rein geschrieben werden. Das sowohl die AGESA als auch IMEI nicht immer so ganz sauber werkeln, hat man ja zb. anhand des SoC/ProcHot Geplänkel gesehen und bei IMEI halt das auch da immer wieder mal Sicherheitslöcher gestopft werden müssen.
Es wird dir auch kein Editor der Welt diese Areas unkodiert auslesen können (zumindest ist mir keiner bekannt), mit ein Grund dafür das selbst die schon sehr guten erst mit Adressbereichen ab 0x27xx beginnen. Alles davor würde, wenn es denn einen Editor gäbe der das eventuell doch könnte, höchstwahrscheinlich ein komplett genullter Bereich sein. AGESA und IMEI das ist Fort Knox seitens AMD und Intel. Keiner kennt auch eine wirklich gute Dokumentation dazu. Wenn ja, her damit!!! (und ich meine jetzt keine Beschreibung, was IMEI ist und macht, sondern den Quellcode).
NACHTRAG @ TE: Du hattest ja geschrieben, dass du auch mal unter Linux getestet hättest und dort das gleiche Problem mit den SSDs unter Bios A50/A52 hast. Mit Bios A50 kam ein großes AGESA-Combo Update, dass dann auch in A52 enthalten ist. Du könntest unter Linux mit folgenden Syntax zwei Sachen testen:
dmesg | grep -E "nvme|PCIe"
A: Wird dir zb. sowas wie: "nvme(X): Device not ready... clearing queues oder frozen state." angezeigt, bedeutet das die SSD stürzt ab, weil die Spannungsversorgung (3.3V) über das Board bei Schreiblast einbricht.
B: Wird dir zb. sowas: "PCIe Bus Error: severity=Corrected/Uncorrected, type=Physical Layer." angezeigt, deutet das schwer darauf hin, dass der AGESA-Microcode das physische Link-Training der Leitungen beschädigt hat. Die Hardware verliert buchstäblich die elektrische Synchronisation zum Chipsatz. Gerade die X870 Boards sollen wohl immer mal Probleme mit Taktsignalschwankungen des X870E-Chipsatz (Promontory 21) generieren (siehe MSI Forum). Wenn das so ist -> HardCUT wie zuvor beschrieben und ein Downgrade auf ein älteres Bios mit älteren ComboUpdate (vieleicht sogar unter A40), anders wird man das nicht lösen können.