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

[deeveedee]

I have adopted a couple of System Settings tweaks from my old hacks to improve Tahoe GUI responsiveness on this hack:

• System Settings > Accessibility > Display > Reduce Transparency: Enable
• System Settings > Accessibility > Motion > Reduce Motion: Enable

More details here.

[deeveedee]

Easy upgrade to first Tahoe Release.  See details here.

 

[deeveedee]

Upgraded Ventura, Sonoma and Sequoia with the same OC EFI attached to Post #1.

 

Ventura 13.7.8

Spoiler

 

Sonoma 14.8

Spoiler

 

Sequoia 15.7

Spoiler

 

Edited September 18, 2025 by deeveedee
Added Ventura 13.7.8

[deeveedee]

Just performed a quick experiment with Secure Boot Model and found that I am no longer able to boot this hack with SBM enabled.  I did not test further and don't know the requirements for SBM, but it may be because I have csr-active-config = <01000000> to permit VoodooHDA.kext in /L/E.  Not sure.  Easy enough to test, just didn't have time.

 

EDIT: Sequoia and earlier versions of macOS boot with SBM enabled, so it's not csr-active-config.  Maybe it's the fact that VoodooHDA.kext is in Tahoe's /L/E.  Will test again when I have time.  The SBM issue is limited to Tahoe.

Edited September 22, 2025 by deeveedee

[deeveedee]

Easy upgrade to Tahoe 26.1 Beta 1.  No change in upgrade procedure from previous Tahoe upgrades.  All good.

 

EDIT: As observed with some previous Tahoe Beta updates, I needed to reboot multiple times after updating to Tahoe 26.1 Beta 1 in order to restore GeekBench 6 synthetic metal benchmark to ~24K.  Immediately after the update, GB6 synthetic metal benchmark was closer to 18K.

Edited September 25, 2025 by deeveedee

[deeveedee]

The only issue that I have with Tahoe (a very minor issue) is that I hear an audio "pop" at boot and shutdown when using VoodooHDA.kext.  I am currently testing the solution here.

 

I am considering the audio "pop" issue as solved.  The solution I posted here is working very well for me.

Edited September 28, 2025 by deeveedee

[deeveedee]

