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

[CloverLeaf]

So many interesting things happening right now It's not a good time to leave!

[LockDown]

we hang on till the end of it all 👍

[deeveedee]

Does anyone know how to override ATY,ControlFlags for Radeon Framebuffer@0 in OC config.plist DeviceProperties?  I've tried properties "@0,ATY,ControlFlags" and "ATY,ControlFlags" and am finding that WEG doesn't override ATY,ControlFlags with these DeviceProperties.  I unsuccessfully tried setting these properties in OC config.plist DeviceProperties and SSDT.

 

I did some research about ATY,ControlFlags and see the following 

ATY,ControlFlags Base64     Notes
0x00000000       MA==       Most common — disables all control logic (safest start)
0x00000001       AQAAAA==   Keep all ports alive, even unconnected ones
0x00000003       AwAAAA==   Prevents port disable & ignores power state
0x00000020       IAAAAA==   Forces hotplug detect line high (useful for black screen on boot)

ATY,ControlFlags for RX 560x Framebuffer@0 on this hack are 0x304.  I'd like to try setting to 0x324 to force hot plug detect line high.

 

Thank you for any help.

 

EDIT: Note that I was able to override ATY,ControlFlags in macOS Catalina (without WhateverGreen) when I was first trying to figure out the unsolvable (at the time) RX 560x black screen issue.  That override technique no longer works in newer macOS.

Edited June 16, 2025 by deeveedee

[pico joe]

I follow u grandma  thanks

[deeveedee]

New IntelMausi.kext here to address VT-d issue reported earlier.  Thanks again @lorys89 for identifying this.

 

EDIT: Note that this is a different fork from Acidanthera.  I think this change should eventually be incorporated into the Acidanthera repo.

 

EDIT2: As of this writing, the new IntelMausiKext 2.5.5d0 does not fix the AppleVTD issue for me.  I still need Kernel > Quirks > DisableIoMapper = true.

Edited June 16, 2025 by deeveedee

[ird]

12 hours ago, deeveedee said:

Does anyone know how to override ATY,ControlFlags for Radeon Framebuffer@0 in OC config.plist DeviceProperties?  I've tried properties "@0,ATY,ControlFlags" and "ATY,ControlFlags" and am finding that WEG doesn't override ATY,ControlFlags with these DeviceProperties.  I unsuccessfully tried setting these properties in OC config.plist DeviceProperties and SSDT.

 

I did some research about ATY,ControlFlags and see the following 

ATY,ControlFlags Base64     Notes
0x00000000       MA==       Most common — disables all control logic (safest start)
0x00000001       AQAAAA==   Keep all ports alive, even unconnected ones
0x00000003       AwAAAA==   Prevents port disable & ignores power state
0x00000020       IAAAAA==   Forces hotplug detect line high (useful for black screen on boot)

ATY,ControlFlags for RX 560x Framebuffer@0 on this hack are 0x304.  I'd like to try setting to 0x324 to force hot plug detect line high.

 

Thank you for any help.

 

EDIT: Note that I was able to override ATY,ControlFlags in macOS Catalina (without WhateverGreen) when I was first trying to figure out the unsolvable (at the time) RX 560x black screen issue.  That override technique no longer works in newer macOS.

 

AFAIR, there was some bug in WEG that prevented any ATY flags to apply. It would overwrite the manually specified ones. I do not know if that is still true for the latest version. Sorry, not sure this is of much help or the answer to your question.

[LockDown]

10 hours ago, deeveedee said:

EDIT2: As of this writing, the new IntelMausiKext 2.5.5d0 does not fix the AppleVTD issue for me.  I still need Kernel > Quirks > DisableIoMapper = true.

What is wrong if it is true? Does it need to be false?

It has been true for me all these years 😄

Edited June 17, 2025 by LockDown

[deeveedee]

@LockDown This thread is for the HP EliteDesk 800 G4/G5 Mini which, through macOS Sequoia, works with DisableIoMapper=false when VT-d is enabled in BIOS. Note that my posted EFI attached to Post #1 (which works through Sequoia) has DisableIoMapper = false.  For more details, read the first few posts of this thread.

 

My posted EFI attached to Post #1 requires the changes here to run Tahoe Beta 1.

