I agree, in every case it is a thing to look closer.
That is the intension to check it and write a note if it is in unusual order.
Got a tip for us?
Let us know
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
- Thread starter Warrington
- Start date
-
- Tags
- mac pro 5.1 nvram
- Sort by reaction score
I agree, in every case it is a thing to look closer.
That is the intension to check it and write a note if it is in unusual order.
my macpro 4,1-> 5,1 also has this same message:
Fsys: 0 override-version, 1 ssn, 2 hwc, 3 son, 4 overrides, 5 EOF (unusual)
I bought this macpro directly from Apple as a refurbished unit back in 2009. It has never booted windows or anything other than a Mac OS or been flashed other than Apple firmware updates and the 5,1 update. It is running monterey using Martin's opencore package. It has no problem booting or running apple stuff. I wonder if this "unusual order" has to do with it being a refurbished device from Apple.
I just found your romdump tool looking to put in the EnableGop functionality.
Do you think it is save to proceed with the EnableGop without fixing this order thing?
Fsys: 0 override-version, 1 ssn, 2 hwc, 3 son, 4 overrides, 5 EOF (unusual)
I bought this macpro directly from Apple as a refurbished unit back in 2009. It has never booted windows or anything other than a Mac OS or been flashed other than Apple firmware updates and the 5,1 update. It is running monterey using Martin's opencore package. It has no problem booting or running apple stuff. I wonder if this "unusual order" has to do with it being a refurbished device from Apple.
I just found your romdump tool looking to put in the EnableGop functionality.
Do you think it is save to proceed with the EnableGop without fixing this order thing?
As it is a 4.1 to 5.1 crossflash (I assume, if it's a reconstructed real 5,1 firmware it writes bootblock of 144.0.0.0.0), it is recommended to do a reconstruction.
Not only for that mixed order in Fsys. That mixed order does no harm at all, but if one part is wrong I would not be 100% sure, that there are no more glitches.
Plus, as said, such a crossflash is not the best way to go for modern OS, heavy use of NVRAM running OpenCore or multiple OS.
You don't give a single word about what you want to do, or what it has to do with the Dumper project or the NVRAM health state.
For dumping with the Dumper: Kext Signing is disabled, so dumping (and checking) the firmware should work.
I want to install windows on my mac pro and was checking the nvram.
And then i saw this message and I was woried something is wrong? Should I be or not?
The sentence that something is "likely to break in the future" is not good? So I thought I needed to change some settings?
And then i saw this message and I was woried something is wrong? Should I be or not?
The sentence that something is "likely to break in the future" is not good? So I thought I needed to change some settings?
I guess, you read the hint about that Netkas crossflash 4.1->5.1 - what sometime tends to break in OpenCore / multiboot configurations with heavy use of NVRAM, when some other things come in play.
The solution for this is not to change some sip settings, the solution is to get a prestine, rebuilt firmware. You can read several posts about this in this forum. Also you have seen the contact possibility...
The solution for this is not to change some sip settings, the solution is to get a prestine, rebuilt firmware. You can read several posts about this in this forum. Also you have seen the contact possibility...
Thank you for the info @Macschrauber
I have done some reading on this subject and I now understand I currently have a crossflash firmware (4.1 -> 5.1), which works, but could fail in the future.
Best way would be to rebuild the firmware. I did a rom dump, but only after I installed OCLP already. Probably I should have done it before, or this does not matter?
I have done some reading on this subject and I now understand I currently have a crossflash firmware (4.1 -> 5.1), which works, but could fail in the future.
Best way would be to rebuild the firmware. I did a rom dump, but only after I installed OCLP already. Probably I should have done it before, or this does not matter?
For a rebuild it is important to have the IDs, this works on an OCLP OS.
If one wants a clean as possible romfile of the particular Mac Pro, it is the best to make a deep nvram reset and boot into a supported Os without OpenCore. I prefer Mavericks in this case, as I dont need to lower sip settings to dump the rom.
Last edited:
New version of the Dumper (5-8-2024):
GitHub - Macschrauber/Macschrauber-s-Rom-Dump: A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1
A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1 - Macschrauber/Macschrauber-s-Rom-Dump
github.com
- Added recognition for Matt Card.
- Added recognition for more errors found by UEFIExtract.
- Implemented dynamic $IBIOSI$ scan to retrieve BIOS versions of "unknown" machines' firmware and unnamed .fd files.
- Revisited OpenCore LauncherOption: Full presentation.
- Fixed: ASCII values in csr-active-config were not interpreted correctly.
- Fixed: Usernames with special characters, such as spaces, no longer cause privilege errors.
Extra Tools (ESP tools, Repair preboot, etc.):
- Enlarged dialog buttons for wider dialogs.
- Improved recognition of dark and light mode for rendering icons of ESPs and System volumes.
- Revisited most of the tools, more robust recognition of OS' and bootloader variants.
- Revisited Bless OpenCore ESP tool.
- Check ESP for MS certificates: added a setup option to live in the login items to scan for Windows ESPs. Also deactivates them by request or automatically.
Optionally checks NVRAM for certificates when csr values are set as needed.
new tool: Macschrauber's System Version Scanner
- Scans for MacOs and Windows versions
- Presents sealed status ( yes / broken ) for MacOS
- Presents UEFI / Bios variant for Windows
Last edited:
new version of the Dumper 1-9-2024
Dumper:
- Various fixes for running the Dumper as a non admin user.- Added iMac 12,1 dumping via Eficheck.
- Adds MacOs version and CPU configuration to the analyse window and log file.
- Added detailed boot block info, with version and release date.
- Detect more empty .fd firmware files for MP41 and MP51.
- Added scanning dump files file system wide via the cli tool.
- Read and decode NVRAM variables directly from NVRAM via the cli tool.
example nvram readout for csr-active-config
Code:
test_nvram '-nvram csr-active-config'
NVRAM output:
csr-active-config w%00%00%00
-------------------------------------------------------------------
Decoded:
77000000
Decoded (little-endian representation):
00000077
-------------------------------------------------------------------
0x001 CSR_ALLOW_UNTRUSTED_KEXTS
0x002 CSR_ALLOW_UNRESTRICTED_FS
0x004 CSR_ALLOW_TASK_FOR_PID
0x010 CSR_ALLOW_APPLE_INTERNAL
0x020 CSR_ALLOW_UNRESTRICTED_DTRACE
0x040 CSR_ALLOW_UNRESTRICTED_NVRAM
-------------------------------------------------------------------
Hexadecimal encoding:
00000000: 3737 3030 3030 3030 77000000
-------------------------------------------------------------------
Raw XML data:
dwAAAA==
-------------------------------------------------------------------
Base64 encoding:
w
-------------------------------------------------------------------
Hexadecimal conversion:
6477414141413d3d
-------------------------------------------------------------------Extra Tools (ESP tools, Repair preboot, etc.):
- boot-args: edit boot-args got a vertical list of boot-args.- Various fixes for running the extra tools as a non admin user.
Github site: https://github.com/Macschrauber/Macschrauber-s-Rom-Dump
changelog: https://github.com/Macschrauber/Macschrauber-s-Rom-Dump/blob/main/changelog.txt
download: https://github.com/Macschrauber/Mac...d/Release/Download.the.Dumper.from.github.zip
Sequoia is also promising (it's before attaching root patches):
The Dumper update 19-10-2024
The Dumper:
-> Detects if running on a T2 or Silicon Mac and removes the button accordingly.
-> Added a dialog for missing LBSN/BD sector.
-> Decodes board-id to Mac model in log file.
-> tells the user if the assigned FireWire address does not match the firmware MAC address.
This may indicate that firmware from another machine was flashed on an MP41 or MP51.
test_nvram:
-> Dumping IM121 is forced to use eficheck (available from High Sierra to Ventura) due to a crash when loading DirectHW.kext.
-> "FW MAC matches not with LBSN" or "FW MAC matches with LBSN" line, when the Mac has Firewire and LBSN sector has a firmware MAC address.
-> A catch when Eficheck is not available (before 10.13, after 13).
-> A catch for an empty EFI Version string.
-> CRC32 check for the main firmware volumes for MP41 and MP51 firmwares.
ESP Tools:
-> Detect amdvbflash ESP.
unmount all ESPs, Mount ESP from list, Mount ESP from list and show bootloader:
-> Unmounting has an option to handle busy status of ESPs.
copy ESP:
-> Sets script into a loop, to work on more than one ESP in a row.
Macschrauber's System Version Scanner:
-> more sealed status report.
-> more progress bar steps for multiple MacOS on one machine.
Select Wi-Fi from found networks and Select Wi-Fi from preferred networks:
-> Message and workaround if Airport Utility cli tool is not working anymore on OS since Ventura.
Boot-Args:
-> edit boot-args got into a loop, so editing more options is more comfortable.
Preboot Fixer:
-> mount ESP needs admin privileges if user is not in admin group, fixed when using stored admin / password data.
Github site: https://github.com/Macschrauber/Macschrauber-s-Rom-Dump
Download: https://github.com/Macschrauber/Mac...d/Release/Download.the.Dumper.from.github.zip
Update from 18-1-2025
The Dumper:
-> confirming twice if the user wants to flash a MP41 firmware on a MP41 with upgraded processor.-> log firmware MAC address.
-> log blessed OS, if not via OpenCore.
-> report missing Fsys stream.
-> recognise Apple M CPUs, ch341a_spi reading and writing for M CPUs. Needs manual lib installation.
Is damaged fix:
-> added suggestions and adaptions to work in Sequoia.test_nvram:
-> fixed MP51.88Z.0085.B00 was detected as MP51.88Z.0087.B00.-> compare Firewire MAC address just for fw0, for machines that have multiple Firewire interfaces.
-> '-vars 4D1ede05-38c7-4a6a-9cc6-4bcca8b38c14' for example, scans this GUID, only.
-> added flashing to test_nvram, you should check the firmware file, before you flash. MP41 and MP51 units are tested, so far.
Installer for CLI tools:
-> present test_nvram versions from Dumper app and installed version.ESP Tools:
-> fixes for Silicon Macs, as they have no ESP on the boot disk.-> fixes for ESPs on single partition disks.
-> Copy ESP does unmount all mounted ESPs again.
-> fixed: Memtest86 comes sometimes in ubuntu folder, so not detected.
Check ESPs for MS bootloaders:
-> fixed glitch: it does not deactivate Windows ESPs in 5 seconds dialog mode.-> fixed glitch: the variable os is not defined, when running in Yosemite and kext-dev-mode=1 is missing.
Preboot Fixer:
-> Detect Apple M CPUs, there is no preboot / boot.efi.Wifi-Scripts:
-> Select Wi-Fi from found networks displays current wifi network.AVX2:
-> new Tool to scan for AVX / AVX2 codes in binaries. NeedsCommand Line Toolsadded icons for the tools, made by Chatgpt.
GitHub - Macschrauber/Macschrauber-s-Rom-Dump: A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1
A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1 - Macschrauber/Macschrauber-s-Rom-Dump
github.com
Last edited:
Update from 29-3-2025
(most important: Xserve 3,1 support)The Dumper:
-> fixed: Big Button was not in the middle in Catalina.-> fixed: Give a note, if DirectHW.kext is not loaded due to Bitdefender, or alike.
-> fixed: Xserve 3,1 flashing gave a missing "chips" variable error.
-> added: Xserve 3,1 recognition, if no serial is in the firmware.
test_nvram:
-> fixed NVRAM firmware rom string had a space for 0x20 and 0x00 for one user, fixed reading MAC address.-> multibyte error in some localisations presented in Monterey for hexdump vars and lbsn.
Github:
GitHub - Macschrauber/Macschrauber-s-Rom-Dump: A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1
A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1 - Macschrauber/Macschrauber-s-Rom-Dump
github.com
@Macschrauber thank you sir for your awesome work!
I have a flashed cMP 4,1 > 5,1 that bought many years ago secondhand and I mostly use it as my "test" machine (long story short as one of the legs is bent). That said, I've only used OCLP in the past and no Windows 10/11 install. I was in the process of rebuilding a new bin file and I got the exact same error message regarding the Firewire MAC address not matching.
I'm familiar with Hex Edit and Hex Fiend. Is there a way to find the offset address to fix this value? Or where could I get the correct value from your ROM Dump app?
Danke schön bitte!
Send me the logs and the dump file, by mail.
Also be sure to use the latest version v29-3-2025 as I had a glitch with firmware MAC addresses containing 0x20 and 0x00.
Last edited:
changelog for v14-6-2025
This release added support for reading the "self blessed" OpenCore ESP. This is masked and not readable by the OS. The tools read it from the firmware chip.The Dumper:
- added: Logging of the GPU's Device ID.
- added: Error handling for cases where the user’s home folder is on a disk that does not allow setting privileges.
- added: DefaultBackgroundColor for type 80 firmware (with 2 alternating streams).
test_nvram:
- fixed: Firmware MAC mismatch report, when the NVRAM variable had a backslash in its encoding.
ESP Tools:
- fixed: Issues when an ESP's name does not start with "ESP", like "No Name", or whatever.
- added: Ability to read BootOrder directly from the firmware chip when BootOrder is masked by OpenCore (LauncherOption=Full, ESP self-blessing).
Preboot Fixer:
- fixed: Sandbox permissions issue on Sequoia / Silicon when editing disk labels on external Intel disks.
new tool: CPU Frequency:
- Measures actual CPU frequency, including under load to force turbo mode.
Downloader:
- fixed: Addressed an install loop that occurred when a user downloaded the Dumper and then launched the downloader again from the disk image. Improved disk image recognition for robustness.
- changed: Now uses a single downloader for all three sources (GitHub, Dropbox, GMX).
All tools:
- fixed: finally got a fix for error -1750 when the tools quit, happened on OS 10.9 and earlier.
Assumed BootOrder masking, OpenCore is detected and BootOrder points not to an ESP:
Read BootOrder from firmware spi chip and found the matching ESP:
Macschrauber's Rom Dump Github side
Macschrauber's Rom Dump Downloader
If there is a message, the downloader is damaged.:
Code:
xattr -cr ~/Downloads/Downloader
Code:
curl -L -o "$HOME/Downloads/Download the Dumper from Github.zip" https://github.com/Macschrauber/Macschrauber-s-Rom-Dump/releases/download/Release/Download.the.Dumper.from.github.zip && unzip -o "$HOME/Downloads/Download the Dumper from Github.zip" -d "$HOME/Downloads" && open -a "$HOME/Downloads/Downloader/Download the Dumper.app"
Last edited:
Macschrauber
I have three containers, Monterrey, Sonoma, and Sequoia on the same NVMe blade.
I kept the the OS's for back while I updated to the newer OS versions.
I'm all good on Sequoia, and should I remove the other two remaining OS's, Monterey and Sonoma?
I'm not needing those verisons.
I have three containers, Monterrey, Sonoma, and Sequoia on the same NVMe blade.
I kept the the OS's for back while I updated to the newer OS versions.
I'm all good on Sequoia, and should I remove the other two remaining OS's, Monterey and Sonoma?
I'm not needing those verisons.
I would strip those down to just a fresh and empty user. To keep for tests.
But what has this to do with firmware and NVRAM ???