Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund

Kleine Änderung vom Dumper:

Es kommt immer wieder vor dass die Leute einen Screenshot des TestDialogs vom Dumper mit ihrer Seriennummer posten.

Diese wird jetzt gekürzt dargestellt. Im Dateinamen und im Log File bleibt sie komplett.

In den anderen Funktionen (test a rom dump file, Analyse vor dem Flashen - oder im test_nvram droplet) ist jetzt ein Hinweis dabei dass man die Seriennummer privat halten soll.

Link ist der Alte.
 
  • Gefällt mir
Reaktionen: Indio und Grobi112
Halli Hallo,

bin dann auch mal hier auf den Thread gestoßen nachdem ich meine alte Käsereibe die Tage auf Monterey gebracht habe.
Ist wieder DIE Geschichte... "gebrauchter 4,1er - Netkas Firmware Flash auf 5,1."
Meint Ihr das sieht gut aus? Hatte mich mit dem ROM/NVRAM eigentlich nie so wirklich beschäftigt.
Aber wenn man dann hier die ganzen interessanten und vor allem tiefgehenden Posts vom Macschrauber liest.....

Ein dump von heute morgen - 2 Neustarts und 6 Stunden später der nächste. 20-2 zu 24-2 Memory Configs. o_O

Grüße K
 

Anhänge

  • kwodo_cmp4,1_romdump_001.png
    kwodo_cmp4,1_romdump_001.png
    445,9 KB · Aufrufe: 132
  • Gefällt mir
Reaktionen: MacNoobDerZweite
Das nach einem Neustart Memory Configs dazu kommen ist normal. Fast 8 KByte ist mir dann aber doch etwas viel.

Das ist ein Gefühl, die Dumps müsste man eingehender untersuchen.

Aber ein Netkas 4.1 mit Monterey schreit nahezu nach einer Frischzellenkur des Nvrams und vor allem nach einem „echten“ Bootlader vom 5.1

Hast ne Unterhaltung.
 
Neue Version vom Dumper.

Die Analyse ist dank Syncretic's Scanvss Tool um einiges intensiver.

Ich stehe im engen Austausch mit dem Autor von dem Tool, so profitiert der Dumper sehr davon.

Über 100 Variablen werden geprüft. Es gibt jetzt eine Unterscheidung Aktiv / Passiv.

Die MemoryConfigs werden jetzt nach den 4 Typen unterschieden. Sollten sich hier Unregelmäßigkeiten ergeben könnten das Kontaktprobleme an den Moduln oder Sockeln sein. Oder natürlich ein Defekt.

Durch die höhere mögliche Anzahl der Variablen werden außer den Windows Zertifikaten nur Variablen angezeigt die mindestens einen Eintrag haben.

Alle anderen Variablen mit einem Vorkommen größer als 4 werden gelistet. Das muss nicht unbedingt schlimm sein. Da muss man noch Erfahrungen sammeln.

In den Logfiles ist jetzt ein vollständiger Lauf von Scanvss. Da dort persönliche Dinge drin stehen wie die SSIDs der Wlans ist das nichts für die Öffentlichkeit.



Das ist ein extrem zerfleddertes nvram volume:
Screenshot 2022-04-24 at 18.45.42.png



Log von Syncretic's Scanvss:
Screenshot 2022-04-25 at 01.03.40.png



Der Link ist der Alte:

https://www.dropbox.com/s/jh4unzd7gd4n5me/Macschrauber%27s%20CMP%20Rom%20Dump.dmg?dl=0
 
  • Gefällt mir
Reaktionen: TomToe007, MacFangio, Proinnsias und 4 andere
geil was aus deinem kleinen tool inzwischen geworden ist!

gratulation und VIELEN DANK
 
  • Gefällt mir
Reaktionen: MacNoobDerZweite
großen Anteil hat Syncretic von Macrumors durch sein Scanvss Tool. Ich hatte nur die Heidenarbeit hunderte von Logs in Variablennamen und Abfragen zu parsen.