[deeveedee]

This article helped me to restore the old LaunchPad to Tahoe. After executing the specified terminal commands and rebooting, I dragged LaunchPad from Applications to the Dock. I haven't tested for long, but so far, the Tahoe LaunchPad is identical to previous macOS LaunchPads.

[Anto65]

😆  we were all looking for the same thing 

 

https://www.insanelymac.com/forum/topic/361162-pre-release-macos-tahoe/page/41/#findComment-2834151

 

[deeveedee]

Maybe others were copying that article.  I'm finding the Tahoe Pre-Release thread to be too cluttered and have stopped paying attention to it.  Maybe I need to take a look again.

Edited June 19, 2025 by deeveedee

[LockDown]

On 6/17/2025 at 8:39 PM, deeveedee said:

@LockDown This thread is for the HP EliteDesk 800 G4/G5 Mini

I do have the 800 but seldom use to try new things, it still has Ventura. Main purpose is only for movie streaming attached to my TV.

Thats why i didnt include it on my sig

[deeveedee]

@LockDown That's great!  I apologize if my answer sounded trite.  I wasn't judging whether you had an 800 G4/G5 Mini (although it's great that you do).  I was just explaining that setting DisableIoMapper = true was a change from the EFI baseline for this thread (attached to Post #1).  For this hack, there shouldn't be anything affected by changing DisableIoMapper = false to true.

Edited June 19, 2025 by deeveedee

[LockDown]

No worries. My EFI was also based of this thread. Thanks 🙂

[Alexey Boronenkov]

Металл.gb6

RX 500 POLARIS MACOS 26.plist

Edited June 20, 2025 by Alexey Boronenkov

[arsradu]

On 6/15/2025 at 5:17 AM, deeveedee said:

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

  Reveal hidden contents

 

Tahoe GB6 (note that GB6 reports macOS version 16.0)

  Reveal hidden contents

 

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 4.32 MB · 66 downloads

 

After so many years, using the RX 580, your post made me realise that the reason why my computer was booting to a "black screen" (cursor, but black screen) is that it was actually outputting to my iGPU instead. If I was using two monitors at the same time, one connected to each GPU, this would have probably been crystal clear. But on a single monitor, it looks like there's an issue booting with the dGPU. When it's actually just booting on "the other monitor". You just can't see it cause you don't have another monitor! :))

 

Edited June 20, 2025 by arsradu

[deeveedee]

As many have already observed, Apple removed AppleHDA from Tahoe Beta 2, so AppleALC.kext doesn't work with Tahoe Beta 2.  Fortunately, VoodooHDA.kext does work.  If you have tried to use VoodooHDA.kext on this HackMini, then you've discovered that VoodooHDA can't bind to Device HDAS, because it is blocked by AppleGFXHDA.  Since AppleALC.kext prevents AppleGFXHDA from binding to HDAS, we may be able to use AppleALC as a helper for VoodooHDA.  Try the following after upgrading to Tahoe Beta 2:

1. Leave AppleALC.kext configuration unchanged in 'Kernel > Add' in your OC config.plist to allow injection of AppleALC.kext in Tahoe.  Note that AppleALC.kext should not conflict with VoodooHDA in Tahoe Beta 2, because Tahoe Beta 2 does not have AppleHDA.
2. In OC config.plist, partially disable SIP by setting NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config = <03080000> <03000000> (see attached sample plist).  Note that after initially posting this, I discovered that VoodooHDA.kext can be installed for the first time with csr-active-config = <03000000>.  csr-active-config can be changed to <01000000> after VoodooHDA.kext is installed and working.
3. Reboot macOS Tahoe so that the new partially-disabled SIP setting is applied. Note that I believe this is the most restrictive SIP setting that we can achieve while still allowing VoodooHDA in Tahoe.  

 

After rebooting with partially-disabled SIP, install VoodooHDA.kext to macOS Tahoe /Library/Extensions as follows:

1. Download VoodooHDA.kext 3.0.2 from here
2. In terminal: sudo cp -R VoodooHDA.kext /Library/Extensions (do not use Finder - use this terminal command)
3. When prompted, Open System Settings and Allow VoodooHDA.kext
4. Reboot macOS Tahoe

 

