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

[TECK]

If you need it I can get it to you....

@tsialex can you send him a PM?

 

[johnwillsey]

I've just updated my machine to 144.0.0.0.0 today and backed up the rom with the romtool. If you need it I can get it to you....

That reminded me.. I picked up a MacPro 4,1 a few months that was in a closet for years.. was a prior server at a company and would not power up. I resurrected it, upgraded to 5,1 with 144.0.0.0.0 and backed up the rom while printing before and after trying OC for the first time. Likely had very little if any long term corruption as it was a server vs a workstation. I have that if that would help the cause.

 

[Jeekee]

Hi guys,

I am already running OC 0.5.9 and catalina without any problem. However, I am trying to run OC 0.6.3 from a usb just to see if it works. However, it is not using the usb and keeps using the OC on the HD.
Any suggestions what i am missing here?

cheers Jay

 

[TECK]

Remove the EFI from your HD and save it locally. Myself I'm always adding all these drivers to OC, even if I don't need them:

OcBinaryData/Drivers at master · acidanthera/OcBinaryData

Contribute to acidanthera/OcBinaryData development by creating an account on GitHub.

github.com

 

[Jeekee]

Remove the EFI from your HD and save it locally. Did you added the drivers so OC can see your USB?

Removing the efi from the hd kinda defeats the purpose of testing a new OC via USB. I know, it’s just as easy to do a normal upgrade but as I understand this should work as well without touching the original OC installation.
But I just copies the original OC EFI to the USB (ext journ with guid) and updated all files. So drivers should be there as well, unless its a seperate driver which isnt included in the standard OC install...

 

[TECK]

Removing the efi from the hd kinda defeats the purpose of testing a new OC via USB

If you boot into recovery, can you mount your USB drive and bless it? This should in theory suffice. I personally do not see the need of an USB drive, I can mount the disk and put whatever I like inside. If I don't like it, I boot into Mojave and restore any settings the way they were before.

 

[Jeekee]

If you boot into recovery, can you mount your USB drive and bless it? This should in theory suffice. I personally do not see the need of an USB drive, I can mount the disk and put whatever I like inside. If I don't like it, I boot into Mojave and restore any settings the way they were before.

You are absolutely right about booting into Mojave and restoring if necessary.
But thanks for the tips, blessing is no problem. Thought it wouldnt be necessary.
Thanks again!

 

[erll]

I had similar experiences, except I'm losing Bluetooth on random reboots. I'm using the @cdf setup with my plistlib generator, @tsialex showed me where are the issues and I hired him to rebuild my ROM, so I can flash it clean and fix all problems. I have a feeling you are in the same boat.

Edit: @tsialex noted the Bluetooth looks like is being a widespread issue.

View attachment 1669403

i seem to be having a similar issue, except rather than problems with bluetooth, it is problems with the WiFi card not being recognized... it's absolutely there and accessible in Mojave, but i can't turn it on in Catalina. not sure if it is due to the update to 10.15.7 or to OpenCore 0.6.3.

 

[TECK]

it is problems with the WiFi card not being recognized

Do an NVRAM reset (3 chimes) and re-bless the OC drive. You will have the Wifi working after one or two reboots. If I understood correctly from @tsialex, this is a clear sign your ROM is corrupted, which unfortunately it happens with 4,1 and 5,1 models. For models who had their 4,1 firmware ported to 5,1 it happens a lot faster, mines is a 2010 5,1.

I should have the new ROM built by tomorrow, so I will report back if my issues are fixed.

 

[erll]

Do an NVRAM reset (3 chimes) and re-bless the OC drive. You will have the Wifi working after one or two reboots. If I understood correctly from @tsialex, this is a clear sign your ROM is corrupted, which unfortunately it happens with 4,1 and 5,1 models. For models who had their 4,1 firmware ported to 5,1 it happens a lot faster, mines is a 2010 5,1.

I should have the new ROM built by tomorrow, so I will report back if my issues are fixed.

thanks for responding! will give this a try... my cMP is a 4,1 > 5,1 with hardware nearly identical to yours.

 

[tsialex]

Do an NVRAM reset (3 chimes) and re-bless the OC drive. You will have the Wifi working after one or two reboots. If I understood correctly from @tsialex, this is a clear sign your ROM is corrupted, which unfortunately it happens with 4,1 and 5,1 models. For models who had their 4,1 firmware ported to 5,1 it happens a lot faster, mines is a 2010 5,1.

I should have the new ROM built by tomorrow, so I will report back if my issues are fixed.

The configuration problem is exclusive for BT, and don't happen for Wi-Fi.

Differently from Bluetooth controllers, where your Mac Pro firmware have to initialise and configure it very early at the pre-boot time, or you won't have KB/mouse support, AirPort Extreme don't have hardware configuration inside the NVRAM, just credentials.

 

