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

[markpaterson]

MacPro5,1. I upgraded direct from the last Mojave to Monterey using Martins 0.7.4 and a few modifications to the config (described somewhere on this post).

Everything seems to be working fine, except my KVM switch. Well, actually it's just a USB switch that toggles keyboard and mouse between my Mac and my Ubuntu box (each has their own monitor). When I toggle the USB switch to the Ubuntu then back to the Mac, the keyboard and mouse no longer work. It's as if the whole machine is frozen – but it's not, I can actually log into the Mac over VNC to move the curser and type, and ultimately just reboot, because that's the only thing that fixes this issue.

Any idea what it could be?

 

[Dayo]

I forgot the old mantra ... "if in doubt, ask @joevt"

... and/or @Syncretic

 

[Dewdman42]

MacPro5,1. I upgraded direct from the last Mojave to Monterey using Martins 0.7.4 and a few modifications to the config (described somewhere on this post).

Everything seems to be working fine, except my KVM switch. Well, actually it's just a USB switch that toggles keyboard and mouse between my Mac and my Ubuntu box (each has their own monitor). When I toggle the USB switch to the Ubuntu then back to the Mac, the keyboard and mouse no longer work. It's as if the whole machine is frozen – but it's not, I can actually log into the Mac over VNC to move the curser and type, and ultimately just reboot, because that's the only thing that fixes this issue.

Any idea what it could be?

I am also getting some flukey behavior with USB ports. I have a midi controller that works fine under Catalina but under both Big Sur and Monterey, it only works if I plug the midi keyboard into an external powered usb hub. If I try to plug it directly into the back of the cMP, then it is not detected at all my macos.

I’d like to try to figure out what is missing from Big Sur or Monterey such that the 5,1’s USB ports arent detecting some devices directly, yet the external
Hub works fine.

I think this could be related to what thr kvm is doing every time it switches and perhaps the incompatible nature of Big Sur and Monterey with the 5,1’s USB ports is causing that to happen for you. You could try to plug the KVM into an external powered hub and see if that avoids the problem, unless anyone knows a Kext injection or some such to get the built in ports working properly?

 

[MacNB2]

MacPro5,1. I upgraded direct from the last Mojave to Monterey using Martins 0.7.4 and a few modifications to the config (described somewhere on this post).

Everything seems to be working fine, except my KVM switch. Well, actually it's just a USB switch that toggles keyboard and mouse between my Mac and my Ubuntu box (each has their own monitor). When I toggle the USB switch to the Ubuntu then back to the Mac, the keyboard and mouse no longer work. It's as if the whole machine is frozen – but it's not, I can actually log into the Mac over VNC to move the curser and type, and ultimately just reboot, because that's the only thing that fixes this issue.

Any idea what it could be?

Big Sur and Monterey removed support for Legacy USB 1.0 peripherals. They work as long as they were plugged into the USB ports at boot time and never removed. If you remove them and replug them then they are not detected.
Workaround is to connected those peripherals to an external powered USB Hub. If you then removed and re-attached those peripherals from the USB Hub, then they work fine.
Try connecting your KVM switch to an external USB Hub.

 

[Dewdman42]

Thanks for that info! Just want to clarify that in the case of my midi keyboard, which is a pretty recent model also, it is not detected at all; not even on first boot. But if it’s plugged into external usb hub then it works fine.

How can we determine which devices at usb 1.0 by the way? I’ll probably just get a bigger powered usb hub, but does anyone know if there is any kind of Patch that can get the 5,1’s ports working completely without a powered hub?

 

[MacNB2]

unless anyone knows a Kext injection or some such to get the built in ports working properly?

There was the old Big Sur Patcher than had a LegacyUsbPatch kext. I tried by extracting the kext from the Patcher App and injecting it via OpenCore but no joy.

 

[orangepop]

For anyone still having issues I got mine to finally install and work 100% by adding and replaced what I had with these lines in the config:

<key>PlatformNVRAM</key>
<dict>
<key>BID</key>
<string></string>
<key>FirmwareFeatures</key>
<data>A1QMwAgAAAA=</data>
<key>FirmwareFeaturesMask</key>
<data>P/8f/wgAAAA=</data>
<key>MLB</key>
<string></string>
<key>ROM</key>
<data></data>
<key>SystemSerialNumber</key>
<string></string>
<key>SystemUUID</key>
<string></string>
</dict>
<key>SMBIOS</key>
<dict>
<key>BoardProduct</key>
<string>Mac-7BA5B2D9E42DDD94</string>
<key>ProcessorType</key>
<integer>1281</integer>
<key>FirmwareFeatures</key>
<data>AxQMwAgAAAA=</data>
<key>FirmwareFeaturesMask</key>
<data>P/8f/wgAAAA=</data>
<key>BIOSVersion</key>
<string>9144.0.7.4.0</string>
</dict>

and

<key>Emulate</key>
<dict>
<key>DummyPowerManagement</key>
<false/>
<key>Cpuid1Data</key>
<data>AAAAAAAAAAAAAACAAAAAAA==</data>
<key>Cpuid1Mask</key>
<data>AAAAAAAAAAAAAAAAAAAAAA==</data>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string></string>
</dict>

Then I downloaded Open core legacy patcher here: https://github.com/dortania/OpenCore-Legacy-Patcher/releases/tag/0.3.1 and then ran the two options. Rebooted then upgraded and now on Monterey!

Thanks to all that took the time to play around.

 

[cMP beginner]

For anyone still having issues I got mine to finally install and work 100% by adding and replaced what I had with these lines in the config:

<key>PlatformNVRAM</key>
<dict>
<key>BID</key>
<string></string>
<key>FirmwareFeatures</key>
<data>A1QMwAgAAAA=</data>
<key>FirmwareFeaturesMask</key>
<data>P/8f/wgAAAA=</data>
<key>MLB</key>
<string></string>
<key>ROM</key>
<data></data>
<key>SystemSerialNumber</key>
<string></string>
<key>SystemUUID</key>
<string></string>
</dict>
<key>SMBIOS</key>
<dict>
<key>BoardProduct</key>
<string>Mac-7BA5B2D9E42DDD94</string>
<key>ProcessorType</key>
<integer>1281</integer>
<key>FirmwareFeatures</key>
<data>AxQMwAgAAAA=</data>
<key>FirmwareFeaturesMask</key>
<data>P/8f/wgAAAA=</data>
<key>BIOSVersion</key>
<string>9144.0.7.4.0</string>
</dict>

and

<key>Emulate</key>
<dict>
<key>DummyPowerManagement</key>
<false/>
<key>Cpuid1Data</key>
<data>AAAAAAAAAAAAAACAAAAAAA==</data>
<key>Cpuid1Mask</key>
<data>AAAAAAAAAAAAAAAAAAAAAA==</data>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string></string>
</dict>

Then I downloaded Open core legacy patcher here: https://github.com/dortania/OpenCore-Legacy-Patcher/releases/tag/0.3.1 and then ran the two options. Rebooted then upgraded and now on Monterey!

Thanks to all that took the time to play around.

Hi,

I added and replaced these lines. Still no success. Could you please have a look at my config.plist from above?

 

[PeterHolbrook]

Then I downloaded Open core legacy patcher here

How is your experience relevant to this thread, which advocates an altogether different method from the one you are endorsing? It flies in the face of this entire thread and, therefore, is disrespectful. If you endorse OCLP, why don’t you share your expertise in the relevant support thread?

 

[Dewdman42]

It seems that a lot of people are coming to this thread because there is not an existing thread to support the OCLP crowd. Maybe one of those people behind OCLP can start a long dedicated OCLP thread. I'd be interested in watching that one too, but I agree, its not relevant to this thread.

What people need to realize about THIS thread, is that its for people that are specifically avoiding automatic patchers and such, such as OCLP and numerous others. Really the first post is about taking ownership for OpenCore settings and configuring OpenCore yourself, manually. There are good reasons for doing this: So that you know WTF is going on with your machine, and also so that you can get your configuration as close to vanilla as possible.