You should now have sound and you should see VoodooHDA in your IORegistry.  Note that AppleALC renames HDAS -> HDEF, but because AppleHDA is missing, it is VoodooHDA that binds to HDEF.

 

We should be able to use AppleALC.kext in this unconventional way (as a blocker for AppleGFXHDA), since macOS Tahoe does not have AppleHDA.  This unconventional use of AppleALC with VoodooHDA is currently working for me.  I'll be curious to know if this works for others.

 

Attached is a sample of the config.plist entries relevant to VoodooHDA.

 

NOTES: With the addition of VoodooHDA.kext as described above, the same OC EFI boots Sonoma, Sequoia and Tahoe.  If Apple restores AppleHDA in a subsequent Tahoe version, we'll simply remove VoodooHDA (undoing the steps above).

 

EDIT: After installing and confirming working VoodooHDA.kext, you may tighten SIP restrictions as noted here.

 

 

VoodooHDA-config.plist.zip

Edited April 5 by deeveedee
Removed VoodooHDA.kext from OC EFI; Changed SIP settings

[deeveedee]

Tahoe Beta 2 did fix the RX 560x so that Tahoe boots normally with a dGPU-connected display.  @ird 's prediction here was correct.  See details here.

Edited June 26, 2025 by deeveedee

[Oyecomova]

4 hours ago, deeveedee said:

Como muchos ya han observado, Apple eliminó AppleHDA de Tahoe Beta 2, por lo que AppleALC.kext no funciona con Tahoe Beta 2. Afortunadamente, VoodooHDA.kext sí funciona. Si has intentado usar VoodooHDA.kext en este HackMini, habrás descubierto que VoodooHDA no puede vincularse con el dispositivo HDAS porque está bloqueado por AppleGFXHDA. Dado que AppleALC.kext impide que AppleGFXHDA se vincule con el HDAS, es posible que podamos usar AppleALC como ayudante para VoodooHDA. Prueba lo siguiente después de actualizar a Tahoe Beta 2:

1. Descargue VoodooHDA.kext 3.0.2 desde aquí
2. No modifique la configuración de AppleALC.kext  en 'Kernel > Agregar' en su OC config.plist para permitir la inyección de AppleALC.kext en Tahoe. Tenga en cuenta que AppleALC.kext no se cargará (como se observa con kextstat) en Tahoe Beta 2, ya que Tahoe Beta 2 no tiene AppleHDA. Esto es justo lo que buscamos, ya que usamos VoodooHDA.
3. Agregue VoodooHDA.kext a OC/Kexts en su OC EFI
4. Agregue VoodooHDA al kernel > Agregue en su OC config.plist con MinKernel 25.0.0 (Tahoe). (vea el ejemplo de plist adjunto)
5. En OC config.plist, deshabilite parcialmente SIP configurando NVRAM > Agregar > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config = <03080000> (vea el ejemplo plist adjunto)

 

Reinicie macOS Tahoe para que se aplique la nueva configuración de SIP parcialmente deshabilitada. Tenga en cuenta que creo que esta es la configuración de SIP más restrictiva que podemos lograr sin que VoodooHDA se desactive en Tahoe.  

 

Ahora instale VoodooHDA.kext en macOS Tahoe /Library/Extensions de la siguiente manera:

1. En la terminal: sudo cp -R VoodooHDA.kext /Library/Extensions
2. Cuando se le solicite, abra Configuración del sistema y permita VoodooHDA.kext
3. Reiniciar macOS Tahoe

 

Ahora debería tener sonido y debería ver VoodooHDA en su Registro IOR. Tenga en cuenta que AppleALC renombra HDAS a HDEF (aunque no se carga).

 

Deberíamos poder usar AppleALC.kext de esta forma inusual (como bloqueador de AppleGFXHDA), ya que macOS Tahoe no tiene AppleHDA y AppleALC.kext no carga. Este método me funciona actualmente. Me gustaría saber si funciona para otros.

 

Se adjunta una muestra de las entradas config.plist relevantes para VoodooHDA.

 

NOTAS: Con la adición de VoodooHDA.kext, como se describió anteriormente, el mismo OC EFI arranca Sonoma, Sequoia y Tahoe. Si Apple restaura AppleHDA en una versión posterior de Tahoe, simplemente eliminaremos VoodooHDA (deshaciendo los pasos anteriores).

 

 

