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

[h9826790]

My goal is to continue to update my Mac with Catalina and beyond natively but I would like to update my GPU and have hardware acceleration. For now I will use VMM flag to update and when I update the GPU I will try again.

Thanks for the help
[automerge]1573899433[/automerge]

machdep.cpu.brand_string: Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz

Thanks for your help earlier, I am now a bit clearer about the hardware requirements for everything I want to work thanks to you and the other kind people who have replied.

For your info, AMD HWAccel may be removed from future Catalina.

I don't know if this is just a "beta bug" at this moment, or Apple did that intentionally. But AFAIK, all HEVC HWAccel entry in RadeonX4000 info.plist is removed by Apple in the latest beta.

In worst case, Apple may move HWAccel to T2 for all newer Mac (include iMac Pro and 7,1), and keep using Intel QuickSync for older Mac (until all supported Mac has T2). And phase out AMD HWAccel in future macOS updates.

If this really happen, cMP users will lost all HWAccel in future Catalina (and beyond). And if we insist to stay at 10.15.1, then we will not receive any security update.

It's hard to tell what will happen at this moment. But please don't expect OpenCore can be the solution for everything as this moment.

If all you want is just "run Catalina like natively support". Please follow the steps in post #1.

If you want full HWAccel, my suggestion is to get a Vega (include Vega20), then stay at Mojave. Only use OpenCore to inject the board-id Mac-7BA5B2D9E42DDD94. I tested this few hours ago, there is no need to ident as iMac Pro in order to get full HWAccel. Just inject the board-id is good enough. In any case, R9 280 won't give you any HWAccel in macOS. And since Polaris HEVC HWAccel already removed in the latest Catalina beta. I also suggest avoid Polaris card, but go straight to Vega. At least, we still have a hope that the T2 on iMac Pro isn't work that well, and Apple will continue to provide HWAccel support for iMac Pro's Vega. So that we can also benefit from it.

 

[startergo]

For your info, AMD HWAccel may be removed from future Catalina.

I don't know if this is just a "beta bug" at this moment, or Apple did that intentionally. But AFAIK, all HEVC HWAccel entry in RadeonX4000 info.plist is removed by Apple in the latest beta.

In worst case, Apple may move HWAccel to T2 for all newer Mac (include iMac Pro and 7,1), and keep using Intel QuickSync for older Mac (until all supported Mac has T2). And phase out AMD HWAccel in future macOS updates.

If this really happen, cMP users will lost all HWAccel in future Catalina (and beyond). And if we insist to stay at 10.15.1, then we will not receive any security update.

It's hard to tell what will happen at this moment. But please don't expect OpenCore can be the solution for everything as this moment.

If all you want is just "run Catalina like natively support". Please follow the steps in post #1.

If you want full HWAccel, my suggestion is to get a Vega (include Vega20), then stay at Mojave. Only use OpenCore to inject the board-id Mac-7BA5B2D9E42DDD94. I tested this few hours ago, there is no need to ident as iMac Pro in order to get full HWAccel. Just inject the board-id is good enough. In any case, R9 280 won't give you any HWAccel in macOS. And since Polaris HEVC HWAccel already removed in the latest Catalina beta. I also suggest avoid Polaris card, but go straight to Vega. At least, we still have a hope that the T2 on iMac Pro isn't work that well, and Apple will continue to provide HWAccel support for iMac Pro's Vega. So that we can also benefit from it.

You said firmware revision and feature mask also changes something. Do we need those?

 

[h9826790]

You said firmware revision and feature mask also changes something. Do we need those?

No.

When boot with board-id Mac-7BA5B2D9E42DDD94, the featureMask reported in AGDCDiagnose also changed from 0x500000 (native 5,1 boot) to 0x108200 (OpenCore boot with only board-id spoofing, but keep all other variable as close to cMP stock config as possible, including serial number etc).

And this seems nothing related to FirmwareFeatureMask (one of the OpenCore setting).

I still have no idea if that featureMask 0x108200 has any relationship to HWAccel yet.

 

[h9826790]

Just spotted a potential issue when boot with board-id Mac-7BA5B2D9E42DDD94 via OpenCore.

CPU Power status is missing.

Under normal situation. CPU_Speed_Limit should be recorded and reported

This may help to explain why the GB5 score seems a bit lower than normal. Turbo boost may not able to function correctly when lack of CPU power status.

This is from native boot.

This is OpenCore boot with board-id spoofing

The single core penalty is about 7%, multi core penalty is about 3.5%, very very close to the expected performance difference that Turbo Boost can bring to a W3690.

 

[h9826790]