[erll]

The configuration problem is exclusive for BT, and don't happen for Wi-Fi.

Differently from Bluetooth controllers, where your Mac Pro firmware have to initialise and configure it very early at the pre-boot time, or you won't have KB/mouse support, AirPort Extreme don't have hardware configuration inside the NVRAM, just credentials.

thank you for your input! so, to be clear, are you saying that a corrupted ROM results in BT issues, but not WiFi issues? my cMP seems to connect to my BT headphones just fine, so BT seesm to be working appropriately...

 

[tsialex]

thank you for your input! so, to be clear, are you saying that a corrupted ROM results in BT issues, but not WiFi issues? my cMP seems to connect to my BT headphones just fine, so BT seesm to be working appropriately...

Like I wrote in my previous post, Wi-Fi is not configured by variables stored inside the NVRAM while Bluetooth is.

 

[erll]

Like I wrote in my previous post, Wi-Fi is not configured by variables stored inside the NVRAM while Bluetooth is.

please accept my apologies... i was not trying to be obtuse, so much as making sure i read your statement correctly. thank you for taking the time to verify!

 

[Stefano85]

Another huge step in getting BCM4322 to work in Catalina and Big Sur

GitHub - khronokernel/IO80211-Patches: Repo for patched IO80211Family Kexts

Repo for patched IO80211Family Kexts. Contribute to khronokernel/IO80211-Patches development by creating an account on GitHub.

github.com

Stock IO80211Family kext from Mojave already works in Catalina, but there were kernel panics when entering recovery because of collission with Catalina's version. Big Sur did not even boot as Big Sur's version is already preloaded in prelinked kernel and trying to inject Mojave version results in kernel panic too.

Patched IO80211Family kext above does not collide with system versions so original Broadcom card now works in Catalina's recovery and even in Big Sur without any system partition modifications!

            <dict>
                <key>Comment</key>
                <string></string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
                <key>Enabled</key>
                <true/>
                <key>MaxKernel</key>
                <string>20.99.99</string>
                <key>MinKernel</key>
                <string>19.0.0</string>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/IO80211Mojave</string>
                <key>Arch</key>
                <string>Any</string>
                <key>BundlePath</key>
                <string>IO80211Mojave.kext</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string></string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
                <key>Enabled</key>
                <true/>
                <key>MaxKernel</key>
                <string>20.99.99</string>
                <key>MinKernel</key>
                <string>19.0.0</string>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/AirPortBrcm4331</string>
                <key>Arch</key>
                <string>Any</string>
                <key>BundlePath</key>
                <string>IO80211Mojave.kext/Contents/PlugIns/AirPortBrcm4331.kext</string>
            </dict>

@cdf It might be a good idea to add this into the wiki post after more testing is done

Hi folks. I can confirm that works as expected on my 5,1 with stock wifi on Big Sur 11.0.1.
We are always more near to a perfect "vanilla" machine....
Thank you for keeping this thread updated with such great news

 

[c-3po]

OC stopped working when updating Mojave to the latest security update.

 

[h9826790]

OC stopped working when updating Mojave to the latest security update.

Which one, 18G6042?

I have that installed, and no issue.

 

[Dewdman42]

You are interpreting it that way but that is not what it says.
It says Software Update can only ignore updates that are eligible for installation

Software Update is a program/utility on your machine. It is the Software Update utility that has this restriction. If you roll back a few versions of Software Update, it will work fine but this means undoing some security updates.

Restrictions on ignoring major updates were introduced into Software Update in one of the recent security updates. That's what is probably behind your issue. I believe there is a way to delay things but that the ability to completely ignore was removed. (Always read the notes that go with the security updates. Can't recollect the details for Catalina as I use Mojave)

Check online for workaround.

You are really confusing me now. I already did check online for workarounds, which is what I tried to do that doesn't work. Do you know another work around that will work with OpenCore MP5,1 running Catalina?

They are removing the ability to ignore updates in Big Sur, it is supposedly just a warning in Catalina, but people can still do it...IF...their machine is eligible, which mine is apparently not.

So again... how can I remove that notification from my OC Catalina MP5,1? It appears to not be possible unless there is some OC hackery around it.

 

[TECK]

You are really confusing me now

What exactly are you trying to do?

 

[Dewdman42]

I have installed Catalina on OpenCore using CDF's instructions. Nothing else changed, exactly like his instructions. And it works fine. Except that the System Preferences Software Update module shows a big red badge on it that I need to update it...and opening it up, it shows that I need to update too BigSur..which I do not want to do. I do not know how to make that go away so that I don't have to look at it.

