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

[cdf]

Well because I see in "settings to remove"

<key>BIOSVersion</key>
<string>9999.0.0.0.0</string>

Oops. This should be "settings to add or change." Thanks! (By "integrated," I understood in the guide, not in OC.)

 

[Angelus]

Thanks for everyone’s efforts with this.

I’m currently running 0.6.5 with Catalina and have been holding out for an upgrade to Big Sur.

I’ve read the first post with updated details for Big Sur installation but I’m curious as to the steps needed if I wanted to upgrade my current Catalina installation to Big Sur? Would it be worth having a section in the first post for those who wish to upgrade Catalina to Big Sur?

Thanks in advance,

Aidan

 

[HuRR]

Just updated to 0.6.6 with 11.2 using @h9826790 package. Everything seems to work great. I just added Nightshift and it's good to have it back! Thanks again!

 

[Dewdman42]

I'm not sure I'm following. To use BIOSVersion to block firmware updates, you still have to add it (either manually like in the guide or by using MaxBIOSVersion in automatic mode).

I was about to ask a question about this, what is the distinction between using the BIOSVersion (per the guide) and the new MaxBIOSVersion that is mentioned in the 0.6.6 OC manual..which I assume is a new feature?

Also if I am setting UpdateSMBIOS to false before doing updates...so I actually need to spoof the BIOSVersion? Just curious, might as set BIOSVersion to be safe I guess, but I was just wondering a bit about the MaxBIOSVersion feature.

 

[startergo]

I am re-checking this again and the VRAM keeps slowly filing up more and more over time letting the system run practically idle..
View attachment 1723746

I am wondering if it may have to do with the RadeonBoost.kext ?

View attachment 1723745

Probably a memory leak somewhere.

Finding Memory Leaks

Guidelines for improving the performance of memory-related code.

developer.apple.com

 

[randomshinichi]

Will this work on a 3,1? I'm not sure what I have to change. if anything.

 

[eicca]

My Mojave machine with OpenCore keeps telling me to upgrade to Big Sur. VMM flag is disabled. It never asked to upgrade to Catalina. I ran a terminal command to ignore Big Sur but it persists.

How do I make it go away??

 

[cdf]

I was about to ask a question about this, what is the distinction between using the BIOSVersion (per the guide) and the new MaxBIOSVersion that is mentioned in the 0.6.6 OC manual..which I assume is a new feature?

That feature is for automatic mode, which is not suitable for the hybridization approach used here in the guide.

Also if I am setting UpdateSMBIOS to false before doing updates...so I actually need to spoof the BIOSVersion? Just curious, might as set BIOSVersion to be safe I guess, but I was just wondering a bit about the MaxBIOSVersion feature.

With no spoofing, there shouldn't be any unwanted firmware updates. In this case, BIOSVersion doesn't apply.

 

[cdf]

My Mojave machine with OpenCore keeps telling me to upgrade to Big Sur. VMM flag is disabled. It never asked to upgrade to Catalina. I ran a terminal command to ignore Big Sur but it persists.

How do I make it go away??

That's interesting. There must be some sort of spoofing for this to happen. As a test, you can try the sample config in the wiki and see if the update goes away.

 

[LFO8]

Probably a memory leak somewhere.

Finding Memory Leaks

Guidelines for improving the performance of memory-related code.

developer.apple.com

Isn’t that referring to RAM memory leaks as opposed to my VRAM issue?

 

[eicca]

That's interesting. There must be some sort of spoofing for this to happen. As a test, you can try the sample config in the wiki and see if the update goes away.

I ran the sysctl machdep.cpu.features command and this is what came up. No VMM:

machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT AES PCID

 

[TECK]

I updated the plistlib generator to support OC 0.6.6 (see notable changes) and wrote a full working wiki example for Big Sur. Please note that I did not displayed the OC version into boot picker like @cdf does, but you can change this very easy with following code into setup.py:

'Misc': {
    'Security': {
       'ExposeSensitiveData': 3
    }
}

OC 0.6.6 technical changes:

• SetApfsTrimTimeout property was added, implementing a 10 seconds trim timeout for APFS filesystems
• BootProtect was replaced with new Launcher properties
• UseRawUuidEncoding property was added, allowing raw encoding for SMBIOS UUIDs

 

[PeterHolbrook]

