MP 1,1-5,1 Healthy NVRAM normal behaviour on 4,1->5,1 machines

[haralds]

Due to an unfortunate incident, I bent some CPU tray pins on the motherboard. I ended up finding a pristine system for $180 and decided to buy it to save myself complete system disassembly and board replacement (my time is money.)
I transplanted my dual CPU tray, PCiE cards, and all drives and everything is working nicely.
However, the ROM dump showed a lingering certificate from UEFI Windows boots by the previous owner with minor corruption.
I ended up forcing an NVRAM reset four times in a row. To my surprise that removed ALL issues and the NVRAM has been clean ever since.

 

[Macschrauber]

Sometimes this works.

I dont know what causes clearing of the certificates does not work, is it when it got copied to the second store? Does it not work when other problems are in?

Guess when its not in VSS2, the clearing sometimes works. So the dumper advices to try that deep NVRAM reset.

When testing the mount esp script with displaying the bootloader I accidently booted Uefi Windows (was just a data disk with a Windows ESP btw) and catched a certificate.

It got into VSS1. Not into VSS2. As copying the valid variables from VSS1 to VSS2 happens by regular garbage collection when NVRAM space is below 2048 bytes. As long as the garbage collection has not run it stays in VSS1.

Clearing by NVRAM reset worked in that case, too. I could easily flash a backup or clean the firmware by myself. But wanted to test, if I could do that by NVRAM reset.

So conclusion is: yes, sometimes that works, but not in every situation.

 

[Macschrauber]

Update from 8-10-2023

-> showing the OpenCore spoofed firmware string (only for fresh dumps possible)
-> counting Microsoft Uefi variables
-> dumping: iMac 11,1, iMac 11,2
-> added a tool to rename ESPs (Bootloaders like OC) shown in the boot picker

details: https://forums.macrumors.com/thread....2207814/page-520?post=32382081#post-32382081

analyzing MBP61, MBP62, IM112, IM113 to shell script

workaround for deeper analysing units with scanvss where scanvss could not scan the dump file directly:
IM112, IM113, IM121, MBP61, MBP62, MBP81, MBP82, MBA41, MBA42, MM51

fixed: infinite loop in the shell script / the Dumper for units with less than 6 NVRAM variables of type (AA.55.7F.00.07)


https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801

 

[Macschrauber]

Update from 12-10-2023


-> NVRAM Volume Detection:
The shell script dynamically identifies the NVRAM volume position and offsets. In theory, this means that all Mac Firmwares could be decoded.

-> Dumping Mac Mini 7,1 for The Dumper and Shell Script

-> ESP Tools: Added a script to automatically label ESPs for the boot picker based on the found bootloader flavor

fixes:
- An error occurred when running Yosemite, and the absence of kext-dev-mode=1 prevented the loading of DirectHW.kext, leading to a missing variable.
- An older OS like Yosemite truncated the firmware version, causing the shell script to display a spoofed firmware.
- A glitch related to logging prevented the selection of multiple found flash chips on untested Macs.

https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801

 

[Macschrauber]

Update from 22-10-2023

-> Find my Mac Detection
The dumper provides information that Find my Mac is activated. This can be important when buying a used device.
Only the shell script provides the configured text output from a Find my Mac lock. Since these texts often contain private data such as phone numbers or email addresses, there is no output in the dumper.

-> The collection of changing NVRAM states is supported.
You can either add your Shasum encrypted serial number to the shell script or provide it as an argument using -gathernvram.vol. If that argument is given, or the shell script has the encoded serial number of your Mac, the Dumper stores (to spare storage space) just the NVRAM volume to a pre configured folder "All_Nvrams" in your home folder.

fixes:
- Some newer Macs' firmware (approximately from 2013 onwards) have a variable of the old (up to around 2013) type. I have revised the detection logic to avoid incorrect classification.

 

[obus]

Sorry if I miss something but where can I find the ROM.tool? The tool is missing in the RomDump.dmg !!
Help is appreciated.

 

[Macschrauber]

It is in the root folder of the disk image and has an icon of an spi chip.

If something is missing, maybe some virus/malware tool was active? They get triggered by flashrom inside the app package.

 

[obus]

Sorry @Macschrauber but there is no ROM.tool in the root of the downloaded "Macschrauber's CMP Rom Dump.dmg"
I Have no virus/malware tool enabled so I'm a little bit confused. This is the content in the downloaded map:
and this is the content in the RomDump map:
according to your video I need a map with the ROMTool to complete the flashing: so I need the ROMTool to flash my newroom. Could you please send me a link where I can upload?

 

