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

[Dewdman42]

I have done something similar to toggle things in the plist. (RequestVarRouting, VMM, GOP)
But I noticed that plutil sadly does not keep the plists key order. (probably sorts them alphabetically)
Do you think that might be a problem? (I guess not, but not sure)

Btw if such commands are kept simple and low-level
you can add them to /Volumes/EFI to be able to use them from recovery as well (eg. /Volumes/EFI/ocToggle)
also copying /usr/bin/nano to Volumes/EFI works fine to do manual edits from recovery
I had no problems so far with those commands being there.

plutil and plist buddy each appear to have pros and cons. Plutil is better for creating the hex data entries. Plist buddy is better for creating dict entries.

the key ordering you are taking about is not really important. I assume you mean, for example, the keys within a dict.

EDIT: I think the ordering could be more important perhaps in some cases for some arrays.

for day to day admin I think it makes more sense to keep a couple of premade config.plist in your efi that you can swap in and out rather then dynamically editing but I like to keep things simple

 

[Dayo]

I noticed that plutil sadly does not keep the plists key order. (probably sorts them alphabetically)

The key order is not particularly important and the config file actually used to flip between alphabetical and not, depending on which of the developers was the last to make an edit as some used an alphabetical order and some did not:

Docs: Updeted Samples and ABC sorting · acidanthera/OpenCorePkg@1b46dfc

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

The example config in Post 1 may have just been started when one of the "non-alphabeticals" was the last to edit things.

The "non-alphabeticals" have also driven the documentation order but from looking at stuff since the linked commit, I believe they have now settled on an alphabetical order for the config files.

 

[austinhealey175]

Thanks everyone for your awesomeness. I think it's pretty hilarious that my 2012 cMP is still chugging on -- now with Catalina, FCPX, Adobe CC. It's all working perfectly and I'm keen now to get Win 10 on it. It'll actually be better than ever.

I would point out that if anyone is having sleep issues, remember to disable the VMM as instructed in Part I/Basic Installation. The way that's worded I thought I didn't need to since I'm on a Westmere processor and had assumed that it's only necessary to shut it off for older generations... which after testing isn't the case for my 3.3 single processor. My Mac wasn't waking from sleep with it enabled, but with it disabled it sleeps w/ the pulsing light and has woken fine thus far. If that's the case I'd perhaps re-word the last sentence in the paragraph to reflect the power management is disabled for all processors?

"Adding the VMM flag to the CPUID is what enables Software Update and the installation of macOS Catalina. On a classic Mac Pro, adding this flag is only possible with a Westmere processor architecture. Older generations like Nehalem lack the necessary Apple Hypervisor support. Because the VMM flag causes a performance loss (about 5%) and disables power management, it is a good idea to only have the flag ON when installing macOS or checking for updates."

 

[cdf]

I'd perhaps re-word the last sentence in the paragraph to reflect the power management is disabled for all processors?

Done. Although perhaps more clarification is needed regarding the Hypervisor requirement: it is apparently possible to set the flag on some processors that don't support the Hypervisor feature. @Dayo have you come to any conclusions regarding this?

 

[Dayo]

Have you come to any conclusions regarding this?

Yes ... Unless Apple changes the distribution script used for updates down the line, Hypervisor capability is not required for VMM Spoofing to work for native updates in OpenCore as the distribution script only checks whether the Mac says it is a Virtual Machine and proceeds if it does .

It does not attempt any vetting of such claims. As a result, once you switch VMM flag on, the updates roll through.

On a classic Mac Pro, adding this flag is only possible with a Westmere processor architecture. Older generations like Nehalem lack the necessary Apple Hypervisor support.

That was what was thought to be the case. However, native updates via OpenCore using VMM Spoofing works on every Mac supported by OpenCore. If will also work if you could run OpenCore on a cMP1,1.

Actually, if Apple did any sort of confirmation, it would NOT have worked for this purpose on a cMP5,1 either since a VMM is not actually in use and if Apple does change things down the line, native updates will be broken for all ... Westmere or any other. Westmere CPU is basically not a factor.

Caveat on the last statement is that this is specifically referring to the Native Software Updates via OpenCore. Running an actual VMM requiring Hypervisor needs the Westmere.

 

[cdf]

Hypervisor capability is not required for VMM Spoofing to work for native updates in OpenCore as the distribution script only checks whether the Mac says it is a Virtual Machine and proceeds if it does .