VoodooHDA-config.plist.zip 3,25 kB · 1 descarga

.. disculpe.. y el elemento VoodooHDA.prefPane como y donde se pone
.. gracias 

[deeveedee]

@Oyecomova I don't use VoodooHDA pref pane on this HackMini.  I simply adjust volume using macOS built-in Volume control.

 

A note about VoodooHDA.kext... you will find a lot of negative comments about VoodoooHDA.  I'm not sure why this is, but it's possible that an older version of VoodooHDA had poor sound quality.  It's more likely that those naysayers just don't know what they are talking about.  VoodooHDA 3.0.2 produces perfectly good sound quality.  @Slice would know more since it is largely thanks to him that we still have VoodooHDA as an option.  He deserves our gratitude for preserving VoodooHDA's viability.

 

VoodooHDA.kext is a proven, well-tested audio solution for hackintoshes.  So far, the VoodooHDA-based solution that I posted here is working perfectly for me on this hack.  I will continue to look for better options if they become available.

Edited June 26, 2025 by deeveedee

[hiphopboy]

17 hours ago, deeveedee said:

As many have already observed, Apple removed AppleHDA from Tahoe Beta 2, so AppleALC.kext doesn't work with Tahoe Beta 2.  Fortunately, VoodooHDA.kext does work.  If you have tried to use VoodooHDA.kext on this HackMini, then you've discovered that VoodooHDA can't bind to Device HDAS, because it is blocked by AppleGFXHDA.  Since AppleALC.kext prevents AppleGFXHDA from binding to HDAS, we may be able to use AppleALC as a helper for VoodooHDA.  Try the following after upgrading to Tahoe Beta 2:

1. Download VoodooHDA.kext 3.0.2 from here
2. Leave AppleALC.kext configuration unchanged in 'Kernel > Add' in your OC config.plist to allow injection of AppleALC.kext in Tahoe.  Note that AppleALC.kext should not conflict with VoodooHDA in Tahoe Beta 2, because Tahoe Beta 2 does not have AppleHDA.
3. Add VoodooHDA.kext to OC/Kexts in your OC EFI
4. Add VoodooHDA to Kernel > Add in your OC config.plist with MinKernel 25.0.0 (Tahoe). (see attached sample plist)
5. In OC config.plist, partially disable SIP by setting NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config = <03080000> (see attached sample plist)
6. Reboot macOS Tahoe so that the new partially-disabled SIP setting is applied. Note that I believe this is the most restrictive SIP setting that we can achieve while still allowing VoodooHDA in Tahoe.  

 

After rebooting with partially-disabled SIP, install VoodooHDA.kext to macOS Tahoe /Library/Extensions as follows:

1. In terminal: sudo cp -R VoodooHDA.kext /Library/Extensions (do not use Finder - use this terminal command)
2. When prompted, Open System Settings and Allow VoodooHDA.kext
3. Reboot macOS Tahoe

 

You should now have sound and you should see VoodooHDA in your IORegistry.  Note that AppleALC renames HDAS -> HDEF, but because AppleHDA is missing, it is VoodooHDA that binds to HDEF.

 

We should be able to use AppleALC.kext in this unconventional way (as a blocker for AppleGFXHDA), since macOS Tahoe does not have AppleHDA.  This unconventional use of AppleALC with VoodooHDA is currently working for me.  I'll be curious to know if this works for others.

 

Attached is a sample of the config.plist entries relevant to VoodooHDA.

 

NOTES: With the addition of VoodooHDA.kext as described above, the same OC EFI boots Sonoma, Sequoia and Tahoe.  If Apple restores AppleHDA in a subsequent Tahoe version, we'll simply remove VoodooHDA (undoing the steps above).

 

 

VoodooHDA-config.plist.zip 3.25 kB · 11 downloads

 

good work. wait for reback applehda  

[deeveedee]

There is a third-party, Chinese-language app claiming to be OCLP that can root-patch macOS Tahoe for unsupported Macs and hacks.  People are excited about being early adopters.

 

Wow. Just when I thought I'd seen everything.

Edited June 26, 2025 by deeveedee

