Because we use manual mode (Automatic=false), AdviseFeatures will unfortunately not work. To add the extra bit, we really must set the complete values with the extra bit. Regarding PlatformNVRAM and SMBIOS, I prefer to only touch the NVRAM part (which is what is needed for updates and installations) until there is a reason to do otherwise.
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
Because we use manual mode (Automatic=false), AdviseFeatures will unfortunately not work. To add the extra bit, we really must set the complete values with the extra bit. Regarding PlatformNVRAM and SMBIOS, I prefer to only touch the NVRAM part (which is what is needed for updates and installations) until there is a reason to do otherwise.
Thanks for your help. I think this helped a bit but I'm still not able to install Monterey. I get to one reboot and sometimes I get the circle w a diagonal line like a do not enter sign, I can reboot then it works until a third of the way then continues to about half way and stops and won't go further - I waited for an hour. When I reboot, it boots into my big sur 11.6.1. No problems other than I was hoping to have Monterey. I attached my config file since at this point Im a bit lost but know I am close.
I don't believe the variables are actually written to the NVRAM if WriteFlash is disabled, or written repeatedly if WriteFlash is enabled. There's also the option to add the variables to the NVRAM section rather than the PlatformNVRAM (as previously pointed out by @Dayo); the behavior regarding writing to the NVRAM should be the same. Still, it might be worth verifying if there are any differences.
Thanks for all your answers!! Monterey installed successfully BUT.... no Bluetooth... Wifi and Ethernet are perfect, but no Bluetooth...
I have a BT USB Dongle 4.0 that works perfect in BigSur...
When I look in the system info, I see that the USB Dongle is detected, but not recognized as Bluetooth:
I was reset the PRAM 3 times in a row, in terminal "sudo kill -9 $(pgrep bluetoothd)"... nothing works...
Any idea??
I have a BT USB Dongle 4.0 that works perfect in BigSur...
When I look in the system info, I see that the USB Dongle is detected, but not recognized as Bluetooth:
I was reset the PRAM 3 times in a row, in terminal "sudo kill -9 $(pgrep bluetoothd)"... nothing works...
Any idea??
if you still have the stock BT card in your 5,1 it will work just fine. I have 4x 5,1's running 12.0.1 and BT works great!
I'm using OCLP 0.3.1
Thanks for posting this, I just tried putting it on and running the "Macintosh HD" that kept on restarting before and the same thing occurred, I'll try running the installer again from start, so give it 58 more minutes. Still in 11.6.1 so no complaints there.
Edit: This is a new one, this was after using your plist file and running the installer again:
After I hit OK the finder disappeared leaving just the desktop background. CMD+OPT+ESC window still worked but was empty, no finder there.
Last edited:
Backstepping to me and having to have the VMM flag on to boot 11.6, I found the time to try different things.
I used OCLP to build a config based on what it found. Totally hosed OC altogether. Thankfully I keep all the needed files on my bootable Mojave. That was a fun 20 minutes :/
It’s been a few days since the update to 11.6 and there was another update today, I thought “what the hell” and tried turning VMM off and still no go using the known-good config.plist I have with VMM normally on. When it starts to boot, the progress bar under the apple logo moves a smidge and then it reboots and gives me the error screen.
I have an updated config for when I update to Monterey (maybe soon), and….errr. Ok. 1st boot with the Monterey additions and VMM -OFF- acted like every other time and immediately rebooted. At the boot picker I clicked the Mojave drive, it blinked and went back to the picker. A few more times of that, and I rebooted. It came back to the boot picker, clicked Mojave, blinked and back at boot picker. I then clicked the BigSur and it started to boot…I had no idea what OS was booting until I saw the 11.6 login screen.
TL;DR: So now I’m at the point where I can boot BigSur with VMM off and Monterey options, but Native Mojave doesn’t boot from the OC picker screen. I win but I lose. *facepalm*
I used OCLP to build a config based on what it found. Totally hosed OC altogether. Thankfully I keep all the needed files on my bootable Mojave. That was a fun 20 minutes :/
It’s been a few days since the update to 11.6 and there was another update today, I thought “what the hell” and tried turning VMM off and still no go using the known-good config.plist I have with VMM normally on. When it starts to boot, the progress bar under the apple logo moves a smidge and then it reboots and gives me the error screen.
I have an updated config for when I update to Monterey (maybe soon), and….errr. Ok. 1st boot with the Monterey additions and VMM -OFF- acted like every other time and immediately rebooted. At the boot picker I clicked the Mojave drive, it blinked and went back to the picker. A few more times of that, and I rebooted. It came back to the boot picker, clicked Mojave, blinked and back at boot picker. I then clicked the BigSur and it started to boot…I had no idea what OS was booting until I saw the 11.6 login screen.
TL;DR: So now I’m at the point where I can boot BigSur with VMM off and Monterey options, but Native Mojave doesn’t boot from the OC picker screen. I win but I lose. *facepalm*
I disabled the BT of the new stock card because I have a lot of BT losses... I installed the newest model with BT 4.0.... but have low signal...
I know that must be a software problem, because I have the same problem in my 2 Mac Pro 5.1...
Last edited:
Can someone please help me with the missing PlatformNvram setting in the package from Martin Lo?
Code:
<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>By this way works for me...
VMM Flag off for Monterey? Some say they had it on although it is stated that we should deactivate it...
Could you please have a look at my config? I attached it again. When verifying Terminal states "OK"
Edit: this does not even boot....
Last edited:
The revised PlatformNVRAM and SMBIOS settings above did not result in anything different other than a reboot back into Big Sur after a few restarts for me. Is there anything else I need to revise to get this upgrade to work?
… ah, I think I need to set the VMM flags to on.
… ah, I think I need to set the VMM flags to on.
Last edited:
I don't think you do. Yesterday I updated my secondary Big Sur disk to Monterey 12.0.1 following @cdf's instructions to the letter. No VMM flag. Everything worked as intended. Now, if you want to follow some alternative guidelines, that's up to you.
I was looking at the beginning of this thread that states...
...however it then says
As I've had no positive results with the above changes I was looking at this setting. After I changed this and rebooted my machine appeared to continue with the failed install which its not done with my previous 6 attempts at this but did not complete. So after a forced reboot and selecting the second Mcintosh HD icon from the boot picker thats recently appear from the failed installs I was able to get back to Big Sur (again).
I'll give this one more shot with re-downloading and installing and watch for further developments assuming this ends in failure again.
After a very bumpy ride (one reset in the middle of my last install attempt) I'm now running Monterey and this was after about 8 attempts without the VMM flags set. Setting these allowed the install to continue with a reset in the middle to completion.
This is the Martin Lo config.plist for 7.4 with the above PlatformNVRAM and SMBIOS modification but only until I changed the VMM flag did it actually install Monterey.
I suspect there are a few things to iron out hence not seeing anything concrete materialising just yet.
This is the Martin Lo config.plist for 7.4 with the above PlatformNVRAM and SMBIOS modification but only until I changed the VMM flag did it actually install Monterey.
I suspect there are a few things to iron out hence not seeing anything concrete materialising just yet.
would you be so kind and share you config with us? I have problems adding the platform nvram section. OC is working fine until I change that...
@cdf ... can you give some insight into feature masking?
If the FeaturesFlag defines which Bits are ON or OFF of a feature set and the FeaturesMask masks these flags by allowing or blocking Bits, shouldn't the default value therefore be the same for both Flags and Masks? That is, a one to one relationship where if something is available, the mask is open and vice versa?
At most, I would expect that the FeaturesMask might have some Bits OFF where the Flag is ON to disable such but I note that often, including the settings in the guide, the FeaturesMask has Bits ON where the Flag is OFF which I can't wrap my head around ... seems they might as well be OFF in such cases (resulting in a one-to-one relationship).
Am I missing something on how these work?
If the FeaturesFlag defines which Bits are ON or OFF of a feature set and the FeaturesMask masks these flags by allowing or blocking Bits, shouldn't the default value therefore be the same for both Flags and Masks? That is, a one to one relationship where if something is available, the mask is open and vice versa?
At most, I would expect that the FeaturesMask might have some Bits OFF where the Flag is ON to disable such but I note that often, including the settings in the guide, the FeaturesMask has Bits ON where the Flag is OFF which I can't wrap my head around ... seems they might as well be OFF in such cases (resulting in a one-to-one relationship).
Am I missing something on how these work?
Sure. There are two changes I made to the original ML config.plist namely (PlatformNVRAM has been added BTW, BIOS has been updated)
Code:
<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 the VMM flag section as follows based on what has been documented at the beginning of this thread (page 1) though I really didn't think this would be necessary but had run out of options...
Code:
<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>This is not perfect and from my view a bit of a hack to get this to work until others more experienced have figured this out. I mentioned having to reset halfway though my install after the percentage bar was stuck in the middle for nearly an hour and then it continued on its merry way and completed.
BTW I restored the original config.plist back to my EFI partition after the installation completed.
Good luck
Last edited:
I think it should be the same now as yours but my Mac does not boot anymore with that plist...
Honestly, this is my understanding as well. Although it's probably not worth the effort, we could always try to reverse the binaries that use the FirmwareFeatures and FirmwareFeaturesMask variables to understand why Apple uses the mask like this. I'd like to think there's a good reason.
The binaries are listed here (of course you know that because you've contributed to that header file
):OpenCorePkg/Include/Apple/IndustryStandard/AppleFeatures.h at master · acidanthera/OpenCorePkg
OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.
github.com
Documenting a success. Hope it helps. I updated BS11.6 to 11.6.1, then upgraded to Monterey. All seems good - BT and network are fine. System seems stable and quick. Configuration in signature.
Some notes:
1. OC 0.7.4; When updating OC I always walk through the full config.plist steps using the latest provided config.plist, checking it at each step. Seems easier to me than trying to modify my own with any changes. I keep the video path, etc handy for quick cut and paste. I add all the bells and whistles - SurPlus, Acceleration, NighShift, etc.
2. I keep VMM off since upgrading to BS. Also use GUI boot picker.
3. I added the 3 changes in post #9264 to my working OC 0.7.4 config.plist but made no other changes. Rebooted into BS 11.6 to make sure all was good before updating.
4. I did the update/upgrade using the Software Update in the System Preferences app (again, VMM is off). It showed Monterey was available but also 11.6.1. Did the 11.6.1 update first. It went as expected. During that update there was a lot of SATA HD activity (Mojave drive) and there was a brief flash on the screen of a recovery mode. I assume the installer is using the recovery partition on Mojave during the process and is doing its own "Apple" boot so doesn't go through OC. Not sure if pulling the Mojave drive would have it use the BS SSD recovery partition and be quicker but if ain't broke don't fix it.
5. Once in BS 11.6.1, I selected the Monterey upgrade in the Software Update pane. This downloaded the upgrade and asked to restart. On restart, the OC GUI boot picker came up and there was a new drive simply labeled Macintosh HD. I chose the new one. That then launched what looked like my BS log in. I logged in and from there the update went smoothly. It rebooted several times and again seemed to use the Mojave recovery partition at one step. Be patient. Progress bars once at 100% still have time to go. On average about 10' longer once at 100%.
6. No hard resets needed. No Cmd-Opt-P-R needed.
Good luck
Some notes:
1. OC 0.7.4; When updating OC I always walk through the full config.plist steps using the latest provided config.plist, checking it at each step. Seems easier to me than trying to modify my own with any changes. I keep the video path, etc handy for quick cut and paste. I add all the bells and whistles - SurPlus, Acceleration, NighShift, etc.
2. I keep VMM off since upgrading to BS. Also use GUI boot picker.
3. I added the 3 changes in post #9264 to my working OC 0.7.4 config.plist but made no other changes. Rebooted into BS 11.6 to make sure all was good before updating.
4. I did the update/upgrade using the Software Update in the System Preferences app (again, VMM is off). It showed Monterey was available but also 11.6.1. Did the 11.6.1 update first. It went as expected. During that update there was a lot of SATA HD activity (Mojave drive) and there was a brief flash on the screen of a recovery mode. I assume the installer is using the recovery partition on Mojave during the process and is doing its own "Apple" boot so doesn't go through OC. Not sure if pulling the Mojave drive would have it use the BS SSD recovery partition and be quicker but if ain't broke don't fix it.
5. Once in BS 11.6.1, I selected the Monterey upgrade in the Software Update pane. This downloaded the upgrade and asked to restart. On restart, the OC GUI boot picker came up and there was a new drive simply labeled Macintosh HD. I chose the new one. That then launched what looked like my BS log in. I logged in and from there the update went smoothly. It rebooted several times and again seemed to use the Mojave recovery partition at one step. Be patient. Progress bars once at 100% still have time to go. On average about 10' longer once at 100%.
6. No hard resets needed. No Cmd-Opt-P-R needed.
Good luck