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

[cdf]

I decided to use Martin Lo's package this time and for the life of me I cannot get it to work. After going thru the steps multiple times I get the same error when checking installed version and the BigSur installer says it cannot install on my target drive. I've tried running the installer from both the cloned target drive and the fresh Mojave install.

It seems that your Mac is not actually booting through OpenCore. Try blessing your EFI from Recovery as descried in the guide.

 

[kjay20]

It seems that your Mac is not actually booting through OpenCore. Try blessing your EFI from Recovery as descried in the guide.

I did follow @h9826790 instructions to the tee several times, performing several nvram resets, then disabling sip in recovery before moving onto Clover and the Bless script. Did not get any errors to suggest something didn't happen. I'll go back thru the regular guide and try it that way. Thank you for the reply.

 

[roobarb!]

My understanding is that in manual mode (Automatic=false), UpdateNVRAM=true applies the settings from PlatformNVRAM, as desired, and the undefined behavior is when UpdateNVRAM=true and the same settings are also added to the NVRAM section (possibly conflicting in value).

And this was the prod I needed to realise that UpdateNVRAM in my config.plist was still set to false, which was the reason I still received "does not support large BaseSystems" errors on attempting to update to RC1 and RC2. Previous OTA updates worked fine without the additional NVRAM firmware features tweaked, but with that switch flipped and SecureBootModel set to Default (showing J160AP as the Bridge in my case) all is well. VMM was disabled throughout.

My config.plists live here on GitHub, though they also contain Thunderbolt and Radeon VII tweaks that may not be relevant to others.

