Not for me and I like that. I want to be able to return to a vanilla setup without removing the drives.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
My package need to cover a wide range of users with different hardware / OS versions.
The only thing that I want to ensure is just able to activate HWAccel in 10.14.6 or later. All other functions are bonus (no matter the users want them or not).
Therefore, I keep the no compat check boot argument there to increase compatibility. That argument itself has nothing to do about HWAccel.
If you want to tailor make a OC package that 100% fit your own need, you better follow cdf's guide.
The guide says to change both Cpuid1Data and Cpuid1Mask to turn the VMM flag on or off. The OC package only changes the Cpuid1Mask. Does changing the mask always accomplish the same thing, or is there some other reason for the difference? (sorry for a newbie question)
<key>Cpuid1Data</key>
<data>AAAAAAAAAAAAAACAAAAAAA==</data>
<key>Cpuid1Mask</key>
<data>AAAAAAAAAAAAAAAAAAAAAA==</data>
<key>Cpuid1Data</key>
<data>AAAAAAAAAAAAAACAAAAAAA==</data>
<key>Cpuid1Mask</key>
<data>AAAAAAAAAAAAAAAAAAAAAA==</data>
Good question.
Short answer: yes
Long answer:
For every BIT in
Cpuid1Mask that is SET to 1, the corresponding BIT in the Cpuid1Data is passed through to the appropriate CPU registers (whatever its state - 0 or 1). Think about the MASK as a gate...it's open (1) or closed (0).So, when the
Cpuid1Mask = AAAAAAAAAAAAAAAAAAAAAA==, then NOTHING from Cpuid1Data will get through. In effect, VMM Flag is OFF.So, to turn ON the VMM flag, your set
Cpuid1Mask = AAAAAAAAAAAAAACAAAAAAA==Basically, keep
Cpuid1Data constant and flip Cpuid1Mask.You can also keep
Cpuid1Mask constant and flip Cpuid1Data.It's much easier to understand it if the values are viewed as HEX values instead of Base64 (as above).
That is, in a plist editor like Plist Edit Pro:
Last edited:
Thanks. I do understand how masks work, I've written a lot of firmware. I just wondered if there was some unusual situation where the mask was actually ignored, which would account for the guide saying both keys had to be changed, while the OC package somehow used that behavior. There was some comment in the OC package post about how he had changed the default VMM flag value between versions and changed the way it was managed that triggered my curiosity about it.
Last edited:
I guess if that situation occurred then it would be classed as a bug in OpenCore. The OpenCore manual states FailSafe value is all bits set to zero.
The original strategy in the guide was to keep the bit set in Cpuid1Data and flip the corresponding bit in Cpuid1Mask to enable the VMM flag. The idea was that by keeping the bit in one of the data fields, the user could easily see what needed to be changed in the other (simply matching the C's in plain text).
However, ocvalidate will detect an error if a Cpuid1Data bit is 1 and the corresponding Cpuid1Mask bit is 0:
Therefore the guide was modified to strictly follow the specification. Because Martin's package offers a pragmatic approach above all, the original strategy was maintained. This is the reason for the difference.
That will certainly work. My preference, however, is not to do this to avoid having OpenCore explicitly set the CPUID bit to 0 on every boot (for the few times it will be set to 1 when enabling the VMM flag). Whether this makes any difference is admittedly questionable, but it appeases my fixation with minimality!
Gang, I've been running OC successfully for a couple of years, but now having problems with a fresh build.
I'm simply getting a black screen (no logo) then a power off.
Plist attached, if you'd be kind enough to cast an eye.
I'm simply getting a black screen (no logo) then a power off.
Plist attached, if you'd be kind enough to cast an eye.
This means that OpenCore is not actually blessed. Regarding your plist, since PickerMode is External, OpenCanopy should be included under Drivers.
Of course it is. Several forum members are currently running the latest Monterey RC without issues. The only caveat is whether the VMM flag will finally be necessary.
When attempting to bless inside High Sierra I get the error "could not determine the file systems of volumes/efi"
Basically, no matter how I do it, even when the disk does get blessed, the machine refuses to boot with opencore.
Using verbose output I get
No BootX creation requested
No boot.efi requested
Can't statfs /Volumes/EFI/EFI/BOOT/BOOTx64.efi
Googling the error is unrevealing.
Last edited:
May be it works for the final release, but with RC1 and RC2 the VMM flag trick doesn't work, at least for MacPro 4,1->5,1 and 5,1. This is what khronokernel have to say about it:
"Apple removed VMM from the Pallas Catalog temporarily, should be restored in the coming days. Either use a non-T2 SMBIOS or set SecureBootModel with a T2 ID and ensure VMM is not exposed
Nothing to be done on our end, wait for Apple to fix this"
Right now if you put the VMM flag "ON" and also SecureBootModel to "Default", the RC2 appears but if you try to update it reboots twice or so and backs to the previous version ( in my case Beta 9 ). Same behavior in RC1. If anybody have a different experience with MacPro 4,1->5,1 or just 5,1, it would be great to hear it, but haven't seen anyone yet on these forums.
I successfully upgraded to RC1 from beta 10. VMM off, SecureBootModel set to Default, and updated FirmwareFeatures.
It's enough to specify FirmwareFeatures and FirmwareFeaturesMask in PlatformInfo>PlatformNVRAM and to set UpdateNVRAM to true.
A detailed description of all this will be provided in a new version of the guide planned for the release of Monterey.
Thanks for the fast answer. I have changed in PlatformInfo>SMBIOS and now changed the UpdateNVRAM to true, but PlatformInfo>NVRAM or PlatformInfo>PlatformNVRAM doesn't exist, at least in Martin Lo's config.plist.
EDITED: I have seen the config.plist from the guide and can see there the PlatformNVRAM and where it should be ( yes, Martin hasn't include this, it jumps from Generic to SMBIOS ), I will add it manually and will cross my fingers...
It worked perfectly!! I add my config.plist for MacPro 4,1->5,1 just in case it could help someone here ( Martin's file modified with your guiding ). Thank you very much!!
If using "Automatic", setting "UpdateNVRAM" is a valid option but when not, as with your minimalised config setup, setting "UpdateNVRAM" is not a good idea and stuff that works will be leveraging undefined behaviour.
Undefined behaviour can be broken or start doing unwanted stuff at any time and the proper way with a minimalised config setup is to add and define "FirmwareFeatures" and "FirmwareFeaturesMask" as "NVRAM" entries and to leave "UpdateNVRAM" as false.
This is what MyBootMgr does to avoid undefined behaviour while staying aligned with minimalisation principles ... MyBootMgr never stopped defining FirmwareFeatures btw.
good evening. I am trying to install opencore on my 2010 MP5.1 in order to upgrade to BigSur. Previously I had an older version working w Catalina for quite some time but the system got corrupted and I had to reformat. I decided to start from scratch and move my back up files over manually. I reinstalled Mojave and cloned that fresh install back to the freshly reformatted internal pci ssd. I decided to use Martin Lo's package this time and for the life of me I cannot get it to work. After going thru the steps multiple times I get the same error when checking installed version and the BigSur installer says it cannot install on my target drive. I've tried running the installer from both the cloned target drive and the fresh Mojave install.
The error;
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102
pencore-version': (iokit/common) data was not found
The config.plist is unchanged from Martin Lo's other than the "exposesensitivedata" set to 15. Still no luck. I have also been unsuccessful in getting the boot picker to come up. I can successfully boot into the Mojave clone on the target disk.
Any suggestions? Any tips much appreciated. config.list attached.
The error;
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102
pencore-version': (iokit/common) data was not foundThe config.plist is unchanged from Martin Lo's other than the "exposesensitivedata" set to 15. Still no luck. I have also been unsuccessful in getting the boot picker to come up. I can successfully boot into the Mojave clone on the target disk.
Any suggestions? Any tips much appreciated. config.list attached.
In my post above, I mentioned the following:
My understanding is that in manual mode (Automatic=false), UpdateNVRAM=true applies the settings from PlatformNVRAM, as desired, and the undefined behavior is when UpdateNVRAM=true and the same settings are also added to the NVRAM section (possibly conflicting in value). The NVRAM section is different from PlatformInfo>PlatformNVRAM.
I recently corrected a slip in my original post on FirmwareFeatures where I referred to PlatformInfo>NVRAM. There is no such section; it is actually PlatformInfo>PlatformNVRAM. Perhaps this caused some confusion.
My understanding is that specifying FirmwareFeatures in PlatformNVRAM and setting UpdateNVRAM=true will not result in any extraneous settings.
For Monterey, there is a check for FirmwareFeatures bit 35. This is new. So you may want to redefine FirmwareFeatures with this bit. There are, however, other options to consider:
SurPlus - The Big Sur/Monterey fix you've been waiting for.
It could, and would alleviate the concerns for FirmwareFeatures issues. As Dhiank and I found, Beta 7+'s patchd will run through a few checks before finishing sealing: Check presence of kern.hv_vmm_present If present, assume firmware supports everything require Else, check if firmware...
forums.macrumors.com