Die im Video gezeigten Bootzeiten sind größtenteils direkt nach dem UEFI-Flash, das heißt mit der erstmaligen RAM-Initialisierung und ähnlichem. Das dauert immer ewig und tritt nicht nur nach UEFI-Updates, sondern bei vielen Platinen auch nach vollständiger Trennung vom Stromnetz (PC an Schalterleiste) auf. Die reinen Kalt-Bootzeiten vom Einschalten bis Windows habe ich nebenan im Artikel festgehalten. Aber auch die sind länger als von vielen Windows-Usern aus der Praxis gewohnt: Windows 10 hat diverse Alternativen zum "Rechner abschalten", bei denen es sich gar nicht vollständig herunterfährt, sondern nur in eine Art abgespeckten Hibernate-Modus geht oder sogar Kopien aller Daten im RAM lässt. Wenn man so einen PC einschaltet, ist er natürlich sehr schnell einsatzbereit, weil er gar nicht booten muss.
Zu den älteren Platinen: Soweit ich es zwischen den Zeilen meiner Mainboard-Kontakte gelesen habe (wirklich offen wollte niemand antworten), werden die AGESAs für die verschiedenen Plattformen erst noch kompiliert. Wenn man 1.0.0.3A/B/... für X470 kompiliert, kommt immer etwas Zen-kompatibles bei raus, wenn man die Parameter für eine X570-Umgebung setzt, läuft nur Zen+ und neuer... .
Der weitere Support mit Microcodes, die meinem Wissen nach nicht Teil des AGESA sind (nein, ich weiß nicht, was da sonst drin steht), ist Sache der Hersteller und ich habe mich auch schon gefragt, warum MSI solche Probleme mit der UEFI-Größe hat, andere Hersteller aber nicht. Aber natürlich will MSI diese Frage nicht beantworten und die anderen können es nicht, weil sie keine MSI-UEFIs können.
Bei Intel sind Microcodes für ganze Generationen jedenfalls nur wenige 100 KiB groß und auch bei AMD habe ich für die gesamte Firmware einer Architektur-Stufe Zahlen zwischen 2 und 3 MiB gehört. Das wäre zwar nicht wenig, sollte aber trotzdem alles in einen 16-MiB-Chip passen – wenn man ihn nicht schon mit RGB- und sonstigen Controllern, UEFI-Designs und ähnlichem vollgepackt hat. Zum Teil mag es auch eine Know-How-Frage sein, denn UEFI-Code ist noch immer low-level-Programmierung. Da sind Positionen zum Teil hardgecoded und wenn ein Programmteil kleiner ausfällt, muss der Freiraum dahinter mit 0en gefüllt werden, damit der nächste Abschnitt am richtigen Bit beginnt. Macht man das nicht, wird das Ganze UEFI funktionslos. Hat man dagegen ein großes Team voller erfahrener Leute, die alle Abschnitte einschließlich der Verweise von Hand optimieren, kann man möglicherweise einige KiB freischaufeln, die ein anderer Hersteller mit derartigem Padding zumüllen muss.
Bei Sockel-1151-Mainbords ist es beispielsweise so, dass man bei Platinen mit 8-MiB-Chip (!) zum Teil nur zwei Microcodes regulär unterbringen kann. Möchte man eine derartige Z170-Platine für
Coffee Lake modden, muss man entweder den Sky- oder den Kabylake-Code rauskicken. Oder aber man findet einen der mittlerweile zahlreichen Mods, die den gesamten Aufbau optimiert und Platz für einen dritten Code geschaffen haben.
Zurück zum Artikel: Ryzen 1000 auf X570 Teil 3: Abwärtskompatibilität zu Summit Ridge plötzlich wieder da?
