I've never used OpenCore. My guess is you need OpenCore to fake the SMBIOS of a Catalina supported Mac, or you need it to add to the nvram boot-args the following "-no_compat_check"
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
Follow the first post instructions and enable VMM spoofing.
[automerge]1575883166[/automerge]
No need to use SMBIOS spoofing at all, just VMM flag spoofing.
Two things to check:
Did you really boot from OC?
If yes what s the:
Code:
nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-versionhave you blessed the opencore.efi?
or do you have -no_compat_check in the boot arguments of the config file?
or do you have :
Code:
b) Enable the VMM flag: Find the Cpuid1Mask entry, and carefully change AAAAAAAAAAAAAAAAAAAAAA== to AAAAAAAAAAAAAACAAAAAAA==. The value should now be the same as for Cpuid1Data.-no_compat_check is not enough for installing, the installer will reject based on board-id. VMM flag spoofing is needed.
That was my third choice. Certainly using VMM or -no_compat_check are easier/safer than SMBIOS spoof. The posted problem is about the installer. -no_compat_check alone requires modification to the installer (dosdude1's Catalina Patcher)? If so, the installer created by dosdude1's Catalina Patcher is supposed to be useable on supported Macs - does it do something weird to the installation on MacPro5,1 if you don't use the post installer? Or maybe the post installer is automatically run? Does an unpatched installer behave differently between the three options?
After macOS is installed, you'll want to choose one of the three options depending on the behavior you want.
The first post doesn't describe all the reasons why you would want to use the VMM option. There should be a Pros and Cons section in the first post. Here's some Pros:
1) Updates are enabled. With the Patcher macOS updates aren't automatic. This is mentioned under part 7 "Updates" of the first post but maybe there could be moved to a new Pros and Cons section.
2) Patches are not required to be installed. I'm not sure what the benefits of this are, except that the system is unmodified.
3) OpenCore has features that may be useful for unsupported Macs. I don't know what all the useful features are, but some of the more important ones are:
a) Modifying platform information (SMBIOS). This is mentioned in part 9 of the first post. It doesn't describe why you might want to do that. HEVC encoding?
b) Modify ACPI (maybe for HEVC encoding; add Thunderbolt? )
c) Add device properties (does this work in OpenCore on real Macs?)
etc.
In the first post, the following line:
Code:
nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM | awk '{split($NF,chars,""); for(n=0;n<256;n++){ord[sprintf("%c",n)]=n}; i=1; j=0; while(i<=length($NF)){if(substr($NF,i,1)=="%"){printf "%s",toupper(substr($NF,i+1,2)); i=i+2} else {printf "%x",toupper(ord[chars[i]])} j=j+2; i++} print("")}' | xxd -r -p | base64
Code:
a=4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM; printf "$(nvram $a | sed -E '/^'$a'.(.*)/s//\1/g;/\\/s//\\\\/g;/%/s//\\x/g')" | base64I wasn't able to achieve full HEVC encode/decode even with SMBIOS spoofing. There is a software Videoproc which "claims" that the HEVC encoding work on a modified SMBIOS. In reality it does not. It actually thinks Intel quicksync is enabled if the machine is imacpro so it "claims" HEVC encoding work. OC is more flexible as far as options can be implemented. That includes device properties and so on. We can also modify the OC and compile as we need it as the source code with the patches is available.
My experience so far. As long as VideoProc says HEVC HWAccel work, both HEVC hardware encode and decode works.
e.g. This is how my Radeon VII hardware decode H264, and hardware encode HEVC in FFMpeg.
And the HWAccel HEVC support is at system level. Something as simple as QuickTime Player can also use hardware HEVC encoding (please use Chromium base browser to watch at 4K, otherwise, may be hard to read the text / detail).
There is no Intel iGPU in the iMac Pro, the idea of using iMac Pro SMBIOS is exactly to avoid the system using Intel Quick Sync, but make it use AMD UVD and VCE.
MP5,1 don't need dosdude1 patches at all, differently from MP3,1 and MP4,1 or any other Mac that have an earlier than Westmere Xeon/Ivy Bridge i5/i7.
With a MP5,1 that have a Westmere Xeon, you just need the Hypervisor framework VMM flag spoof from OpenCore. Earlier Macs, like MP3,1, MP4,1 or MP5,1 with Nehalem Xeons, don't support Hypervisor.framework and that is required for the VMM bypass of the distribution file.
MM6,1
MP3,1:
With Macs that have processors older than Westmere, the only alternative is SMBIOS spoofing or dosdude1 patched install.
You can check if your Mac supports Hypervisor.framework with sysctl kern.hv_support:
Code:
sysctl machdep.cpu.brand_string; sysctl kern.hv_supporthttps://forums.macrumors.com/threads/activate-amd-hardware-acceleration.2180095/post-27980340
Here is an example of fooled VideoProc. Neither cmP nor the imacpro have Intel. but that is how Videoproc treats it. Plus Videoproc itself cannot decode the HEVC no matter what.
Documentation about Apple Hypervisor framework:
https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/ 229
https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/ 229
Except for the original wifi. The 10.15.1 patcher from dosdude has an option to patch it when booting from it or the correct kext from Mojave can be loaded instead, but still oob the wifi does not work.
I know VideoProc cannot correctly identify the cMP is using AMD HWAccel but not Intel Quick Sync. I won't be too surprised for that. 99% Mac out there use Quick Sync, but not AMD HWAccel. It's very likely the developer simply programmed the macOS version VideoProc "as long as HWAccel is detected, then display Intel at that UI"
Besides, I already proved that full HEVC HWAccel can work on cMP by using OpenCore SMBIOS spoofing. Video provided.
If that doesn't work on your setup. It should be you did something wrong, but not OpenCore SMBIOS method doesn't work.
Your argument (e.g. VideoProc shows "Intel") isn't related to "if HEVC HWAccel really works on the cMP". I never ever suggest anyone use VideoProc to convert video, I also mentioned quite a few times that "Intel" is cosmetic error. I only recommend people use VideoProc HWAccel page as a quick check if HWAccel is activated correctly.
Anyway, I just make another two screen recording to show that VideoProc can encode and decode HEVC / H264.
1) HEVC to H264 video conversion by VideoProc. CPU usage, IOReg (terminal), and conversion speed suggest VideoProc hardware decode HEVC, and hardware encode H264
2) H264 to HEVC video conversion by VideoProc. CPU usage, IOReg (terminal), and conversion speed suggest VideoProc hardware decode H264, and hardware encode HEVC
This is by using OpenCore to spoof the SMBIOS (as iMac Pro), that's why the reported CPU speed is 3.5GHz for my W3690.
So, it can work properly, even in VideoProc. Just the UI shows Intel, but that doesn't really matter, won't affect the function.
Last edited:
This is with Mojave. I can't even boot to Catalina with my dual Xeons with spoofed iMac Pro bios. It panics on boot. You probably have some other tweaks or remnants from non OC WEG setup or plist patches.
May I know what's wrong in your screen capture?
If you want to show QuickTime cannot export 4K, then most likely because your source video isn't 4K, and QuickTime won't give you the option to upscale the video.
Anyway, if the discussion is purely about HWAccel, but not "if OpenCore can make HWAccel work", then we better go back to the HWAccel thread to discuss.
A slightly shorter line using perl:
Code:
a=4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM; printf "$(nvram $a | perl -pe 's/^'$a'.//;s/\\/\\\\/g;s/%/\\x/g')" | base64
Code:
a=4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM; printf "$(nvram $a | sed -E 's/^'$a'.//;s/\\/\\\\/g;s/%/\\x/g')" | base64
Last edited:
In my 3,1 on 10.14.6 with RX 580 using OC SMBIOS spoofing I get full h264/HEVC encode / decode.
I haven't tried 10.15 at this time as I see no real urge to go there, and the times I have tried have failed in the installer and I've not dedicated the time to debug it.
Using handbrake I've done some re-encoding tests with various sources and see a massive performance increase in FPS for encoding into HEVC using video toolbox.
I also shared examples of using ffmpeg from the command line in the AMD acceleration thread, so if I can do it on my 3,1 spoofing imacpro via OC, you certainly should be able to in a 5,1.
My guess is you aren't spoofing the board-id correctly and the debug tool from Apple I mentioned in the AMD thread is not reporting the iMacPro board ID but is showing the 5,1 board ID.
Ok. The encoding/decoding both work with SMBIOS spoofing in Mojave. Don't expect though the Videoproc to even play (decode) the HEVC without CPU usage even though it claims HEVC encoding and decoding is enabled. Quicktime on the other hand encodes only through the GPU. ShikiGVA=160 is not used only SMBIOS of iMac Pro. Catalina will not boot with this configuration with dual CPU's. There is a recorded bug on GitHub and there is no solution for that. CPUfriend or other kexts don't help the situation. This can only be used if somebody wants to do HEVC encoding but one has to be signed out from Apple account or avoid using FaceTime or iMessage to avoid account blocking from Apple.
Dosdude1's patcher can install a vanilla Catalina to the cMP5.1 provided the no_compat_check is present. If you set the options in the menu before you start you can select the installer not to apply the APFS patch and not to do any post install patches. The installer is patched so it can run-on the cMP5.1 but nothing weird happens to the actual Catalina installation. In this mode you end up with a vanilla Catalina. However, OTA updates to Catalina will not work.
NVRAM reset from the OC boot screen restored the chime loud and clear.
[automerge]1576068608[/automerge]
After NVRAM reset with this value for csrutil in the configuration:
I got this protection disabled:
[automerge]1576068608[/automerge]
After NVRAM reset with this value for csrutil in the configuration:
Code:
<key>csr-active-config</key>
<data>5wMAAA==</data>
Code:
csrutil status
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
BaseSystem Verification: disabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.Thats 0x03e7 = 8 bits are set.
There are 11 flags:
Code:
#define CSR_ALLOW_UNTRUSTED_KEXTS (1 << 0)
#define CSR_ALLOW_UNRESTRICTED_FS (1 << 1)
#define CSR_ALLOW_TASK_FOR_PID (1 << 2)
#define CSR_ALLOW_KERNEL_DEBUGGER (1 << 3)
#define CSR_ALLOW_APPLE_INTERNAL (1 << 4)
#define CSR_ALLOW_UNRESTRICTED_DTRACE (1 << 5)
#define CSR_ALLOW_UNRESTRICTED_NVRAM (1 << 6)
#define CSR_ALLOW_DEVICE_CONFIGURATION (1 << 7)
#define CSR_ALLOW_ANY_RECOVERY_OS (1 << 8)
#define CSR_ALLOW_UNAPPROVED_KEXTS (1 << 9)
#define CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE (1 << 10)The usual SIP disabled value is 0x67 which does not include CSR_ALLOW_DEVICE_CONFIGURATION, CSR_ALLOW_ANY_RECOVERY_OS, and CSR_ALLOW_UNAPPROVED_KEXTS.
I don't know if I interpreted that correctly, since the output says "Apple Internal: disabled" but CSR_ALLOW_APPLE_INTERNAL isn't set. I guess we should check each bit of csr-active-config one at a time...
Actually it is 0x77 when csrutil disable command is issued. Nevertheless I am having issues blessing the opencore.efi from Catalina. Before I could do it. Even when I set 0x77 from the recovery partition. As I said opencore breaks some XML structure in the firmware. If I restore my firmware it will work. I can't figure out what is broken. It can'set the boot order but it sets the boot arguments.
Isn't 0x77 the value set by dosdude1's Catalina Patcher? My MacMini 2018 has 0x67. May MacPro3,1 has 0x77.
Some of the boot variables use xml.
Code:
nvram -p | grep '<'By boot args, do you mean the boot-args nvram variable?
By boot order, do you mean the EFI BootOrder, Boot0001, Boot0002, ... variables?
https://wikileaks.org/ciav7p1/cms/page_27262978.html
The EFI Shell can dump all the nvram variables at once. The nvram command seems to only output the Apple nvram variables - other variables need to be referenced by name and include a UUID.
I don't think you're supposed to mess with the BootOrder variables on a Mac, but according to the output from my MacPro3,1 in macOS, some programs have modified the EFI boot* variables. They seem ok though.
Code:
nvramp () { printf "$(nvram $1 | sed -E '/^'$1'./s///;s/\\/\\\\/g;s/%/\\x/g')" }
bootvar () {
thebytes=$(nvramp 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:$1 | xxd -p -c 99999)
theflag=$((0x${thebytes:6:2}${thebytes:4:2}${thebytes:2:2}${thebytes:0:2}))
thenum=0x${thebytes:10:2}${thebytes:8:2}
thestring=$(xxd -p -r <<< ${thebytes:12} | iconv -f UTF-16LE -t UTF-8 | tr '\0' '\n' | sed -n -E '1p' | tr -d '\n')
thepath=${thebytes:12 + (${#thestring}+1) * 4}
echo -n "$theflag, $thenum, "'"'"$thestring"'" : '
[[ -n $thebytes ]] && DevicePathUtil $thepath
}
nvramp 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootOrder | xxd -p -c 99999 | sed -E 's/(..)(..)/Boot\2\1 /g'
Boot0080 Boot0000
bootvar Boot0080
1, 0x004a, "Mac OS X" : PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(11,GPT,01A40057-B54C-4974-AF84-A70CD2E937FF,0x6FC68A00,0x19088)
# Catalina Boot set by bless command
bootvar Boot0081
1, 0x0108, "Mac OS X" : PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(8,GPT,977D4C1D-54CA-4594-B9F6-FCABF87AC36C,0x4B405D88,0x174876E8)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,7E98A08505BD8940A1199C16AA7CD67D)/\10D5CE8C-43FE-43F2-8089-DAEDF6485644\System\Library\CoreServices\boot.efi
# Preboot of Mojave6
bootvar Boot0082
0, 0x, "" : nvram: Error getting variable - '8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0082': (iokit/common) data was not found
bootvar Boot0000
1, 0x0062, "ubuntu" : HD(1,GPT,19D44A4A-72CE-488C-869C-32776991515D,0x28,0x64000)/\EFI\ubuntu\shimx64.efi
# ubuntu shim
Code:
➜ ~ nvramp () { printf "$(nvram $1 | sed -E '/^'$1'./s///;s/\\/\\\\/g;s/%/\\x/g')" }
➜ ~ sudo nvramp () { printf "$(nvram $1 | sed -E '/^'$1'./s///;s/\\/\\\\/g;s/%/\\x/g')" }
➜ ~
➜ ~ nvramp () { printf "$(nvram $1 | sed -E '/^'$1'./s///;s/\\/\\\\/g;s/%/\\x/g')" }
bootvar () {
thebytes=$(nvramp 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:$1 | xxd -p -c 99999)
theflag=$((0x${thebytes:6:2}${thebytes:4:2}${thebytes:2:2}${thebytes:0:2}))
thenum=0x${thebytes:10:2}${thebytes:8:2}
thestring=$(xxd -p -r <<< ${thebytes:12} | iconv -f UTF-16LE -t UTF-8 | tr '\0' '\n' | sed -n -E '1p' | tr -d '\n')
thepath=${thebytes:12 + (${#thestring}+1) * 4}
echo -n "$theflag, $thenum, "'"'"$thestring"'" : '
[[ -n $thebytes ]] && DevicePathUtil $thepath
}
<key>csr-active-config</key>
<data>B/8=</data>
csrutil status
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
BaseSystem Verification: disabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.