I think many OCLP users are running that tool, which automatically generates a config.plist for them, and then after that if it doesn't work right they have nowhere else to ask questions, perhaps other then this thread right now; because now they need to dive into manual intervention. Of course a lot of stuff that OCLP may be automatically configuring is way behind the scope of CDF's original guide.

I suggest that a dedicated OCLP thread, started by someone that is somewhat relevant; would be a good place to discuss all the myriad of combinations and post-editing of config.plist as it pertains to OCLP setup.

I'm genuinely curious about OCLP and will follow it a bit over time, but I agree, its really clouding this thread with unrelated questions, though its still somewhat interesting as it pertains to using it to drive an actual 5,1 MacPro (the subject of this thread). But this thread is really about using CDF's guide to get there.

 

[MacRumors3590]

It seems that a lot of people are coming to this thread because there is not an existing thread to support the OCLP crowd. Maybe one of those people behind OCLP can start a long dedicated OCLP thread. I'd be interested in watching that one too, but I agree, its not relevant to this thread.

What people need to realize about THIS thread, is that its for people that are specifically avoiding automatic patchers and such, such as OCLP and numerous others. Really the first post is about taking ownership for OpenCore settings and configuring OpenCore yourself, manually. There are good reasons for doing this: So that you know WTF is going on with your machine, and also so that you can get your configuration as close to vanilla as possible.

I think many OCLP users are running that tool, which automatically generates a config.plist for them, and then after that if it doesn't work right they have nowhere else to ask questions, perhaps other then this thread right now; because now they need to dive into manual intervention. Of course a lot of stuff that OCLP may be automatically configuring is way behind the scope of CDF's original guide.

I suggest that a dedicated OCLP thread, started by someone that is somewhat relevant; would be a good place to discuss all the myriad of combinations and post-editing of config.plist as it pertains to OCLP setup.

I'm genuinely curious about OCLP and will follow it a bit over time, but I agree, its really clouding this thread with unrelated questions, though its still somewhat interesting as it pertains to using it to drive an actual 5,1 MacPro (the subject of this thread). But this thread is really about using CDF's guide to get there.

There is one here:

OCLP and other OpenCore Packages/Managers

(I see a lot of talk but no action, so I'll take the plunge, even though I'll have little to contribute to this thread going forward.) OpenCore (code here, documentation here) is a boot loader; if you're not already familiar with it, here's an overview. If you are an advanced user or have...

forums.macrumors.com

but it doesn't see much action.

 

[Dewdman42]

Alright @cdf, another question for you about the BigSur/Monterey optional additions, from your guide:

I did get Monterey up and running 100% using your guide instructions, thanks.

I wanted to run both Catalina and Monterey side by side in a dual boot configuration until Monterey gets a little further along. This means using OpenCore for both of them, but I'm concerned about the possibility that they would need different config.plist settings.

I note that SurPlus is smart enough to only engage when the Kernel version is within a certain range. fine so far.

I guess, but not sure, that the bit 35 FirmwareFeatures values will be ok if I launch Catalina with that setting. Can you confirm that?

I guess, but not sure that UpdateNVRAM should also not negatively affect Catalina, but can you confirm? Still somewhat concerned if that will be wearing out my NVRAM hardware faster, or might grow the size of it faster, etc.

New question is related to SecureBootModel. It was advised in the past to have that set to "disabled" I guess for running Catalina. For Monterey we need it set to "Default". But I am concerned what will happen if I run Catalina through that same OpenCore configuration instead of having it set to "Disabled" for Catalina.

I would rather have one single config.plist for both versions of MacOS mainly because I want to make sure I don't accidentally launch Monterey without the related settings. So if I can effectively run both Catalina and Monterey through a single OpenCore config, that would be preferable.

If I have to use separate configs in order to handle SecureBootModel differently in each case, then I want to at least make sure neither OS volume could get messed up if I accidentally use the wrong OC config, so I guess adding SurPlus to both of them, should be safe and at least make sure Monterey won't corrupt its own boot volume should I accidentally chose the Catalina OC config.

