T5xx (T500-550 ohne "p") T530: Coreboot 4.12 Default Konfiguration mit SeaBIOS und libgfxinit fuehrt zu Resets

[jal2]

Hallo,

irgendwie stehe ich bei Coreboot gerade auf dem Schlauch. Ich hatte versucht, ein defektes T530 Intel-Only Board (geht an, aber schwarzer Bildschirm, kein Piepsen) durch Ueberschreiben von SPI2 zu reparieren. Diesmal wollte ich es gleich mal mit Coreboot probieren. Also Coreboot git Repository geclont, auf Tag 4.12 gesetzt, fuer T530 konfiguriert und alles auf Default gelassen (Payload: SeaBIOS, Graphics initialization: Use libgfxinit). Ich habe keine Blobs aus dem alten Image in Flash extrahiert. Einfach nur gebaut und die letzten 4MByte von coreboot.rom ins SPI2 geschrieben.

Damit sehe ich SeaBIOS starten und ich komme auch in das Menu eines Multiboot USB Sticks. Beim Booten einen Live-Linux (grml32/64, xubuntu 18.04) kommt es aber zum spontanen Reboot des T530. Vermutlich an der Stelle, an der die Intel-Grafik angesprochen wird (Umschalten auf kleinere Schrift/anderen Font bei grml).

Ich koennte jetzt versuchen, das Intel Grafik VGA ROM aus dem UEFI Dump zu extrahieren und statt libgfxinit zu nutzen, aber laut Doku sollte libgfxinit doch Intel Grafik auf dem Ivy Bridge unterstuetzen, oder?

Die Resets koennten natuerlich auch von einer defekten ME Region im Flash ausgeloest werden, aber kommt dieser Reset nicht erst nach ca. 30 Minuten?

Gruss,
jal2

 

[Exe]

Wieso probierst du es nicht erst mit dem Original Lenovo Bios?
Die 4MB kannst du dir ja auch aus jedem Bios Update rausziehen

 

[jal2]

Wieso probierst du es nicht erst mit dem Original Lenovo Bios?
Die 4MB kannst du dir ja auch aus jedem Bios Update rausziehen

Mit dem Original BIOS (2.70) bleibt der Fehler bestehen: Thinklight blitzt kurz auf, der Luefter dreht, aber der Bildschirm bleibt schwarz. Mit den Sicherungen zum Display ist alles OK, da ich danach mit Coreboot wieder Ausschriften sah.

Das Intel VGA ROM im Coreboot hat nicht geholfen, der Reset beim Booten von grml und Xubuntu bleibt. Ich werde mal ein Video aufnehmen, um die letzte Ausschrift vor dem Reset lesen zu koennen.

Hat noch jemand eine andere Idee?

Gruss,
jal2

 

[Exe]

Ich hab mal ein ähnliches verhalten bei nem T430 gehabt.
Probier mal, ob er beim zweiten Mal startet. Dabei aber nicht vom Strom trennen! Hard power off über langes drücken des Power Button und danach wieder einschalten. Dann hat es gebootet. Sobald man Akku oder Netzteil getrennt hatte, ging es immer erst beim zweiten Start nach hard power off

 

[jal2]

Ich hab mal ein ähnliches verhalten bei nem T430 gehabt.
Probier mal, ob er beim zweiten Mal startet. Dabei aber nicht vom Strom trennen! Hard power off über langes drücken des Power Button und danach wieder einschalten. Dann hat es gebootet. Sobald man Akku oder Netzteil getrennt hatte, ging es immer erst beim zweiten Start nach hard power off

Nein, auch beim zweiten Mal gibt es wieder einen Reset beim Starten von grml. Ich habe die Startmeldungen mit deaktiviertem Framebuffer als Video aufgenommen, die letzte Zeile ist immer:

tmp_tis 00:06: 1.2 TPM (device-id 0x0, rev-id 78)

also der TPM Treiber. Wenn das TPM defekt ist, wuerde das auch das Haengen mit dem Original BIOS erklaeren. Dieses braucht das TPM, um den PowerOn Passwort Check beim Start durchzufuehren. Angeblich ist das EEPROM beim T530 immer TCPA locked (wenn ein TPM verbaut ist).
Ich ueberlege, ob ich den TPM Chip entferne. Laut FRU BOM und Schaltplan gibt es T530 Boards ohne TPM. Je nach EEPROM Inhalt kann dann das orginale BIOS nicht mehr genutzt werden, aber Coreboot wuerde mir genuegen.

 

[Exe]

Ich meinte eigentlich mit dem originalen Bios beim starten.
Ich mache keine versuche mit Coreboot auf Boards, die mit dem originalen Bios schon nicht sauber laufen.

 

[jal2]

Ich meinte eigentlich mit dem originalen Bios beim starten.
Ich mache keine versuche mit Coreboot auf Boards, die mit dem originalen Bios schon nicht sauber laufen.

Das hatte ich ganz zu Beginn schon mal mit dem orginalen BIOS probiert, ohne Erfolg.


EDIT:
Das Entfernen des TPM (aka TCPA) Chip hat nicht geholfen, jetzt ist die letzte Zeile, dass Linux nach ISA Geraeten scannt.

EDIT2: "noisapnp" auf der Kernel Commandline hilft nicht. Das Board bleibt beliebig lang an, wenn ich aus den grml Addons Memtest86+ starte.

 

[explit]

Hatte ein ähnliches verhalten auf IvyBridge Devices, wenn Intel-ME Bereich irgendwie beschädigt wurde. Bei mir hat geholfen: Original-Lenovo BIOS (Full Dump) von beiden Chips 8MB + 4MB aus einem anderen Seriengleichen Gerät flashen,
danach meckert er kurz über CSR Mismatch, bootet aber. Einmal ins Setup und Defaults laden. Danach gehts ohne fehler. Danach COreboot nach Anleitung flashen.

 

[jal2]

Hatte ein ähnliches verhalten auf IvyBridge Devices, wenn Intel-ME Bereich irgendwie beschädigt wurde. Bei mir hat geholfen: Original-Lenovo BIOS (Full Dump) von beiden Chips 8MB + 4MB aus einem anderen Seriengleichen Gerät flashen,
danach meckert er kurz über CSR Mismatch, bootet aber. Einmal ins Setup und Defaults laden. Danach gehts ohne fehler. Danach COreboot nach Anleitung flashen.

Danke fuer den Tipp! Leider kann ich zur Zeit das Board nicht mehr testen, weil ich die anderen Teile wieder zusammengebaut und als defektes W530 verkauft habe. Das W530 Board hatte uebrigens den gleichen Fehler. Ich habe den Tipp an den Kaeufer weitergegeben.

Wenn wirklich der Intel ME reinfunkt und den Reset ausloest, muesste dann nicht auch der MECleaner helfen?