MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0

[tsialex]

You should read the first post of the OpenCore thread, link below, and ask your OC related questions there.

OpenCore on the Mac Pro

This guide explains how to use the excellent OpenCore boot loader to install, run, and update the latest version of macOS on the MacPro5,1, resulting in a clean, unaltered operating system just like on a supported Mac.

forums.macrumors.com

BootCamp installs are not not compatible with OpenCore, so, you have to chain load rEFInd+/MyBootMGR to load it. This is the thread about it:

MyBootMgr: RefindPlus|OpenCore

This is a guide to using OpenCore and RefindPlus, to multiboot Classic MacPros (3,1 to 5,1) as well as equivalent Xserve (2,1 and 3,1). It involves booting Mac OS from one or more OpenCore instances chain-loaded from RefindPlus and booting other OS types directly from RefindPlus. The guide is...

forums.macrumors.com

 

[reatis]

Hi there!
I have a Mac Pro 5.1 mid 2010,2x3.46GHz,128 Gb ram and Radeon Rx 580 GPU.I'm still on Mojave,since I am a musician and some stuff I've got isn't yet compatible with Monterey.Eventually I will go OpenCore down the road, so the very first thing I wanted to check is BootRom health(even if I stay on Mojave for a longer period, since from my readings here I understood that BootRom is the weak spot of 5.1)
So I used my rescue ssd I have for Mojave(I used it for the very first time) and the result was this:

No need to say I was panicked! In the meantime, i saw there was the last Mojave update I had not done in my rescue SSD,so I did it and try to dump the BootRom again.This time, the result was this:

Again the result was weird, for a very very mistreated secondhand 2x3.46 machine.So, I performed the deep five time NVRAM reset, and this time things appeared to be normal:

Now,do all these results look normal to you?Is it due to the fact that my Mojave SSD was used for the first time? I read somewhere here what Tsialex wrote that free space isn't the only factor we should trust.So, @tsialex,would you be so kind to PM me for a cleaning service?Even if finally the last result is reliable,I would like to have a clean BootRom to flash every 3 or 4 months, just in case!
thank you for your patience
with kind regards,
Michalis

 

[tsialex]

Hi there!
I have a Mac Pro 5.1 mid 2010,2x3.46GHz,128 Gb ram and Radeon Rx 580 GPU.I'm still on Mojave,since I am a musician and some stuff I've got isn't yet compatible with Monterey.Eventually I will go OpenCore down the road, so the very first thing I wanted to check is BootRom health(even if I stay on Mojave for a longer period, since from my readings here I understood that BootRom is the weak spot of 5.1)
So I used my rescue ssd I have for Mojave(I used it for the very first time) and the result was this: View attachment 2032278 No need to say I was panicked! In the meantime, i saw there was the last Mojave update I had not done in my rescue SSD,so I did it and try to dump the BootRom again.This time, the result was this: View attachment 2032279 Again the result was weird, for a very very mistreated secondhand 2x3.46 machine.So, I performed the deep five time NVRAM reset, and this time things appeared to be normal: View attachment 2032281 Now,do all these results look normal to you?Is it due to the fact that my Mojave SSD was used for the first time? I read somewhere here what Tsialex wrote that free space isn't the only factor we should trust.So, @tsialex,would you be so kind to PM me for a cleaning service?Even if finally the last result is reliable,I would like to have a clean BootRom to flash every 3 or 4 months, just in case!
thank you for your patience
with kind regards,
Michalis

Forced garbage collection runs when the EFI firmware, at POST, detects that the NVRAM main VSS store is below 2048 bytes available. This threshold worked fine for the majority of people* until the staging of Software Updates for recent macOS releases that have sealed containers, BigSur->, started to brick MacPro5,1s right and left.

People with Samsung 8x16GB DIMMs have around 34~35KB available, while some Hynix 8x16GB that have a variant of Intel XMP is commonly in the low 20KBs, you can't get much better than that with these.

Besides NVRAM VSS store issues, you can have other things going wrong like the hardware descriptor being outdated making your X5690s to run 10ºC hotter and the factory instaled BootBlock riddled with bugs - just to talk about two common issues that I find everyday. I'll send you a PM.

