MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[JMP]

You may first use Macschrauber's ROM dump tool to check if EnableGOP is correctly flashed into the cMP.

If yes, then the XFX card is known to have firmware compatible issue on the 5,1. You may need to flash the graphic card as well in order to have a working GOP.

First of all, thank you for your response. Do you happen to have a link for that rom dump tool, I can't find it. The links I found all have the file deleted.

Thank you.

 

[JMP]

You may first use Macschrauber's ROM dump tool to check if EnableGOP is correctly flashed into the cMP.

If yes, then the XFX card is known to have firmware compatible issue on the 5,1. You may need to flash the graphic card as well in order to have a working GOP.

But isn't the whole point of this procedure NOT have to flash individual graphics cards at all?

PS: I found the Macschrauber's ROM directly from the link off his youtube channel. However, the RomDump application doesn't open. Instead I get an error message saying: "The application is damaged and can't be opened. You should eject the disk".

Should I try the EnableGopDirect version instead of EnableGop??

Thanks.

 

[JMP]

You may first use Macschrauber's ROM dump tool to check if EnableGOP is correctly flashed into the cMP.

If yes, then the XFX card is known to have firmware compatible issue on the 5,1. You may need to flash the graphic card as well in order to have a working GOP.

 

[h9826790]

But isn't the whole point of this procedure NOT have to flash individual graphics cards at all?

The idea is to provide boot screen on the cMP by using UEFI GOP. Most of the modern graphic cards have a working GOP from factory now, but some cards don’t. Therefore, you may still need to flash the card occasionally.

This especially likely required when buying used card. Because any modification to the VBIOS will basically disable the GOP. Therefore, if the previous owner modded the card’s VBIOS (e.g. for mining), then the GOP will be disabled, and a cMP user will need to flash the card with a factory ROM that has functional UEFI GOP in order to see the boot screen.

So, in the old days, we need to flash the card with a customised ROM. But nowadays, you may need to flash a factory ROM into the card.

Anyway, from your screen capture, EnableGop 1.4 is there. So, it should the card’s issue.

 

[JMP]

The idea is to provide boot screen on the cMP by using UEFI GOP. Most of the modern graphic cards have a working GOP from factory now, but some cards don’t. Therefore, you may still need to flash the card occasionally.

This especially likely required when buying used card. Because any modification to the VBIOS will basically disable the GOP. Therefore, if the previous owner modded the card’s VBIOS (e.g. for mining), then the GOP will be disabled, and a cMP user will need to flash the card with a factory ROM that has functional UEFI GOP in order to see the boot screen.

So, in the old days, we need to flash the card with a customised ROM. But nowadays, you may need to flash a factory ROM into the card.

Anyway, from your screen capture, EnableGop 1.4 is there. So, it should the card’s issue.

So I need to flash the card anyway... Bummer. I'll probably need a EPROM burner...

 

[h9826790]

So I need to flash the card anyway... Bummer. I'll probably need a EPROM burner...

No no no, you can simply use software flasher in Linux, Windows, or even DOS.

IMO, Linux is the best.

Anyway, if the discussion is about flash graphic cards, but not about OpenCore config anymore, we should move to another thread to continue the discussion.

 

[Macschrauber]

First of all, thank you for your response. Do you happen to have a link for that rom dump tool, I can't find it. The links I found all have the file deleted.

Thank you.

I have (temporarily) issues with Dropbox. Use the GMX Link and the unprotect Script until they are solved.

Solved by a timeout and encrypting the disk image. Password is rom.


The main post about the dumper is in my signature (to better update it).

 

[basslik]

Thanks in advance. I've upgraded before to Big Sur three years ago, and had to revert for a project I had to finish, and certain plugins weren't working, so I've done this before.

Anyhow I done something wrong.

I have OpenCore mounted on my slot 1 spinner ( MOJAVE )

Tried twice. I booted up on the spinner (Mojave), then I ran the Monterey installer on the NVME PCIe, and when I go through the install process, on reboot it gives me an error. A required firmware update could not be installed.

I first downloaded Ventura and quit the install and created a boot-able USB for the future. Then I installed Monterey and I also created a boot-able USB. I now noticed my previous firmware 144. was replaced by 9144.0.9.5

I'm trying to install Monterey.

Error. A required firmware update could not be installed.

Note, when it reboots Opencore tell me to select a drive, perhaps I'm not picking the right drive?

Maybe I have TO disable SIP again?

 

[h9826790]

Thanks in advance. I've upgraded before to Big Sur three years ago, and had to revert for a project I had to finish, and certain plugins weren't working, so I've done this before.

Anyhow I done something wrong.

I have OpenCore mounted on my slot 1 spinner ( MOJAVE )

Tried twice. I booted up on the spinner (Mojave), then I ran the Monterey installer on the NVME PCIe, and when I go through the install process, on reboot it gives me an error. A required firmware update could not be installed.