But a single OC config for both would be preferable and more simple...but depends on my questions above.

 

[Dewdman42]

There is one here:

OCLP and other OpenCore Packages/Managers

(I see a lot of talk but no action, so I'll take the plunge, even though I'll have little to contribute to this thread going forward.) OpenCore (code here, documentation here) is a boot loader; if you're not already familiar with it, here's an overview. If you are an advanced user or have...

forums.macrumors.com

but it doesn't see much action.

Let's just keep redirecting people there when appropriate.

 

[MacRumors3590]

Alright CDF, another question for you about the BigSur/Monterey optional additions, from your guide:

I did get Monterey up and running 100% using your guide instructions, thanks.

I wanted to run both Catalina and Monterey side by side in a dual boot configuration until Monterey gets a little further along. This means using OpenCore for both of them, but I'm concerned about the possibility that they would need different config.plist settings.

I note that SurPlus is smart enough to only engage when the Kernel version is within a certain range. fine so far.

I guess, but not sure, that the bit 35 FirmwareFeatures values will be ok if I launch Catalina with that setting. Can you confirm that?

I guess, but not sure that UpdateNVRAM should also not negatively affect Catalina, but can you confirm? Still somewhat concerned if that will be wearing out my NVRAM hardware faster, or might grow the size of it faster, etc.

New question is related to SecureBootModel. It was advised in the past to have that set to "disabled" I guess for running Catalina. For Monterey we need it set to "Default". But I am concerned what will happen if I run Catalina through that same OpenCore configuration instead of having it set to "Disabled" for Catalina.

I would rather have one single config.plist for both versions of MacOS mainly because I want to make sure I don't accidentally launch Monterey without the related settings. So if I can effectively run both Catalina and Monterey through a single OpenCore config, that would be preferable.

If I have to use separate configs in order to handle SecureBootModel differently in each case, then I want to at least make sure neither OS volume could get messed up if I accidentally use the wrong OC config, so I guess adding SurPlus to both of them, should be safe and at least make sure Monterey won't corrupt its own boot volume should I accidentally chose the Catalina OC config.

But a single OC config for both would be preferable and more simple...but depends on my questions above.

CDF is the expert but i'm pretty sure you will need 2 Config files. I would simply put Monterey on a second SSD/HD.. And when you boot up, hold "OPTION" and choose the correct OC icon and then the desired OS Icon.
I was doing this with BS and Monterey in the same machine with no issues.
Cheers

 

[Syncretic]

... and/or @Syncretic

boot.efi does this (symbol names are either mine or auto-generated):

;;;;;;;;;;;;   Basically, return <FirmwareFeatures> & <FirmwareFeaturesMask>
0000000000006C4F GetMaskedFirmwareFeatures:
0000000000006C4F     pushq    %rbp
0000000000006C50     movq     %rsp, %rbp
0000000000006C53     pushq    %rsi
0000000000006C54     subq     $0x38, %rsp
0000000000006C58     movq     %rcx, %rsi
0000000000006C5B     xorl     %eax, %eax
0000000000006C5D     leaq     -0x10(%rbp), %rcx
0000000000006C61     movl     %eax, (%rcx)
0000000000006C63     movl     %eax, -0x0c(%rbp)
0000000000006C66     leaq     -0x18(%rbp), %r9
0000000000006C6A     movq     $4, (%r9)
0000000000006C71     movq     FunctionArray, %rax
0000000000006C78     movq     %rcx, 0x20(%rsp)
0000000000006C7D     leaq     strFirmwareFeatures, %rcx ; "FirmwareFeatures"
0000000000006C84     leaq     NV_GUID, %rdx
0000000000006C8B     xorl     %r8d, %r8d
0000000000006C8E     callq    0x48(%rax) ; read FirmwareFeatures from NVRAM to -0x10(%rbp)
0000000000006C91     testq    rax, rax
0000000000006C94     js       1f
0000000000006C96     leaq     -0x18(%rbp), %r9
0000000000006C9A     movq     $4, (%r9)
0000000000006CA1     movq     FunctionArray, %rax
0000000000006CA8     leaq     -0x0c(%rbp), %rcx
0000000000006CAC     movq     %rcx, 0x20(%rsp)
0000000000006CB1     leaq     strFirmwareFeaturesMask, %rcx ; "FirmwareFeaturesMask"
0000000000006CB8     leaq     NV_GUID, %rdx
0000000000006CBF     xorl     %r8d, %r8d
0000000000006CC2     callq    0x48(%rax) ; Read FirmwareFeaturesMask from NVRAM to -0x0c(%rbp)
0000000000006CC5     testq    %rax, %rax
0000000000006CC8     js       1f
0000000000006CCA     movl     -0x10(%rbp), %ecx ; ECX = FirmwareFeatures
0000000000006CCD     andl     -0x0c(%rbp), %ecx ; ECX &= FirmwareFeaturesMask
0000000000006CD0     movl     %ecx, (%rsi)      ; save masked features
0000000000006CD2 1:
0000000000006CD2     addq     0x38, %rsp
0000000000006CD6     popq     %rsi
0000000000006CD7     popq     %rbp
0000000000006CD8     ret