On the advice of a previous post, I have been fully spoofing the identity of my Mac Pro 5,1, making it explicitly appear as an iMac Pro 1,1. The main reason I did this was in order to enable NightShift. Now that the NightShiftEnabler.kext seems to be operational, what are the recommended parameters for SMBIOS spoofing?

Right now, before booting up again, this is what I have:

<dict>
<key>BIOSVersion</key>
<string>9999.0.0.0.0</string>
<key>BoardProduct</key>
<string>Mac-7BA5B2D9E42DDD94</string>
<key>FirmwareFeatures</key>
<data>
A1QM4A==
</data>
<key>FirmwareFeaturesMask</key>
<data>
P/8f/w==
</data>
</dict>

Should I remove any of these parameters? Is anything missing?

 

[amstel78]

@cdf @tsialex

Sorry to bring this subject up again, but I'm reading some contradictory posts regarding OC writing to NVRAM on the SPI flash chip.

As I understand it, SPI flash has a finite amount of write/delete cycles (100k I think). I'm curious therefore if OC is physically writing or deleting NVRAM entries every single time it boots.

Unless I'm interpreting the following logs incorrectly, it appears to me that it does:

Would like to confirm if this is indeed the case, and what course of action is best to prevent an early death of the SPI flash.

I guess I'll dump my 5,1 BootROM now and store it in case of failure.

 

[h9826790]

On the advice of a previous post, I have been fully spoofing the identity of my Mac Pro 5,1, making it explicitly appear as an iMac Pro 1,1. The main reason I did this was in order to enable NightShift. Now that the NightShiftEnabler.kext seems to be operational, what are the recommended parameters for SMBIOS spoofing?

Right now, before booting up again, this is what I have:

<dict>
<key>BIOSVersion</key>
<string>9999.0.0.0.0</string>
<key>BoardProduct</key>
<string>Mac-7BA5B2D9E42DDD94</string>
<key>FirmwareFeatures</key>
<data>
A1QM4A==
</data>
<key>FirmwareFeaturesMask</key>
<data>
P/8f/w==
</data>
</dict>

Should I remove any of these parameters? Is anything missing?

For Big Sur only

        <key>SMBIOS</key>
        <dict>
            <key>BoardProduct</key>
            <string>Mac-27AD2F918AE68F61</string>
            <key>FirmwareFeatures</key>
            <data>A1QM4A==</data>
            <key>FirmwareFeaturesMask</key>
            <data>P/8f/w==</data>
            <key>BIOSVersion</key>
            <string>9999.0.0.0.0</string>
        </dict>

N.B. the reason to use Mac-7BA5B2D9E42DDD94 is because 7,1 isn't a supported model in Mojave. Therefore, we need the iMac Pro board ID to enable HWAccel.

But in Big Sur, both Mac-7BA5B2D9E42DDD94 and Mac-27AD2F918AE68F61 can be used to enable HWAccel. Use Mac-27AD2F918AE68F61 is better because can effectively avoid some "port disabled" issue.

 

[Angelus]

Just to follow on my previous post, in order to upgrade my 5.1 Opencore Catalina install to Big Sur do I just need to update Opencore and then click on the Big Sur upgrade in system update?

 

[cdf]

what are the recommended parameters for SMBIOS spoofing?

For Big Sur only

        <key>SMBIOS</key>
        <dict>
            <key>BoardProduct</key>
            <string>Mac-27AD2F918AE68F61</string>
            <key>FirmwareFeatures</key>
            <data>A1QM4A==</data>
            <key>FirmwareFeaturesMask</key>
            <data>P/8f/w==</data>
            <key>BIOSVersion</key>
            <string>9999.0.0.0.0</string>
        </dict>

Actually, it seems that for 11.1 and later, firmware features are no longer needed.

 

[cdf]

@cdf @tsialex

Sorry to bring this subject up again, but I'm reading some contradictory posts regarding OC writing to NVRAM on the SPI flash chip.

As I understand it, SPI flash has a finite amount of write/delete cycles (100k I think). I'm curious therefore if OC is physically writing or deleting NVRAM entries every single time it boots.

Unless I'm interpreting the following logs incorrectly, it appears to me that it does:

Would like to confirm if this is indeed the case, and what course of action is best to prevent an early death of the SPI flash.

This depends on your configuration. With WriteFlash set to false, nothing is actually written.

 

[h9826790]

Actually, it seems that for 11.1 and later, firmware features are no longer needed.

