Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund

jetzt fehlt nur mehr die möglichkeit die garbage manual anzuwerfen +g*
 
  • Gefällt mir
Reaktionen: Macschrauber
  • Haha
Reaktionen: Istari 3of5, Indio und Elebato
Nach einigen Jahren Mac-Pause bin ich nun auch wieder hier angekommen. Unsere Agentur ist nun fast komplett vom Mac auf Windows umgezogen und die alten Mac Pro gehen an die Angestellten. Ich habe meinen alten 5.1er für mich und einen 4.1er für meinen Vater gesichert und bereite drei weitere Macs für Arbeitskollegen auf.

Da ich mich nach El Capitan gerade wieder auf nen aktuellen Stand bringe, habe ich schon einiges hilfreiches hier gefunden. Meinen 5.1er schon auf Catalina upgedated, der 4.1er für meinen Vater streikt bei Systemen über HS und hat Mojave erst beim 5. Versuch geschluckt, Catalina will bisher gar nicht.

Unsere IT ist eher gegen Macs eingetellt. Ich habe rausgefunden, dass alle Macs per Firmwareupdate von 4.1 auf 5.1 gebracht wurden. Das letzte System Mojave wurde leider per Clonen der Festplatte installiert, da unser ITler auch an den toten Downloadlinks und verfallenen Zertifikaten von Apple scheiterte und es sich einfach machen wollte. Somit hatte keiner der Macs das aktuelle Bootrom für Mojave, einige noch nicht mal das für High Sierra.

High Sierra downzuloaden war schon die erste Hürde für mich, einzig per "AnyOS" konnte ich es tatsächlich finden. Leider bietet dieses Tool Mavericks nicht mehr zum Download an, wenn da jemand noch nen aktuellen Link hätte wäre super, da ich mehrere Pros checken muss.

Gerade habe ich den ersten Mac mit Deinem Tool gecheckt, zum Glück alles in Ordnung. Ich vermute aber, dass der eine oder andere Kandidat dabei sein wird, da einige Macs auch Berührung mit Windows hatten und wir sogar einen Mac in der Firma haben der nur noch Windows starten will. Ich werde demnach am Wochenende alle gründlich checken und Backups machen.

An Dieser Stelle schonmal ein ganz dickes Dankeschön @Macschrauber (y)
 
  • Gefällt mir
Reaktionen: roger.rebel
(csm/legacy/bios) Windows an sich ist ja überhaupt nicht grundlegend böse (was die Firmware betrifft).

Problematisch ist wenn die Classic Mac Pros Uefi Windows ausführen müssen und kein OpenCore / RedindPlus Bootloader das Schlimmste verhindert.

Dort genügt das Booten des Windows USB Installationsstick und wir haben Zertifikate im NVram die wir nicht mehr wegbekommen.

Es sei denn, wir haben ein Backup der Firmware. Wenn man die zurückflasht dann bekommen wir den faux pas wieder weg.

Die Zertifikate an sich sind bei einem 100% gesunden Rom / Nvram gar nicht mal so extrem schädlich. Nur hat niemand bei normaler Benutzung ein gesundes Nvram.

Die Firmware des Mac Pros schreibt nach jedem Boot zusätzliche Informationen ins Nvram, bis der Platz (etwa 64kb) aufgebraucht ist, dann läuft die garbage collection, der wichtigste Inhalt des Nvram wird in einen zweiten Bereich (VSS2) kopiert, der erste Teil (VSS1) wird gelöscht und mit dem Inhalt von VSS2 ersetzt.

Wenn nun VSS1 überläuft dann ist VSS2 nicht mehr funktionsfähig. Wenn's nun ganz blöd läuft dann startet der Mac nicht mehr und das Backplane ist ein Fall für den Schrauber ;-)

Gut wenn man dann wenigstens ein Backup der Firmware hat, dann ist der Aufwand diese zu Rekonstruieren deutlich geringer.
 
  • Gefällt mir
Reaktionen: dg2rbf, Grobi112, Istari 3of5 und 3 andere
…es tut so gut, hier um Forum auch mal richtig gute, von Sachkenntnis geprägte Beiträge zu lesen - danke! 🙏
 
  • Gefällt mir
Reaktionen: dg2rbf, Grobi112, SirVikon und 2 andere
In Macrumors konnte ich einem Kollegen helfen bei dem die AppleDienste (iCloud, Messages, etc etc) nicht mehr funktionierten.