...which is called by:

;;;;;;;;;;;;   Return AL = 1/0 if requested feature (in ECX) is available/unavailable
0000000000006C1F IsFeatureAvailable:
0000000000006C1F     pushq   %rbp
0000000000006C20     movq    %rsp, %rbp
0000000000006C23     pushq   %rsi
0000000000006C24     subq    $0x28, %rsp
0000000000006C28     movl    %ecx, %esi ; bit mask to test is in %ecx, save in %esi
0000000000006C2A     leaq    -0x0c(%rbp), %rcx
0000000000006C2E     movl    $0, (%rcx)
0000000000006C34     callq   GetMaskedFirmwareFeatures
0000000000006C39     testq   %rax, %rax
0000000000006C3C     js      1f
0000000000006C3E     testl   %esi, -0x0c(%rbp)
0000000000006C41     setnz   %al     ; set AL = 1 if requested bit (mask) is set
0000000000006C44     jmp     2f
0000000000006C46 1:
0000000000006C46     xorl    %eax, %eax ; set AL = 0 if requested bit (mask) is not set
0000000000006C48 2:
0000000000006C48     addq    $0x28, %rsp
0000000000006C4C     popq    %rsi
0000000000006C4D     popq    %rbp
0000000000006C4E     ret

So other code can just do something like this:

    movl    $0x10000000, %ecx  ; FW_FEATURE_DISABLE_MBA_S4_WORKAROUND
    callq   IsFeatureAvailable
    testb   %al, %al
    jz      1f
    ; do something here if the feature is available
1:

Coming up with a confident why would require more time than I have to investigate this. The obvious guess would be that FirmwareFeatures is populated by something reading the actual hardware/firmware, and FirmwareFeaturesMask provides a simple way to disable features without kludging the actual hardware/firmware results.

 

[MacNB2]

Let's just keep redirecting people there when appropriate.

Agreed.
I did ask one of the Devs of OCLP why he has not started dedicated thread but got no response. I guess they only come here to advertise the releases of OCLP but discussions/support are all done via Discord
You cannot really discuss on Github....you just get closed out.

 

[paalb]

It seems that a lot of people are coming to this thread because there is not an existing thread to support the OCLP crowd. Maybe one of those people behind OCLP can start a long dedicated OCLP thread. I'd be interested in watching that one too, but I agree, its not relevant to this thread.

What people need to realize about THIS thread, is that its for people that are specifically avoiding automatic patchers and such, such as OCLP and numerous others. Really the first post is about taking ownership for OpenCore settings and configuring OpenCore yourself, manually. There are good reasons for doing this: So that you know WTF is going on with your machine, and also so that you can get your configuration as close to vanilla as possible.

I think many OCLP users are running that tool, which automatically generates a config.plist for them, and then after that if it doesn't work right they have nowhere else to ask questions, perhaps other then this thread right now; because now they need to dive into manual intervention. Of course a lot of stuff that OCLP may be automatically configuring is way behind the scope of CDF's original guide.

