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

[zzzachi]

@richardjhurst :
as long as your present system disk with the botched OC is in your mac, you wont be able to boot. you need a mojave installer on an usb disk and a different hd / ssd attached where you can install mojave on. re-install mojave, shut down, re-attach your catalina disk, then fix the OC config.plist

 

[richardjhurst]

@richardjhurst :
as long as your present system disk with the botched OC is in your mac, you wont be able to boot. you need a mojave installer on an usb disk and a different hd / ssd attached where you can install mojave on. re-install mojave, shut down, re-attach your catalina disk, then fix the OC config.plist

Thank you. I am just creating a Mojave installer on usb now in my work. And in the Mac 5.1 I have a few HD drives, I could use one of those to install Mojave on. The one thing I do not have any idea how to do is then fix the OC config.plist

 

[zzzachi]

@richardjhurst : check your PM mailbox

 

[richardjhurst]

@richardjhurst : check your PM mailbox

Thank you, just replied to you.

 

[richardjhurst]

Add details to signature.

So why disregard the instructions?

Anyway, what's your backup strategy? Don't you have a spare bootable disk?

You need to get your hands on a spare bootable disk, boot into this and fix the situation.

You should have taken my earlier advice.

Hi Dave
Yes I have made some major newbie Fu*k up's right now. I am just creating a bootable Mojave USB at work on the computer and then taking that home. In my 5.1 I had some back up HDD's so I can just use one of those to load Mojave on and then hopefully if I put the original SSD back in someone can guide me to as what to do with it

 

[Dayo]

someone can guide me to as what to do with it

Once you get a version of Mojave up and running, delete your current broken OC Setup from the Catalina disk and use MyBootMgr to set things up. It will enable the WIFI patch automatically.

 

[svavaroe]

I've been using OpenCore on my mid 2010 Mac Pro 5,1 for a few months now based on the information from this and a couple of other forums. I recently updated to OpenCore 0.6.6 and to Big Sur 11.2 from Catalina. And this evening did an OTA update to 11.2.1. Everything appears to be running fine. However I just checked in the system report and my System Firmware Version is now listed as 9144.0.6.6.0. Is this a bug or a feature? Should I be happy or panicking?

probably because you have PlatformInfo -> SMBIOS -> BIOSVersion configured.
After I updated to OC 0.6.6 and configured BIOSVersion as : 9999.0.0.0.0
I have Boot ROM Version 9999.0.0.0.0 under System Information.App.
Just cosmetic.

 

[anarchi]

probably because you have PlatformInfo -> SMBIOS -> BIOSVersion configured.
After I updated to OC 0.6.6 and configured BIOSVersion as : 9999.0.0.0.0
I have Boot ROM Version 9999.0.0.0.0 under System Information.App.
Just cosmetic.

Ah yes, you're quite right. It's in the config I downloaded and used as the base for my OC. Yet another example of the many things I know nothing about.

Thanks

 

[h9826790]

For info, since cdf discovered the FirmwearFeature and FirmwareFeatureMask. I always keep the VMM flag off. And I can install / update all versions of Big Sur (including betas) like native.

For those who don't like unnecessary spoofing for daily use, them may remove that part (but keep the board id injection for HWAccel). And only inject the FirmwearFeature on the day that perform masOS update.

But in my own experience, I can't see any adverse effect to keep the FirmwearFeature at there. So, I believe keep it there is the easiest way to run Big Sur on cMP.

On the other hand, due to VMM will infringe the CPU power management. So, I will consider that's the backup means to gain Big Sur support. And try not to touch it unless absolutely necessary.

 

[startergo]

For info, since cdf discovered the FirmwearFeature and FirmwareFeatureMask. I always keep the VMM flag off. And I can install / update all versions of Big Sur (including betas) like native.View attachment 1727984

For those who don't like unnecessary spoofing for daily use, them may remove that part (but keep the board id injection for HWAccel). And only inject the FirmwearFeature on the day that perform masOS update.

But in my own experience, I can't see any adverse effect to keep the FirmwearFeature at there. So, I believe keep it there is the easiest way to run Big Sur on cMP.

On the other hand, due to VMM will infringe the CPU power management. So, I will consider that's the backup means to gain Big Sur support. And try not to touch it unless absolutely necessary.

VMM is ON by default so nobody pays attention and leave it ON.

 

[cdf]

VMM is ON by default so nobody pays attention and leave it ON.

That will change with the next update.

 

[h9826790]

VMM is ON by default so nobody pays attention and leave it ON.

cdf's default config is aim for making the cMP can run Catalina and newer macOS. It make sense to keep the VMM on by default.

My package's primary goal is to provide HWAccel. That's why I keep VMM off, but provide another short video to illustrate how to turn on VMM (if the user want to install Catalina).

It's really hard for cdf to provide a single config that works perfectly in both Catalina and Big Sur. And as you said, not many people pay attention no matter how clear we write in the tutorial / guide / wiki / post / reply...

That will change with the next update.

I think it's really hard for you to make a single config that fits everyone.

May be you have to make two configs, one of Catalina which has VMM on. So that even some people haven't read through the wiki, can still install / update Catalina with that config. But just lost Intel TurboBoost.

And for those who just want to run Big Sur, you can give them a config which has VMM off. So that they don't need to touch it at all.

Another suggestion, you may actually use the BIOS version to help yourself to distinguish the two different config.

e.g.

9999.0.0.0.0 is for Catalina which has VMM default on.

and

9999.0.0.0.1 is for Big Sur which has VVM default off.

I am now also using this to help me to identify that people running which config / package.