Die Firmware war fragmentiert. Weniger an der Analyse zu sehen wie am Effekt

Code:
Firmware 144.0.0.0 (latest)
18 Memory Configs (ok)
0 xml (ok)
4 Kernel Panic Dumps
2 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
2 BluetoothActiveControllerInfos (ok)
2 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
11 AAPL Path Properties (ok)
Length of 2nd VSS Store is wrong (FF FF FF FF)
18560 Bytes free space of 65472

Nach Rekonstruktion funktionierte es wieder.

-------------------

>Eingangspost:

"Couple days ago i noticed that i stopped receiving messages/text in messages. Cant log in it.
I get activation error. Facetime doesn’t work too. Icloud still works. Im afraid to log out.
Continuity stopped working too."

>nach Flash der gefixten Firmware:

"Even services like continuity and hands off came back. Messages and facetime too."


https://forums.macrumors.com/threads/mojave-opencore-apple-services-stopped-working.2324806/
 
  • Gefällt mir
Reaktionen: Indio, OpencoreMacPro und Elebato
weil es indirekt schon (wegen Windows UEFI) mit dem Firmwarethema und den Zertifikaten zusammenhängt verweise ich auf eine aktuelle Beschreibung wie man Legacy Windows 10 auf den Mac Pro bekommt, auch ohne Bootscreen GPU.

Legacy Windows per Virtualisierung nativ installieren
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf und Macschrauber
Dumpen funktioniert auch super mit SystemRescue Linux USB Stick :)

yep, füge noch nen Link hinzu welches Image du verwendet hast.

Hatten wir schon:

https://www.macuser.de/threads/mac-...scher-hintergrund.844183/page-6#post-11044077 ;-)

Aber man kann es ruhig öfter thematisieren, als Lösung wenns über MacOs nicht klappt oder aufwändig wird.

Allerdings hat man nicht die grundsätzliche Analyse direkt dabei.

Dafür kann man aber das test nvram droplet den Linux Dump anschauen lassen.

Technisch ist es egal wie man den Dump bekommt.

Das Tool was liest ist immer Flashrom, das Klickibunti davor fragt den Flash Typ ab (Dosdude) oder weiss ihn über die Hardware ID und wenn das doch nicht klappt testet es aus (mein Dumper).
 
Ja, als alter Linuxer fand ich das mit dem Linux USB Stick deutlich eleganter als die Recovery + Reboot Orgie. :)
Aber auch eine gute Alternative zum Dumpen wenn man gerade kein lauffähiges System drauf hat.
 
Ich bin ein gar ganz fauler Hund und hab dafür eine Platte mit Mavericks, da hab ich alle Tools und das System drauf das ich für 3.1 bis 5.1 einsetzen kann.

Da gab's noch kein SIP.

Jaja, früher™ war alles besser :Oldno:


nein, im Ernst, manchmal hat man bei einem Rechner mit zerfledderter Firmware nur einen Versuch den zu starten und dann nehm ich ein System was auf Anhieb dumpen kann.

Aufgrund meinen Erfahrungen bekomme ich öfter solche Fälle auf den Tisch.
 
Zuletzt bearbeitet:
Hmm, also bei mir müsste jetzt ja mit dem nächsten Neustart die GC laufen ... wenn nicht, dann wars das? Oder soll ich die GC lieber von Hand anstossen?

Bildschirmfoto 2021-12-16 um 00.08.46.png
 
Zuletzt bearbeitet:
Afair hast Du ein sauberes Rom von mir bekommen. Die Anzahl der Variablen sind völlig ok. Also keine Sorge, das passiert so ca. alle 12 mal booten, je nach Anzahl der Ram slots. Ein Dual mit vielen Riegeln wird schneller voll.

Zur Erinnerung hier nochmal ein vollständiger Lauf von Garbage Collection zur nächsten Garbage Collection: https://www.macuser.de/threads/mac-...cher-hintergrund.844183/page-12#post-11268261

Wer viel mit Bootloadern und Systemen experimentiert könnte idealerweise so alle 3 Monate ein bereinigtes (oder ein 1, 2 mal gebootetes mit OpenCore Blessing) Flashen um wieder bei Null anzufangen.
 
  • Gefällt mir
Reaktionen: SirVikon
@Macschrauber
habe mal dein neues Tool genommen und da wird mir folgendes angezeigt:

Bildschirmfoto 2021-12-16 um 00.52.52.png

Aber ich kann da jetzt einfach einen Neustart machen und dann wird die GC automatisch gemacht?
 