I suggest that a dedicated OCLP thread, started by someone that is somewhat relevant; would be a good place to discuss all the myriad of combinations and post-editing of config.plist as it pertains to OCLP setup.

I'm genuinely curious about OCLP and will follow it a bit over time, but I agree, its really clouding this thread with unrelated questions, though its still somewhat interesting as it pertains to using it to drive an actual 5,1 MacPro (the subject of this thread). But this thread is really about using CDF's guide to get there.

There is a thread here: OCLP and other OpenCore Packages/Managers and there is also a recommended way to get fast support: OpenCore Patcher Paradise Discord Server. Nobody seems to want to use them. Maybe this thread should change its name to something else like "OpenCore on the Mac Pro minimal manual configuration"? This is certainly not up to me to decide, just a humble suggestion.

 

[Dewdman42]

CDF is the expert but i'm pretty sure you will need 2 Config files. I would simply put Monterey on a second SSD/HD.. And when you boot up, hold "OPTION" and choose the correct OC icon and then the desired OS Icon.
I was doing this with BS and Monterey in the same machine with no issues.
Cheers

I have them both on seperate drives already.

The concern is about me accidentally selecting the wrong two things in a row. I would prefer to make sure, per my original question, that either there is just one config.plist that works for both...or else I need to make sure that accidentally running either OS with the other's config.plist will not corrupt my OS volumes in any way.

I am actually using RefindPlus in addition to OC, so that I can have one single EFI partition. Then I can selectively choose between different OC configurations if I need to from RefindPlus. In the past I used this to select with or without VMM for updating Catalina.

Then after RefindPlus, OC launches and I still have to choose which volume to actually boot up from OC's picker list. I can't remember exactly how I configured OC right now, but it generally shows me several bootable volumes, with the last one I blessed as "startup disk" being the one that is automatically selected.

But if the OC configs have to be different for each Bootable OS, then there is too much possibility for me to accidentally do it wrong. I need to make sure nothing will end up getting corrupted if that happens that I choose the wrong OC with the wrong boot volume.

I don't know if its possible with OC to tied one OC config.plist to only work with one known boot volume, but it seems like when I was trying to figure that out a few months ago, I couldn't figure it out.

so back to my original question, how can I either share the same config.plist for Catalina and Monterey, or if not...then at least how can I make sure that if I do choose wrongly during reboot, nothing will be corrupted.

 

[paalb]

Agreed.
I did ask one of the Devs of OCLP why he has not started dedicated thread but got no response. I guess they only come here to advertise the releases of OCLP but discussions/support are all done via Discord
You cannot really discuss on Github....you just get closed out.

On the other hand, you get great support on Discord. I helped a friend of mine who did not want to get into manual editing getting started with his MacBook Pro 2012. Asked some questions and got support instantly.

 

[MacNB2]

boot.efi does this (symbol names are either mine or auto-generated):