This shows up regardless of whether I have VMM enabled or disabled.

I google around and found the command line trick (see my earlier post)..which is supposed to tell software update to ignore that particular update..the BigSur one...however that command line trick doesn't work, it complains that my machine is not eligible...and there is some dispute here apparently about the exact meaning of that message, but regardless...it doesn't work..I cannot tell software update to ignore BigSur. Presumably if I had a newer mac...I would be able to...but with this OC MP5,1...no I can not tell software update to ignore BigSur.

Do you know a workaround?

 

[TECK]

Except that the System Preferences Software Update module shows a big red badge on it that I need to update it...and opening it up, it shows that I need to update too BigSur..which I do not want to do.

You mean this? (screen from my Mojave disk)

When you turn off VMM, it will stop the Catalina updates, but not Big Sur. To our big surprise, people started getting Big Sur update notifications, even when they had VMM off. So that is what we have on hand, for now.

Just curious, why do you not want to upgrade to Big Sur? In order to upgrade, you will need to apply the changes described in post #4,399 to your existing config.plist.

From my perspective, I use OC because I always want the latest OS with latest fixes. Before I used to use dosdude1 releases which did not offered updates.

 

[Dewdman42]

This is what I see now:

When you turn off VMM, it will stop the Catalina updates

I understand that much. I more or less thought even with VMM off, it doesn't block the notifications about Catalina updates, but if you try actually run the update, it will fail.

, but not Big Sur.

Well certainly its displaying the notification. I suspect that if I enable VMM, then I could theoretically run the BigSur updater and it would work. With VMM off, the notification is still displayed and running the updater would fail.

To our big surprise, people started getting Big Sur update notifications, even when they had VMM off. So that is what we have on hand, for now.

Right, which is why I was looking for a way to disable the notification. The above command line trick is what most people normally do, but in my case, it doesn't work, it complains about eligibility.

The irony is that with VMM disabled:

1. I can't run BigSur update (check)
2. I still see the notification
3. I can't run the command line tool to ignore the notification because machine not eligible to run it, so therefore it assumes I'm not eligible to ignore the notification either.

I already tried to enable VMM and try the command line trick, but same complaint...so VMM trick doesn't work to fake the software updater into ignoring BigSur notification.

Regarding your question about why not Big Sur....baby steps. I may get there eventually. I waited to go to Catalina until now for a reason, stability. I'm still not even 100% sure I will stick with this configuration, I'm just trying it out. It will be at least 6 months before I will consider moving this machine to BigSur...for a lot of reasons...not just whether or not OC can do it. I use a lot of audio software and stuff that as of now is not even compatible on BigSur and we are told by dozens of software makers to wait, as of now.

 

[startergo]

This is what I see now:

View attachment 1670037View attachment 1670038View attachment 1670039



I understand that much. I more or less thought even with VMM on, it doesn't block the notifications about Catalina updates, but if you try actually run the update, it will fail.



Well certainly its displaying the notification. I suspect that if I enable VMM, then I could theoretically run the BigSur updater and it would work. With VMM off, the notification is still displayed and running the updater would fail.



Right, which is why I was looking for a way to disable the notification. The above command line trick is what most people normally do, but in my case, it doesn't work, it complains about eligibility.

The irony is that with VMM disabled:

1. I can't run BigSur update (check)
2. I still see the notification
3. I can't run the command line tool to ignore the notification because machine not eligible to run it, so therefore it assumes I'm not eligible to ignore the notification either.

I already tried to enable VMM and try the command line trick, but same complaint...so VMM trick doesn't work to fake the software updater into ignoring BigSur notification.

Regarding your question about why not Big Sur....baby steps. I may get there eventually. I waited to go to Catalina until now for a reason, stability. I'm still not even 100% sure I will stick with this configuration, I'm just trying it out. It will be at least 6 months before I will consider moving this machine to BigSur...for a lot of reasons...not just whether or not OC can do it. I use a lot of audio software and stuff that as of now is not even compatible on BigSur and we are told by dozens of software makers to wait, as of now.

Disable SMBIOS spoofing.

 

[Dewdman42]

Disable SMBIOS spoofing.

from post#1, are you meaning this?:

<dict>
<key>BoardProduct</key>
<string>Mac-7BA5B2D9E42DDD94</string>
</dict>

I'm not sure why cdf put that in there...something about getting hardware acceleration to work 100%. So you're saying in order to avoid the red badge I would need to compromise hardware acceleration by this method?

 

[startergo]

from post#1, are you meaning this?:



I'm not sure why cdf put that in there...something about getting hardware acceleration to work 100%. So you're saying in order to avoid the red badge I would need to compromise hardware acceleration by this method?

Is this the only thing you inject in SMBIOS?