Nochmal großen Dank an dieser Stelle an Syncretic :)
 
  • Gefällt mir
Reaktionen: MacFangio, DL8LAQ, Elebato und 3 andere
kleines Update...

da ich mich viel mehr mit Skripten, Forschung und dem Kampf mit den Drachen der Shell-Skript-Syntax beschäftigte, hatte ich eine Menge englische Rechtschreib- und Grammatikfehler und einige Tippfehler in dem Scripten.

Ich habe Einige davon korrigiert.

Da mein Englisch eher pragmatisch ist sind bestimmt noch etliche Fehler enthalten.

Danke @Dayo für die unendliche Geduld, mir beim Verfassen von korrekten englischen Dialogen zu helfen :)

Neben den Textkorrekturen gibt es auch einige Korrekturen im test_nvram Shell-Skript.

Der Link ist der Selbe.
 
  • Gefällt mir
Reaktionen: MacFangio, Elebato, j43zt12 und 2 andere
Neuzugang, Rebuild von 0089 auf 144. Schick (y)
 

Anhänge

  • 144 Dump Dual 5,1.png
    144 Dump Dual 5,1.png
    175 KB · Aufrufe: 157
Wenn das dann noch geblesst hast für OpenCore dann ist das ne schöne Blaupause für eine regelmäßigen Firmware - Auffrischung.

Geblesst musst dann auch nichts extra tun, einspielen und fertig.
 
Wenn das dann noch geblesst hast für OpenCore dann ist das ne schöne Blaupause für eine regelmäßigen Firmware - Auffrischung.
...wobei ich nicht so recht weiß, wie das zu seinen „assumed boots since garbadge collection“ kommt.

Da die 1080 keinen Deepsleep macht, muss ich meinen Rechner jeden Tag richtig neu starten. Ich weiß gar nicht, wann ich meinen letzten „Deep Reset“ gemacht habe. Aber mein aktueller Firmware-Dump meint „7 Boots“ seit dem. In Wirlichkeit, würde ich vermuten, waren es mindestens 70.
 
Die Garbage Collection wird ausgeführt wenn der freie Platz weniger als 2048 Bytes sind.

Nach jedem Boot zwackt sich das nvram so etwa 5k ab.

So wird, je nach Menge und Größe der aktiven Variablen so alle 10 plus mal starten eine Garbage Collection durchgeführt.

Die reguläre GC ist nicht zu verwechseln mit der Manuellen (durch mehrfach NVRAM-Reset oder durch setzen der NVRAM Variable: ResetNVRam=1).

Die Reguläre löscht nichts, sie räumt nur die inaktiven Variablen weg, macht eine Kopie der Aktiven in VSS2, löscht VSS1 und kopiert VSS2 in VSS1 zurück.

Bei einer Manuellen werden alle aktiven und inaktiven Variablen gelöscht und keine Kopie in VSS2 gemacht, deshalb auch die Meldung des Tools VSS2 empty after Firmware rebuilt or triple nvram reset). Triple nvram reset ist die Manuelle Garbage Collection.

Der Text dafür wurde inzwischen angepasst nachdem mit ResetNVRam=1 eine weitere Methode gefunden wurde um die manuelle GC anzustoßen.

Wie bei einer SSD ist eine Garbage Collection nicht destruktiv, die räumt nur auf. Im Gegensatz zur Manuellen, die löscht alle bekannten * Variablen.


* unbekannte Variablen sind zum Beispiel Microsoft Zertifikate, uralt Variablen von Vorgängersystemen wie denen vom 4.1 bei 4.1->5.1 Crossflashs oder irgendwelche verunglückten Fragmente die durch Abstürze, harte Resets, Bugs etc etc entstanden sind.