;;;;;;;;;;;;   Basically, return <FirmwareFeatures> & <FirmwareFeaturesMask>
0000000000006C4F GetMaskedFirmwareFeatures:
0000000000006C4F     pushq    %rbp
0000000000006C50     movq     %rsp, %rbp
0000000000006C53     pushq    %rsi
0000000000006C54     subq     $0x38, %rsp
0000000000006C58     movq     %rcx, %rsi
0000000000006C5B     xorl     %eax, %eax
0000000000006C5D     leaq     -0x10(%rbp), %rcx
0000000000006C61     movl     %eax, (%rcx)
0000000000006C63     movl     %eax, -0x0c(%rbp)
0000000000006C66     leaq     -0x18(%rbp), %r9
0000000000006C6A     movq     $4, (%r9)
0000000000006C71     movq     FunctionArray, %rax
0000000000006C78     movq     %rcx, 0x20(%rsp)
0000000000006C7D     leaq     strFirmwareFeatures, %rcx ; "FirmwareFeatures"
0000000000006C84     leaq     NV_GUID, %rdx
0000000000006C8B     xorl     %r8d, %r8d
0000000000006C8E     callq    0x48(%rax) ; read FirmwareFeatures from NVRAM to -0x10(%rbp)
0000000000006C91     testq    rax, rax
0000000000006C94     js       1f
0000000000006C96     leaq     -0x18(%rbp), %r9
0000000000006C9A     movq     $4, (%r9)
0000000000006CA1     movq     FunctionArray, %rax
0000000000006CA8     leaq     -0x0c(%rbp), %rcx
0000000000006CAC     movq     %rcx, 0x20(%rsp)
0000000000006CB1     leaq     strFirmwareFeaturesMask, %rcx ; "FirmwareFeaturesMask"
0000000000006CB8     leaq     NV_GUID, %rdx
0000000000006CBF     xorl     %r8d, %r8d
0000000000006CC2     callq    0x48(%rax) ; Read FirmwareFeaturesMask from NVRAM to -0x0c(%rbp)
0000000000006CC5     testq    %rax, %rax
0000000000006CC8     js       1f
0000000000006CCA     movl     -0x10(%rbp), %ecx ; ECX = FirmwareFeatures
0000000000006CCD     andl     -0x0c(%rbp), %ecx ; ECX &= FirmwareFeaturesMask
0000000000006CD0     movl     %ecx, (%rsi)      ; save masked features
0000000000006CD2 1:
0000000000006CD2     addq     0x38, %rsp
0000000000006CD6     popq     %rsi
0000000000006CD7     popq     %rbp
0000000000006CD8     ret

...which is called by:

;;;;;;;;;;;;   Return AL = 1/0 if requested feature (in ECX) is available/unavailable
0000000000006C1F IsFeatureAvailable:
0000000000006C1F     pushq   %rbp
0000000000006C20     movq    %rsp, %rbp
0000000000006C23     pushq   %rsi
0000000000006C24     subq    $0x28, %rsp
0000000000006C28     movl    %ecx, %esi ; bit mask to test is in %ecx, save in %esi
0000000000006C2A     leaq    -0x0c(%rbp), %rcx
0000000000006C2E     movl    $0, (%rcx)
0000000000006C34     callq   GetMaskedFirmwareFeatures
0000000000006C39     testq   %rax, %rax
0000000000006C3C     js      1f
0000000000006C3E     testl   %esi, -0x0c(%rbp)
0000000000006C41     setnz   %al     ; set AL = 1 if requested bit (mask) is set
0000000000006C44     jmp     2f
0000000000006C46 1:
0000000000006C46     xorl    %eax, %eax ; set AL = 0 if requested bit (mask) is not set
0000000000006C48 2:
0000000000006C48     addq    $0x28, %rsp
0000000000006C4C     popq    %rsi
0000000000006C4D     popq    %rbp
0000000000006C4E     ret

So other code can just do something like this:

    movl    $0x10000000, %ecx  ; FW_FEATURE_DISABLE_MBA_S4_WORKAROUND
    callq   IsFeatureAvailable
    testb   %al, %al
    jnz     1f
    ; do something here if the feature is available
1:

Coming up with a confident why would require more time than I have to investigate this. The obvious guess would be that FirmwareFeatures is populated by something reading the actual hardware/firmware, and FirmwareFeaturesMask provides a simple way to disable features without kludging the actual hardware/firmware results.

Thanks for your investigation.
Does this mean that the FirmwareFeatures & FirmwareFeaturesMask from NVRAM are checked but not the ones in the SMBIOS ?

 

[Dewdman42]

Thanks for your investigation.
Does this mean that the FirmwareFeatures & FirmwareFeaturesMask from NVRAM are checked but not the ones in the SMBIOS ?

According to CDF here, yes: https://forums.macrumors.com/thread....2207814/page-374?post=30520209#post-30520209

 

[mangombia]

