Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund

Schönen Sonntag erst ein mal in die Runde........
Ich hatte für 4 Wochen nen M1 Mini hier, hab den jetzt allerdings wieder weggegeben. Wollte mich dann doch mal mit OpenCore hier aufm MP beschäftigen.
Erst mal vielen Dank an Macschrauber für die tolle Software.
Bräuchte allerdings mal ein wenig Hilfe bei der Säuberung 😊......
Bildschirmfoto 2022-03-06 um 15.19.14.png

Liebe Grüße
 
So ich hab diese Woche doch noch mal ein Stündchen Zeit gefunden, um mich mit dem Rechner zu beschäftigen....

Hab mit meinem gefährlichen Halbwissen den NVRam reset durchgeführt und anschließend nach 4-fachem Gong die Garbage Collection durchlaufen lassen.
Hier an dieser Stelle für das ein großes Dankeschön an dieses Forum und alle Beteiligten. Bin hier seit knapp 2 Jahren angemeldet, als ich mir nen gebrauchten 4.1 geholt habe, und habe seitdem ne Menge hilfreichen Input hier bekommen (quasi als stiller Mitleser).

Würde auf meinem Rechner gern OC installieren und würde dazu natürlich gern wie von @Macschrauber hier in diesem Thread betont gern ein sauberes Rom benutzen.
Nach dem NVRam Reset und der GC sieht's jetzt folgendermaßen aus.....
Kann ich da loslegen oder sind die knapp 26KB doch zu wenig?

Hab keine Ahnung, wie ich da evtl. defragmentieren soll...
 
Zuletzt bearbeitet:
Die freien 26k werden sich bei jedem Neustart, je nach Speicherausbau und Konfiguration um ca. 4k verringern bis die Garbage Collection eingreift und wieder aufräumt.

Wenn _nach_ einer GC, manuell oder automatisch, wenig freier Platz da ist dann ist das richtig schlecht.


Auf den erst Blick ist das so in Ordnung, da es aber mal ein 4.1 war empfiehlt sich die Firmware neu zu machen.

Vor Allem wegen dem Hybrid Bootlader.

Hast ne Unterhaltung.
 
Zuletzt bearbeitet:
Moin @Macschrauber

Geht dein Tool nicht mit 12.3?

Ich bekomme beim starten immer diese Fehlermeldung:

Bildschirmfoto 2022-03-16 um 12.35.16.png
 
muss ich mir am Wochenende anschauen, so schnell bin ich nicht bei unsupporteten Systemen ;-)
 
  • Gefällt mir
Reaktionen: SirVikon
Alles gut, wollte nur mal aufgrund der Berichte mit Monterey nachsehen, was mein NVRAM so macht. War vor einigen Wochen aber noch okay ;)
 
Man sollte immer ein supportetes System griffbereit haben wenn man ein unsupportetes laufen hat, schon allein aus Wartungs- und Reparaturgründen. Der Dumper / Analyser funktioniert ab 10.8

Wegen 12.3 muss ich mal schauen, hab erst einige Optimierungen im Shell Script gemacht die Python Befehle benutzen.
 
Screen Sharing Picture 17. March 2022 at 18.48.48 CET.png


Python benötige ich für die Abfrage der Starttasten des Dumpers (Alt-Taste für Freigabe des Flashens, Shift-Taste für anonymisieren der Seriennummer).

Hab schon gehirnt wo im Shell Script denn Python drin ist. Perl und awk ist drin, aber das gibt's noch unter 12.3.

Hab noch andere Erweiterungen. Wie das Auslesen des Bootblocks um einen Neuaufbau sowie einen Crossflash 4.1->5.1 zu erkennen.

Bis ich eine Lösung für die Abfrage der Shift- und Alt- Taste per AppleScript ohne Python für 12.3 und höher habe gibt's die Vorabversion per PM wenn jemand unbedingt unter 12.3 dumpen möchte.
 
  • Gefällt mir
Reaktionen: Indio
es ist vollbracht.

Neue Version vom Dumper mit ohne Python für 12.3