Thanks for this info. I haven't test this yet.

But if this is true, then we need to test at least

1) Update from 11.1 to 11.2 by using OTA
2) Install 11.2 via full installer in 11.1
3) Install 11.2 via full installer from Catalina (the OS that just before Big Sur)
4) Install 11.2 via full installer from Mojave (the OS that last support on 5,1)
5) install 11.2 from Big Sur recovery partition

And found out which exact situation need the Firmware Feature injection.

e.g. In case 4, in general, VMM flag should be off. Which means, without the Firmware Feature, the installer should reject the 5,1 to install 11.2.

So, unless there is any disadvantage for Firmware Feature injection (e.g. like the VMM flag which will disable some CPU power management functions). I think it's better to keep it there as fail safe.

 

[cdf]

Please note that I did not displayed the OC version into boot picker like @cdf does

You've misunderstood this setting: 1+2 is for the path of the EFI volume and the OC version, both exposed as NVRAM variables. Add 4 if you want to show the version on the boot picker.

 

[cdf]

Thanks for this info. I haven't test this yet.

I've tested the full installer of 11.1 from Mojave (VMM enables the installation without firmware features). I'll try 11.2 OTA from 11.1 later (hybridization with no firmware features).

So, unless there is any disadvantage for Firmware Feature injection (e.g. like the VMM flag which will disable some CPU power management functions). I think it's better to keep it there as fail safe.

I agree, but I also would like to determine what the most minimal settings are.

 

[cdf]

Just to follow on my previous post, in order to upgrade my 5.1 Opencore Catalina install to Big Sur do I just need to update Opencore and then click on the Big Sur upgrade in system update?

The best course of action is to have a back up first. Then, after updating OpenCore and loading a recommended configuration, you can certainly try Software Update from Catalina.

 

[startergo]

This depends on your configuration. With WriteFlash set to false, nothing is actually written.

with WriteFlash set to true also, as long as it is already written:

00:137 00:002 OC: OcLoadNvramSupport...
00:140 00:002 OC: Not deleting NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale, matches add
00:142 00:002 OC: Not deleting NVRAM 7C436110-AB2A-4BBB-A880-FE41995C9F82:boot-args, matches add
00:145 00:002 OC: Setting NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale - ignored, exists
00:148 00:002 OC: Setting NVRAM 7C436110-AB2A-4BBB-A880-FE41995C9F82:SystemAudioVolume - ignored, exists
00:150 00:002 OC: Setting NVRAM 7C436110-AB2A-4BBB-A880-FE41995C9F82:boot-args - ignored, exists
00:153 00:002 OC: Setting NVRAM 7C436110-AB2A-4BBB-A880-FE41995C9F82:csr-active-config - ignored, exists
00:155 00:002 OC: Current version is DBG-067-2021-02-02

It looks like with WriteFlash set to False the NVRAM variables are written only to RAM therefore are not persistent:

NVRAM was updated when WriteFlash set to false · Issue #929 · acidanthera/bugtracker

My understanding is that when "WriteFlash" set to false, NVRAM should not be updated. However, hackintool shows different NVRAM even with "WriteFlash" set to false. Looking at code, the WriteFlash ...

github.com

Spoiler: Set Variable

A variable must contain one or more bytes of Data. Unless the EFI_VARIABLE_APPEND_WRITE,EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, orEFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS attributeisset(seebelow),using SetVariable() with a DataSize of zero will cause the entire variable to be deleted. The space consumed by the deleted variable may not be available until the next power cycle.
If a variable with matching name, GUID, and attributes already exists, its value is updated. The Attributes have the following usage rules:

• If a preexisting variable is rewritten with different attributes, SetVariable()shall not modify the variable and shall return EFI_INVALID_PARAMETER. The only exception to this is when the only attribute differing is EFI_VARIABLE_APPEND_WRITE. In such cases the call's successful outcome or not is determined by the actual value being written. There are two exceptions to this rule:
  • — If a preexisting variable is rewritten with no access attributes specified, the variable will be deleted.
  • — EFI_VARIABLE_APPEND_WRITE attribute presents a special case. It is acceptable to rewrite the variable with or without EFI_VARIABLE_APPEND_WRITE attribute.