Linpack also shows similar result. When boot as 5,1 natively. CPU speed shows 3.73GHz during test start.

But when boot with board-id Mac-7BA5B2D9E42DDD94. CPU speed reduce to 3.46GHz

 

[startergo]

Linpack also shows similar result. When boot as 5,1 natively. CPU speed shows 3.73GHz during test start.
View attachment 877564

But when boot with board-id Mac-7BA5B2D9E42DDD94. CPU speed reduce to 3.46GHz
View attachment 877563

We might have to use the Pike R. Alpha SSDT generator:

Quick Guide to Generate a SSDT for CPU Power Management

Piker Alpha's ssdtPRGen script will generate a SSDT you can use to achieve the maximum amount of power states for your desktop CPU. Please note that desktop power management is not mandatory. Requirements: Working internet connection How to Generate a SSDT for Power Management 1. Configure...

www.tonymacx86.com

We will need to extract the ACPI with hackintool booted normally without OC.

 

[h9826790]

We might have to use the Pike R. Alpha SSDT generator:

Quick Guide to Generate a SSDT for CPU Power Management

Piker Alpha's ssdtPRGen script will generate a SSDT you can use to achieve the maximum amount of power states for your desktop CPU. Please note that desktop power management is not mandatory. Requirements: Working internet connection How to Generate a SSDT for Power Management 1. Configure...

www.tonymacx86.com

We will need to extract the ACPI with hackintool booted normally without OC.

I boot as 5,1 natively (no OpenCore)

Run Hackintool to dump ACPI

Put all aml files in the /EFI/EFI/OC/ACPI

And add them in the config plist

    <key>ACPI</key>
    <dict>
        <key>Add</key>
        <array>
            <dict>
                <key>Comment</key>
                <string>My custom DSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>DSDT.aml</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string>My custom SSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT-1.aml</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string>My custom SSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT-2.aml</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string>My custom SSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT.aml</string>
            </dict>
        </array>

But still the same reported CPU clock speed when boot with Board-ID spoofing, and no noticeable improvement in Linpack / GB5.

Anyway, it seems the Pike R. Alpha SSDT generator doesn't work W3690

And if try to get AppleIntelInfo from Hackintosh, the cMP will crash straight away and self reboot.

 

[startergo]

I boot as 5,1 natively (no OpenCore)

Run Hackintool to dump ACPI

Put all aml files in the /EFI/EFI/OC/ACPI
View attachment 877595

And add them in the config plist

    <key>ACPI</key>
    <dict>
        <key>Add</key>
        <array>
            <dict>
                <key>Comment</key>
                <string>My custom DSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>DSDT.aml</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string>My custom SSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT-1.aml</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string>My custom SSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT-2.aml</string>
            </dict>
            <dict>
                <key>Comment</key>
                <string>My custom SSDT</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT.aml</string>
            </dict>
        </array>

But still the same reported CPU clock speed when boot with Board-ID spoofing, and no noticeable improvement in Linpack / GB5.

Anyway, it seems the Pike R. Alpha SSDT generator doesn't work W3690
View attachment 877605

And if try to get AppleIntelInfo from Hackintosh, the cMP will crash straight away and self reboot.

You need to drop OEM first to use the patched one:

OpenCore General Discussion

www.insanelymac.com

 

[CMMChris]

No need for SSDT. Use CPUFriend.kext and CPUFriendDataProvider.kext
To generate CPUFriendDataProvider.kext run:

• cd ~/Desktop
• git clone https://github.com/PMheart/CPUFriend
• cd ./CPUFriend/Tools
• ./ResourceConverter.sh --kext /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/<BOARD-ID-OF-YOUR-MAC-PRO>.plist

Now inject both and proper CPU power management should be up and running again. Please note that CPUFriend depends on Lilu.

 

[startergo]

No need for SSDT. Use CPUFriend.kext and CPUFriendDataProvider.kext
To generate CPUFriendDataProvider.kext run:

• cd ~/Desktop
• git clone https://github.com/PMheart/CPUFriend
• cd ./CPUFriend/ResourceConverter
• ./ResourceConverter.sh --kext /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/<BOARD-ID-OF-YOUR-MAC-PRO>.plist

Now inject both and proper CPU power management should be up and running again. Please note that CPUFriend depends on Lilu.

It should be:

cd ~/Desktop
git clone https://github.com/PMheart/CPUFriend
cd ./CPUFriend/Tools
./ResourceConverter.sh --kext /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/<BOARD-ID-OF-YOUR-MAC-PRO>.plist

The problem is there is no Mac-F221BEC8 in that folder.

Edit:
Also when building with Xcode there is an error:

Build input file cannot be found: '/Users/g5/Desktop/CPUFriend/Lilu.kext/Contents/Resources/Library/plugin_start.cpp' (in target 'CPUFriend' from project 'CPUFriend')

I looked inside Lilu and there is no "Resources" folder

 

[Ludacrisvp]

It should be:

cd ~/Desktop
git clone https://github.com/PMheart/CPUFriend
cd ./CPUFriend/Tools
./ResourceConverter.sh --kext /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/<BOARD-ID-OF-YOUR-MAC-PRO>.plist

The problem is there is no Mac-F221BEC8 in that folder.

It’s my understanding that if you are using the imacpro board ID then you should use that board ID in this command.

 

[startergo]

Well I did exactly that cause I couldn't find the cMP board but it did not work. I even put Lilufriend inside kexts folder as well but it still did not work.

 

[h9826790]

You need to drop OEM first to use the patched one:

Still no effect yet

    <key>ACPI</key>
    <dict>
        <key>Add</key>
        <array>
            <dict>
                <key>Comment</key>
                <string>PMRef CpuPPM</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT.aml</string>
            </dict>
        </array>
        <key>Block</key>
        <array>
            <dict>
                <key>All</key>
                <true/>
                <key>Comment</key>
                <string>Drop PmRef</string>
                <key>Enabled</key>
                <true/>
                <key>OemTableId</key>
                <data>UG1SZWY=</data>
                <key>TableLength</key>
                <integer>0</integer>
                <key>TableSignature</key>
                <data>U1NEVA==</data>
            </dict>
        </array>

 

[CMMChris]

It should be:

Ah folder changed, thanks for the correction. Haven't done it in a while.

Also when building with Xcode there is an error:

What are you trying to build in Xcode?

It’s my understanding that if you are using the imacpro board ID then you should use that board ID in this command.

This is wrong and makes absolutely no sense. Just think about it: You spoof a different SMBIOS or Board-ID than the one suitable for your Mac. macOS will use a wrong power management configuration due to this. CPUFriend is for injecting custom power management data. So of course you need to use the power management data of your mac model and not a different one.

I couldn't find the cMP board

You mean the Mac Pros don't have a .plist inside X86PlatformPlugin? Since I am not familiar with them: Do the old cMPs use the X86PlatformPlugin at all or do they run on SMCPlatformPlugin?

Still no effect yet

Stop dropping and replacing stock ACPI stuff. It's not necessary on a real Mac.

 

[h9826790]

Stop dropping and replacing stock ACPI stuff. It's not necessary on a real Mac.

I know, but nothing hurt (to me) anyway. I am happy to run this kind of test. At least now we confirmed that won't help.

 

[startergo]

What are you trying to build in Xcode?

I was just following the instructions for that kext. But now I realized it needs the source code for Lilu in its folder not the prebuild version

You mean the Mac Pros don't have a .plist inside X86PlatformPlugin?

It looks like cMP5.1 has never been supported:

Quick Guide to Generate a SSDT for CPU Power Management

Piker Alpha's ssdtPRGen script will generate a SSDT you can use to achieve the maximum amount of power states for your desktop CPU. Please note that desktop power management is not mandatory. Requirements: Working internet connection How to Generate a SSDT for Power Management 1. Configure...

www.tonymacx86.com

 

[CMMChris]

No idea why you want to compile CPUFriend yourself. Just download the prebuilt version from Acidanthera. The DataProvider doesn't need to be compiled. It's just a script that creates a codeless Kext with power management data that is injected by CPUFriend.

Again my question: Do the cMP use X86PlatformPlugin or SMCPlatformPlugin? When using SMCPlatformPlugin the "No CPU power status has been recorded" message apparently is normal.

I run my Hackintosh (i7-8700k) using SMCPlatformPlugin since it provides more speed steps. I haven't observed any reduction in performance. In fact, benchmark scores are higher in my case compared to X86PlatformPlugin taking control (compared with power management data of the recent iMacs and the 2018 Mac Mini).

 

[Ludacrisvp]

This is wrong and makes absolutely no sense. Just think about it: You spoof a different SMBIOS or Board-ID than the one suitable for your Mac. macOS will use a wrong power management configuration due to this. CPUFriend is for injecting custom power management data. So of course you need to use the power management data of your mac model and not a different one.

It would seem to me that since we are telling macOS that we have an iMacPro1,1 board ID that we would want to use that board ID so that the settings associated to that ID gets used. Based on the command usage it seemed to me that we are updating the kext and modifying the values associated to the board ID. So if we identify as iMacPro’s board ID and we are updating the values in the plist for that board ID I don’t see how we could be using the wrong power management configuration.

