HP EliteDesk 800 G4 / G5 Mini with RX560x dGPU (hackintosh)

[deeveedee]

Open Core 1.0.4 has been released.  I don't see anything in the release or updated Acidanthera kexts that is important to this HackMini8,1, so I will not be creating an OC 1.0.4 EFI any time soon.  I hope everyone is enjoying this hack.  It's my favorite of all the hacks I've created.

 

EDIT: For those who want to upgrade their EFI to OC 1.0.4, here are the updates that I see.  At the time of this post, VirtualSMC 1.3.5 compiled kext has not yet been posted (only the source).

 

• Upgrade BOOT/BOOTx64.efi
• Upgrade OC/OpenCore.efi
• Upgrade OC/Drivers/*.* (except HfsPlus.efi)
• Upgrade OC/Tools/*.*
• Upgrade OC/Kexts
  • AppleALC.kext 1.9.3 -> 1.9.4
  • VirtualSMC.kext 1.3.4 -> 1.3.5
    • SMCSuperIO.kext 1.3.4 -> 1.3.5
    • SMCProcessor.kext 1.3.4 -> 1.3.5
• OC/config.plist
  • Add Booter > Quirks > ClearTaskSwitchBit (Boolean, False)

 

EDIT: The compiled VirtualSMC 1.3.5 kexts are now posted.

Edited March 5, 2025 by deeveedee

[ird]

FYI came across this PSA on github regarding userspace lilu patching. I personally only use Bluetoolfixup out of the list in there. I can't say I've experienced anything particular when it comes to instability but perhaps others have something to add in case, in case they do.

 

https://github.com/orgs/ChefKissInc/discussions/64

[LockDown]

@ird 

iirc @deeveedee mentioned this before.

For my "APFS Volume Hash Mismatch" issue, it was the BluetoolFixup +  RestrictEvent causing it.

[deeveedee]

As I mentioned before, there is nothing that I see in Open Core 1.0.4 or the latest Acidanthera kexts that improves our EFI over my Open Core 1.0.3 EFI.  That said, I have upgraded to Open Core 1.0.4 and have uploaded my new EFI as an attachment to Post #1.

 

The changes from my OC 1.0.3 EFI to OC 1.0.4 EFI are as follows:

• Upgrade BOOT/BOOTx64.efi
• Upgrade OC/OpenCore.efi
• Upgrade OC/Drivers/*.* (except HfsPlus.efi)
• Upgrade OC/Tools/*.*
• Upgrade OC/Kexts
  • AppleALC.kext 1.9.3 -> 1.9.4
  • VirtualSMC.kext 1.3.4 -> 1.3.5
    • SMCSuperIO.kext 1.3.4 -> 1.3.5
    • SMCProcessor.kext 1.3.4 -> 1.3.5
• Removed Kext SMCRadeonSensors.kext (leaving the disabled Kernel > Add entry in OC config.plist)
• OC/config.plist
  • Add Booter > Quirks > ClearTaskSwitchBit (Boolean, False)
  • Disabled Kernel > Add entry for SMCRadeonSensors.kext (enable this if you download SMCRadeonSensors.kext to your OC/Kexts folder)

 

I have removed SMCRadeonSensors.kext from my posted EFI, since the author is soliciting donations.  If you want to add SMCRadeonSensors.kext to your EFI, download it to your OC/Kext folder from here and enable the associated Kernel > Add entry in OC's config.plist.

[deeveedee]

Has anyone noticed that their RX560x fan runs more under Sequoia 15.4 Release Candidate than in Sequoia 15.3.2?  I haven't collected any data, so my suspicions are only perceived at this time, but my RX560x fan (not CPU fan) is noticeably louder running the same apps.  With Sequoia 15.3.2, my RX560x fan is virtually silent.  With Sequoia 15.4 RC, the RX560x fan is noticeably louder.  I am booting Sequoia 15.3.2 and Sequoia 15.4 RC with the OC 1.0.4 EFI attached to Post #1.

 

If I have time to collect measurements, I will report back here in this post.

 

EDIT: The addition of Radeon dGPU property PP,PP_WorkLoadPolicyMask = 0x04 (POWERSAVING_WORKLOAD) makes no difference in performance/fan.  Note that I have never found any PP_WorkLoadPolicyMask values to affect the performance of this RX 560x.

Edited March 26, 2025 by deeveedee

[ird]

8 hours ago, deeveedee said:

Has anyone noticed that their RX560x fan runs more under Sequoia 15.4 Release Candidate than in Sequoia 15.3.2?  I haven't collected any data, so my suspicions are only perceived at this time, but my RX560x fan (not CPU fan) is noticeably louder running the same apps.  With Sequoia 15.3.2, my RX560x fan is virtually silent.  With Sequoia 15.4 RC, the RX560x fan is noticeably louder.  I am booting Sequoia 15.3.2 and Sequoia 15.4 RC with the OC 1.0.4 EFI attached to Post #1.

 

If I have time to collect measurements, I will report back here in this post.

 

EDIT: The addition of Radeon dGPU property PP,PP_WorkLoadPolicyMask = 0x04 (POWERSAVING_WORKLOAD) makes no difference in performance/fan.  Note that I have never found any PP_WorkLoadPolicyMask values to affect the performance of this RX 560x.

 

I'm still on 15.3.2, but is the GPU usage spiking? Activity monitor should show what process is taking up GPU time. There are also some terminal tools that can show this info, see here: Is there a terminal script or tool to monitor the M1 GPU and MEM usage in real time? : r/MacOS

 

[deeveedee]

@ird Thanks for the advice.  Activity Monitor confuses me.  In Sequoia 15.4 RC, Activity Monitor doesn't show any GPU utilization when I'm streaming video in Firefox (regardless of whether I'm displaying video on the dGPU-connected display).  Again, I'm booting 15.4 and 15.3.2 with the same EFI attached to Post #1 (although I have added/enabled SMCRadeonSensors.kext 2.4.0).  I won't be making any further attempts to diagnose/debug until 15.4 is officially released.

 

Sequoia 15.4 RC

 

Sequoia 15.3.2

 

EDIT: Keep in mind that I am enabling multiple displays with SMBIOS MacMini8,1 and a non-headless (headed?) iGPU Framebuffer, so my dGPU observations are likely to be different from those observed when using SMBIOS iMac19,x / headless iGPU.

Edited March 27, 2025 by deeveedee

[ird]

2 hours ago, deeveedee said:

@ird Thanks for the advice.  Activity Monitor confuses me.  In Sequoia 15.4 RC, Activity Monitor doesn't show any GPU utilization when I'm streaming video in Firefox (regardless of whether I'm displaying video on the dGPU-connected display).  Again, I'm booting 15.4 and 15.3.2 with the same EFI attached to Post #1 (although I have added/enabled SMCRadeonSensors.kext 2.4.0).  I won't be making any further attempts to diagnose/debug until 15.4 is officially released.

 

Sequoia 15.4 RC

 

Sequoia 15.3.2

 

EDIT: Keep in mind that I am enabling multiple displays with SMBIOS MacMini8,1 and a non-headless (headed?) iGPU Framebuffer, so my dGPU observations are likely to be different from those observed when using SMBIOS iMac19,x / headless iGPU.

 

Good point on the headless vs non-headless. Do you have a "GPU History" menu option under Window menu in Activity Manager? IIRC correctly it should show both GPUs in non-headless mode. Another option is to download Intel Power Gadget to see if the iGPU is NOT being used and instead the dGPU is doing all the video decode. It should show iGPU activity regardless of headless mode. Download from here, if you already don't have it on your machine: https://archive.org/download/intel-power-gadget-3-0-3-osx

[deeveedee]

A warning to users of this EliteDesk 800 G4/G5 Mini with RX 560x: I have been moving a single RX 560x between two EliteDesk 800 G4 Minis (uninstalling from one and installing in another) in order to experiment with motherboard modifications.  The dGPU PCIe connection is becoming temperamental, such that sometimes the RX 560x is not properly detected until I reseat it.  I am sure that the dGPU connector on this PC is not intended to survive many installs/uninstalls, so I'm not surprised by this development.

 

If you are removing and reinstalling your RX 560x for experimentation like I am, handle with care.

[deeveedee]

During my experimentation to diagnose the higher fan with Sequoia 15.4RC, I experimented with the following additional DeviceProperties:

• PP,PP_EnableLoadFalconSmcFirmware (Number, 1)
• Force_Load_FalconSMUFW (Boolean, True)

It may be just my perception, but it seems to me that after setting these, my GeekBench6 GPU Metal scores are higher and more consistent.  I'd be interested in the test results of others just to see if I'm imagining things.  A sample plist with the DeviceProperties is attached.  I haven't found any claims that forcing Firmware loading benefits, let alone is relevant to our RX 560x, but at the very least, these settings don't appear to hurt anything.

 

If others are willing to test, I'd be interested in your observations.  Thank you.

 

 

config.plist.zip

Edited March 28, 2025 by deeveedee

[ird]

1 hour ago, deeveedee said:

During my experimentation to diagnose the higher fan with Sequoia 15.4RC, I experimented with the following additional DeviceProperties:

• PP,PP_EnableLoadFalconSmcFirmware (Number, 1)
• Force_Load_FalconSMUFW (Boolean, True)

It may be just my perception, but it seems to me that after setting these, my GeekBench6 GPU Metal scores are higher and more consistent.  I'd be interested in the test results of others just to see if I'm imagining things.  A sample plist with the DeviceProperties is attached.  I haven't found any claims that forcing Firmware loading benefits, let alone is relevant to our RX 560x, but at the very least, these settings don't appear to hurt anything.

 

If others are willing to test, I'd be interested in your observations.  Thank you.

 

 

config.plist.zip 3.26 kB · 3 downloads

 

I tried but did not find any material difference in scores (+/- <100 averaged over few runs). But then again, I use iMac19,2 SMBIOS.

[deeveedee]

@ird I don't think the SMBIOS is affecting results.  I'm juggling multiple variables (including different versions of macOS), so thanks for testing and eliminating the DeviceProperties as possibilities.

[deeveedee]

*** It does not appear to me that these properties are harmful, but proceed at your own risk. ***

 

In my search to isolate the cause of the increased fan after upgrading from 15.3.2 -> 15.4 RC (1 & 2), I stumbled upon this old thread with suggested Radeon DeviceProperties.  I couldn't find any evidence that the thread was applicable to our RX 560x, but I tried some of the suggestions anyway and produced what I think is my highest observed GB6 Benchmark yet:

 

 

It's a minor increase over my previous personal best here.

 

The settings I added are as follows and are included in the attached plist:

• PP,PP_WorkLoadPolicyMask = 1
• PP,PP_DisablePowerContainment = 1
• PP,PP_DisablePCCLimitControl = 1
• PP,PP_DisableDIDT = 1

I didn't experiment enough to determine which of these properties is responsible for the increased benchmark.  I didn't remove the Falcon Firmware - related properties, but as ird found, I don't think these Falcon Firmware properties are responsible for any observed performance improvements.

 

EDIT: I noticed that WhateverGreen was setting the wrong data type (to Boolean) for PP_WorkLoadPolicyMask when I set PP,PP_WorkLoadPolicyMask = <01> (Data).  Setting PP,PP_WorkLoadPolicyMask = 1 (Number) works.  I didn't investigate to determine whether this was a WhateverGreen issue or an inadvertent error in my plist (caused by user error or Xcode).  I would recommend inspecting GFX0 DeviceProperties with IORegistryExplorer to make sure the properties are set as you expect them to be.

 

 

*** It does not appear to me that these properties are harmful, but proceed at your own risk. ***

 

 

config.plist.zip

Edited March 30, 2025 by deeveedee
Forgot to attach plist

[ird]

2 hours ago, deeveedee said:

 

• PP,PP_WorkLoadPolicyMask = 1
• PP,PP_DisablePowerContainment = 1
• PP,PP_DisablePCCLimitControl = 1
• PP,PP_DisableDIDT = 1

3.08 kB · 1 download

 

It does not surprise me. Most, if not all, of these options disable all power management so a boost is warranted. If power consumption/noise/heat isn't a consideration and perf is a need these should help. These options should disable DVFS, raise the dynamic power limits, disable any droop mitigation (Di/Dt) among other things.

Edited March 30, 2025 by ird
Typos

[deeveedee]

Smooth upgrade from Sequoia 15.3.2 -> 15.4 Release.  After upgrade observed yet another best GB6 Metal Benchmark.

 

[deeveedee]

EDIT2: VirtualSMC.kext 1.3.6 is now released here.

 

EDIT: Leaving the text below for history.  The solution to the high PerfPowerServices CPU utilization is to upgrade VirtualSMC.kext to 1.3.6.  See here if you want an early release of this kext.

 

If you applied vit9696 temporary fix, run this in terminal to undo the fix:

 

sudo defaults -currentHost delete /Library/Preferences/com.apple.powerlogd SMCMonitorCadence

 

----------------------------------------------------------------

 

This thread reveals the cause of the high fan in Sequoia 15.4.  It is the CPU fan, not the GPU fan (as I incorrectly stated before) that is running excessively.

 

EDIT: For those who need to run Sequoia 15.4 and who are experiencing the high CPU / high fan problem, this clever solution may be an option.  I'm going to stay with Sequoia 15.3.2 until this is resolved.

 

EDIT2: vit9696 has provided a working solution for the high PerfPowerServices CPU here.

Edited April 9, 2025 by deeveedee

[deeveedee]

EDIT: Leaving the post below for history.  BrcmPatchRAM 2.7.0 is now released here

 

-------------------------------------

 

Acidanthera is going to be releasing a new version of BrcmPatchRAM 2.7.0 which includes changes to BluetoolFixup.kext.  I am testing with this new BluetoolFixup.kext now.   If you want to test the update before it is formally released, login to GitHub and download Artifacts from here.

 

Edited April 9, 2025 by deeveedee

[deeveedee]

I have uploaded a new Open Core EFI attached to Post #1.  This new EFI based on Open Core 1.0.4 includes the upgraded VirtualSMC.kext (version 1.3.6) and a slightly refactored SSDT-WAK ACPI patch (no functional changes).  This new EFI includes a disabled 'Kernel > Add 'for SMCRadeonSensors.kext in the config.plist.  If you want to add SMCRadeonSensors.kext, you'll need to download it to your OC/Kexts folder and enable the associated 'Kernel > Add' entry in the config.plist.

[deeveedee]

I have posted an updated Open Core 1.0.4 EFI (attached to Post #1).  This revised EFI fixes a bug that I had in my DAGPM.kext (required to properly specify RX 560x dGPU power management with SMBIOS MacMini8,1).  I discovered that I had inadvertently copied the wrong IGPU AGPM properties for the MacMini8,1's UHD630 (copied from AppleGraphicsPowerManagement.kext in /System/Library/Extensions).  More details are below.  The new EFI based on OC 1.0.4 includes the following changes:

 

OC/Kexts

• DAGPM.kext: Update IGPU entry to be consistent with IGPU for MacMini8,1

 

Details

In order to create a MacMini "hackinstein" with both iGPU and dGPU ports enabled/accelerated, I needed to modify this hack's graphics power management to include power management for the RX 560x dGPU.  This is because the real MacMini8,1 does not have an RX 560x, so AppleGraphicsPowerManagement.kext does not specify dGPU power management properties for the MacMini8,1 (only iGPU properties are specified).

 

As Toleda determined (maybe others, too - not sure who deserves the original credit), AppleGraphicsPowerManagement properties can be added with a codeless kext (Info.plist only) that injects the proper AGPM properties.  I started with Toleda's DAGPM.kext as my framework and modified the "Machines" Dictionary to include Macmini8,1 with GFX0, IGPU and redundantly Vendor1002Device67ff (same properties as GFX0).  I copied the GFX0 and IGPU properties for my DAGPM.kext from the original Sonoma AppleGraphicsPowerManagement.kext in /System/Libraray/Extensions (MacMini8,1 = Mac-7BA5B2DFE22DDD8C).  It turns out that I inadvertently copied the wrong IGPU properties.  Since my DAGPM.kext overrides the Apple defaults in AppleGraphicsPowerManagement.kext, the IGPU AGPM properties in IORegistry were inconsistent with those of a real MacMini8,1.

 

If you look closely at the IORegistryExplorer screenshots below, you can see that the incorrect IGPU properties are missing properties found in the correct IGPU properties.

 

Incorrect IGPU properties (viewed using IORegsitryExplorer)

 

Correct IGPU properties (viewed using IORegsitryExplorer)

 

I haven't done much testing, so I can't say that I notice any difference after making this correction.  Having both IGPU and DGPU heads enabled in a Mac and having an IGPU and DGPU in a MacMini8,1 are non-standard configurations that have worked well for me so far.  I'll need to conduct more testing to determine whether this DAGPM.kext change makes any difference in performance.

 

EDIT: Note that the Logic Board ID for iMac19,2 is Mac-63001698E7A34814.  Since the real iMac19,2 has an RX 560x, I copied the GFX0 properties for Mac-63001698E7A34814 from AppleGraphicsPowerManagement.kext into my DAGPM.kext.  The iMac19,2 configures the UHD630 as headless, so I do not want the IGPU properties for iMac19,2 (Mac-63001698E7A34814) in AppleGraphicsPowerManagement.kext.  Those who have a single display connected to the RX 560x DP port (configuring the UHD630 as headless) can use SMBIOS iMac19,2 without a DAGPM.kext.

Edited May 7, 2025 by deeveedee

[deeveedee]

After testing with the new EFI (with revised DAGPM.kext) that I posted, I can't say that I notice any performance/behavioral differences from my previous EFI.  This hack continues to run perfectly without any issues.  For most operations, the CPU and GPU fans are silent and performance is outstanding, so power management is working well.  Geekbench 6 synthetic metal benchmarks are consistently very good (which I think may be more because of Apple's refinements in macOS and less about my tweaks).

[deeveedee]

This is going to be my last post in this thread and one of my final posts at InsanelyMac.  There are rumors about macOS 26 (the next major release after Sequoia macOS 15).  The rumor mill indicates that MacMini8,1 is being dropped from official macOS support.  If MacMini8,1 is dropped in the next major macOS and Apple hasn't changed too much, we should be able extend the life of this hack by switching to SMBIOS iMac19,2 (which is rumored to have continued support) with the following changes:

• OC/config.plist: generate new PlatformInfo for SMBIOS 19,2
• OC/kexts/DAGPM.kext/Contents/info.plist: Change SMBIOS macMini8,1 -> iMac19,2 (I suspect this is necessary only for those using multiple displays with iMac19,2.  For those using a single display connected to the dGPU DP port, DAGPM.kext can be disabled / deleted).  I haven't thought this through completely, so some testing may be necessary.
• OC/kexts/USBPorts.kext/Contents/info.plist: Change SMBIOS macMini8,1 -> iMac19,2

@ird is currently running with SMBIOS iMac19,2 (albeit with a headless UHD630 framebuffer and single dGPU-connected display), so he should be the expert on this new config.

 

I have thoroughly enjoyed working with those who contributed to this thread.  Thank you and good luck to all.

[ird]

4 hours ago, deeveedee said:

This is going to be my last post in this thread and one of my final posts at InsanelyMac.  There are rumors about macOS 26 (the next major release after Sequoia macOS 15).  The rumor mill indicates that MacMini8,1 is being dropped from official macOS support.  If MacMini8,1 is dropped in the next major macOS and Apple hasn't changed too much, we should be able extend the life of this hack by switching to SMBIOS iMac19,2 (which is rumored to have continued support) with the following changes:

• OC/config.plist: generate new PlatformInfo for SMBIOS 19,2
• OC/kexts/DAGPM.kext/Contents/info.plist: Change SMBIOS macMini8,1 -> iMac19,2 (I suspect this is necessary only for those using multiple displays with iMac19,2.  For those using a single display connected to the dGPU DP port, DAGPM.kext can be disabled / deleted).  I haven't thought this through completely, so some testing may be necessary.
• OC/kexts/USBPorts.kext/Contents/info.plist: Change SMBIOS macMini8,1 -> iMac19,2

@ird is currently running with SMBIOS iMac19,2 (albeit with a headless UHD630 framebuffer and single dGPU-connected display), so he should be the expert on this new config.

 

I have thoroughly enjoyed working with those who contributed to this thread.  Thank you and good luck to all.

I’ve learned a lot from you and this forum, @deeveedee! It has been a pleasure interacting with you. You are immensely experienced yet so humble. These forums need experts like you!

[deeveedee]

@ird It has been a pleasure interacting with you, too.  We make a good team.

 

Also, it looks like I may have misinterpreted the rumors about macOS 26 (which doesn't mean much, since they are just rumors). If iMac19,2 is not a viable SMBIOS for the next macOS but at least one Intel Mac is still supported, I'm sure you'll figure out a way to extend the life of this hack and of this thread.

 

... and now this really is my last post in this thread.

Edited May 31, 2025 by deeveedee

[ird]

Tahoe officially supports iMac20,1 and MacPro7,1. The fact that MacPro7,1 is supported gives me hope that Polaris GPU drivers are not yet dropped in Tahoe (MacPro7,1 originally came with RX580). I hear that Metal 2 is broken in current beta, which should hopefully be fixed in the next drop.

[deeveedee]

I have RX 560x working in macOS Tahoe.  The trick (for Tahoe Beta 1) is to enable the RX 560x (don't use -wegnoegpu) but to disconnect displays from the RX 560x port.  Since my configuration with SMBIOS MacMini8,1 enables the dGPU port and the iGPU ports in WEG device properties (I don't use a headless iGPU framebuffer), I am able to boot Tahoe with dGPU accelerated iGPU ports.  This seems to indicate (to me) that we'll be seeing full use of RX 560x (and other Polaris) in Tahoe with an update to WhateverGreen.kext or, as @ird suggested, a fix to Tahoe.  

 

For those who wish to debug, this multi-GPU configuration allows easy inspection of the dGPU IORegistry via displays connected to iGPU ports.

 

Tahoe IOReg

Spoiler

 

Tahoe GB6 (note that GB6 reports macOS version 16.0)

Spoiler

 

EDIT: I'm going to stop saying that this is my last post

 

EDIT2: This is rock-solid stable.  No issues that I've observed so far.

 

EDIT3: I haven't tested this much, but it does appear that the RX560X-connected display works if I connect it after login.  This needs more testing but is another indicator that a permanent fix should be coming.

 

EDIT4: The EFI that I'm currently using to test Tahoe is attached.  It is my personally customized EFI (an extension of the EFI that I attached to Post #1 in this thread) and I haven't cleaned it up.  Note that boot-args do not contain -wegnoegpu and @0,AAPL,boot-display is commented-out in dGPU DeviceProperties (I don't currently have a dGPU-connected display for my testing).  Also note that Kernel > Quirks > DisableIoMapper = true for working Ethernet / IntelMausi.kext in Tahoe.  Also note that my USB map is USBPorts.kext generated by Hackintool with the addition of usb-port-type and usb-port-number to each mapped port (no other changes needed for working USB in Big Sur through Tahoe with same USBPorts.kext).

 

EFI-MM81-RX560x-OC105Beta-R08-Bluetooth.zip

Edited June 15, 2025 by deeveedee