leider wurde es notwendig für ältere Systeme (Mavericks ist getestet) eine weitere Programmversion mit ins Paket zu nehmen. Funktional keinerlei Unterschied.

Neu (außer der Anpassung für 12.3) ist unter Anderem das Auslesen der Bootloader Version und das Anzeigen eines Crossflashs 4.1->5.1

Dadurch lässt sich einfach ermitteln ob das Rom einen (uralten) originalen Bootlader hat oder den aktuellen der mit 144.0.0.0 kam.

Diesen Aktuellen gibt's nur durch Neuaufbau des Roms. Warum auch immer Apple das nicht aktualisiert beim regulären Firmware Update.


Soll die Seriennummer nur gekürzt angezeigt werden ist die Shift-Taste beim Starten des Dumpers zu drücken.



ein paar Beispiele:

5.1 normal.png

(138er Firmware mit historischem Bootblock)


crossflash.png

(144er Firmware eines 4.1 mit historischem Zwitter Bootblock)



5.1 rebuilt.png

(144er Firmware mit aktuellem Bootblock durch Neuaufbau der Firmware)




Der Link bleibt wie er war:


https://www.dropbox.com/s/jh4unzd7gd4n5me/Macschrauber%27s%20CMP%20Rom%20Dump.dmg?dl=0
 
  • Gefällt mir
Reaktionen: TomToe007, SirVikon, Indio und eine weitere Person
Vielen Dank (mal wieder) für Deine Mühe! (y)

(y)(y)
 
Das Bootrom meines Single scheint auch nach dem Update auf 12.3 noch absolut okay zu sein und hat nur zwei Cras-Dumps drin. Dennoch mache ich mir, obwohl ich mit dem Rechner nicht so viel mache, da, nachdem, was da auf MR zu lesen war, jetzt ein bißchen Sorgen für die Zukunft.

Deshalb mal eine generelle Frage:

tsialex drüben bei MR empfiehlt ja, in Intervallen von ca. einem Vierteljahr mal eine saubere, neu aufgebaute Firmware aufzuspielen. Wo genau ist denn da jetzt der funktionale Vorteil gegenüber einem deep NVRAM Reset (vorausgesetzt natürlich, vorher ist alles noch in Ordnung!) oder dem Aufspielen eines Dumps „aus guten Zeiten“ im gleichen Intervall?

Wenn das Problem hauptsächlich ist, dass jetzt, seit 12.3, Crash-Dumps in den NVRAM geschrieben werden, sollte doch, wenn ich eine Sicherung des aktuellen Zustands (mit lediglich zwei Crash-Dumps) aufspiele, auch alles praktisch wieder „wie neu“ sein, oder?
 
eine Garbage Collection schmeisst nur die zusätzlichen Kopien der Settings raus, siehe den Lauf den ich hier gepostet hab von leer bis voll. Settings die die Firmware nicht kennt belässt es drin. Wäre auch seltsam wenn nach 8-16 mal Neustart Settings weg wären.

Das sind entweder historische Settings wie die MobileMe tokens, verunglückte Settings oder von anderen Tools die was reinschreiben wie der Nvidia WebDriver oder Uefi Windows seine Zertifikate. Die bleiben. Wenn dann durcheinander ist (Alex nennt das Fragmention) dann sind vielleicht auch alte Settings die normal gelöscht werden trotzdem drin.

Deshalb der Tipp: Garbage Collection manuell anstoßen und schauen was nach ein mal Booten noch an Speicher frei ist. Sollte das zu wenig sein ist Alarm.

...

eine neu aufgebaute Firmware hat zwei völlig leere nvram Streams VSS1 und VSS2.

Der zweite Stream ist eine Kopie des ersten falls während der Garbage Collection was abstürzt oder der Strom ausfällt damit noch eine Sicherung da ist. Der Zweite enthält auch nur einmal den relevanten Datensatz. Der erste füllt sich bei jedem Neustart mit zum Beispiel den Daten der Speichersticks. Bis voll, dann kommt die automatische GC - oder nicht, dann haben wir den Brick :-/