For those who want to dual-boot Windows and macOS on the same SSD (maybe because you haven't added the second NVMe SSD documented in this thread), this technique by @MaLd0n looks very interesting.

[deeveedee]

I received a PM asking why my implementation of SSDT-XOSI does not match Dortania's (or any other posted SSDT-XOSI).  Read this if you're curious.  The other implementations of SSDT-XOSI are overly complicated.

[deeveedee]

Smooth upgrade from Tahoe 26.1 Beta 2 -> Beta 3. All appears fine.  I did notice a drop in GB6 Metal Benchmark, but I've seen this before with Betas.  I've also seen synthetic Metal benchmark performance increase with successive boot cycles after a macOS update, so maybe this will improve.  I'm incredible impressed with this hack.

 

Still very pleased with VoodooHDA.kext 3.0.2 for sound (which I haven't touched since Tahoe 26.0 Beta 2) with csr-active-config = <01000000>.

 

GeekBench 6 Metal (Tahoe 26.1 Beta 3)

Spoiler

 

Edited October 15, 2025 by deeveedee

[deeveedee]

Easy upgrade from Tahoe 26.1 Beta 3 -> Beta 4.  As with Beta 3, GB6 Metal benchmarks achieve full potential (~24K) after multiple reboots.

 

About This Hack: Tahoe 26.1 Beta 4

Spoiler

 

 

EDIT: I am now using VoodooHDA.kext 3.0.3 from here.

Edited October 22, 2025 by deeveedee

[deeveedee]

laobomac_yyds reports here that he has fixed the WhateverGreen issue that requires us to use boot-arg -wegnoegpu during Tahoe upgrades.  I haven't tested yet, but look for this fix in a future release of WhateverGreen.

 

EDIT: Latest pre-release here.   While it's in testing phase and until the official release, continue to look for newer releases.

Edited November 1, 2025 by deeveedee

[deeveedee]

I'm seeing strange ACPI patching behavior on another hack and invite others to take a look here.  Am I seeing things?

[deeveedee]

macOS Tahoe updates on this hack are still going smoothly.  Upgrade from Tahoe 26.2 Beta 1 -> Beta 2 was easy.

 

I'm still using Acidanthera's WhateverGreen.kext 1.7.0, so I need boot-arg -wegnoegpu to perform the upgrade.  I won't be changing my version of WEG until a new version is released by Acidanthera (just my personal preference).  My complete upgrade process is as follows:

• Temporarily disable BluetoolFixup.kext and add boot-arg -wegnoegpu (I have a USB thumbdrive with the modified config.plist so that I don't need to touch the EFI on my SSD).  Adding boot-arg -wegnoegpu disables dGPU output, but my iGPU-connected displays remain active.
• Boot with the modified EFI and apply the macOS update
• Restore BluetoolFixup.kext, remove boot-arg -wegnoegpu (in my case, boot with the SSD EFI) and reboot
• Since I'm using VoodooHDA.kext for Tahoe audio, I don't need to touch SIP or apply any post-install patches after the update.  SIP stays at csr-active-config = <01000000> and VoodooHDA.kext 3.0.3 remains installed in /Library/Extensions
• Also, since VoodooHDA.kext is installed in Tahoe's /Library/Extensions and AppleALC.kext is injected by Open Core, macOS versions prior to Tahoe continue to use AppleHDA with the same EFI.  The only change that affects previous versions of macOS is that SIP is relaxed with csr-active-config = <01000000>.

I'm disapointed that Dortania documentation continues to includes statements about bad VoodooHDA sound quality.  That is simply not true.

 

EDIT: Same for Tahoe 26.2 Beta 2 -> Beta 3 as mentioned here.

Edited November 17, 2025 by deeveedee

[deeveedee]

I was helping someone else with ACPI patches and noticed an error in my SSDT-PTS: Method _PTS should be NotSerialized.  This error has been in my ACPI patches for this hack for a long time.  I'll make the correction in my next posted EFI.

[ird]

On 11/21/2025 at 9:01 AM, deeveedee said:

I was helping someone else with ACPI patches and noticed an error in my SSDT-PTS: Method _PTS should be NotSerialized.  This error has been in my ACPI patches for this hack for a long time.  I'll make the correction in my next posted EFI.

 

I made the change but, to your point, did not observe any tangible difference. What's the signficance of this option?

[deeveedee]

@ird Good question.  I don't expect that we'll notice a difference.  When a method in ACPI is Serialized, only one thread at a time can execute the method.  A method that is NotSerialized can be executed by multiple threads simultaneously.  Since we're not observing any problems, this suggests that _PTS is being executed by a single kernel thread that manages power state transitions (which makes sense).  Thus, declaring _PTS as Serialized or NotSerialized doesn't matter.

 

My "error" is only that I inadvertently changed the original declaration of _PTS (the declaration in the original unpatched ACPI for the EliteDesk 800 G4/G5 Mini) from NotSerialized to Serialized.  The fix is not urgent, which is why I won't be making it until I update the EFI.

Edited November 24, 2025 by deeveedee

[ird]

On 11/24/2025 at 4:32 AM, deeveedee said:

@ird Good question.  I don't expect that we'll notice a difference.  When a method in ACPI is Serialized, only one thread at a time can execute the method.  A method that is NotSerialized can be executed by multiple threads simultaneously.  Since we're not observing any problems, this suggests that _PTS is being executed by a single kernel thread that manages power state transitions (which makes sense).  Thus, declaring _PTS as Serialized or NotSerialized doesn't matter.

 

My "error" is only that I inadvertently changed the original declaration of _PTS (the declaration in the original unpatched ACPI for the EliteDesk 800 G4/G5 Mini) from NotSerialized to Serialized.  The fix is not urgent, which is why I won't be making it until I update the EFI.

 

Thank you for the explanation. I learnt something new today! I suppose as long as no other declaration have any depdency on this initialization, marking it non-serialized should be safe. I doubt it makes any meaningful difference in the startup speed either.

[deeveedee]

I have tested two methods of booting macOS, Windows and Ubuntu on the same SSD.  The methods and my test results are as follows:

• Grub: This method is working well for me.  I am able to select Ubuntu, Windows and macOS from a single grub menu.  I have installed multiple versions of macOS, so when I select macOS from the Grub menu, I'm presented with the Open Core boot menu.   If I allow the OC menu selection to timeout, my preferred version of macOS boots.
• Add EFI partition: This method did not work for me.  I created the 2nd EFI partition as instructed, but my PC's BIOS/UEFI did not detect the new UEFI boot option for macOS.  I tested on an HP Elitebook 850 G7 laptop which has Windows 11, Ubuntu 24.0.4 and Open Core 1.0.6 / macOS with a single APFS Container.

 

I would like to figure out why the "Add EFI" method did not work, so if anyone else tests, please share your test experience.  Thank you.

[Matgen84]

Hi @deeveedee

Add EFI partition will be, perhaps, working if you use system-boot instead of grub. In this case, the computer have a multiboot from  Linux menu. Few month ago, I try this solution to test several (five) linux distributions.

Unfortunately, in your case, Ubuntu do not using systems-boot by default. But you can install it: the process in French sorry There is also some explanation (I prefer this) in English on Archwiki: EFI structure explanation and here for dual boot, could be multi boot.

Have a nice day.

Edited November 26, 2025 by Matgen84

[deeveedee]

@Matgen84 I'm sorry that my post made you sad.  I will review your recommendations.

[Anto65]

I'll let OC handle everything

Assuming I've prepared the partitions for the various OSes with their respective installation USBs, and copied my working OC EFI to a bootable USB,

 

I empty the EFI (OC) folder on the disk.

I begin by installing Windows in its dedicated partition , Windows will place its boot files (Boot and Microsoft) in the only available EFI
partition on the disk.

 

I proceed with installing Ubuntu, which will also place the boot files in the same EFI, overwriting the Windows Boot folder.

 

In my case, I continue installing FydeOS, and its boot files will end up with those of Windows and Ubuntu, once again overwriting the Boot folder from Ubuntu 

 

In the end in the EFI I will have like this ... ( I also added Clover )

 

 

 

Ok, now I Boot from OC USB and restore the Boot folder and OC folder ( previously saved )

 

 

Ok OC Boot now from the NVME ( you may need to Reset / Clean Nvram  ) but  with scanpolicy set to 0 at boot I only see this (OSX S) and nothing else

 

I add Custom ENTRIES , After find the Path of my Nvme via Shell ( and set scanpolicy to 2687747 ) 

 

in my case PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,D2-A8-9C-46-8B-44-1B-00)/HD(1,GPT,F9185C75-7F79-40BA-B1D7-3089D8043532,0x28,0x64000) 

 

and that will be the same path, for all the other Bootloaders (since the Boot files are together in the same folder / disk)

 

So I'm going to add for example the call for WINDOWS in Misc->Entries

 

PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,D2-A8-9C-46-8B-44-1B-00)/HD(1,GPT,F9185C75-7F79-40BA-B1D7-3089D8043532,0x28,0x64000)/\EFI\Microsoft\Boot\bootmgfw.efi        ( Windows )

 

PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,D2-A8-9C-46-8B-44-1B-00)/HD(1,GPT,F9185C75-7F79-40BA-B1D7-3089D8043532,0x28,0x64000)/\EFI\CLOVER\CLOVERX64.efi                ( Clover )

 

PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,D2-A8-9C-46-8B-44-1B-00)/HD(1,GPT,F9185C75-7F79-40BA-B1D7-3089D8043532,0x28,0x64000)/\EFI\ubuntu\grubx64.efi                         ( Ubuntu )

 

PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,D2-A8-9C-46-8B-44-1B-00)/HD(1,GPT,F9185C75-7F79-40BA-B1D7-3089D8043532,0x28,0x64000)/\EFI\fydeos\bootx64.efi                         ( Fydeos )

 

After saving and rebooting this is the result

 

 

... every os can be booted from OC, no drivers needed for Linux

 

 

Edited November 26, 2025 by Anto65

[Anto65]

@deeveedee  Here's  https://www.insanelymac.com/forum/topic/361492-efi-mounter/page/11/#findComment-2841956  another example with a second EFI same disk ... both working

 

 

 

[deeveedee]

@Anto65 I'll try it. Thank you.

[miliuco]

@Anto65

OT: please remember me where to get this nice OC theme. I know you showed it to me in the past but can't find it.

[deeveedee]

I have attached an updated Open Core EFI to Post #1.  This updated EFI based on Open Core 1.0.6 includes the following updates from my previoulsy posted EFI:

• Upgrade OC 1.0.5 -> OC 1.0.6

  • Upgrade BOOT/BOOTx64.efi

  • Upgrade OC/OpenCore.efi

  • OC/Drivers

    • Upgrade OC/Drivers/*.* (except HfsPlus.efi)

  • Upgrade OC/Tools/*.*

• Upgrade OC/Kexts

  • AppleALC.kext 1.9.5 -> 1.9.6

• OC/ACPI

  • SSDT-PTS: Change method _PTS from Serialized to NotSerialized (bug fix)

Notes

This EFI has csr-active-config = <00000000> (SIP fully enabled).  Be sure to modify csr-active-config if you're using VoodooHDA.kext for Tahoe audio (e.g., csr-active-config = <01000000>) or if you're using OCLP patchers (e.g., csr-active-config = <03080000>.)

 

When upgrading macOS Tahoe, temporarily disable RX 560x by adding boot-arg -wegnoegpu.  After the Tahoe update is complete, remove the boot-arg.  Since -wegnoegpu disables the RX 560x, you'll need a display connected to one of the iGPU ports during the upgrade.   This minor update inconvenience is because I am still using Acidanthera's WhateverGreen.kext 1.7.0.  Laobamac has a proposed fix with a new WhateverGreen.kext - see details here.

 

EDIT: Easy upgrade to macOS Tahoe 26.2 RC1 using this new EFI.

Spoiler

 

Edited December 8, 2025 by deeveedee
Added Tahoe 26.2 update