I first downloaded Ventura and quit the install and created a boot-able USB for the future. Then I installed Monterey and I also created a boot-able USB. I now noticed my previous firmware 144. was replaced by 9144.0.9.5

Error. A required firmware update could not be installed.
View attachment 2307346

Note, when it reboots Opencore tell me to select a drive, perhaps I'm not picking the right drive?
View attachment 2307349

Maybe I have TO disable SIP again?

Enable VMM, and disable SMBIOS spoofing.

If you keep SMBIOS spoofing, you may get that firmware update error.

 

[basslik]

Enable VMM, and disable SMBIOS spoofing.

If you keep SMBIOS spoofing, you may get that firmware update error.

That's in the kexts correct ?

I just used to to doing it the way you originally posted, so I must have got mixed up with the other way to mount the EFI from the new version way, and forgot to change the script. Thank you.

 

[h9826790]

That's in the kexts correct ?

I just used to to doing it the way you originally posted, so I must have got mixed up with the other way to mount the EFI from the new version way, and forgot to change the script. Thank you.

 

[basslik]

Thank you all, got it going. Truly appreciate what you folks do for us on keeping these beast of a machine chugging along.

I think I might have read somewhere (so much reading), it truly had me overwhelmed. Anyhow am I mistaken that there is a workaround to get the original Wi-Fi carding working or do I stall have to buy an updated Wi-Fi card ?

If not no biggie, I'll just buy a long Ethernet cable.

One more thing if I may. Now the I have Monterey installed on my NVMe. How do I get back to the Plist to change back the settings as recommended ?

It's no longer visible, unless I boot back into my spinner (MOJAVE)?

 

[sailmac]

So I need to flash the card anyway... Bummer. I'll probably need a EPROM burner...

I'm seeing this a few days after you posted it, so maybe you already have it sorted out, but if not then this tutorial may be useful in helping you flash your GPU with a factory VBIOS. It's a method for flashing the card directly on your cMP -- no PC or burner required.

https://forums.macrumors.com/threads/pre-opencore-gop-support-for-efi-era-imacs-and-mac-pros.2378942/post-32671327

 

[basslik]

Thank you. As well as everyone else.

I now have Monterey installed on a clean NVME, although how do I change back the Cpuid1mask & SMbios now that I'm booted in Monterey? Opencore is not mounted on the NVMe.

Opencore is on the spinner disk on Mojave.

Thanks.

 

[h9826790]

Thank you. As well as everyone else.

I now have Monterey installed on a clean NVME, although how do I change back the Cpuid1mask & SMbios now that I'm booted in Monterey? Opencore is not mounted on the NVMe.

Opencore is on the spinner disk on Mojave.

Thanks.

Same procedure.

OpenCore EFI folder and macOS are independent.

Even you put the OC EFI folder onto the Mojave drive, you can still mount it and mod it inside Monterey.

 

[tsialex]

OpenCore 0.9.6 was just released:

v0.9.6​

• Updated builtin firmware versions for SMBIOS and the rest
• Fixed hang while generating boot entries on some systems
• Added efidebug.tool support for 32-bit on 32-bit using GDB or LLDB
• Fixed potential incorrect values in kernel image capabilities calculation
• Added FixupAppleEfiImages quirk to allow booting Mac OS X 10.4 and 10.5 boot.efi images on modern secure image loaders

 

[cdf]

The guide has been updated to OpenCore version 0.9.6.

 

[PeterHolbrook]

There were no issues in my update to 0.9.6. Thanks to all those involved.

 

[basslik]

Same procedure.

OpenCore EFI folder and macOS are independent.

Even you put the OC EFI folder onto the Mojave drive, you can still mount it and mod it inside Monterey.

Cool, so I'm in Monterey and run opencore off the USB stick?

The reason I asked is when I went to boot back into Mojave on the spinner where I ran opencore and went to change it back, Cpuid1mask & SMbios, it showed it already reverted back to the original setting, unless I'm not looking at the right spot?

 

[1stCameLC]

Is the Bluetooth card on MacPro5,1 supposed to work in Monterey? I just see this in System Information:

  Bluetooth Controller:
  Address:    NULL
  State:    Off
  Chipset:    BCM_4350C2
  Discoverable:    Off
  Firmware Version:    v0 c0
  Product ID:    0x0001
  Supported Devices:    0x382039 < HFP AVRCP A2DP HID Braille AACP GATT Serial >
  Transport:    USB
  Vendor ID:    0x004C (Apple)

 

[borgo1971]

