Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

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.
 
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.
 
Last edited:
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
 
  • Like
Reactions: superlativo, datafeedexpert and h9826790
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
 
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.
 
  • Like
Reactions: w1z and h9826790
Sorry if I miss something but where can I find the ROM.tool? The tool is missing in the RomDump.dmg !!
Help is appreciated.
 
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.
 
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: Untitled1.jpg
and this is the content in the RomDump map:Untitled3.jpg
according to your video I need a map with the ROMTool to complete the flashing:Untitled4.jpgso I need the ROMTool to flash my newroom. Could you please send me a link where I can upload?
 
obus said:
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 2304819so I need the ROMTool to flash my newroom. Could you please send me a link where I can upload?
Click to expand...
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.
 
Last edited:
  • Like
Reactions: obus
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.
 
Last edited:
  • Like
Reactions: obus and 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.
 
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
 
basslik said:
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
Click to expand...

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.
 
Last edited:
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.

Screenshot Monterey selection.png

Screenshot Monterey rename.png
 
Last edited:
  • Like
Reactions: h9826790
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 ?
 
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).
 

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
 
Last edited:
  • Like
Reactions: h9826790
Macschrauber said:

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
Click to expand...
Thank you for what you do, as well as all the others.
 
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



forums.macrumors.com

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 forums.macrumors.com

some screenshots:
firmware programming mode off.png

firmware programming mode unknown yet.png

firmware programming mode on.png

admin password.png

analyse.png
 
Last edited:
  • Like
Reactions: crjackson2134 and h9826790
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
 
Last edited:
  • Like
Reactions: h9826790
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back