It does not attempt any vetting of such claims. As a result, once you switch VMM flag on, the updates roll through.

Right. Originally the issue was that the VMM flag, despite being set in OpenCore, was not seen by macOS. This was reported on machines with processors lacking Hypervisor support. But Hypervisor support might not have been the problem to begin with, or perhaps things have changed in macOS... I will update the guide.

 

[startergo]

Right. Originally the issue was that the VMM flag, despite being set in OpenCore, was not seen by macOS. This was reported on machines with processors lacking Hypervisor support. But Hypervisor support might not have been the problem to begin with, or perhaps things have changed in macOS... I will update the guide.

Right, and the VMM flag if needed for Catalina is not needed for Big Sur. Just updated with board-id spoofing to macOS 11.2 (20D53).

 

[cdf]

Right, and the VMM flag if needed for Catalina is not needed for Big Sur. Just updated with board-id spoofing to macOS 11.2 (20D53).

Nice. I was waiting for the public release of 11.2 to confirm this myself. This is great for Big Sur.

 

[h9826790]

Right, and the VMM flag if needed for Catalina is not needed for Big Sur. Just updated with board-id spoofing to macOS 11.2 (20D53).

You mean no FirmwareFeatures and FirmwareFeaturesMask injection. But just board ID spoofing without VMM?

 

[startergo]

You mean no FirmwareFeatures and FirmwareFeaturesMask injection. But just board ID spoofing without VMM?

No those are still injected:

But also there is a problem with the bluetooth. It is not working. Back in Catalina it works.

 

[h9826790]

No those are still injected:
View attachment 1718694

But also there is a problem with the bluetooth. It is not working. Back in Catalina it works.

It's the FirmwareFeatures and FirmwareFeaturesMask injection alleviate the requirement of VMM, not the board ID injection.

 

[startergo]

It's the FirmwareFeatures and FirmwareFeaturesMask injection alleviate the requirement of VMM, not the board ID injection.

I mention board id due to previous corruption with the latest Catalina security update. Since that update also upgraded the firmware on most supported machines it broke the partition on the cMP. When I get brave enough I may try it again with 9999.0.0.0.0

 

[h9826790]

But also there is a problem with the bluetooth. It is not working. Back in Catalina it works.

For BT, you have no way to make it work in Big Sur?

e.g.
1) warm reboot (may need a few times)
2) inject BrcmBluetoothInjector.kext, BrcmFirmwareData.kext, and BrcmPatchRAM3.kext
3) NVRAM reset
4) re-flash a reconstructed clean ROM to the cMP

Anyway, my BT usually works fine so far (in Big Sur). But on the first few days I use Big Sur, it may stop working after some cold boot. BT icon shows normal on the menu bar, but no actual BT connection can be made.

On one occasion, I was busing on the phone, so delayed the reboot. And after a few minutes (may be something like 5-10min), the BT suddenly start working again (without any user input).

 

[zzzachi]

just to mention...
It would be nice to have separate threads and guides for Catalina and Big Sur in the future.
this thead here is already a bit confusing about this, now.
🙃

 

[cdf]

just to mention...
It would be nice to have separate threads and guides for Catalina and Big Sur in the future.
this thead here is already a bit confusing about this, now.
🙃

Actually, the basic installation methods for both Catalina and Big Sur are similar enough to maintain the same guide. Note that Big Sur specifics will be detailed in the next update.

 

[EddieK420]

I mention board id due to previous corruption with the latest Catalina security update. Since that update also upgraded the firmware on most supported machines it broke the partition on the cMP. When I get brave enough I may try it again with 9999.0.0.0.0

@startergo are you talking about a Catalina security update on our MacPros 5,1 that corrupts the firmware? Where can I read more about this.

I did all the security updates on my MacPro 5,1 with Catalina 10.15.7 and it is working normally. How can you tell the firmware is corrupted? Thank you.

 

[Randalf]

If you're doing the SMBIOS spoofing to get hardware acceleration then those quad core Xeons will show up as i3 - it won't affect anything as far as usability. Your best course is to replace those with the newer Westmere based Xeons.

There is a kext you can add that will put WiFi support back in. Big Sur is possible, but all the kinks aren't worked out yet - but it sounds like an update with instructions for Big Sur is coming towards the start of February.

