Open your dump with Hexfiend and search for BIOS, you will get the version there.
The dump I cleaned is 141.0.0.0.0:
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 MacPro5,1: BootROM thread | 144.0.0.0.0
- Thread starter tsialex
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
The dump I cleaned is 141.0.0.0.0:
Thank you!
How important is it that I flash my ROM with that cleaned file (after it's been updated to 144.0.0.0). Thinking it would it be more or less the same if I take my relatively clean saved state from July 2021 (after verifying that it's 144.0.0.0).
Use your BootROM image with the greatest available space that the EFI is already 144.0.0.0.0. I've just looked your original dump and it's a 0x03 release (most recent is 0x0D), with base_20 hardware descriptor (most recent is base_21) and BootBlock APLEFI1.88Z.0005.I00.1007141219, older even that the one Apple sent with Mac Pro EFI Firmware Update 1.5 back in October 2010.
When I cleaned the NVRAM volume of your BootROM image three years ago, I've not yet found the Apple dumbest bug/oversight of the incorrect free space indicators sent with the generic firmware upgrade image MP51.fd (MP51.fd NVRAM area is completely ignored by efiflasher, so Apple didn't even tried to make a correct NVRAM volume) or the 0x0D BootROM version that Apple only sent with mid-2012s made around September/October 2013, just before the late-2013 production started. So, don't make much sense to flash your 141.0.0.0.0 image back and have all the work to upgrade it to 144.0.0.0.0.
@tsialex : I have a MP3,1 (I apologize if this should be elsewhere) that, according to your procedure, shows only 5222 free space full size in the first (only?) VSS store. It also may have the missing second VSS store/corruption, as you show in your final example.
I have had no problems, yet. I am just trying to figure out OC to move my machine past ElCapitan and, somewhere in the process of reading that thread, I wound up clicking through to this one. (I now note that OC thread also says MP5,1) Finding the bad values, I am concerned that perhaps I should stop everything until I get this NVRAM issue resolved. The end of your procedure says that if one finds "any of the issues above" to ask about reconstruction, but am I at that point or should I just try to reset NVRAM first? (I'd hate to improperly irritate it even more, if it is about to die.)
I have had no problems, yet. I am just trying to figure out OC to move my machine past ElCapitan and, somewhere in the process of reading that thread, I wound up clicking through to this one. (I now note that OC thread also says MP5,1) Finding the bad values, I am concerned that perhaps I should stop everything until I get this NVRAM issue resolved. The end of your procedure says that if one finds "any of the issues above" to ask about reconstruction, but am I at that point or should I just try to reset NVRAM first? (I'd hate to improperly irritate it even more, if it is about to die.)
early-2008 Mac Pro have very different NVRAM design, with just one VSS store and a FTW store. Also, the BootROM is stored on a separate Firmware Hub flash memory instead of a SPI flash memory like on MacPro5,1.
So, the rules for a MacPro3,1 are different from a MacPro5,1. The early-2008 Mac Pro had only one EFI firmware update and most MacPro3,1 already have it. While is also possible to reconstruct it, my advice with an early-2008 Mac Pro is to first do a deep NVRAM reset and track the available space of the VSS store over time. If you use it constantly, checking two times over ten days should be enough to give an idea of the state of the VSS store.
If you can't improve the available space, then a BootROM reconstruction would be needed.
Hi Everyone, I'm new to MacRumours but have been keeping Mac Pros alive for several years. Currently I have a 5,1 as in the attachment. I have only just discovered the NVRAM problem and am concerned as I have a lot of invalid VSS entries. I think I'm heading for a brick.
Any help with Boot Rom reconstruction etc would be much appreciated @tsialex. TIA
Any help with Boot Rom reconstruction etc would be much appreciated @tsialex. TIA
Attachments
Some VSS store invalid entries are expected and are variables that changed/superseded, it's normal to have it until the garbage collection process remove it all.
Since you have a clean secondary VSS store, your NVRAM probably had garbage collection triggered recently. You can try to do a deep NVRAM reset forcing the garbage collection process again and see if you get a considerable improvement on your available space. If not, a BootROM reconstruction service is the next step, I'll send a PM.
Last edited:
Wow, thanks for the quick reply. I'll do the deep NVRAM reset (tomorrow morning as I'm at work now) and report again. I have received your PM, thank you, and will follow the instructions. Thanks heaps
I wanted to give a recommendation for using @tsialex's bootROM services. My 2012 5,1 3.33 was on the verge of self-destruction having been through Nvidia drivers (back in the pre-Metal days) and multiple iterations of Opencore. My BootROM was properly messed up (although admittedly I didn't realize it, and used his services as a precaution) and he provided a thorough explanation, showed me updates as he went about it, and now I have a clean image to refresh every 90 days (per his recommendation). Mine was bad enough that he told me to stop using my Mac Pro until it's flashed b/c he was concerned about its imminent bricking. Thanks @tsialex.
You almost certainly would bricked your Mac Pro running the 12.3 software update this week, the NVRAM was almost completely filled with crash dumps, 14 enormous PanicInfo logs, and both circular logs were already corrupted. You got it repaired in the nick of time.
Before Monterey, the crash dumps were save inside ~/Library/Logs/DiagnosticReports and not in the NVRAM, this is a enormous problem now and a big regression in my view.
Btw, I'll add your double circular log corruption as an example of failure on my post about the NVRAM health.
Last edited:
Maybe this has been covered already (I did search) but when a Mac Pro is bricked this way, what does it do? Does it have any startup chime or activity? Or does it just shut off immediately?
No chimes.
Shutdown depends on where exactly the BootROM failed, can shutdown immediately or not even power up when the SPI flash memory itself is dead. Also can have a SMC shutdown after 3 or 4 minutes, this is more common with NVRAM corruption or when the X86 Reset Vector area is corrupted.
Hi @tsialex, I did a deep NVRAM reset and I think things got worse. My Primary VSS Free Space disappeared and stops at "padding". See screen shot. I still have to boot into Mojave (without OC) to follow your instructions to properly dump ROM etc. Am I safe to do this? Would another deep NVRAM reset help or make things worse? TIA
Attachments
Yep, unfortunately your circular log just went haywire. The garbage collection is not even saving the valid entries of the circular log to the secondary VSS store. Don't do more NVRAM resets or you'll risk getting a brick.
Send me both the dumps you already have and the pictures, then power off your Mac Pro until I get the BootROM image fully cleaned/upgraded/reconstructed.
@tsialex: Wanted to ask you about best procedure(s) when re-flashing a re-constructed BootROM paired with a macOS update/upgrade. I ask specifically because I read a comment of yours on another thread about how some NVRAM changes brought by macOS 12.3 tax our cMP BootROM even more than in the past (please correct me if I misunderstood).
I plan on upgrading to macOS 12.3 soon. I only have one OS at a time in my cMP (currently macOS 12.2.1). When upgrading OpenCore and/or macOS, I usually do the following:
Thanks!
I plan on upgrading to macOS 12.3 soon. I only have one OS at a time in my cMP (currently macOS 12.2.1). When upgrading OpenCore and/or macOS, I usually do the following:
- I remove all HDDs/SSDs and PCIe cards
- Put my Mojave SSD in Bay 1
- Boot and reset NVRAM
- Do the re-construsted BootROM re-flash (including de-activating SIP etc)
- Re-install my OC dedicated SSD in Bay 4 and upgrade/bless OC.
- Install back all reimaining internals as per my signature and remove Mojave SSD from Bay 1.
- Boot back into my latest macOS via OC and then do any macOS update/upgrade available.
Thanks!
Last edited:
Interesting question!
Earlier today @austinhealey175, I reconstructed his booted BootROM image on Monday afternoon and he flashed it on Tuesday, sent me his dump after the 12.2.1 Monterey OTA update and it had not even 2KB available - crazy since it's a single CPU. See below the UEFITool screenshot he sent me:
Remember, this is the OTA to 12.2.1, with a never booted BootROM image flashed two days prior! So, with all the craziness of the 12.3 OTA update, if you don't have a MATT card, you probably should flash the reconstructed image before and after the Monterey software upgrade. Your workflow is good/safe, btw.
Edit:
While I not installed 12.3 myself yet, I'll do it over the weekend, several other people sent me dumps after the 12.3 and it's crazy the amount of variables needed for the staging of the MacPro7,1 EFI update and the crashes/PanicInfoLogs saved inside the NVRAM (I'm not going to post screenshots since most have FindMyMac and iCloud credentials). I'm still trying to understand what 12.3 OTA is doing, seems that Apple changed the way EFI firmware upgrades are setup and OC is not blocking it anymore - ping @cdf.
Last edited:
Possible with caveats, if you have UDIMMs instead of RDIMMs, no iCloud configured and just recently had a deep NVRAM reset/forced GarbageCollection.
Easier with a single CPU tray, practically impossible with dual CPU tray and 6+ DIMMs installed.
@tsialex
Hi again, I did a deep NVRAM reset and here is the result (I made 2 dumps to be sure)
That's more like it.
Do I need to do something?
As I see, the result should be between 30000 and 35000.
THANKS
Hi again, I did a deep NVRAM reset and here is the result (I made 2 dumps to be sure)
That's more like it.
Do I need to do something?
As I see, the result should be between 30000 and 35000.
THANKS
Attachments
Last edited:
It's totally implausible that with 8 RDIMMs installed and everything else inside the NVRAM will be stored with less than 15KB. Something is wrong.
Why you suddenly used the additional ~23KB?!? If this MacPro was mine I'd start investigating why this is happening, first step would be to validate the MLB sector, then flash the generic upgrade image for 144.0.0.0.0 (MP51.fd) to see if the NAND cells of the NVRAM area still work as expected.@tsialex
Hi again, I did a deep NVRAM reset and here is the result (I made 2 dumps to be sure)
That's more like it.
Do I need to do something?
As I see, the result should be between 30000 and 35000.
THANKS
P.S.:
Remove your screenshot with the serial number, people to this day clone MacPro5,1 serials for Messages usage with hackintoshes.
OK, thanks for the clarifications and new insights. So in conclusion, the only additional step suggested at this time, is to flash reconstructed image twice, once before and once after the macOS upgrade, correct? That works for me, will start doing it with the 12.3 upgrade and related process.
Sounds good. As always, lots to learn from your findings. Keep us informed on any new findings in this (and many other) thread(s). Thanks!
Since it's not really clear what is going on with the way Apple is now bootstrapping the firmware upgrades, my recommendation is to at least enable VMM spoofing (no firmware upgrades with virtual machines) and to really be on the safe side, like for people without MATT cards, to flash the never booted BootROM image before and after the 12.3 upgrade.
Don't all those "Invalid" entries count as free space? I think UEFITool should try to identify the contents of those entries and mark them as Deleted? That way you can tell what NVRAM variables are churning more frequently.
Got it. I do have a MATT card with my reconstructed never booted BootROM, but it's there on the ready for that tragic day when my cMP might brick. I don't see a problem in doing the flashing twice, adds a bit of extra work of course, but it's not a big deal to be on the safe side of things.