*Failed GC bricking MacPros with SoftwareUpdates happened in the past also, like the several threads with variants of "HighSierra Security Update bricked my MacPro".

 

[reatis]

Forced garbage collection runs when at POST the EFI firmware detects that the NVRAM main VSS store is below 2048 bytes available. This threshold worked fine for the majority of people* until Software Updates staging of macOS releases that have sealed containers, BigSur->, started to brick MacPro5,1s right and left.

People with Samsung 8x16GB DIMMs have around 34~35KB available, while some Hynix 8x16GB that have a variant of Intel XMP is commonly in the low 20KBs, you can't get much better than that with these.

Besides NVRAM VSS store issues, you can have other things going wrong like the hardware descriptor being outdated making your X5690s to run 10ºC hotter and the factory BootBlock riddled with bugs - just to talk about two common issues that I find everyday. I'll send you a PM.

*Failed GC bricking MacPros with SoftwareUpdates happened in the past also, like the several threads with variants of "HighSierra Security Update bricked my MacPro".

Thank you for your fast reply! No, I don't use OpenCore or dosdude patch, just vanilla Mojave,and the BootRom was never bricked.As for the rest, please allow me to gather all the needed information you asked(to digest it also a bit!) and hopefully I 'll send it to you tomorrow or the day after tomorrow. Thanks a lot again.

 

[crowtrobot3000]

Hi @tsialex, I came across this thread while doing some research and am wondering if my BootRom is corrupted. I'm running an early 2009 Mac Pro that was purchased flashed from 4.1 to 5.1. It's running 10.14.6. I also have Windows 10 installed on a separate HD. I followed the instructions in the first post and while the free space seems ok at around 35,000, I'm not seeing a second VSS store in the list. Would you be able to help me make sure my BootRom is ok? Please let me know what other information you need.

Thanks!

 

[tsialex]

Hi @tsialex, I came across this thread while doing some research and am wondering if my BootRom is corrupted. I'm running an early 2009 Mac Pro that was purchased flashed from 4.1 to 5.1. It's running 10.14.6. I also have Windows 10 installed on a separate HD. I followed the instructions in the first post and while the free space seems ok at around 35,000, I'm not seeing a second VSS store in the list. Would you be able to help me make sure my BootRom is ok? Please let me know what other information you need.

Thanks!

Missing secondary VSS store is one of the most common corruptions of the NVRAM volume for an early-2009, the MP4,1 NVRAM volume and the MP5,1 one are different and this always cause problems/bricks in the long run.

If you already have the secondary VSS store header corrupt, you almost certainly have other issues. I'm gonna send you a PM.

 

[crowtrobot3000]

Missing secondary VSS store is one of the most common corruptions of the NVRAM volume for an early-2009, the MP4,1 NVRAM volume and the MP5,1 one are different and this always cause problems/bricks in the long run.

If you already have the secondary VSS store header corrupt, you almost certainly have other issues. I'm gonna send you a PM.

Thanks so much! Will work on getting you the info tonight.

 

[fredericorama]

Hello folks, @tsialex do you think that this kind of VSS store header corruption might be related to some PCIe boards to not be recognized by the system? I have a PCIe wifi board and a PCIe NVMe board that doens't even show up in the system profile. Cheers.

 

[tsialex]

Hello folks, @tsialex do you think that this kind of VSS store header corruption might be related to some PCIe boards to not be recognized by the system? I have a PCIe wifi board and a PCIe NVMe board that doens't even show up in the system profile. Cheers.

Not really, but everything is possible.

I'd check if the PCIe cards are really working with another UEFI PC/Mac Pro, if the hardware is really compatible with Mac Pros and etc - you have to do your all your basic homework before jumping so far ahead. There are lot's of reasons for a NVMe blade to not work with a Mac Pro, like not following the requirements of NVMe 1.3, using a non compatible macOS release, Mac Pro firmware being ancient, BootCamp, etc…

Anyway, it's relatively easy to confirm or disprove:

• dump your BootROM with ROMTool, save it securely since you will need to flash it back after
• flash 144.0.0.0.0 MP51.fd with ROMTool
• test with your PCIe cards.

 