Thank you for your answer. Can you point me to the needed wifi kest?

 

[startergo]

@startergo are you talking about a Catalina security update on our MacPros 5,1 that corrupts the firmware? Where can I read more about this.

I did all the security updates on my MacPro 5,1 with Catalina 10.15.7 and it is working normally. How can you tell the firmware is corrupted? Thank you.

Not the firmware it corrupted the partition. But if you used the VMM flag it will not affect you.

 

[MaSaLaBa]

There is. Install Catalina.

Why? If you already have OC installed on your EFI partition, just create a regular, non-patched copy of Catalina installer using an USB flash drive and
sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/USBFLASH


I'm afraid this will not render a vanilla installer. Use an Apple-provided method mentioned above.

Thanks so much for the answer,

Of course, that is so obvious! ;-) All these tutorials that show how to install Mojave first got me totally confused. Thanks for the clarification. Ive just made a USB installer.

There is still one thing that is not clear to me. In most tutorials it is demonstrated that Open Core comes on the EFI of the boot drive.

Can I also put Open Core on the EFI of an internal data SSD instead of the EFI of my boot drive?

Indexing the SSD during the boot process is usually faster than the NVME drive I have my system running on.


Thanks for the help.

 

[cdf]

Can I also put Open Core on the EFI of an internal data SSD instead of the EFI of my boot drive?

Yes, any EFI partition will do.

 

[startergo]

For BT, you have no way to make it work in Big Sur?

e.g.
1) warm reboot (may need a few times)
2) inject BrcmBluetoothInjector.kext, BrcmFirmwareData.kext, and BrcmPatchRAM3.kext
3) NVRAM reset
4) re-flash a reconstructed clean ROM to the cMP

Anyway, my BT usually works fine so far (in Big Sur). But on the first few days I use Big Sur, it may stop working after some cold boot. BT icon shows normal on the menu bar, but no actual BT connection can be made.

On one occasion, I was busing on the phone, so delayed the reboot. And after a few minutes (may be something like 5-10min), the BT suddenly start working again (without any user input).

BT started working. I did several NVRAM resets, but don't know if that is what fixed it.

 

[Dewdman42]

I mention board id due to previous corruption with the latest Catalina security update. Since that update also upgraded the firmware on most supported machines it broke the partition on the cMP. When I get brave enough I may try it again with 9999.0.0.0.0

i had the corruption too. Just FYI, I was using a patched standalone security updater; I thought maybe you were too? In any case I did the procedure of reinstalling Catalina via cdf’s guide and restoring from time machine backup before doing cdf’s advanced settings.

During all of that the security update was applied in some way and I did not have to spoof the firmware at all.

my take away is the best way to keep Catalina updated is to turn on VMM and turn off the UpdateSMBIOS flag while using normal apple software update. Those were the settings when Catalina updated itself for me the normal way and apple security update without any problems.

as I understand it, the firmware updates do low level stuff to make sure that the wrong firmware won’t be installed or corrupted, but it’s possible that security updater assumed a failure when the firmware couldn’t be applied and then exited very ungracefully, leaving behind a broken file system. Just guessing...

 

[zzzachi]

Of course, that is so obvious! ;-) All these tutorials that show how to install Mojave first got me totally confused. Thanks for the clarification. Ive just made a USB installer.

a mojave is not mandatory, but keep in mind:
it is highly! advised to have one drive with mojave installed, so that you can boot something when you get in trouble!
with an opencore setup without that, you will sooner or later end up with a black screen and no solution.
in the dvd drive cage is a spare plug where you can add a ($30) 120gb ssd with mojave for safety.

 

[hwojtek]

with an opencore setup without that, you will sooner or later end up with a black screen and no solution.

Could you elaborate on "sooner or later end ups with a black screen and no solution"? This is totally untrue.

 

[zzzachi]

Could you elaborate on "sooner or later end ups with a black screen and no solution"? This is totally untrue.

well, only one small inattention (eg. some error in your config) and your machine will not boot anymore.
happens easily when experimenting and getting to know opencore. in this case you must the remove the catalina (or big sur) disk and the disk containing the opencore efi partition. if you dont have a bootable safety disk left, you can insert a dvd and reinstall a system. good luck with that if you have a GPU not showing anything before the login 😑
mojave is the system that can boot both opencore and non-opencore. i wouldnt recommend older systems for safety.