e.g. My latest package has BIOS version 9144.0.6.6.0.

If there is another update I must made before 0.6.7 release. Then I will change the version to 9144.0.6.6.1.

Therefore, when people asking questions. I can use their BIOS version to know which config they are using.

 

[cdf]

Regarding SMBIOS properties: There are five properties that don't failsafe to machine values. These are

1. PlatformFeature
2. SmcVersion
3. FirmwareFeatures
4. FirmwareFeaturesMask
5. ProcessorType

We have mostly ignored these without trouble, but setting FirmwareFeatures and FirmwareFeaturesMask can have an effect in Big Sur. I wonder if we should be setting the others...

 

[startergo]

9999.0.0.0.1

My latest package has BIOS version 9144.0.6.6.0

What is the reason for these can you please elaborate?

 

[startergo]

1. FirmwareFeatures
2. FirmwareFeaturesMask

Why don't you put those in the misc NVRAM section? They seem to apply globally there in comparison to the SMBIOS section?

 

[cdf]

Why don't you put those in the misc NVRAM section? They seem to apply globally there in comparison to the SMBIOS section?

Well, setting them in the SMBIOS section is what has had an effect when installing Big Sur from Catalina... Can we confirm their global application when set in the NVRAM section?

 

[startergo]

Well, setting them in the SMBIOS section is what has had an effect when installing Big Sur from Catalina... Can we confirm their global application when set in the NVRAM section?

OpenCore on the Mac Pro

I just realized this only affects the variable in that NVRAM GUID, but it does not apply globally: sudo bless --setBoot --folder /Volumes/CAT1/System/Library/CoreServices --file /Volumes/CAT1/System/Library/CoreServices/boot.efi --verbose Password: EFI found at IODeviceTree:/efi Mount point for...

forums.macrumors.com

 

[Bmju]

Regarding SMBIOS properties: There are five properties that don't failsafe to machine values. These are

1. PlatformFeature
2. SmcVersion
3. FirmwareFeatures
4. FirmwareFeaturesMask
5. ProcessorType

We have mostly ignored these without trouble, but setting FirmwareFeatures and FirmwareFeaturesMask can have an effect in Big Sur. I wonder if we should be setting the others...

ProcessorType of 0 autodetects the existing processor - i.e. does failsafe to the machine default. I've used it and looked at the code. I used the PlatformInfo/Generic version but from what I know, I do believe that it works in the same way as the SMBIOS version of the same setting - and Configuration.pdf appears to confirm this.

 

[chrisrm9208]

The question is can you boot OS installed on an HFS+ drive using OC?

Turns out you can; I just put a USB SSD together for BS re-installation using HFS and the text BootPicker saw it and booted from it.

 

[cdf]

OpenCore on the Mac Pro

I just realized this only affects the variable in that NVRAM GUID, but it does not apply globally: sudo bless --setBoot --folder /Volumes/CAT1/System/Library/CoreServices --file /Volumes/CAT1/System/Library/CoreServices/boot.efi --verbose Password: EFI found at IODeviceTree:/efi Mount point for...

forums.macrumors.com

Actually, take a look at the two outputs of the NVRAM variable in that post. The first is A1QMwA== (not A1QM4A==) , so both the NVRAM variable and the bless verbosity do not at all reflect the change in the SMBIOS section.

ProcessorType of 0 autodetects the existing processor value - i.e. does failsafe to the machine default - I believe.

Yes, I suppose it gets the right value that way.

 

[startergo]

so both the NVRAM variable and the bless verbosity do not at all reflect the change in the SMBIOS section.

That is what I said. The value set as A1QM4A== in the SMBIOS does not apply globally. What is the result of your bless output?

 

[Dayo]

Yes, I suppose it gets the right value that way.

Not sure if this has been fixed in the interim as I have been inputting my value since v0.5.6 or so, but setting to zero used to give incorrect/incomplete info on some units. At least cosmetically in "About This Mac".

 

[cdf]

That is what I said. The value set as A1QM4A== in the SMBIOS does not apply globally.

Right. I can repeat the experiment with the same result.

The firmware features are not being set globally via the SMBIOS, but when setting them through the NVRAM, despite being able to retrieve them as NVRAM variables and seeing them in the bless command, they are not necessarily being set globally either. We know that setting them via the SMBIOS has an effect, though.

 

[Bmju]

Not sure if this has been fixed in the interim as I have been inputting my value since v0.5.6 or so, but setting to zero used to give incorrect/incomplete info on some units. At least cosmetically in "About This Mac".

If you still have the same Mac it would be interesting to confirm if 0.6.6 still does give wrong info now with a 0 value, if you had the time to check? (From my trip into that code, I understood that after it had detected a certain value, e.g. 0x0604 for my MBP, then everything else after that was the same as if you had manually specified that same value. But as you say it might have been updated, or I might easily have missed something in that incredible subtle codebase!)

 

[h9826790]

Regarding SMBIOS properties: There are five properties that don't failsafe to machine values. These are

1. PlatformFeature
2. SmcVersion
3. FirmwareFeatures
4. FirmwareFeaturesMask
5. ProcessorType

We have mostly ignored these without trouble, but setting FirmwareFeatures and FirmwareFeaturesMask can have an effect in Big Sur. I wonder if we should be setting the others...

From my own experience, it's actually better to ProcessorType=1281 in the config.

When the OS that can correctly ident the Xeon, which same as no effect.

But for some reasons, without this ProcessorType "spoofing", some Xeon will ident as i3. Then this ProcessorType injection can help to show the correct CPU ident.