Und genau die sind es die uns das NVRAM verhageln können, mit Pech so weit dass die reguläre GC nicht mehr läuft weil der VSS1 so groß geworden ist dass er VSS2 überschreibt und so die GC nicht mehr korrekt läuft. *



in diesem Lauf nach dem 12. mal:

Code:
1. Dump after manual Garbage Collection:

6 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
0 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
52864 Bytes free space of 65472


2. Dump after manual Garbage Collection

8 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
2 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
47488 Bytes free space of 65472


3. Dump after manual Garbage Collection:

10 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
3 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
42816 Bytes free space of 65472


4. Dump after manual Garbage Collection:

12 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
4 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
38144 Bytes free space of 65472


5. Dump after manual Garbage Collection:

14 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
5 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
33472 Bytes free space of 65472


6. Dump after manual Garbage Collection:

16 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
6 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
28800 Bytes free space of 65472


7. Dump after manual Garbage Collection:

18 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
7 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
24128 Bytes free space of 65472


8. Dump after manual Garbage Collection:

20 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
8 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
19456 Bytes free space of 65472


9. Dump after manual Garbage Collection:

22 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
9 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
14784 Bytes free space of 65472


10. Dump after manual Garbage Collection:

24 Memory Configs (take care)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
10 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
10112 Bytes free space of 65472


11. Dump after manual Garbage Collection:

26 Memory Configs (take care)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
11 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
5440 Bytes free space of 65472


12. Dump after manual Garbage Collection
(768 Bytes free, next is automatic Garbage Collection):

28 Memory Configs (take care)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
12 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
768 Bytes free space of 65472 (take care)


13. Dump after manual Garbage Collection:
(VSS2 Stream was written, free space is back)

6 + 4 Memory Configs (ok)
0 + 0 xml (ok)
0 + 0 iCloud Tokkens (ok)
0 + 0 Microsoft Certificates (ok)
0 + 0 BluetoothActiveControllerInfos (ok)
0 + 0 BluetoothInternalControllerInfos (ok)
0 + 0 current-network (ok)
2 + 2 AAPL Path Properties (ok)
51776 Bytes free space of 65472
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: flyproductions, MacFangio und Indio
Manuelle Garbage Collection hat sich einfach so als Begriff eingebürgert. Eigentlich ists eine Kombination aus einem normalen NVRAM Reset der dazu durch das Wiederholen eine Garbage Collection mit auslöst und so gründlicher aufräumt.
 
23 Memory Configs (take care)
2 xml (ok)
2 Microsoft Certificates (very bad)
0 BluetoothActiveControllerInfos (ok)
1 BluetoothInternalControllerInfos (ok)
3072 Bytes free space of 65464

Echt tolle Arbeit vom Macschrauber - eigentlich läuft alles bin endlich dazu gekommen nen Backup zu machen, da ich Linux auch über OCLP boote, Backup über Lubuntu gemacht, könntest Du Dich evtl. einmal direkt melden?
 
hast ne Unterhaltung. Die Zertifikate sollten raus.
 
Da immer mehr User den OCLP (OpenCore Legacy Patcher) benutzen ein paar Hinweise zum Erlauben der DirectHW.kext (die Kernel Extension die Flashrom zum Lesen und Schreiben benötigt).

Das aufgedröselte CSR Bit ist csr_allow_untrusted_kexts

Selbstverständlich sei es jedem freigestellt ob er das zeitweise oder ständig erlauben möchte.

csr_allow_untrusted_kexts in OCLP.png


wird für den Dumper benötigt.

Ansonsten per OpenCore conifg.plist ändern wäre es dieser Eintrag:

Code:
<key>csr-active-config</key>
<data>Qwo=</data>
 
  • Gefällt mir
Reaktionen: MacFangio und Indio
  • Gefällt mir
Reaktionen: PropClear, Indio und hutzi20
  • Gefällt mir
Reaktionen: PropClear, Dorena Verne, DL8LAQ und eine weitere Person
Zurück
Oben Unten