Ja, halte aber mal die AAPL Path Properties im Auge, ob die durch ein Update so hoch gelaufen sind.

Das sind Verweise für Devices im PCI Baum (was eigentlich irgendwie alles ist was an der Kiste hängt). Wenn viele USB Devices und Hubs an dem Rechner sind kann das normal sein.

Da fehlt mir noch ein wenig das Gefühl für diese Variable, die Bewertung ob ok kann sich also noch ändern.
 
  • Gefällt mir
Reaktionen: SirVikon
Es gibt immer wieder Unklarheiten über die zwei Streams, wann der zweite leer ist.
Da ich das gerade getextet hab nochmal hier zusammengefasst:

Warum ist der zweite Stream leer und warum warnt der Dumper davor?

Das ist normal, wenn:

- Gerade eine Garbage Collection (GC) manuell angestoßen wurde (4fach nvram reset am Stück).
- Eine neu aufgebaute bzw reparierte Firmware geflasht wurde.


im ersten Fall wurde der zweite Stream von der Firmware geleert. Das ist gut, denn das zeigt dass die GC funktioniert.

im zweiten Fall füllt sich der erste Stream bei jedem Booten um etwa 4000 Bytes. Bis er bei etwa 64000 Bytes voll ist und dann wird die GC von der Firmware ausgelöst.

Das nvram besteht aus zwei Streams, VSS1 und VSS2. VSS1 ist das Nvram, VSS2 ist sowas wie ein Backup eines Parametersatzes was nur von der Firmware benutzt wird.


Also kurz zusammengefasst: VSS2 leer ist ok nach 4fach nvram reset und flashen einer neu aufgebauten Firmware.

---

sollte der zweite Stream leer sein ohne dass eine GC manuell ausgelöst wurde oder die Firmware erneuert wurde könnte etwas faul sein.



Links:

https://forums.macrumors.com/thread...s.2289056/page-21?post=29845724#post-29845724
https://www.macuser.de/threads/mac-...cher-hintergrund.844183/page-12#post-11268261
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Elebato und Indio
Hallo die Runde und vorab vielen Dank der technischen Dokumentation hier im Board!

Beim Auslesen der Firmware meines cMP 5.1 (Mid 2012) mit dem beschrieben Tool 'test_nvram.dmg' bin ich auf einen Widerspruch gestoßen. Das ROM Dump Backup speichert im Dateinamen, wie gesagt Seriennummer, Datum und Chipnummer. Verglichen mit der Bezeichnung auf dem Chip – siehe Anhang, gibt es hierbei jedoch keine Übereinstimmung. Im Dateinamen der Bin-Datei ist die 'MX25L3206E' angegeben, was beim Flashen eines ROM Backups ja verbindlich ist.

Das hält mich natürlich zunächst davon ab, es durchzuführen, weshalb ich mich hiermit sicherheitshalber noch einmal öffentlich an den Autor 'Macschrauber' wende mit der Frage: Ist der Dateiname des NVRAM-Tools verbindlich?

Zugegeben, die Nummer auf dem Chip schaut strange aus, dennoch im Zweifelsfall eher der Variante mit der Endung '…3205D' zuzuordnen.

Hintergrund für den Reflash der Firmware sind zwei Microsoft-Zertifikate, die mir persönlich etwas Sorge bereiten. Carbage Collection hatte ich manuell angestoßen, sprich also Speicherplatz freigegeben, weshalb theoretisch nix passieren sollte… Oder hab ich da vielleicht was übersehen?

Für jedwede Rückmeldung wäre ich mehr als dankbar.
 

Anhänge

  • MX25L3205D.JPG
    MX25L3205D.JPG
    120,7 KB · Aufrufe: 69
Hallo die Runde und vorab vielen Dank der technischen Dokumentation hier im Board!

Beim Auslesen der Firmware meines cMP 5.1 (Mid 2012) mit dem beschrieben Tool 'test_nvram.dmg' bin ich auf einen Widerspruch gestoßen. Das ROM Dump Backup speichert im Dateinamen, wie gesagt Seriennummer, Datum und Chipnummer. Verglichen mit der Bezeichnung auf dem Chip – siehe Anhang, gibt es hierbei jedoch keine Übereinstimmung. Im Dateinamen der Bin-Datei ist die 'MX25L3206E' angegeben, was beim Flashen eines ROM Backups ja verbindlich ist.