Bei einer manuell angestoßenen GC wird der erste Stream gelöscht, der zweite auf den ersten kopiert und dann der zweite gelöscht.

Deshalb nenne ich auch einen Firmware rebuilt einen nvram reset deluxe. Vollkommen leer, nix, null, nada. Danach muss halt wieder neu geblesst werden etc. Die meisten Settings spielt das System dann in den ersten Stream, der zweite bleibt leer.

Das hat den Vorteil nur aktuelle Settings drin zu haben, Karteileichen werden entfernt - und erst recht irgend welcher Müll der sich darin tummelt.
 
  • Gefällt mir
Reaktionen: SirVikon und flyproductions
Die meisten Settings spielt das System dann in den ersten Stream, der zweite bleibt leer.
Ah, danke für die ausführliche Erklärung!

Denn gehe ich mal davon aus, dass ein jetzt gezogener Dump vielleicht nicht ganz so perfekt ist wie ein neu aufgebautes Bootrom, aber doch okay. Windows war auf der Kiste bisher jedenfalls ebensowenig wie ein NV-Webdriver. Und freier Speicher ist auch noch genug da.
 
eine gute Blaupause wäre eine manuell angestoßene GC, danach das System oder den ESP blessen (je nachdem ob man OpenCore, Refind(Plus) oder das native System bis Mojave laufen hat. Dann den Dump ziehen, am allerbesten mit einem alten System wie Mavericks und manuell per Bootpicker ausgewählt.

Dann müsste man nach neu Flashen nichts mehr einstellen, vor allem bei OpenCore und GPUs ohne Bootscreen ein großer Vorteil.

Meine wichtigste Diagnose und Programmierplatte läuft unter Mavericks, weil es da noch kein Rootless gab.
 
Aus aktuellem Anlass (Möglicher Kernel Panic beim 12.3 OTA Update) habe ich den Dumper um das Erkennen der vollständigen und komprimierten Kernel Panics erweitert.

Es gibt zwei, einer zeigt auf eine gespeicherte Datei (Type A),
der Andere (Type B) enthält den vollständigen, komprimierten Kernel Panic Log in mehreren Teilen.

Wenn Type B passiert während das nvram ziemlich voll ist dann könnte das zum Brick führen. Ist wohl wohl beim 12.3 OTA Update schon vorgekommen wenn dabei ein Kernel Panic passiert. Diese sind beim Mac Pro 7.1 spoofing so groß dass das nvram überlaufen _könnte_.

Das Thema ist leider noch zu neu dass man da ganz genaues sagen kann, aber die Warnung ist nicht verkehrt.



Besser eine möglichst leere Firmware vorher flashen oder die manuelle Garbage Collection ausführen (und dummerweise OpenCore neu blessen).



Der link ist der alte

Real Kernel Panic a & b.png

(Das ist ein alter Dump, diese Type B Kernel Panics gibt es schon lange)




und immer wieder bestätigt sich es: OpenCore nie ohne Firmware Backup!
 
  • Gefällt mir
Reaktionen: SirVikon und Indio
Hallo MacSchrauber,

War in der Vergangenheit schon fleißig am mitlesen hier und bei MR und hab dann nach dem Update auf MacOs 12.3 (OC ist aktiv) entschlossen mich um mein Bootrom zu „kümmern“!

Besitze einen MacPro DualProz mit einem Crossflashs 4.1->5.1.
Hab auch schon einen Dump mithilfe von deinem Tool gemacht.

Finde es toll wieviel Mühe du in die Sache gesteckt hast und dein Wissen Leuten wie mir zur Verfügung stellst und deine Hilfe anbietest. Vielen Dank erstmal dafür!

Nachdem ich eine GC manuell angestoßen habe, waren zuerst ca 30000 Bytes frei, nach 2 mal Booten hab ich jetzt noch 11200 frei.
serial from firmware: 3T92
Firmware 144.0.0.0 (latest)
Crossflash 4.1->5.1
18 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
1 BluetoothActiveControllerInfos (ok)
1 BluetoothInternalControllerInfos (ok)
2 current-network (not ok)
12 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
11200 Bytes free space of 65472

flashrom v0.9.7-r1711 on Darwin 21.4.0 (x86_64)
flashrom was built with libpci 3.2.0, LLVM Clang 4.2 (clang-425.0.28), little endian
Command line (8 args): /Users/tom/Desktop/Mac Tools/MacSchrauber/RomDump Macschrauber.app/Contents/Resources/flashrom097r1711 -p internal -c SST25VF032B -r /Users/tom/downloads/3T9xxxxxB9MD_9999.0.0.0.0_SST25VF032B_20.03.2022_18-21-48.bin -o /Users/tom/downloads/3T9xxxxxB9MD_SST25VF032B_20.03.2022_18-21-48.log
Calibrating delay loop... OS timer resolution is 1 usecs, 490M loops per second, 10 myus = 10 us, 100 myus = 94 us, 1000 myus = 1017 us, 10000 myus = 10061 us, 4 myus = 3 us, OK.
Initializing internal programmer
Mapping low megabyte at 0x0000000000000400, unaligned size 0xffc00.
Mapping low megabyte, 0xffc00 bytes at unaligned 0x0000000000000400.
No coreboot table found.
dmidecode execution unsuccessful - continuing without DMI info
Found chipset "Intel ICH10" with PCI ID 8086:3a18. Enabling flash write...
0xfff80000/0xffb80000 FWH IDSEL: 0x0
0xfff00000/0xffb00000 FWH IDSEL: 0x0
0xffe80000/0xffa80000 FWH IDSEL: 0x0
0xffe00000/0xffa00000 FWH IDSEL: 0x0
0xffd80000/0xff980000 FWH IDSEL: 0x0
0xffd00000/0xff900000 FWH IDSEL: 0x0
0xffc80000/0xff880000 FWH IDSEL: 0x0
0xffc00000/0xff800000 FWH IDSEL: 0x0
0xff700000/0xff300000 FWH IDSEL: 0x4
0xff600000/0xff200000 FWH IDSEL: 0x5
0xff500000/0xff100000 FWH IDSEL: 0x6
0xff400000/0xff000000 FWH IDSEL: 0x7
0xfff80000/0xffb80000 FWH decode enabled
0xfff00000/0xffb00000 FWH decode enabled
0xffe80000/0xffa80000 FWH decode enabled
0xffe00000/0xffa00000 FWH decode enabled
0xffd80000/0xff980000 FWH decode enabled
0xffd00000/0xff900000 FWH decode enabled
0xffc80000/0xff880000 FWH decode enabled
0xffc00000/0xff800000 FWH decode enabled
0xff700000/0xff300000 FWH decode disabled
0xff600000/0xff200000 FWH decode disabled
0xff500000/0xff100000 FWH decode disabled
0xff400000/0xff000000 FWH decode disabled
Maximum FWH chip size: 0x400000 bytes
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xd60461: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x1 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xa008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=0, FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES... done
OP Type Pre-OP
op[0]: 0x9f, read w/o addr, none
op[1]: 0xab, read w/ addr, none
op[2]: 0x01, write w/o addr, none
op[3]: 0x02, write w/ addr, none
op[4]: 0x03, read w/ addr, none
op[5]: 0xd8, write w/ addr, none
op[6]: 0x05, read w/o addr, none
op[7]: 0x20, write w/ addr, none
Pre-OP 0: 0x06, Pre-OP 1: 0x50
0x08: 0x00000000 (FADDR)
0x74: 0x811f0000 PR0: Warning: 0x00000000-0x0011ffff is read-only.
0x78: 0x9fff0150 PR1: Warning: 0x00150000-0x01ffffff is read-only.
0x7C: 0x00000000 (PR2 is unused)
0x80: 0x00000000 (PR3 is unused)
0x84: 0x00000000 (PR4 is unused)
Writes have been disabled for safety reasons. You can enforce write
support with the ich_spi_force programmer option, but you will most likely
harm your hardware! If you force flashrom you will get no support if
something breaks. On a few mainboards it is possible to enable write
access by setting a jumper (see its documentation or the board itself).
0x90: 0x04 (SSFS)
SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
0x91: 0x014060 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=6, DBC=0, SME=0, SCF=1
0x94: 0x5006 (PREOP)
0x96: 0xced8 (OPTYPE)
0x98: 0x0201ab9f (OPMENU)
0x9C: 0x2005d803 (OPMENU+4)
0xA0: 0x00000000 (BBAR)

SPI Read Configuration: prefetching disabled, caching enabled, OK.
The following protocols are supported: FWH, SPI.
Probing for SST SST25VF032B, 4096 kB: probe_spi_rdid_generic: id1 0xbf, id2 0x254a
Found SST flash chip "SST25VF032B" (4096 kB, SPI) at physical address 0xffc00000.
Chip status register is 0x1c.
Chip status register: Block Protect Write Disable (BPL) is not set
Chip status register: Auto Address Increment Programming (AAI) is not set
Chip status register: Block Protect 3 (BP3) is not set
Chip status register: Block Protect 2 (BP2) is set
Chip status register: Block Protect 1 (BP1) is set
Chip status register: Block Protect 0 (BP0) is set
Chip status register: Write Enable Latch (WEL) is not set
Chip status register: Write In Progress (WIP/BUSY) is not set
Some block protection in effect, disabling... disabled.
Reading flash... done.
Restoring MMIO space at 0x10e8be8a0
Restoring PCI config space for 00:1f:0 reg 0xdc





Kannst du mir evtl ein leeres Bootrom mit aktuellem Bootloader zur verfügung stellen, das ich dann flashen kann?
 
Hallo MacSchrauber,

Kannst du mir evtl ein leeres Bootrom mit aktuellem Bootloader zur verfügung stellen, das ich dann flashen kann?

Ein leeres Bootrom wäre das mp51.fd aus dem letzten Mojave Installer.

Dann hättest Du aber eine Firmware ohne Identität, die Seriennummer würde fehlen, alle IDs (zum Beispiel die Seriennummer des Logic Boards würden fehlen).

Apple könnte den Mac nicht mehr deiner Apple ID zuordnen.

Was Du benötigst ist eine Firmware mit den IDs deines Rechners, dazu brauche ich einen Dump von Dir.

hast eine PN
 
Nachdem ich eine GC manuell angestoßen habe, waren zuerst ca 30000 Bytes frei, nach 2 mal Booten hab ich jetzt noch 11200 frei.
serial from firmware: 3T92
Firmware 144.0.0.0 (latest)
Crossflash 4.1->5.1
18 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
1 BluetoothActiveControllerInfos (ok)
1 BluetoothInternalControllerInfos (ok)
2 current-network (not ok)
12 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
11200 Bytes free space of 65472


Die sehr grobe Mathematik für den Free Space wäre (aber wirklich nur grob):
65472-(18 Memory Configs a´ 2300) = 24072 Bytes Free Space

Auch wenn das extrem überschlagen ist dann fehlt da Einiges.

Kann man hier so rechnen weil der zweite Stream leer ist. Es wird ja nur der erste Stream benutzt.


...im Übrigen bin ich gerade dabei das Test Script zu ändern, so dass es die beiden Streams getrennt darstellt (x + y Memory Configs, etc)

Die Bewertungen ok / caution / very bad, usw. berücksichtigen im Script die beiden Streams.

Ich hab mich eine Weile dagegen gewehrt, weil es doch eine massive Änderung ist, aber technisch wichtig ist der erste Stream.

Es sei denn der Zweite wird überschrieben, aber das würde dann in den Ergebnissen auch auftauchen.

Wird aber noch ne Weile dauern bis das offiziell einfließt.
 
  • Gefällt mir
Reaktionen: TomToe007
Gibt es noch die Möglichkeit falls das BootRom defekt sein sollte, es zu tauschen bzw ein neues BootRom mit einer Matt Card zu installieren?
 
Zurück
Oben Unten