Only odd thing I noticed on this update; the APPLE directory on my EFI partition remains (but is not shown in OpenCore's default menu) containing UPDATERS/MULTIUPDATER. Though this is also the first OTA update I've done since swapping to MacPro7,1 board identifiers; I have no idea if that's related.

 

[Dayo]

My understanding is that in manual mode (Automatic=false), UpdateNVRAM=true applies the settings from PlatformNVRAM, as desired, and the undefined behavior is when UpdateNVRAM=true and the same settings are also added to the NVRAM section (possibly conflicting in value).

My understanding is that specifying FirmwareFeatures in PlatformNVRAM and setting UpdateNVRAM=true will not result in any extraneous settings.

Isn't the use of "PlatformNVRAM" linked to Automatic=true in the first place?

Anyway, separate from the undefined behaviour angle, is a wider item of the application of the minimalisation principles.

We have been taught by the legendary cdf to strictly only amend the "SMBIOS" section for light changes to our cMP, keep "Automatic" off, and to avoid the "Generic" and "PlatformNVRAM" sections like the plague.

Since defining the two items under "SMBIOS" is apparently not sufficient, these are then added to "NVRAM" (along with boot-args etc). The "PlatformNVRAM" and "UpdateNVRAM" sections, along with any reliance on any internal OC Automation/Magic, are thus skipped. Everything is manually/explicitly set.

For Monterey, there is a check for FirmwareFeatures bit 35.

Already added Bit 35 to the definition for the betas. I suppose the Bit could also be activated by setting "AdviseFeatures" but again preferred to explicitly set stuff needed (and only stuff needed) to avoid internal OC Automation/Magic.

There are, however, other options to consider:

Took care of the OTA/VMM/T2 angle as well. All needs further testing though.

 

[Dayo]

My understanding is that specifying FirmwareFeatures in PlatformNVRAM and setting UpdateNVRAM=true will not result in any extraneous settings.

Isn't the use of "PlatformNVRAM" linked to Automatic=true in the first place?

Got some clarification on this ...

UpdateNVRAM makes OC read the "PlatformNVRAM" section when Automatic=false and makes it read the "Generic" section when Automatic=true.

That is, the behaviour is defined in either case.

I suppose it is all down to the principle of wanting to only use "SMBIOS". I think this is better and more consistent with overall principles in play but yes, the outlined approach is perfectly fine ... as long as there is no unwanted/undesirable stuff under the PlatformNVRAM section. I believe the failsafes have all been aligned so most likely ok.

Sticking with setting them under "NVRAM" and only touching "SMBIOS" myself though ... as taught by cdf!

 

[GSXB]

It worked perfectly!! I add my config.plist for MacPro 4,1->5,1 just in case it could help someone here ( Martin's file modified with your guiding ). Thank you very much!!

Thanks for posting your modified config.plist, I’ve been trying all week to update with no joy I will try this and post results

 

[enervate]

Hi Everyone,

First up - what a great thread and a great group of contributors supporting each other. I've learnt so much over the last twelve months of casual reading. Well done and keep up the great work!

I'd love to ask for some help if possible.

My Setup:
Mac Pro 5.1
2x X5680
96GB
MSI Rx580 8GB (Slot 2)
3x Samsung 970 Evo Plus in a Highpoint SSD7103 (Slot 1) - Data
1x Samsung 970 Evo Plus in a single NVMe to PCI (Slot 4) - Opencore/OS
Big Sur 11.2.2
Martins Opencore 0.63

I recently installed Martins 0.74 with SurPlus, and upgraded to Big Sur 11.6 (which works a treat with just the single NVMe SSD installed in slot 4 for the OS), but no matter what I do, I can't get the system to boot if I have the Highpoint card installed (it just hangs on a black screen and monitor stays on power save after chime). I've tried a variety of things including combinations of SATA drives for OC, appropriate blessing etc), but no matter what, if I have the Highpoint 7103 installed, it just doesn't boot :-(

I feel like I'm missing something simple, but I'm stumped. Any ideas?

 

[babe-di-bupi]

Thank you for all the tips and updates!

BTW, running my Mac big sur 11.6 and waiting patiently for a stable app and compatible Monterey to upgrade.

In the meantime, I found this link:

Intel® Software Development Emulator

Learn more about the emulator, including a product overview, installation instructions, and instructions for running emulator tools and modes.

www.intel.com

And that got me wondering if there is there is any way to compile AVX emulators within Open Core for those who might need to run AVX programs ex:. for audio production; or even hardware such as the new Navi GPU?

It would be great adding this to the discussion!

 

[cdf]

Only odd thing I noticed on this update; the APPLE directory on my EFI partition remains (but is not shown in OpenCore's default menu) containing UPDATERS/MULTIUPDATER. Though this is also the first OTA update I've done since swapping to MacPro7,1 board identifiers; I have no idea if that's related.

The presence of this folder is normal for the MacPro7,1 board ID and secure boot model on this update. It indicates a firmware update, which was staged but blocked by OpenCore. With BlacklistAppleUpdate, OpenCore will ignore such boot entries.

I've verified that the staging of this firmware update, including the setting up of the related NVRAM variables, occurs whether or not BIOSVersion is spoofed to a high value. In fact, multiupdater handles peripheral firmware in general, so spoofing BIOSVersion is insufficient. Besides, given BlacklistAppleUpdate, this spoofing is really just a failsafe. A better failsafe seems to be the VMM flag (provided that the update is compatible with it, unlike the current release candidates of Monterey).

I suppose it is all down to the principle of wanting to only use "SMBIOS". I think this is better and more consistent with overall principles in play but yes, the outlined approach is perfectly fine ... as long as there is no unwanted/undesirable stuff under the PlatformNVRAM section. I believe the failsafes have all been aligned so most likely ok.

Sticking with setting them under "NVRAM" and only touching "SMBIOS" myself though

Leaving the fields empty in PlatformNVRAM will cause the corresponding variables to not be set. As a result, the original variables set by the firmware will remain intact. In keeping with minimization, there should be no difference whether FirmwareFeatures and FirmwareFeaturesMask are applied in NVRAM or PlatformNVRAM. What swayed my decision was the specification, which states: "Using PlatformInfo is the recommended way of setting these variables."

We have been taught by the legendary cdf to strictly only amend the "SMBIOS" section for light changes to our cMP, keep "Automatic" off, and to avoid the "Generic" and "PlatformNVRAM" sections like the plague.

... as taught by cdf!

Ha! Yes, avoid automatic mode on Macs at all costs. But PlatformNVRAM is actually for manual mode (Automatic=false), so everything should still be in our control, and the changes minimal, as explained above.

I suppose the Bit could also be activated by setting "AdviseFeatures" but again preferred to explicitly set stuff needed (and only stuff needed) to avoid internal OC Automation/Magic.

AdviseFeatures is just for automatic mode. However, a case could be made for AdviseFeatures in manual mode, because we really just want to add one bit to the existing FirmwareFeatures and FirmwareFeaturesMask; currently, to do this, we have to specify the entire variables with the extra bit.

 

[cdf]

I feel like I'm missing something simple, but I'm stumped. Any ideas?

Perhaps try the barebones sample config in the guide to rule out any particular setting. For this test, you'll have to add SurPlus manually or boot into macOS 11.2.3 or earlier.

 

[cdf]

I must be missing the finest of details as I cannot get that rc2 update to install I’ve added my config if you would be so kind to take a look

In platformNVRAM, before the closing </dict>, you have "</string" instead of "</string>". I'm not sure if this is the issue here. Also, for the update, it is enough to add FirmwareFeatures and FirmwareFeaturesMask to PlatformNVRAM.

 

[abaxworld]

Thanks for posting your modified config.plist, I’ve been trying all week to update with no joy I will try this and post results

It worked perfectly for me ( thanks @cdf again for your support ). I added FirmwareFeatures and FirmwareFeaturesMask both for PlatformInfo>PlatformNVRAM and PlatformInfo>SMBIOS but if it doesn't work for you, keep only the PlatformNVRAM options as @cdf says, although it should work with both modified. For me the next step now is to get the BlueTooth BCM_4350C2 to work again. Haven't found the right method until now.

 

[GSXB]

In platformNVRAM, before the closing </dict>, you have "</string" instead of "</string>". I'm not sure if this is the issue here. Also, for the update, it is enough to add FirmwareFeatures and FirmwareFeaturesMask to PlatformNVRAM.

ive been over the config with a fine tooth comb and made the amend you suggested to no avail it refuses to update to 12,0,1 RC 2 I'm stumped

 

[GSXB]

It worked perfectly for me ( thanks @cdf again for your support ). I added FirmwareFeatures and FirmwareFeaturesMask both for PlatformInfo>PlatformNVRAM and PlatformInfo>SMBIOS but if it doesn't work for you, keep only the PlatformNVRAM options as @cdf says, although it should work with both modified. For me the next step now is to get the BlueTooth BCM_4350C2 to work again. Haven't found the right method until now.

post up your config for comparison purposes please I've hit a brick wall

 

[abaxworld]

post up your config for comparison purposes please I've hit a brick wall

Here you are again in .zip format

 

[kjay20]

I did follow @h9826790 instructions to the tee several times, performing several nvram resets, then disabling sip in recovery before moving onto Clover and the Bless script. Did not get any errors to suggest something didn't happen. I'll go back thru the regular guide and try it that way. Thank you for the reply.

It seems that your Mac is not actually booting through OpenCore. Try blessing your EFI from Recovery as descried in the guide.

Removed all disks so only Disk A remained. Followed the instructions in post 1 on blessing the EFI. Everything seemed to work as expected. When I rebooted out of Recovery, computer was stuck in a 5 minute boot loop. Approx 5 min after boot chime, fans spin up, then 30 sec later, another boot chime. This kept occurring until I used the pwr button to shut down. Reinstalled Disk B and was able to boot into it.

config.plist is still h9826790's unmodified 7.4 version except for changing the exposesensitivedata value.

Suggestions for next steps? Thank you.

 

[kjay20]

Removed all disks so only Disk A remained. Followed the instructions in post 1 on blessing the EFI. Everything seemed to work as expected. When I rebooted out of Recovery, computer was stuck in a 5 minute boot loop. Approx 5 min after boot chime, fans spin up, then 30 sec later, another boot chime. This kept occurring until I used the pwr button to shut down. Reinstalled Disk B and was able to boot into it.

config.plist is still h9826790's unmodified 7.4 version except for changing the exposesensitivedata value.

Suggestions for next steps? Thank you.

I was able to get booted in and updated to BigSur. thank you all for the assistance and hard work.

 

[GSXB]

Here you are again in .zip format

Many thanks I will compare it to mine and post results later
Just to confirm this Is for 0,7,4?

 

[enervate]

Thanks cdf!

Used the sample config and added SurPlus which worked. I then added each part in the guide and its now working. Appreciate the help!

Perhaps try the barebones sample config in the guide to rule out any particular setting. For this test, you'll have to add SurPlus manually or boot into macOS 11.2.3 or earlier.

 

[GSXB]

Here you are again in .zip format

I swapped over to the config provided and I've booted back to the desktop no problems gonna download the 1.93 gb update and try again

 

[KernkraftX360]

I managed to use OCLP for MacPro3,1 with the latest version of 0.0.30. But I come to a blank screen during boot on the Mac Pro 3,1. When I tried to use Macbook Pro 2010, the Mac Pro ssd boots. Do I need to remove the BT card on the Mac Pro tower for it to work? Or what did I do wrong somehow? I did run the patch also. Cheers.

 

[paalb]

I managed to use OCLP for MacPro3,1 with the latest version of 0.0.30. But I come to a blank screen during boot on the Mac Pro 3,1. When I tried to use Macbook Pro 2010, the Mac Pro ssd boots. Do I need to remove the BT card on the Mac Pro tower for it to work? Or what did I do wrong somehow? I did run the patch also. Cheers.

There is a thread for OCLP: OCLP and other OpenCore Packages/Managers This thread is for those who follow the instructions on the first page here. You can also get support on Discord.

 

[TECK]

Monterey will be released this Monday, anything we need to look into before the upgrade?

 

[thoomp]

Hey everyone – Having a cMP 5,1 11.6 boot loop issue and could really use some help before the workweek.

I’m lucky to have two cMP 5,1 towers, one of which I leave at my folks’ place that’s 140 miles from home (for telecommuting/remote work purposes). Both cMPs are essentially twins of each other, but with different serial numbers and RAM amounts. My tower back home is now running 11.6 and is rock solid after Martin Lo’s OC 0.74 that incorporates SurPlus (just fantastic!). The drives in both cMP towers: Bay 1 is a 500GB Samsung SSD. Bay 2 is a 3TB HD with Mojave. On both cMPs, the OC boot screen shows up with both Big Sur and Mojave drives, plus the two respective recovery drives.

Anyhow, periodically I’ll use a stand-alone “bit-for-bit” hard SATA drive cloner, which has worked great to date and has saved my bacon on multiple occasions. This way, I can work at both locations and periodically update the remote computer with its twin and overwrite the remote drives with the updated versions. Also, this also gives me an off-site co-location backup whenever I visit.

However, this time – things aren’t going so well at the remote location here after writing over both the SSD and the 3TB drives. After cloning both drives as a periodic backup (it had been running just fine in 11.2.1), the remote cMP is stuck in the boot loop when trying to boot into 11.6. I can access the OC boot picker window without issue, and select 11.6. Then, it goes to the white apple with the progress bar…about 1/3 full before the screen goes blank and then the boot loop. Upon rebooting, and I choose the 11.6 partition, it goes into the boot loop with the error “Your computer restarted because of a problem (kernel panic?) black window” and then proceeds with the boot loop.

I’ve tried everything including the following, but same issue and no resolution:

* reset NVRAM 3x (if not more)
* reset SMC
* booting with just the 500GB SSD installed (no 3TB drive)
* trying an absolutely clean reinstall of 11.6 from the recovery drive
* Re-cloning the drive again
* Running the “Bless drive” app in Mojave, and then rebooting
* Reinstalling MLo's OC 0.74 on the SSD partition, and then running the "Bless drive" app in Mojave
* I’m aware that my NVRAM will at some point need replacement (a major project requiring motherboard soldering, but the fact that I can easily boot into 11.6 recovery or Mojave – I’m unclear if this is the problem right now
* I successfully booted into 11.6 recovery, but couldn’t disable SIP (“csrutil disable”). I get an error message: "failed to update system integrity configuration: failed to set csr-active-config"
* I do NOT want to try installing the original SSD and 3TB from the home location, in fear of somehow corrupting both (at least those will definitely work when I get home) as they’re my work Macs and have my vital backups.

Any thoughts appreciated, especially as I had planned to work for the week remotely using it. Thanks!

 

[cdf]

Monterey will be released this Monday, anything we need to look into before the upgrade?

Based on the release candidates:

1. Set SecureBootModel to Default
2. Under PlatformNVRAM:
   

   <key>FirmwareFeatures</key>
   <data>A1QMwAgAAAA=</data>
   <key>FirmwareFeaturesMask</key>
   <data>P/8f/wgAAAA=</data>

3. Set UpdateNVRAM to true

Also, make sure not to enable the VMM flag.

The promised revision to the guide is still under testing, so I've added the information to the current guide.