• Setting a data variable with no access attributes causes it to be deleted.
• EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated and should not be used. PlatformsshouldreturnEFI_UNSUPPORTEDifacallertoSetVariable() specifiesthis attribute.
• Unless the EFI_VARIABLE_APPEND_WRITE,EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, orEFI_VARIABLE_ENHANCED_AUTHENTICATED_WRITE_ACCESS attribute is set, setting a data variable with zero DataSize specified, causes it to be deleted.
• Runtime access to a data variable implies boot service access. Attributes that haveEFI_VARIABLE_RUNTIME_ACCESS set must also have EFI_VARIABLE_BOOTSERVICE_ACCESS set. The caller is responsible for following this rule.
• Once EFI_BOOT_SERVICES.ExitBootServices() is performed, data variables that did not have EFI_VARIABLE_RUNTIME_ACCESS set are no longer visible to GetVariable().

UEFI Forum, Inc. May 2020 241
UEFI Specification, Version 2.8 Errata B Services — Runtime Services

• Once ExitBootServices() is performed, only variables that have EFI_VARIABLE_RUNTIME_ACCESS and EFI_VARIABLE_NON_VOLATILE set can be set with SetVariable(). Variables that have runtime access but that are not nonvolatile are read- only data variables once ExitBootServices() is performed.
  When the EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS attribute is set in a SetVariable() call, the authentication shall use the EFI_VARIABLE_AUTHENTICATION_3 descriptor, which will be followed by any descriptors indicated in the Type and Flags fields.
• When the EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute is set ina SetVariable()call,theauthenticationshallusethe EFI_VARIABLE_AUTHENTICATION_2 descriptor.
• If both the EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS and theEFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS attribute are set in a SetVariable() call,thenthefirmwaremustreturnEFI_INVALID_PARAMETER.
• If the EFI_VARIABLE_APPEND_WRITE attribute is set in a SetVariable() call, then any existing variable value shall be appended with the value of the Data parameter. If the firmwaredoesnotsupporttheappendoperation,thenthe SetVariable()callshallreturn EFI_INVALID_PARAMETER.
• If the EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute is set in a SetVariable() call, and firmware does not support signature type of the certificate included in the EFI_VARIABLE_AUTHENTICATION_2 descriptor, then the SetVariable() call shall return EFI_INVALID_PARAMETER. The list of signature types supported by the firmware is defined by the SignatureSupport variable. Signature type of the certificate is defined by its digest and encryption algorithms.
• If the EFI_VARIABLE_HARDWARE_ERROR_RECORD attribute is set, VariableName and VendorGuid must comply with the rules stated in Section 8.2.4.2 and Appendix P. Otherwise, the SetVariable() call shall return EFI_INVALID_PARAMETER.
• Globally Defined Variables must be created with the attributes defined in Table 14 of the Boot Manager chapter. If a globally defined variable is created with the wrong attributes, the result is indeterminate and may vary between implementations.
• If using the EFI_VARIABLE_ENHANCED_AUTHETICATED_ACCESS interface to update the cert authority for a given variable, it is valid for the Data region of the payload to be empty. This would update the cert without modifying the data itself. If the Data region is empty AND no NewCert is specified, the variable will be deleted (assuming all authorizations are verified).
• Secure Boot Policy Variable must be created with theEFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute set, and the authentication shall use the EFI_VARIABLE_AUTHENTICATION_2 descriptor. If the appropriate attribute bit is not set, then the firmware shall return EFI_INVALID_PARAMETER.
  The only rules the firmware must implement when saving a nonvolatile variable is that it has actually been saved to nonvolatile storage before returning EFI_SUCCESS, and that a partial save is not performed. If power fails during a call to SetVariable() the variable may contain its previous value, or its new value. In addition there is no read, write, or delete security protection.

 

[Takubon]

The guide has been updated to OpenCore version 0.6.6.

There are also a few changes and additions to the guide. These include

• simplifications to the instructions
• details for Big Sur
• directions for easier updates

Thank you, I was able to successfully upgrade to OpenCore 0.6.6.
The software I'm using doesn't support Big Sur yet, so I'll install Big Sur when they will be do.
2010MacPro 2*X5675, Catalina10.15.7(19H512), Sapphire Nitro+ RX580 8G

 

[amstel78]

This depends on your configuration. With WriteFlash set to false, nothing is actually written.

This is what's in my config.plist and I assume is what you're referring to:

So if that is set to <false/>, where are settings actually stored?

EDIT: just saw @startergo post. Any weird behaviors if settings are written to RAM rather than NVRAM?