Das hält mich natürlich zunächst davon ab, es durchzuführen, weshalb ich mich hiermit sicherheitshalber noch einmal öffentlich an den Autor 'Macschrauber' wende mit der Frage: Ist der Dateiname des NVRAM-Tools verbindlich?

Zugegeben, die Nummer auf dem Chip schaut strange aus, dennoch im Zweifelsfall eher der Variante mit der Endung '…3205D' zuzuordnen.

Hintergrund für den Reflash der Firmware sind zwei Microsoft-Zertifikate, die mir persönlich etwas Sorge bereiten. Carbage Collection hatte ich manuell angestoßen, sprich also Speicherplatz freigegeben, weshalb theoretisch nix passieren sollte… Oder hab ich da vielleicht was übersehen?

Für jedwede Rückmeldung wäre ich mehr als dankbar.


Man weiß aus Erfahrung / Beobachtung welche Flash ICs in welchem Modell meistens stecken. Deshalb versucht der Dumper mit Hilfe von FlashRom unter Angabe des vermuteten Chips zu lesen.

Wenn das klappt dann ist es für den Dumper der Chip der klappt. Es gibt meines Wissens nach keine Möglichkeit den Chiptype anderweitig auszulesen.

Code:
if Mac_Pro is in "Mac Pro 2012" then -- Mac Pro 5,1 2012
	if found_chip of do_flashrom_read("MX25L3206E", flashrom, serial, boot_rom_version) is false then
		if found_chip of do_flashrom_read("MX25L3205D", flashrom, serial, boot_rom_version) is false then
			if found_chip of do_flashrom_read("SST25VF032B", flashrom, serial, boot_rom_version) is false then
				display alert "neither MX25L3206E nor MX25L3205D nor SST25VF032B for MP5,1 2012"
			end if
		end if
	end if
end if

hier ein wenig Code der fast selbsterklärend ist. do_flashrom_read ist eine weitere Routine die false zurückgibt wenn ein Fehler von FlashRom zurück kam.

Der SST25VF032B wird kaum mal in einem 2012er stecken, das ist der vom 2009er, aber er kann ja mal gewechselt worden sein. Dem Board ist egal was drin ist solange es eine kompatible Version ist.

Beim Lesen ist es auch unerheblich, das Ergebnis stimmt oder ist völlig falsch.


Wie dem logfile zu entnehmen ist (was ich inzwischen bekommen habe) gibt Flashrom die E Type zurück wenn per MX25L3206E ein probing gemacht wird:

Code:
SPI Read Configuration: prefetching disabled, caching enabled, OK.
The following protocols are supported: FWH, SPI.
Probing for Macronix MX25L3206E, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2016
Found Macronix flash chip "MX25L3206E" (4096 kB, SPI) at physical address 0xffc00000.

Beim Flashen funktioniert das auch mit der MXL3206E Type beim MXL3205D. Beim nächsten 2012er den ich vor mir habe schaue ich aber mal genauer hin.

Wenn man manuell im Dateinamen den Typ auf MX25L3205D ändert flasht der Dumper zuerst mit der im Dateinamen gefundenen Type.

Danach geht er nach der Baureihe (2009, 2010, 2012)

-------


Viel wichtiger ist dass die Zertifikate aus der Firmware wieder verschwinden und auch nicht wiederkommen.

Wenn die GC jetzt noch funktioniert ist der Rest des Nvrams wohl nicht allzu schlimm durcheinander. Ob das so bleibt kann niemand wissen.

Ob bei der nächsten GC 4000 oder 20 Bytes frei sind macht auch einen Unterschied, das ist ein wenig russisches Roulette.



Wird aktuell UEFI Windows ohne Schutz des Nvrams genutzt?
 
Zuletzt bearbeitet:
Es gibt meines Wissens nach keine Möglichkeit den Chiptype anderweitig auszulesen.
Hmmm, den kann man doch vom Chip ablesen. Und bei Dosdude’s Dumper wählt man den dann halt einfach aus einem Pulldown aus. Leuchtet mir vom Prinzip her, ehrlich gesagt, mehr ein.
 
Zugegeben, die Nummer auf dem Chip schaut strange aus, dennoch im Zweifelsfall eher der Variante mit der Endung '…3205D' zuzuordnen.
Sieht für mich sehr klar nach einem 3205D aus. Ist übrigens auch der, der bei meinen beiden Mid 2010 5,1ern drin ist.
 
  • Gefällt mir
Reaktionen: Riqpat
Zurück
Oben Unten