Hi. In my case I just upgraded from BigSur 11.7.10 to Monterey 12.7.1, using Monterey installer from may Application folder. All went fine, but after the upgrade was done (I didn't watch it while upgrading), I noticed that my MacPro needs much more time to boot. OC Picker appears normally (after 12-13 sec.), but after selecting Monterey volume for boot, progress bar increases normally until about 1/3, and then becomes terrible slow… it needs about 4’45” to arrive to 1/2. After that, Apple logo and progress bar disappears replaced for some seconds from an all-black screen and then from login window, after which all seems to work flawless.

With BigSur, for which I reserved an APFS container in the same drive (nVme Samsung SSD 970 EVO PLUS), boot time after selecting to boot with it in OC Picker is about 1 minute. So Monterey needs about 5 times the time used by BigSur. Once booted up, Monterey 12.7.1 seems to work very well, and disk performance seems also as good as they are with BigSur (measured with BlackMagic Disk Speed Test).

To troubleshoot the issue, I upgraded OpenCore from 0.91 to 0.96 editing config.plist from scratch, and I made some verbose boots, hoping to see one step that need particularly long time, but I found that many steps need much time. I toke some picture from all steps that toke more then 10” (some of them toke even 30”), bath I noticed even many other steps that toke between 5” and 10”, and all together brings boot time to about 5 minutes.

Can someone help me to troubleshoot this issue? I attach the pictures I toke during last verbose boot and OC config file.

 

[cdf]

Can someone help me to troubleshoot this issue?

Some ideas:

• FirmwareFeatures and FirmwareFeaturesMask should be added to PlatformNVRAM not SMBIOS. This misconfiguration prevents using the vanilla installation method, so you have to resort to the VMM flag. Also note that a mix of installation methods 1 and 2 (see post #1) can result in a faulty installation.
• Make sure that all kexts are updated to the latest versions.
• Try disabling AVXpel.
• If possible, try disabling audio assist. AudioDxe can cause a delays (though that should really only affect the OC boot picker).
• Concurrent APFS installations (Big Sur and Monterey) have proven to be problematic (updates should be fine, though).
• Some hardware component may be at fault.

 

[borgo1971]

Some ideas:

• FirmwareFeatures and FirmwareFeaturesMask should be added to PlatformNVRAM not SMBIOS. This misconfiguration prevents using the vanilla installation method, so you have to resort to the VMM flag. Also note that a mix of installation methods 1 and 2 (see post #1) can result in a faulty installation.

OK, this was an oversight. But in OC 0.91 config.plist, FirmwareFeatures and FirmwareFeaturesMask were correctly added to PlatformNVRAM, and and startup times was anyway insanely long with Monterey.

• Make sure that all kexts are updated to the latest versions.

Yes, when I decided to try to upgrade OC too (hoping it patches the issue), I downloaded all components from scratch.

• Try disabling AVXpel.
• If possible, try disabling audio assist. AudioDxe can cause a delays (though that should really only affect the OC boot picker).
• Concurrent APFS installations (Big Sur and Monterey) have proven to be problematic (updates should be fine, though).
• Some hardware component may be at fault.

Maybe one of the above suggestions also has to do with long startup times, but I've found that the issue will magically disappear by setting SetApfsTrimTimeout to 0. With SetApfsTrimTimeout 0, startup from OC picker is much faster, even compared what it was with BigSur (and I guess with Catalina, as I don't remember huge difference with BigSur). Now my MacPro, from click on Monterey container in Boot Picker to loginwindow needs only 25 seconds. That's less then half the time it used with BigSur and previous configuration!
But this raises a question in my mind: why is 9999999 recommended in the OpenCore instructions? Using 0 for SetApfsTrimTimeout, can it cause any problems?

 

[borgo1971]

But this raises a question in my mind: why is 9999999 recommended in the OpenCore instructions? Using 0 for SetApfsTrimTimeout, can it cause any problems?

From OpenCore Manual:

7.8 Quirks Properties​

21. SetApfsTrimTimeout
Type: plist integer
Failsafe: -1
Requirement: 10.14 (not required for older)
Description: Set trim timeout in microseconds for APFS filesystems on SSDs.
The APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.
Depending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.
On several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.
One way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Setting this option to a high value, such as 4294967295 ensures that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be mostly disabled by setting a very low timeout value, while 0 entirely disables it. Refer to this article for details.
Note: The failsafe value -1 indicates that this patch will not be applied, such that apfs.kext will remain untouched.
Note 2: On macOS 12.0 and above, it is no longer possible to specify trim timeout. However, trim can be disabled by setting 0.
Note 3: Trim operations are only affected at booting phase when the startup volume is mounted. Either specifying timeout, or completely disabling trim with 0, will not affect normal macOS running.

seems safe... 😃

 

[cdf]

But this raises a question in my mind: why is 9999999 recommended in the OpenCore instructions?

The sample config sets it to 0, and the guide (see Basic setup>Overview of basic settings) mentions this:

Use Mac value (9.999999 seconds) unless boot times become too long (experiment)

To clarify: 9999999 is the value Apple uses. So in keeping with the guide’s theme of minimal deviation from Apple, that’s the “desired” value. However, using this value isn’t always possible. Note that the only other effective value post-Monterey is 0 (trim disabled).