T14*/T15* T14 Gen 3i: tot nach BIOS Recovery

[rumpumpel1]

Hallo,

ich habe hier einen T14 Gen3 Intel, eigentlich nur das Mainboard (NM-E981), Historie unbekannt, das folgendes Verhalten zeigt:
zuerst bootete das Board gar nicht. Nachdem alle Spannungen da waren habe ich das BIOS ausgelesen und mit dem ME Analyzer angeschaut. Die Fehlermeldungen deuteten auf eine defekte ME-Region. Also habe ich die durch eine konfigurierte ersetzt und das BIOS auf das Board geflashed. Ab da funktionierte alles einwandfrei: ich konnte Windows installieren und alles testen. Als krönender Abschluß der Installationsorgie habe ich ein BIOS Update gemacht. Das lief auch durch - wenngleich es relativ lange dauerte. Unmittelbar nach dem Neustart lief das BIOS recovery los und hat das soeben neu installierete BIOS mit etwas alten überschrieben. Das war es: ab da startet der Laptop nicht mehr. Das ganze ist reproduzierbar: ich habe den Zyklus jetzt 3 Mal durchlaufen.
Hat jemand eine Idee woran das liegt?

 

[KNARZ]

sehr interessant. In dem Thema bin ich noch nicht tiefer eingestiegen, aber es klingt so als wäre das Selfhealing Bios corrupted. Und im Anschluss kickt dann Boot Guard.?!

 

[rumpumpel1]

Um Probleme zu vermeiden stelle ich beim Zusammenbau des BIOS mit mfit Bootguard immer auf Boot Guard Profile 0 - No_FVME. Wobei, wie das Recovery BIOS konfiguriert ist, weiss ich nicht. Also kann es sein, das Bootguard den Start verhindert.

Ob es nur an einem kaputten Recovery BIOS liegt, da bin ich mir inzwischen nicht mehr so sicher. 1. Wodurch wird denn die Revocery Prozedur ausgelöst? Durch das neu installierte BIOS? 2. Ich habe von Telegramm ein passendes BIOS + Recovery BIOS geflashed. Es war gereinigt (Configured) und ich nehme mal an, dass das Revovery BIOS zum BIOS gepasst hat. Beides geflashed: es passiert genau das gleiche.

 

[KNARZ]

Das Profil bringt dir nichts mehr. Klar kann man machen, aber wie ich das bisher immer verstanden habe ist das irrelevant, weil die fuses und das Profil dazu durch sind. Es ist leider immer bisschen schwer zu beurteilen ob andere (nicht du direkt) das auch wirklich richtig gemacht haben. Klar beim dumpen sollte nicht zu viel schief gehen, aber am Ende ist das wieder eine variable.

Gib dem Board ggf mehr Zeit zum booten? 3 bis 4 min.

 

[rumpumpel1]

ich schau mir immer den Stromverbrauch an: wenn der für 1 Minute konstant ist (nur noch im mA Bereich schwankt), dann gehe ich davon aus, dass da nichts mehr passiert.

 

[KNARZ]

Komplett richtig. Wenn noch was passiert würdest du das daran sehen. Was genau der trigger ist hab ich leider auch nicht nicht komplett herausgefunden.

 

[rumpumpel1]

btw, kennst du eine Methode in einem Alderlake BIOS dump den DMI Block zu identifizieren?

 

[KNARZ]

DMI steht ja alles im EEPROM, nicht im SPI. Abgesehen vom Windows Key.

 

[rumpumpel1]

Angeblich sollen diese Daten zusätzlich auch im SPI stehen, XORed, damit nicht sofort lesbar. Siehe

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

Bei älteren Modellen kann man nach Keywords wie LENV suchen, bei Alder Lake aber nicht mehr.

 

[KNARZ]

ThinkPad ist anders. EC/EEPROM.
Alles andere (was mir spontan einfällt) SPI.

 

[ATh]

Da ich das Thema "ungewohltes Bios Recovery" auch schon hatte, wie kann man Bios Recovery verhindern ?

 

[rumpumpel1]

Wie man ein Recovery verhindern kann, weiß ich nicht. Ich finde es schon eigenartig, dass der Recovery Chip unmittelbar nach einem BIOS Update direkt beschrieben wird, das BIOS Update ist noch nicht einmal erfolgreich gestartet worden, aber es wird sofort in den Recovery Chip kopiert.


Wie dem auch sei: mein Problem ist gelöst: es war ein defekter BIOS Chip. Eigenartig, denn er lies sich völlig problemlos mehrfach lesen und beschreiben, aber das war wohl nicht hinreichend.

 

[KNARZ]

Ah... sowas kann mal passieren. Min 2x lesen, hash drüber laufen lassen und vergleichen. Bei defekten chips kommt meist nicht das gleiche bei raus. Welcher Chip war denn defekt, der vom Backup?

 

[rumpumpel1]

es war der BIOS chip U2203. Mein Programmer macht automatisch immer ein Verify. Der Chip war beim Lesen und Schreiben völlig unauffälliig.

 

[KNARZ]

Klingt nach backup. Oft war 2201 der main. Ich check jetzt aber kein schematic dafür

Hm das alles sauber durch läuft kann schon Mal sein. Der nächste durchlauf würde dann aber nicht mehr identisch sein, in den meisten Fällen. Außer die Region im chip ist wirklich exakt nur in einen Bereich tot. Dann muss man auf Plausibilität prüfen. Ich checke bei meiner automatissierten Station auf bestimmte Bytes am Anfang und Ende des dumps und hash compare

 

[rumpumpel1]

Beim NM-E981 gibt es keinen 2201. Der Recovery Chip heißt U8001. Das Board ist auch sonst eigenartig: ich dachte die Intel Versionen haben immer einen MECxxx als EC. Dieses hat einen NPCX997.

 

[KNARZ]

Bei paar generationen gibt's sogar 4 board ids/varianten