Hallo zusammen,
da es unwahrscheinlich ist, dass Gigabyte für die alten Mainboards ein Update bringt, ist meine Frage. Ist es möglich ein Microcode Update als Ozmosis oder "normale" Bios Version zu erstellen?
VG
Scatman
GA Z87X-UD3H: Meltdown, Spetre: Microcode Update
-
- Erledigt
- scatman
- Erledigt
-
Möglich wäre es auf jedenfall. Es sollte sogar problemlos möglich sein.
Leider hab ich beim Versuch auf meinem B85M Board irgendwie das BIOS vernichtet, das Board bootet im Moment leider nicht. Warte momentan auf einen Flasher und probiere das dann wieder.
Mit dem UBU Tool ist die Modifikation fast trivial durchführbar. -
Was ist denn damit:
http://www.gigabyte.de/Motherb…70-HD3P-rev-10#support-dl
Ich habe schon das 22d drauf und bin mir unsicher ob ich tatsächlich 22e aufspielen soll. Jemand eine Vermutung inwieweit sich das alles auf die Arbeit mit dem Hacki auswirkt?
-
Ich habe meine beiden Boards am Mittwoch mit den jeweils letzten ROMs ausgestattet und hatte keine großen Probleme, die nicht mit einem NVRAM-Reset hätten kuriert werden können...
-
Hmm der neue Microcode soll ja laut Intel zu erhöhter Instabilität führen. Da hüte ich mich etwas davor den einzuspielen auf meiner Hauptmaschine.
-
So sehe ich das auch. Ich warte und hoffe das jemand mutig genug ist es zu testen. Immerhin hab ich 5 Tage gebraucht um die Maschine zum Laufen zu bringen. Ich würde sterben, wenn nach dem Update die Kiste Panic verbreitet.
-
Ich habe F22e kürzlich auf dem Gigabyte GA-Z170-HD3P eingespielt und so 100%ig rund läuft es noch nicht. Ich habe alle ACPI-Tables mit Clover extrahiert und die DSDT um einen einziegn Fehler bereinigt. Wenn ich diese DSDT in ACPI/patched ablege, sehe ich beim Booten direkt nach dem Initialisieren von FakeSMC eine Kernel-Panic. Wenn ich ohne DSDT (aber mit einigen DSDT- und Clover-ACPI-Patches) boote, ist alles fein. Ich bin noch nicht dahintergestiegen, woran das liegen könnte.
Nachtrag: Sorry, passt nicht so genau zu Thema.
-
Och, ich finde, das passt sehr gut. Immerhin weiß ich nun, dass ich mir das nicht antun werde. Und zwar genau so lange, bis ich lesen kann, dass alles gut ist und was man dafür tun muss.
Ich diesem Sinne danke an für den Pioniergeist
-
Da Intel die Microcodes zurückgezogen hat (die Problematik mit den Instabilitäten erfordert wohl ein gänzlich neues Update), würde ich im Moment eh nicht updaten.
-
Es ist in dem Fall tatsächlich wie immer: Abwarten, Tee trinken und abwarten. Gerade für Leute die nicht so fit darin sind Dinge wieder in den Griff zu bekommen.
Bin echt gespannt, wie das weitergeht.
-
F22e läuft fast problemlos bei mir. Nur nicht mit einer DSDT, die aus origin geladen wird. Und die muss nichtmal gepatcht sein. Ich probiere mal wie von @al6042 erwähnt einen NVRAM-Reset. Nachtrag: NVRAM-Reset hat nix gebracht, seltsam.
Noch ein Nachtrag: Mit einer älteren, aus F5 extrahierten DSDT kann ich problemlos booten, erhalte dann aber ein paar ACPI-Fehler.
-
Die ACPI Fehler stammen aus doppelt deklarierten Einträgen aus SSDTs. Hab die Fehler bei meinem Board auch seit den 20er Versionen.
Wenn man die DSDT Extrahierung à la RehabMan beim Obst vornimmt (Umwandlung von DSDT.aml zu .dsl mit Einbindung der SSDT Verweise), dann zeigt er auch die doppelten SSDT Deklarationen an.
Lustigerweise bootet der manchmal kalt nicht mit DSDT wegen ACPI Fehlern, booten ohne DSDT und dann Neustart mit DSDT bringt es aber problemlos zum laufen.
Ingesamt gesehen sind diese 20er BIOS bei Gigabyte sehr komisch. -
Ich hab zwar kein Wort verstanden, finde es aber spannend.
Aber ich weiss ja nun an wen ich mich wenden kann, wenn der Wald brennt.
-
-
Nur nicht mit einer DSDT, die aus origin geladen wird.
Aus "origin" wird normal nix geladen. Nur die komplette ACPI abgelegt, wenn man es erzwingt (F4 im CLovermenü). Sollte es bei dir anders sein, würde ich mal Clover aktualisieren/neu aufspielen. "origin" ist normal leer, die Befüllung ändert auch nichts am booten. Eigene DSDT und SSDTs gehören in "patched".
-
Sorry, verschrieben. Ich meinte natürlich "patched". Wenn dort die aus Clover extrahierte DSDT liegt, gibt's die oben zu sehende Kernel Panic.
Nachtrag: Ich habe die ACPI-Dateien jetzt mal wie folgt decompiliert:
iasl -da -dl DSDT.aml SSDT*.aml
Ergebnis:
Bis auf den mir bekannten Fehler (BNUM) sehe ich da nix auffälliges, oder habe ich etwas übersehen?