[Bmju]

I looked a bit more. @zzzippp you're referring to https://dortania.github.io/OpenCore...ml#enabling-emulated-nvram-with-a-nvram-plist (same thing as in OC Configuration.pdf, ofc, but with quite a lot more detail) . From a bit of research so far, and trying to ask around, this is not the full NVRAM emulation solution it sounds like. This is mostly aimed at legacy BIOS Hackintoshes which are using OpenDuet (a UEFI firmware emulation layer than runs under legacy BIOS). I believe that it won't help with solving MacPro NVRAM write problems, because when there is a normal UEFI NVRAM runtime service (as there is on the MacPro), then nothing in this 'emulation' stops that from working. Any full-blown, non-volatile NVRAM writes made in-OS would still be full-blown, non-volatile NVRAM writes. If I've understood correctly, the NVRAM service provided by OpenDuet is always effectively volatile (even if apparently non-volatile; because there is no backing NVRAM), which is what makes this useful there.

As a considerably belated follow up to this discussion from back in April, emulated NVRAM is now available for all users of OpenCore (formerly it was only available as part of OpenDuet, the UEFI implementation provided with OpenCore for use on old legacy BIOS machines).

To get it, upgrade to OpenCore 0.8.3, then search for OpenVariableRuntimeDxe in the latest docs for set up instructions.

Hopefully this will prove to be another useful tool for avoiding wear on cMP NVRAM chips, given that macOS updates now hammer them so hard. With this driver running (and the associated launchd script installed) OTA updates go through fine, but all the NVRAM traffic happens in RAM instead.

 

[William4673]

As a considerably belated follow up to this discussion from back in April, emulated NVRAM is now available for all users of OpenCore (formerly it was only available as part of OpenDuet, the UEFI implementation provided with OpenCore for use on old legacy BIOS machines).

To get it, upgrade to OpenCore 0.8.3, then search for OpenVariableRuntimeDxe in the latest docs for set up instructions.

Hopefully this will prove to be another useful tool for avoiding wear on cMP NVRAM chips, given that macOS updates now hammer them so hard. With this driver running (and the associated launchd script installed) OTA updates go through fine, but all the NVRAM traffic happens in RAM instead.

Is there a guide included with the update, or has been this been posted and discussed elsewhere?

 

[Bmju]

Is there a guide included with the update, or has been this been posted and discussed elsewhere?

There is a guide in the docs (i.e. in Configuration.pdf): "search for OpenVariableRuntimeDxe in the latest docs for set up [and usage] instructions" - read the whole section.

Launchd.command also has built in usage instructions at the command line (run with no arguments), but you basically just need ./Launchd.command install, ./Launchd.command uninstall and ./Launchd.command status.

You may also want to examine the log of the script which saves NVRAM (i.e. the above script, once installed), it is located at /var/log/org.acidanthera.nvramhook.launchd/launchd.log.

The location and meaning of the saved files is also documented, search for nvram.plist in Configuration.pdf.

 

[AppaloosaMac]

I'm guessing this is not what I want to see?

 

[tsialex]

I'm guessing this is not what I want to see?

Nope, since your Mac Pro main VSS free space is now being recognized as padding, you probably have Windows SecureBoot UEFI signing or the circular log corrupted there - at least.

 

[AppaloosaMac]

In my research, I noted that Windows needs to be installed in Legacy, but apparently I did not succeed in doing so. Msinfo32.exe confirmed that it was in UEFI mode, so that drive it gone and the goal is to make this healthy and then do a fresh Windows install after making sure I know what I'm doing next time.

What do I need to do to fix this?

 

[trifero]

In my research, I noted that Windows needs to be installed in Legacy, but apparently I did not succeed in doing so. Msinfo32.exe confirmed that it was in UEFI mode, so that drive it gone and the goal is to make this healthy and then do a fresh Windows install after making sure I know what I'm doing next time.

What do I need to do to fix this?

Ask for a ROM to @tsialex

 

[AppaloosaMac]

Beleza. Valeu.
Sweet. Thanks.

