Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie funktioniert ein Microcode-Update genau?
Ich suche gerade Infos zu Microcode-Updates. Dabei kann ich nur lesen, daß das Bios bei jedem Start die CPU aktualisiert. Mich würde interessieren, wie genau das funktioniert. Da die CPU über kein Flash-Rom verfügt, kann ich mir das nur so erklären, daß gewisse CPU-Befehle im Arbeitspeicher irgendwie umgemappt werden.
Weiß jemand mehr dazu?
Einfach gesagt läd die CPU beim Start des Rechners seinen Befehlssatz aus dem BIOS. Sind hier Fehler vorhanden führt das zu Rechenfehlern oder schlimmerem. Jede Revision hat ihren eigenen angepassten Befehlssatz. Wird dieser nicht vom BIOS unterstützt läuft die CPU nicht Rund.
Unterstützt das BIOS eines AM2 Systems nur Rev.F CPUs und man setzt eine Rev.G CPU ein, wird das BIOS diese nicht erkennen und die CPU mit dem vorhandenen Rev.F Befehlssatz Fehler machen, da es nicht den korrekten Rev.G Satz mit Microcodes enthält.
BlackBirdSR
2007-07-02, 14:15:41
Ich suche gerade Infos zu Microcode-Updates. Dabei kann ich nur lesen, daß das Bios bei jedem Start die CPU aktualisiert. Mich würde interessieren, wie genau das funktioniert. Da die CPU über kein Flash-Rom verfügt, kann ich mir das nur so erklären, daß gewisse CPU-Befehle im Arbeitspeicher irgendwie umgemappt werden.
Weiß jemand mehr dazu?
Seit dem PentiumPro haben alle Intel CPUs ein beschreibbares ROM. Der Name ist also eigentlich falsch. Alle Microcodebefehle sind darin gespeichert. Nach den Initialisieren der CPU, bevor der L2-Cache initialisiert wurde, kann ein alternativer Microcode in den dafür vorgesehenen Speicher in der CPU geladen werden. Dieser ist dann aktiv, und ersetzt den fixen Microcode im ROM. Bei jeden Systemstart ist der neue Microcode dann aktiv und behebt Fehler und Probleme.
Mit dem Arbeitsspeicher hat das zum Glück nichts zu tun, sonst wären Performanceunterschiede wirklich spübar. So fallen die minimalen Unterschiede gar nicht erst auf.
K4mPFwUr$t
2007-07-02, 14:27:30
@blackbird
in wellcher größenordnung fällt dieser microcode speicher denn an?
nur so ausm intresse heraus.
hmm der neue microcode muss doch nach jedem systemstart wieder neu in die cpu geladen werden oder nich ?
BlackBirdSR
2007-07-02, 14:36:26
@blackbird
in wellcher größenordnung fällt dieser microcode speicher denn an?
nur so ausm intresse heraus.
2048 bytes, wobei 48 davon für die Identifizierung anfallen und die restlichen 2000 bytes das Update + Prüfsummen enthalten können
Unterstützt das BIOS eines AM2 Systems nur Rev.F CPUs und man setzt eine Rev.G CPU ein, wird das BIOS diese nicht erkennen und die CPU mit dem vorhandenen Rev.F Befehlssatz Fehler machen, da es nicht den korrekten Rev.G Satz mit Microcodes enthält.
Die CPUs haben einen Default-Microcode. Wenn Rev. G nicht erkannt wird macht das BIOS eben gar nichts und fixt somit keine möglichen Fehler die evtl. ale Rev. G CPUs haben.
Seit dem PentiumPro haben alle Intel CPUs ein beschreibbares ROM. Der Name ist also eigentlich falsch. Alle Microcodebefehle sind darin gespeichert. Nach den Initialisieren der CPU, bevor der L2-Cache initialisiert wurde, kann ein alternativer Microcode in den dafür vorgesehenen Speicher in der CPU geladen werden. Dieser ist dann aktiv, und ersetzt den fixen Microcode im ROM. Bei jeden Systemstart ist der neue Microcode dann aktiv und behebt Fehler und Probleme.
Heißt das jetzt, das jedesmal dieses Rom beim Start des PCs durch das Bios beschrieben wird oder ist das ein einmaliger Vorgang im Sinnne eines Updates? Und bleibt dieses Microcode-Update dann immer in der CPU präsent, auch wenn diese dann wo anders einbaue?
BlackBirdSR
2007-07-02, 18:02:23
Heißt das jetzt, das jedesmal dieses Rom beim Start des PCs durch das Bios beschrieben wird oder ist das ein einmaliger Vorgang im Sinnne eines Updates? Und bleibt dieses Microcode-Update dann immer in der CPU präsent, auch wenn diese dann wo anders einbaue?
Nein, das ROM wird nicht neu eingebrannt. Der neue Microcode wird temporär in die CPU geladen.
Hast du die CPU also einmal mit einem neuen Bios und Microcode betrieben, ist dieser in einem Board ohne das Update trotzdem nicht vorhanden.
stickedy
2007-07-02, 18:13:05
Ein "beschreibbares ROM" wäre ja auch schon ein Widerspruch in sich...
Wahrscheinlich gibt's ein ROM das per default in ein SRAM geladen wird. Dieses SRAM kann jetzt aber auch das BIOS oder OS überschreiben wenn's sein muss.
DR.DEATH
2007-07-02, 18:37:44
Ein "beschreibbares ROM" wäre ja auch schon ein Widerspruch in sich...
Was ist dann ein EEPROM?
Nein, das ROM wird nicht neu eingebrannt. Der neue Microcode wird temporär in die CPU geladen.
Hast du die CPU also einmal mit einem neuen Bios und Microcode betrieben, ist dieser in einem Board ohne das Update trotzdem nicht vorhanden.
Aha, danke, jetzt habe ich es kapiert. Also doch fast wie ein Remapping von Befehlen, nur daß die CPU selbst den Speicher bereitstellt, um diesen neuen Code zu laden. Ich frage mich, warum man CPUs heute nicht mit einer Art Flashspeicher ausstattet, damit man eventuelle Fehler beheben könnte. Technisch dürfte das heute keinen großen Aufwand mehr machen.
Was ist dann ein EEPROM?
Auch eigentlich ein Widerspruch in sich selbst ;)
Aha, danke, jetzt habe ich es kapiert. Also doch fast wie ein Remapping von Befehlen, nur daß die CPU selbst den Speicher bereitstellt, um diesen neuen Code zu laden. Ich frage mich, warum man CPUs heute nicht mit einer Art Flashspeicher ausstattet, damit man eventuelle Fehler beheben könnte. Technisch dürfte das heute keinen großen Aufwand mehr machen.
Genau das tut der Microcode doch.
Genau das tut der Microcode doch.
Ha na, er wird nicht fest gespeichert, er wird, wenn ich es richtig verstanden habe, vom Bios beim Rechnerstart jedes Mal neu reingeladen. Ich meine die Variaten wie ein Firmwareupdate, bei der die Hardware die Änderungen immer vorhanden hat, egal ob man sie umbaut oder neu einbaut.
Tyrann
2007-07-02, 22:11:29
Ha na, er wird nicht fest gespeichert, er wird, wenn ich es richtig verstanden habe, vom Bios beim Rechnerstart jedes Mal neu reingeladen. Ich meine die Variaten wie ein Firmwareupdate, bei der die Hardware die Änderungen immer vorhanden hat, egal ob man sie umbaut oder neu einbaut.
ich glaube nicht daß das funktioniert,
Flashspeicher wird ganz anders hergestellt als ne cpu, da bräuchte man dann wie bei den slot-cpus ne eigene Platine
stickedy
2007-07-02, 22:21:51
Das wär wohl nicht unbedingt das Problem, ich sehe da mehr Sicherheitsrisiken: Das gäbe ne interessante Angriffstelle für Viren und wenn ich mir angucke, wieviel es schaffen, das beim flashen des Mainboard-BIOS was schief geht, dann ist das schon besser so. Außerdem: Was hätte man denn dadurch gewonnen? Nix imho...
Ha na, er wird nicht fest gespeichert, er wird, wenn ich es richtig verstanden habe, vom Bios beim Rechnerstart jedes Mal neu reingeladen. Ich meine die Variaten wie ein Firmwareupdate, bei der die Hardware die Änderungen immer vorhanden hat, egal ob man sie umbaut oder neu einbaut.
Tut's doch. Das BIOS ist doch schon Flash.
sind diese updates eigentlich irgendwie verschlüsselt oder kann gibts dazu sogar irgendwo ne (inoffizielle) doku wie das genau aufgebaut is und "beispielquellcodes" oder sowas in der art? das intel sowas nich allzugerne sehen dürfte is mir klar aber vllt hat da ja irgendwer schonma was rausgefunden
Tut's doch. Das BIOS ist doch schon Flash.
Ja, aber es muß jedes Mal beim Start neu geladen werden. Gut, tut natürlich nicht weh.
jojo4u
2007-07-03, 16:27:55
sind diese updates eigentlich irgendwie verschlüsselt oder kann gibts dazu sogar irgendwo ne (inoffizielle) doku wie das genau aufgebaut is und "beispielquellcodes" oder sowas in der art?
http://urbanmyth.org/microcode/ucode/intel-ia32microcode-23April2007.txt.bz2
Wow. Das hättest du ihm genausogut in binary geben können X-D
Wow. Das hättest du ihm genausogut in binary geben können X-D
Lol, erinnert mich fast an mein erstes Assembler-Listung eines Z80. Was mich erstaunt ist die Tatsache, daß man mit 2000 Bytes für das Umbiegen von Befehlen hinkommt.
Naja. Assembler ist ja lesbar. Das ist einfach nur random wenn man es nicht disassemblieren kann.
Update, aktuelle c't 15, Seite 22, Prozessorgeflüster:
Interessante Sichtweise zu den Fehlern im Core2Duo-Design (lesenswert) und dann Infos zu Microcode-Updates: (http://www.heise.de/ct/07/15/022/default.shtml)
Im Regelfall kann das BIOS einen entsprechenden Mikrocode-Patch laden. Anfangs waren die gesammelten Patches pro Prozessor nur maximal 800 Byte groß, dann 2 KByte - nun liegt die Obergrenze bereits bei 16 Kilobyte, Tendenz weiter steigend - das kann kein BIOS mehr speichern. Längst schon ist dieser Job daher an das Betriebssystem delegiert. Unter Windows gibt es seit Windows 98 den Treiber update.sys, der für eine größere Zahl von Prozessorversionen und Plattformen die passenden Patches bereithält. Und der wird einigermaßen regelmäßig gepflegt. Doch welche Mikrocode-Patch-Version nun welche Fehler behebt - damit lässt uns Intel im Regen stehen. Höchste Zeit, dass sich das mal ändert.
Sieh an, wer weiß, was da schon alles gefixt wurde! Aber durch diese Infos wissen wir nun, daß die MC-Updates bereits viel größer sein können. Ich wunderte mich schon, da ich 2000 Bytes für nicht aussreichend hielt, mein Wundern wurde bestätigt.
RavenTS
2007-07-08, 23:45:54
Interessant. Könnte das durch EFI vielleicht irgendwann mal wieder aufs MoBo zurückwandern oder wird der Speicher dort einfach gespart, da anzunehmen ist, daß sich die Updates aufgrund komplexerer CPUs weiterhin stark vergrößern..?
Interessant. Könnte das durch EFI vielleicht irgendwann mal wieder aufs MoBo zurückwandern oder wird der Speicher dort einfach gespart, da anzunehmen ist, daß sich die Updates aufgrund komplexerer CPUs weiterhin stark vergrößern..?Neuer Sockel. Dann passen die alten nicht mehr drauf und man braucht im BIOS keine Updates für zig Masken bereithalten ;)
BlackBirdSR
2007-07-08, 23:57:57
Sieh an, wer weiß, was da schon alles gefixt wurde! Aber durch diese Infos wissen wir nun, daß die MC-Updates bereits viel größer sein können. Ich wunderte mich schon, da ich 2000 Bytes für nicht aussreichend hielt, mein Wundern wurde bestätigt.
Obergrenze bei 16000 Bytes.
Bis einschließlich PentiumM waren Microcode-Updates definitiv 2000 bytes groß. Intel hat das höchstens für den Core2 und Folgende geändert.
Obergrenze bei 16000 Bytes.
Bis einschließlich PentiumM waren Microcode-Updates definitiv 2000 bytes groß. Intel hat das höchstens für den Core2 und Folgende geändert.
Jedoch wird davon gesprochen, daß die update.sys schon seit Windows 98 viele CPU-Updates innehat. Dann konnten diese Updates doch viel größer als 2000 Bytes sein, wer weiß, was darin alles schon bisher gepatched wurde.
Ich habe dazu mal einen interessanten Foreneintrag gefunden:
http://www.msfn.org/board/index.php?showtopic=44388&st=40
weiter vorne kann man noch ein paar Bemerkungen zu bisherige CPU-Updates lesen.
Das Microcode-Update der CPUs ist dokumentiert und auch in Linux implementiert. Prozessoren vor Core 2 (?) haben da eben definitiv nur 2000 Bytes Platz.
BlackBirdSR
2007-07-09, 11:39:24
Jedoch wird davon gesprochen, daß die update.sys schon seit Windows 98 viele CPU-Updates innehat. Dann konnten diese Updates doch viel größer als 2000 Bytes sein, wer weiß, was darin alles schon bisher gepatched wurde.
Ich habe dazu mal einen interessanten Foreneintrag gefunden:
http://www.msfn.org/board/index.php?showtopic=44388&st=40
weiter vorne kann man noch ein paar Bemerkungen zu bisherige CPU-Updates lesen.
"könnten", sind sie aber bis zum PentiumM nicht.
Siehe dazu z.B http://www.digit-life.com/articles/cpuerrata/index.html
Zumal viele Bios-Hersteller dieses Update anscheinend bereits in neuere Biosrevisionen eingefügt haben.
Also muss Microsoft das nicht machen, weil es zu groß wäre. Anscheinend erreicht man damit eine viel größere Nutzerschicht. Notebooks etc.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.