You mean the Mac Pros don't have a .plist inside X86PlatformPlugin? Since I am not familiar with them: Do the old cMPs use the X86PlatformPlugin at all or do they run on SMCPlatformPlugin?

I can’t speak for the 5,1 in this regard but the 3,1 at least does not use the X86PlatformPlugin, it definitely uses the SMCPlatformPlugin.

 

[CMMChris]

So if we identify as iMacPro’s board ID and we are updating the values in the plist for that board ID I don’t see how we could be using the wrong power management configuration.

You don't have an iMac Pro. Your cMP has a different processor. Thus power management of iMacPro1,1 doesn't match and you don't wanna use it.

 

[Ludacrisvp]

You don't have an iMac Pro. Your cMP has a different processor. Thus power management of iMacPro1,1 doesn't match and you don't wanna use it.

in order to get the restricted functionality we are pretending that we do have an iMacpro.

Yeah that’s what I thought this was correcting... that it would replace the cpu power management values removing the ones for the imacpro processors and injecting it with the correct ones for the cMP.

 

[CMMChris]

I am not sure if CPUFriend works with the SMCPlatformPlugin.
You can try generating a DataProvider Kext with:
./ResourceConverter.sh --kext /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/<MAC_NAME>.plist

There are:
- MacPro1_1.plist
- MacPro2_1.plist
- MacPro3_1.plist
- MacPro4_1.plist
- MacPro5_1.plist

 

[Charmandrigo]

Unfortunately, OpenCore does not support booting legacy installations of Windows. You can, however, still boot Windows (and Catalina for that matter) without OC. See part 10 of the guide. Just remember to re-enable OC for system updates.

There's an issue when disabling the boot-args, done that within the Catalina's Recovery partition and then disabled OC, I can boot windows but then, when using the Bootcamp manager to boot back to MacOS, the boot-args get enabled again, PC shut down as expected when boot-args are enabled, I have to boot back to Mojave, repeat the OC enabling process in order to return to catalina, is a bit tedious but I don't know why the boot-args enabled again by itself

 

[cdf]

I have to boot back to Mojave, repeat the OC enabling process in order to return to catalina, is a bit tedious but I don't know why the boot-args enabled again by itself

Let me try to shed some light on this: For Catalina to work on the cMP, the -no_compat_check boot argument is required. The configuration in the guide ensures that OC always automatically sets the boot-arg variable during boot, even if you manually changed the variable in terminal using the nvram command before rebooting.

However, because OC sets variables as volatile, they are no longer present after a reboot without OC. This is why it is important to set the variable manually immediately before the first non-OC reboot. That way when you select your Catalina disk in Boot Camp Control Panel, your machine will be able to boot, albeit without OC.

There are other ways to manage the NVRAM with OC. If you change

<key>Block</key>
<dict>
    <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
    <array>
        <string>boot-args</string>
    </array>
</dict>

to

<key>Block</key>
<dict/>

then OC will only set the boot-arg variable during boot if the variable isn't already there. That way you can set it manually whenever you want and have it still there when rebooting without OC. The disadvantage is that if you set the boot-arg variable with something other than -no_compat_check, then OC will not add it.

 

[Charmandrigo]

Let me try to shed some light on this: For Catalina to work on the cMP, the -no_compat_check boot argument is required. The configuration in the guide ensures that OC always automatically sets the boot-arg variable during boot, even if you manually changed the variable in terminal using the nvram command before rebooting.

However, because OC sets variables as volatile, they are no longer present after a reboot without OC. This is why it is important to set the variable manually immediately before the first non-OC reboot. That way when you select your Catalina disk in Boot Camp Control Panel, your machine will be able to boot, albeit without OC.

There are other ways to manage the NVRAM with OC. If you change

<key>Block</key>
<dict>
    <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
    <array>
        <string>boot-args</string>
    </array>
</dict>

to

<key>Block</key>
<dict/>

then OC will only set the boot-arg variable during boot if the variable isn't already there. That way you can set it manually whenever you want and have it still there when rebooting without OC. The disadvantage is that if you set the boot-arg variable with something other than -no_compat_check, then OC will not add it.

Alright, then I need to disable OC first before disabling the boot args to boot Catalina natively and being able to boot Windows on legacy boot.
the catalina recovery isn't device locked right? If OC is disabled I can still access the Catalina recovery then?

 

[cdf]

the catalina recovery isn't device locked right? If OC is disabled I can still access the Catalina recovery then?

I believe you still need -no_compat_check for recovery. Perhaps somebody can confirm this.