Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Okay maybe some additional limitation inside the cMP SMBIOS then. Anyhow, in the Quick Sync enabled SMBIOSes it used to work absolutely flawlessly in Mojave and in Catalina it doesn't. So basically WEG developers have to look into two things:
  1. Why is board-id spoofing broken in Catalina
  2. What's preventing HEVC on the cMP SMBIOSes
I personally won't contribute to this on Insanelymac anymore tho. I am sick and tired of talking to a wall.
 
Something to mention in Mojave final cut pro does not work, whereas in Catalina it works.
And finally my Polaris card with boot screen for better testing:
Radeon RX 480:
Chipset Model: Radeon RX 480
Type: GPU
Bus: PCIe
Slot: Slot-1
PCIe Lane Width: x16
VRAM (Total): 8 GB
Vendor: AMD (0x1002)
Device ID: 0x67df
Revision ID: 0x00c7
EFI Driver Version: MacVidCards
Metal: Supported, feature set macOS GPUFamily2 v1
Displays:
SyncMaster:
Resolution: 1680 x 1050 (Widescreen Super eXtended Graphics Array Plus)
UI Looks like: 1680 x 1050 @ 60 Hz
Framebuffer Depth: 24-Bit Color (ARGB8888)
Display Serial Number: H9FQ803833
Mirror: Off
Online: Yes
Rotation: Supported
Automatically Adjust Brightness: No
SMBX2440:
Resolution: 1920 x 1080 (1080p FHD - Full High Definition)
UI Looks like: 1920 x 1080 @ 60 Hz
Framebuffer Depth: 24-Bit Color (ARGB8888)
Display Serial Number: HVSB200326
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Automatically Adjust Brightness: No
Connection Type: DisplayPort
 