[Macschrauber]

Sorry @Macschrauber but there is no ROM.tool in the root of the downloaded "Macschrauber's CMP Rom Dump.dmg"
I Have no virus/malware tool enabled so I'm a little bit confused. This is the content in the downloaded map: View attachment 2304815
and this is the content in the RomDump map: View attachment 2304816
according to your video I need a map with the ROMTool to complete the flashing: View attachment 2304819 so I need the ROMTool to flash my newroom. Could you please send me a link where I can upload?

This is a bundle by @Henninges what I am not very happy with. It is outdated, you should contact the guy what makes it to update it.

You don't need RomTool. My Tool does all what is needed, and comparing to RomTool it does a lot of verification and reporting. RomTool does not even tell in some situations if it has not flashed the firmware.

I guess he took Romtool in his guide as the warning in my tool what comes before flashing scared him. RomTool does the exact same thing, even uses the same FlashRom version as the executing background tool. I took a load of effort to verify, analyse and report possible problems before flashing a Mac Pro 4,1/5,1 firmware.

RomTool is an universal tool for all kind of Macs and does not even tell if you flash a completely different firmware from another Mac.

The Dumper is (especially the flashing part) a Mac Pro 4,1/5,1 tool, only. In the last year I added dumping (reading) of other Mac's firmwares. But I do not add flashing for other Macs. As I don't want to take the responsibility for bricking a Mac what is not tested. I flashed dozens of Mac Pros before adding flashing to the field version of the Dumper.

 

[Borowski]

It is the same tool, you can also use it for flashing. Look at the screenshots inside. No explanation needed.

Edit: double posting....too late.

 

[obus]

Perfect. Thank's both of you for this explanation.

 

[basslik]

Thank you, THANK YOU ALL.

Looks like I was pushing the envelope.

 

[Macschrauber]

Nothing really wrong there, just a good filled nvram volume, two or three reboots and garbage collection should run.

Then the 2nd stream should be built.

MTC counter tells you did a deep nvram reset or a flash of a rebuilt "empty" firmware 8 boots ago.

 

[basslik]

I did okay then?

Yeah this cool stuff is all new to me. You folks are amazing to be able to keep this old beast of a machine rocking.

THANKS AGAIN

 

[Macschrauber]

I did okay then?

Yeah this cool stuff is all new to me. You folks are amazing to be able to keep this old beast of a machine rocking.

THANKS AGAIN

Yes, just let the box boot 3 more times, it should build the 2nd stream and free space should be in the 40,000ish, depending on what hardware you have, how many ram sticks and of what kind, how many wifi networks are stored.

Just to name a few points.

With every boot a load of variables renew, marking the old ones as deleted. This strange method is because of the physics of the firmware chip what holds the nvram stream(s) as well.

 

[basslik]

Thank you. The dumper Wasn't able to get legacy WiFi to work, but maybe I'll trying this option and see.

https://forums.macrumors.com/threads/mp3-1-5-1-macos-12-3-oc-oclp-problem-with-10g-adapters-aquantia-chipset-solved.2395959/?post=32346028#post-32346028

 

[Macschrauber]

Updated the Dumper (18-11-2023)

Biggest upgrade is to get much more information from the NVRAM Volume.

Added a -vars argument to the shell script. No way the main .app can display such big content. The limits of AppleScript come here in play. And I dont want to waste time with AppleScript GUI extensions.

The Dumper has an installer to deploy the shell script and the helper tools: Installer for the CLI tools (optional)


After deploying it could be used like:

test_nvram -dump -vars to dump the firmware and display all the vars, including decoding the hardware descriptor in FSYS, showing XML data and fetching the text fragments.
or
test_nvram -vars path/to/my/dump.bin to show all what's in an already dumped firmware file.

Some examples and a more detailed changelog is in the main post:
https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801

But never post such a detailed dump to public sources. The dump, and the big report contains loads of personal and machine data. So again: never, ever post that shell script report!


Also added a little helper (rename preboot) to edit the name a system disk displayed in the bootloader. Sometimes it get stuck to the old name.

 

[obus]

Thank you @Macschrauber for your eminent tool. Updated my firmware with gop and everything worked like a treat.🤙👍👍

 