[deeveedee]

I'm continuing to experiment with VoodooHDA.  My current configuration disables VoodooHDA.kext in my OC config.plist.  After limited testing, sound is still working fine with only the following:

• Partially disabled SIP (OC config.plist: NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config = <03080000>
• VoodooHDA.kext 3.0.2 copied to /Library/Extensions (copied using 'sudo cp -R VoodooHDA.kext /Library/Extensions') and enabled in System Settings > Privacy and Security

At this time, I am not sure that VoodooHDA.kext needs to be injected with Open Core.

 

If this simplified installation continues to work, I'll modify my instructions here (removing steps 3 and 4 in the first part of the installation that modifies the OC EFI).

 

EDIT: I removed VoodooHDA.kext from /Library/Extensions, rebooted, reset NVRAM and confirmed that there were no traces of VoodooHDA.kext in my hack (leaving SIP partially disabled).  I left 'Kernel > Add> VoodooHDA.kext' disabled in my OC config.plist and copied VoodooHDA.kext to /Library/Extensions (sudo cp -R VoodooHDA.kext /Library/Extensions).  After being prompted to Allow VoodooHDA.kext in 'System Settings > Privacy and Security' and Allowing VoodooHDA.kext, I rebooted.  Sound is working fine.  I'll leave my hack in this state with the simplified installation of VoodooHDA.kext to continue testing.

 

I welcome feedback from others who would like to help test.

Edited June 27, 2025 by deeveedee

[ird]

51 minutes ago, deeveedee said:

I'm continuing to experiment with VoodooHDA.  My current configuration disables VoodooHDA.kext in my OC config.plist.  After limited testing, sound is still working fine with only the following:

• Partially disabled SIP (OC config.plist: NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config = <03080000>
• VoodooHDA.kext 3.0.2 copied to /Library/Extensions (copied using 'sudo cp -R VoodooHDA.kext /Library/Extensions') and enabled in System Settings > Privacy and Security

At this time, I am not sure that VoodooHDA.kext needs to be injected with Open Core.

 

If this simplified installation continues to work, I'll modify my instructions here (removing steps 3 and 4 in the first part of the installation that modifies the OC EFI).

 

EDIT: I removed VoodooHDA.kext from /Library/Extensions, rebooted, reset NVRAM and confirmed that there were no traces of VoodooHDA.kext in my hack (leaving SIP partially disabled).  I left 'Kernel > Add> VoodooHDA.kext' disabled in my OC config.plist and copied VoodooHDA.kext to /Library/Extensions (sudo cp -R VoodooHDA.kext /Library/Extensions).  After being prompted to Allow VoodooHDA.kext in 'System Settings > Privacy and Security' and Allowing VoodooHDA.kext, I rebooted.  Sound is working fine.  I'll leave my hack in this state with the simplified installation of VoodooHDA.kext to continue testing.

 

I welcome feedback from others who would like to help test.

 

I don't have much more to add than just say, thank you for this investigation!

 

Intel chipsets implement the standard HD Audio codec protocol. Apple HDA controller libraries know how to talk to Intel HW. Even if Apple removes AppleHDA from macOS, they'd still have to support Intel codecs, at least in macOS 26. Apple Silicon is not bound to support the standard codecs though, but one way or the other Apple will have to support iMac/MacPro. I'll wait to see what's in store for the next beta. The fact that AppleHDA existed in Beta1 to start may point to the fact that this could be a bug that will be eventually fixed, one way or the other.

[deeveedee]

@ird I totally agree.  It may be that Acidanthera just needs a new AppleALC to work with AppleGFXHDA.

 

EDIT: Acidanthera's current position (as of this writing) is that this will be fixed by OCLP.  I don't plan to use OCLP on this hack, so if OCLP is the only AppleALC option, I will continue to use VoodooHDA on this hack.

 

EDIT: @ird  According to Acidanthera, "Macs compatible with Tahoe don't contain the analog HDA codec. The analog audio in them is implemented on another, and is used BridgeAudioController.kext AppleGFXHDA long ago known kext for digital audio of displays only. You can use AppleALC or AppleALCU for AppleGFXHDA - digital audio of displays."

Edited June 28, 2025 by deeveedee