All right. Taking the plunge. OC 0.7.4 with the FWF & FWFM in NVRAM & SMBIOS but NOT VMM. Cloned my production drive of BS and swapped it for my Mojave installation, ran the update (it took nearly an hour with several reboots, but no anomalous reboots) and Monterey came up. Ethernet, Bluetooth & WiFi all working (I've got an upgraded OSXWiFi card). Now applying it to the the production BS NVMe drive. Will report.

 

[cdf]

I guess, but not sure, that the bit 35 FirmwareFeatures values will be ok if I launch Catalina with that setting. Can you confirm that?

Correct. The presence of this bit does not affect booting previous versions of macOS.

I guess, but not sure that UpdateNVRAM should also not negatively affect Catalina, but can you confirm?

Same answer as above. UpdateNVRAM set to true is what applies the FirmwareFeatures and FirmwareFeaturesMask variables.

Still somewhat concerned if that will be wearing out my NVRAM hardware faster, or might grow the size of it faster, etc.

In any case, the NVRAM usage of modern macOS is so much more than what the BootROM of the MacPro5,1 was designed for, so it's becoming increasingly important to use a Matt card as a precautionary measure, or at least to periodically refresh a clean BootROM image.

New question is related to SecureBootModel. It was advised in the past to have that set to "disabled" I guess for running Catalina. For Monterey we need it set to "Default". But I am concerned what will happen if I run Catalina through that same OpenCore configuration instead of having it set to "Disabled" for Catalina.

I've tested SecureBootModel set to Default with Big Sur and Monterey. Since 0.7.4, the Default option takes the model matching the board ID. I haven't tested this in Catalina.

I would rather have one single config.plist for both versions of MacOS mainly because I want to make sure I don't accidentally launch Monterey without the related settings. So if I can effectively run both Catalina and Monterey through a single OpenCore config, that would be preferable.

If I have to use separate configs in order to handle SecureBootModel differently in each case, then I want to at least make sure neither OS volume could get messed up if I accidentally use the wrong OC config, so I guess adding SurPlus to both of them, should be safe and at least make sure Monterey won't corrupt its own boot volume should I accidentally chose the Catalina OC config.

But a single OC config for both would be preferable and more simple...but depends on my questions above.

My recommendation for installing Monterey (SecureBootModel and updated firmware features) was based on the release candidates, which had VMM left out. The flag will likely work with future updates (without SecureBootModel and firmware features), so that might be your answer.

 

[mangombia]

All right. Taking the plunge. OC 0.7.4 with the FWF & FWFM in NVRAM & SMBIOS but NOT VMM. Cloned my production drive of BS and swapped it for my Mojave installation, ran the update (it took nearly an hour with several reboots, but no anomalous reboots) and Monterey came up. Ethernet, Bluetooth & WiFi all working (I've got an upgraded OSXWiFi card). Now applying it to the the production BS NVMe drive. Will report.

Well, it succeeded without issue. Interesting, drive usage report now says "System Data" (in my case nearly 120gb) instead of "Other." Now the question I have regarding the config.plist -- what among these Firmware Features settings can we remove to run Monterey, and what are necessary for applying updates? Can we eliminate the "Update NVRAM" setting and just go with Update SMBIOS as before with Catalina & Big Sur?

 

[mangombia]

Correct. The presence of this bit does not affect booting previous versions of macOS.


Same answer as above. UpdateNVRAM set to true is what applies the FirmwareFeatures and FirmwareFeaturesMask variables.


In any case, the NVRAM usage of modern macOS is so much more than what the BootROM of the MacPro5,1 was designed for, so it's becoming increasingly important to use a Matt card as a precautionary measure, or at least to periodically refresh a clean BootROM image.


I've tested SecureBootModel set to Default with Big Sur and Monterey. Since 0.7.4, the Default option takes the model matching the board ID. I haven't tested this in Catalina.


My recommendation for installing Monterey (SecureBootModel and updated firmware features) was based on the release candidates, which had VMM left out. The flag will likely work with future updates (without SecureBootModel and firmware features), so that might be your answer.

I keep a clean Mojave install first in the boot order in case anything should go wrong so I can get into a working system. My question is whether we can eliminate the updating of NVRAM and Firmware Features/Mask settings from PlatformNVRAM in order to successfully run Monterey day-to-day?