Last edited:
Attempted to change the board ID to iMacPro1,1 and upon reboot only one of the screens was working, but when I started testing I lost output from all ports on the card. :(
 
Attempted to change the board ID to iMacPro1,1 and upon reboot only one of the screens was working, but when I started testing I lost output from all ports on the card. :(

It's been discussed before. Please add the following WEG boot argument to activate all ports properly.
Code:
agdpmod=pikera
 
It's been discussed before. Please add the following WEG boot argument to activate all ports properly.
Code:
agdpmod=pikera
Oh I never removed that boot argument. The thing is one of the ports used to work with board ID spoofing with my regular vbios, but apparently with macvidcard's vbios the situation is not exactly the same
 
Oh I never removed that boot argument. The thing is one of the ports used to work with board ID spoofing with my regular vbios, but apparently with macvidcard's vbios the situation is not exactly the same

Good point, the MVC Mac EFI may make the difference
 
Seeing that enabling the VMM flag results in a 4% to 5% CPU performance penalty as reported by another forum member, I wanted to disable the flag while still using OpenCore and only renable it when an update is available.

So do we just change AAAAAAAAAAAAAACAAAAAAA back to AAAAAAAAAAAAAAAAAAAAAA== or do we leave both Cpuid1Data and Cpuid1Mask blank ie.

Code:
<key>Emulate</key>
        <dict>
            <key>Cpuid1Data</key>
            <data></data>
            <key>Cpuid1Mask</key>
            <data></data>
        </dict>

Edit: or even

Code:
<key>Emulate</key>
<array/>
 
Last edited:
I personally won't contribute to this on Insanelymac anymore tho. I am sick and tired of talking to a wall.

No doubt you are from what I have seen it is the same bunch of clowns that were involved with the previous effort at the efi loading. Except this time they do not need the bios flashing to do it, I would think they still display the same ignorance and arrogance as they always did. A leopard does not change its spots as the saying goes...
 
Seeing that enabling the VMM flag results in a 4% to 5% CPU performance penalty as reported by another forum member, I wanted to disable the flag while still using OpenCore and only renable it when an update is available.

So do we just change AAAAAAAAAAAAAACAAAAAAA back to AAAAAAAAAAAAAAAAAAAAAA== or do we leave both Cpuid1Data and Cpuid1Mask blank ie.

Code:
<key>Emulate</key>
        <dict>
            <key>Cpuid1Data</key>
            <data></data>
            <key>Cpuid1Mask</key>
            <data></data>
        </dict>

Edit: or even

Code:
<key>Emulate</key>
<array/>

My preference is to change Cpuid1Mask from AAAAAAAAAAAAAACAAAAAAA== to AAAAAAAAAAAAAAAAAAAAAA==, because it's easy to change back for updates. But you can also leave Cpuid1Data and Cpuid1Mask empty as <data></data>.
 
Last edited:
  • Like
Reactions: w1z
My preference is to change Cpuid1Mask from AAAAAAAAAAAAAACAAAAAAA== to AAAAAAAAAAAAAAAAAAAAAA==, because it's easy to change back for updates. But you can also leave Cpuid1Data and Cpuid1Mask empty as .
Thanks. I was in the middle of experimenting with values when you responded and I can confirm that that the data fields must be populated with values in both cases (VMM enabled or disabled) as leaving them empty causes the cMP to hang on boot.
 
  • Like
Reactions: octoviaa and cdf
Thanks. I was in the middle of experimenting with values when you responded and I can confirm that that the data fields must be populated with values in both cases (VMM enabled or disabled) as leaving them empty causes the cMP to hang on boot.

You're right. According to the manual, the failsafe for each field is all zeros.
 
  • Like
Reactions: octoviaa
If you boot into Linux you can see all Mac NVRAM variables as files in the folder /sys/firmware/efi/efivars/. Variables can also be created, deleted and modified with the efivar command. More on the topic here.

Again, no one without means to reflash the SPI should mess with OpenCore, besides the log that fill up @startergo NVRAM, a big binary table was inside the first stream/store of the NVRAM. Enabling OC log to NVRAM can cause flash cell starvation, be warned.

If you don't have a clean dump, you can't repair a messed up BootROM since this NVRAM areas are not cleaned by Command-Option-P-R.

Dumping the firmware is a bit of an overkill for accessing NVRAM variables. Have you tried booting into Linux to see if the OpenCore log is visible? What is the name of the variable? Of course, if you cannot even boot into Linux, you will need means to reflash the SPI.
 
If you boot into Linux you can see all Mac NVRAM variables as files in the folder /sys/firmware/efi/efivars/. Variables can also be created, deleted and modified with the efivar command. More on the topic here.



Dumping the firmware is a bit of an overkill for accessing NVRAM variables. Have you tried booting into Linux to see if the OpenCore log is visible? What is the name of the variable? Of course, if you cannot even boot into Linux, you will need means to reflash the SPI.
The problem is if your NVRAM is full you may loose the possibility to boot. Also Clearing NVRAM from the OC bootpicker deletes all logs (if your Mac can boot to that stage). This only happens if you have the debug logging enabled with debug values 113 or 117 and 65 is safe because it only writes logs to file.
 
Last edited:
in the OC configuration there is a Csr_active_config set to disable the SIP, so it disabled it without going to the recovery partition

Nice!

What data value did you use to completely disable SIP? base64 or hex ie. 5wMAAA== or E7030000 and did you enclose the value in angle brackets <>?

Edit: On a real mac, when SIP is deactivated via recovery the value is w%00%00%00
 
Nice!

What data value did you use to completely disable SIP? base64 or hex ie. 5wMAAA== or E7030000 and did you enclose the value in angle brackets <>?

Edit: On a real mac, when SIP is deactivated via recovery the value is w%00%00%00

This is what you can see in the SampleFull.plist
Screenshot 2019-12-03 at 5.10.31 PM.png
 
This is what you can see in the SampleFull.plist
View attachment 880522
I know but some sections of OpenCore online guide reference hex values with no reference to base64 at all.

Strangely enough, the base64 I referenced in my previous post disables SIP but its hex is different than the hex we are accustomed to seeing under real macs (SIP disabled via recovery) which is why I am asking.

w000000 is not a hexidecimal value that can be converted into base64 for use with OC
 
The correct base64 value to disable SIP under OC for real macs is

Code:
dwAAAA==

In addition: To disable SIP and Hyper-threading using OC I used

Code:
<key>boot-args</key>
                <string>-no_compat_check cwae=2</string>
                <key>csr-active-config</key>
                <data>dwAAAA==</data>
                <key>SMTDisable</key>
                <data>AQ==</data>

The above survives NVRAM/PRAM resets under OC if you wish to always have SIP and Hyper-Threading disabled on cMP 5,1
 
Last edited:
  • Like
Reactions: h9826790
I used
Code:
ZwAAAA==
But I saw it is scratched here:
csr-active-config: <00000000> (SIP settings)
  • 00000000 -SIP is fully turned on
  • 30000000 -Allow unsigned Kext to mount and allow writing to protected file system paths
  • E7030000 -SIP is completely closed
  • 67000000 - 67000000
https://github.com/apple/darwin-xnu/blob/master/bsd/sys/csr.h

Noted. However, dwAAAA== is set by macOS under Recovery when executing csrutil disable. I don't have a matt card to experiment with different values so I am playing it safe and sticking with Apple default values.
 
The correct base64 value to disable SIP under OC for real macs is

Code:
dwAAAA==

In addition: To disable SIP and Hyper-threading using OC I used

Code:
<key>boot-args</key>
                <string>-no_compat_check cwae=2</string>
                <key>csr-active-config</key>
                <data>dwAAAA==</data>
                <key>SMTDisable</key>
                <data>AQ==</data>

The above survives NVRAM/PRAM resets under OC if you wish to always have SIP and Hyper-Threading disabled on cMP 5,1

SIP status base on the corresponding Hex value, however, you have to convert it to base64 for OpenCore.

My understanding so far, always base on the sample plist entry for correct format, and reference to the manual for correct value.

If the sample plist use base64, then no matter the manual only mention Hex or Dec, convert the value into base64 for OpenCore config plist.
 
SIP status base on the corresponding Hex value, however, you have to convert it to base64 for OpenCore.

My understanding so far, always base on the sample plist entry for correct format, and reference to the manual for correct value.

If the sample plist use base64, then no matter the manual only mention Hex or Dec, convert the value into base64 for OpenCore config plist.

Agreed. When in doubt ie. csr-active-config having w%00%00%00 in nvram, use nvram -x -p to see the xml/base64 values to use in OC.

Thank you guys!
 
Convert base64 to bytes/ascii:
Code:
base64 -d <<< dwAAAA== | xxd

00000000: 7700 0000                                w...

Convert csr-active-config to a 32 bit hex number (big endian, like a C code literal):
Code:
hex=$(printf "$(nvram csr-active-config | sed -E '/^csr-active-config.(.*)/s//\1/g;/\\/s//\\\\/g;/%/s//\\x/g')" | xxd -p);hex=0x${hex:6:2}${hex:4:2}${hex:2:2}${hex:0:2};echo $hex

0x00000077

Convert w%00%00%00 to base64 (should work with any nvram command output):
Code:
printf "$(echo -n 'w%00%00%00' | sed -E '/\\/s//\\\\/g;/%/s//\\x/g')" | base64

dwAAAA==
 
Last edited:
Can someone please tell my why my Macpro 5,1 still says " This mac is not supported" and all disks greyed out after booting in Opencore and trying to install Catalina? Do I need a modified version of Catalina?

I have searched everywhere for the answer???
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.