(I hope this board doesn't have rules against foreign languages...)

Edit: It appears I cannot start a conversation yet.

 

[tsialex]

In my research, I noted that Windows needs to be installed in Legacy, but apparently I did not succeed in doing so. Msinfo32.exe confirmed that it was in UEFI mode, so that drive it gone and the goal is to make this healthy and then do a fresh Windows install after making sure I know what I'm doing next time.

What do I need to do to fix this?

Once you already have it as the screenshot shows there is a extremely high probability of problems elsewhere in the BootROM image, but a reconstruction service can solve it and you can re-flash anytime in the future if you have any SecureBoot or garbage collection problems.

For the UEFI Windows install, you can use OpenCore to protect your BootROM from the UEFI Windows SecureBoot signing or you can re-install Windows as a BootCamp/CSM install - after you flash your Mac Pro clean/upgraded/reconstructed BootROM image. I'm gonna send you a PM.

 

[trifero]

Once you already have it as the screenshot shows there is a extremely high probability of problems elsewhere in the BootROM image, but a reconstruction service can solve it and you can re-flash anytime in the future if you have any SecureBoot or garbage collection problems.

For the UEFI Windows install, you can use OpenCore to protect your BootROM from the UEFI Windows SecureBoot signing or you can re-install Windows as a BootCamp/CSM install - after you flash your Mac Pro clean/upgraded/reconstructed BootROM image. I'm gonna send you a PM.

I use Windows 10 in Legacy mode, no UEFI, since so many years. Works like a charm.

 

[AppaloosaMac]

I’ve looked into OpenCore a little and never found a straight forward clean “best practice”, so I opted to not mess with my functional machine. I also apparently didn’t find good directions on how to install Windows 10 in Legacy mode though; I made too many assumptions.

I’ll be looking into both next to determine how I configure my machine now that I’m starting over.

 

[tsialex]

I’ve looked into OpenCore a little and never found a straight forward clean “best practice”, so I opted to not mess with my functional machine. I also apparently didn’t find good directions on how to install Windows 10 in Legacy mode though; I made too many assumptions.

OpenCore only supports UEFI Windows installs, BootCamp/CSM installs are not supported. While BootCamp/CSM installs are preferred for a lot of people, UEFI Windows installs have several advantages, like NVMe support and the possibility of upgrading "easily" to Windows 11, obviously once you protect your BootROM with OpenCore.

You can workaround this OperCore limitation of only supporting UEFI Windows installs with chain loading, using rEFInd+ or MyBootMGR - but now with a clean/updated/reconstructed BootROM image you can use OpenCore to protect your Mac Pro from Windows SecureBoot.

I’ll be looking into both next to determine how I configure my machine now that I’m starting over.

Look at the OpenCore stickie thread here on the forum if you want a hands-on approach or go directly to OCLP if you want a point and click one.

I'm guessing this is not what I want to see?

I was right about the main VSS store missing free space being caused by Windows SecureBoot. The problems were double Windows UEFI SecureBoot signing and issues related to the cross-flashing process, including 20 MemoryConfigs for just 3 installed DIMMs.

Nope, since your Mac Pro main VSS free space is now being recognized as padding, you probably have Windows SecureBoot UEFI signing or the circular log corrupted there - at least.

 

[EdMun]

hi, I just acquired a base model 2012 5,1 and updated the firmware with Mojave installer, dumped the Rom from MX25L3205D (In my impatient muddling way I didn't reset or dump it before flashing)
First look it was sick but after a NVRAM reset looked OK and I assumed it was healed but model identity issues have me wondering.

after resetting NVRAM

 

[tsialex]

after resetting NVRAM
View attachment 2050003

This is not even possible, you dumped a completely empty NVRAM…

 

[EdMun]

I don't understand what's not possible or how I dumped an empty NVRAM I'm sorry.

 

[tsialex]

I don't understand what's not possible or how I dumped an empty NVRAM I'm sorry.

From the screenshots you sent, something is wrong, you shouldn't have a clean store on the second screenshot or just one with the first one.

I'm gonna send a PM with instructions on how correctly dump and everything that you need to get to validate the BootROM image.