[basslik]

My I ask can one run the dumper after one has already installed Monterey, or does it still have to be a untarnished clean OS like Mojave ?

 

[Macschrauber]

If you need a dump for reconstruction it doesnt care.

if you need a dump to backup your settings for, lets say running Monterey via OpenCore, it needs to be Monterey.

If you have no effort to boot a supported OS use the supported OS.

If you are in deep trouble with a barely working OS, Mavericks is the way it could work when pulling the RTC battery before as this bypasses the nvram (part of the firmware chip).

 

[basslik]

Got it, thanks.

 

[Macschrauber]

The Dumper got a new version:​

Update from 10-12-2023

-> detecting Nvidia Chipsets to report long readout duration
Macs with Nvidia chipsets (MCP79 / MCP89 built around 2009) could take about 5 minutes to read the firmware

-> Multiple flash chip definitions for dumping with the shell script
it prompts for the chip of a Mac whose spi data is not captured (yet) if Flashrom returns more than one type

-> checking Bootblock vectors for rebuilds, showing Fsys header type after base_xx

-> emergency stop if one tries to flash a firmware from another Mac model in a MP 4,1/5,1
exits if the pre-flashing information readout is ignored

-> reading MBP54 and MBP91, updated some chip definitions for other models

-> added a copy ESP script to the ESP tools
Post in thread 'Manually Configured OpenCore on the Mac Pro'


https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801

 

[basslik]

The Dumper got a new version:​

Update from 10-12-2023

-> detecting Nvidia Chipsets to report long readout duration
Macs with Nvidia chipsets (MCP79 / MCP 89 built around 2009) could take about 5 minutes to read the firmware

-> Multiple flash chip definitions for dumping with the shell script
it prompts for the chip of a Mac whose spi data is not captured (yet) if Flashrom returns more than one type

-> checking Bootblock vectors for rebuilds, showing Fsys header type after base_xx

-> emergency stop if one tries to flash a firmware from another Mac model in a MP 4,1/5,1
exits if the pre-flashing information readout is ignored

-> reading MBP54 and MBP91, updated some chip definitions for other models

-> added a copy ESP script to the ESP tools
Post in thread 'Manually Configured OpenCore on the Mac Pro'


https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801

Thank you for what you do, as well as all the others.

 

[Macschrauber]

Update from 23-12-2023

-> showing firmware programming mode [ ] [off] [on]
The Dumper checks for firmware programming mode on compatible units (MacPro 4,1/5,1). It does this during reading/flashing or directly, when the password is stored encrypted by a CLI tool in the Other Tools folder.

(Firmware programming mode is initiated by pressing the power button until a long tone and blinking power LED appear when starting the box.)

I don't want the user to give access to the keychain or to bother him with passwords before the Dumper initiates any visible actions.

If the firmware programming mode status is unknown it presents the flash button until it touches the firmware chip the first time. After it detects no programming mode it hides the <flash firmware>button.

Edit: I have a bug in that version. Run the tool: Installer for the CLI tools (optional) to copy Flashrom to /usr/local/bin or use 25-12-2023, otherwise the Dumper will not show the <flash firmware> button :-/


-> Wrapped the Dumper into a loop, does not end directly after flashing / dumping.

Fixes:
- if the user's Downloads folder is not available it prompts for another
- The scanvss log filename had the spoofed firmware version in, now it's the real firmware version

Healthy NVRAM normal behaviour on 4,1->5,1 machines

Macschrauber's Rom Dump I needed to encrypt the disk image as DropBox has flagged it for containing Flashrom. The password is rom. What's new in the latest versions: Update from 20-2-2024 -> checking Fsys for missing items or wrong order sometimes they get into the wrong order or items...

forums.macrumors.com

some screenshots:

 

[Macschrauber]

Fix from 25-12-2023

-> I had a glitch in with the path from Flashrom for checking firmware programming mode, did /usr/local/bin as I have my tools there. This is corrected in 25-12-2023 version, using embedded Flashrom.

This prevented checking for firmware programming mode, showing the message the machine was not set in programming mode when <flash firmware> was selected.

Did not noticed it as I have that tools in this path on my machines for test_nvram CLI variant. I am sorry about that :-/

The link is the same:
https://forums.macrumors.com/threads/healthy-nvram-normal-behaviour-on-4-1-5-1-machines.2333460/page-4?post=32055801#post-32055801