[GUIDE] Catalina, Big Sur, Monterey, Ventura, Sonoma, Sequoia, Tahoe on HP EliteDesk 800 G4/G5 Mini - The perfect MacMini8,1 Hackintosh

[deeveedee]

I'm patching another hack that requires experimentation with frame buffer patching to resolve black screen issues.  I have learned that boot-arg 'darkwake=2' can break sleep. 

 

For those who read this thread from the beginning, you'll see that I introduced darkwake=2 as a boot-arg very early in the development of this solution and then I never changed it.  Is anyone having any sleep issues with this hack?  If so, you may want to experiment with removing boot-arg darkwake=2.

[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.

[MacKonsti]

Hi @deeveedee although was't possible to find an HP like yours in my area/market, I still follow your postings ! Care to provide slightly more information for educational purposes?

The error was in macOS logs? Which OS, Sonoma or Sequoia? And the fix had to do with the compiled AML itself? I suspect here some NotSerialized wrong external declaration in the DSL code, right? Cheers!

Edited November 22, 2025 by MacKonsti

[deeveedee]

Hi, @MacKonsti !  There was no error message.  Method _PTS in the original unpatched DSDT is declared as NotSerialized.  When I overrode _PTS in SSDT-PTS, I incorrectly declared the new _PTS as Serialized.  The error (my error) is simply that I did not maintain consistency with the original method.

 

Original:

Method (_PTS, 1, NotSerialized)

 

New _PTS in SSDT-PTS (incorrect)

Method (_PTS, 1, Serialized)

 

Edited November 22, 2025 by deeveedee

[xenophon]

Dear DeeVeeDee, just want to say thanks.

 

Transplanted your frame buffer Device Properties to a ThinkCentre M70q (UHD630) that had been running for years through DP on a modern monitor. I decided to connect a gorgeous 20-year-old Apple Cinema Display (via a DVI->DP adapter) but would output no signal after the Apple logo.

 

Pity, because its size and industrial design are unsurpassed, to this day.

 

As I was getting ready to quit, I tried your EFI and, sure enough, your frame buffer patching worked!

 

Once again, thanks!

 

With greetings from Athens,

 

Xen

[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>.)

[deeveedee]

I am experimenting with some minor changes to my posted EFI based on things I learned while hacking my HP Elitebook 850 G7.  The changes with which I'm experimenting are:

• Remove boot-arg darkwake=2 (which may impact sleep)
• Add DeviceProperty "pci-aspm-default = <02000000>" to each NVMe m.2 SSD device for NVMe power management as explained by MaLd0N here.

In my macOS Tahoe testing, I find that NVMe ASPM is disabled without the addition of the pci-aspm-default DeviceProperties.  A sample plist is attached with my changes for those who may want to experiment.

 

After adding the pci-aspm-default DeviceProperties, Hackintool shows NVMe ASPM enabled in Tahoe:

Spoiler

 

 

config.plist.zip

[MacKonsti]

Ηι @deeveedee why didn't you ask me, I'd tell you sooner LOL

 

I have had this aspm parameter for some time, and indeed it still shows in Hackintool as L1, you are right!

 

However I don't use 4 bytes but 1, to achieve the same result--I think I saw it someplace in some other native IOReg, so you could very well use only 2 bytes:

			<key>PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)</key>
			<dict>
				<key>pci-aspm-enable</key>
				<data>AQ==</data>
				<key>model</key>
				<string>WD Black SN750 NVMe Controller</string>
			</dict>

However, I am not sure how this can be truly measured if it has any (positive) impact, except the L1 mention in Hackintool... didn't bother to dig further.

 

I have had my eyes on an HP EliteDesk G5 Mini but they are hard to find in Europe and very expensive, to join your great thread here (still have my Intel NUCs) so allow me to keep reading your findings and post from time to time!  Take care

[deeveedee]

@MacKonsti I should have asked you!     Are you adding the pci-aspm-default property to any other PCIe devices on your NUC?  On my HP Elitebook 850 G7 (laptop), I have added the property to NVMe m.2 SSD and to Wi-Fi.

 

I am not sure "pci-aspm-default = 2" will make any difference on this HP EliteDesk desktop platform.  I only started experimenting with the power management properties to maximize battery life on my laptop.

 

EDIT: @MacKonsti we are using different ASPM properties.  I did a quick search and found this:

In macOS, pci-aspm-enable (or force) forcibly turns on PCIe Active-State Power Management for power saving, while pci-aspm-default (or auto/off) lets the system use its firmware's default, often turning it off or to a safe state, especially for non-Apple SSDs where enabling it can fix power drain but disabling it (via default/off) prevents hangs. pci-aspm-enable (or force) is for power savings but risks instability, whereas pci-aspm-default prioritizes stability but might use more power. 

Edited December 9, 2025 by deeveedee

[jlrycm]

On 12/8/2025 at 11:49 AM, deeveedee said:

 

I am experimenting with some minor changes to my posted EFI based on things I learned while hacking my HP Elitebook 850 G7.  The changes with which I'm experimenting are:

• Remove boot-arg darkwake=2 (which may impact sleep)
• Add DeviceProperty "pci-aspm-default = <02000000>" to each NVMe m.2 SSD device for NVMe power management as explained by MaLd0N here.

In my macOS Tahoe testing, I find that NVMe ASPM is disabled without the addition of the pci-aspm-default DeviceProperties.  A sample plist is attached with my changes for those who may want to experiment.

 

After adding the pci-aspm-default DeviceProperties, Hackintool shows NVMe ASPM enabled in Tahoe:

  Reveal hidden contents

 

 

config.plist.zip 1.04 kB · 6 downloads

@MaLd0n @deeveedee I tried enabling the ASPM device property for my NVME drives and it did not work. Below you can see what I defined for two of my NVMEs.

 

Spoiler

 

Do you know why it may have not worked in my case? Is it that the property value may be different for me?

Edited December 11, 2025 by jlrycm

[deeveedee]

@jlrycm Assuming you have the correct DevicePath for NVMe in your DeviceProperties (since you're asking about a system that is different from the one discussed in this thread), make sure that ASPM (Active-State Power Management) is enabled in BIOS (if that is a BIOS option for you).  If you have confirmed both the DevicePath in your DeviceProperties and your BIOS settings and Hackintool still shows ASPM disabled, you may want to try using pci-aspm-enable instead of pci-aspm-default as MacKonsti has done.

Edited December 12, 2025 by deeveedee

[jlrycm]

15 hours ago, deeveedee said:

@jlrycm Assuming you have the correct DevicePath for NVMe in your DeviceProperties (since you're asking about a system that is different from the one discussed in this thread), make sure that ASPM (Active-State Power Management) is enabled in BIOS (if that is a BIOS option for you).  If you have confirmed both the DevicePath in your DeviceProperties and your BIOS settings and Hackintool still shows ASPM disabled, you may want to try using pci-aspm-enable instead of pci-aspm-default as MacKonsti has done.

Thank you @deeveedee I was able to enable ASPM at PCIe level for two NVMEs for which the root port was listed in BIOS settings and now I see L1 for both. The root port for another NVME was not listed and the fourth NVME I’m using is plugged to the TB4 port and I haven’t enable ASPM for TB4 because I read somewhere that it is not recommended to enable ASPM for TB4. @deeveedee based on you tests of NVMe ASPM property, are you seeing any improvements, issues or no difference?

Edited December 13, 2025 by jlrycm

[MacKonsti]

On 12/8/2025 at 11:27 PM, deeveedee said:

@MacKonsti I should have asked you!     Are you adding the pci-aspm-default property to any other PCIe devices on your NUC?  On my HP Elitebook 850 G7 (laptop), I have added the property to NVMe m.2 SSD and to Wi-Fi.

 

I am not sure "pci-aspm-default = 2" will make any difference on this HP EliteDesk desktop platform.  I only started experimenting with the power management properties to maximize battery life on my laptop.

 

EDIT: @MacKonsti we are using different ASPM properties.  I did a quick search and found this:

 

In macOS, pci-aspm-enable (or force) forcibly turns on PCIe Active-State Power Management for power saving, while pci-aspm-default (or auto/off) lets the system use its firmware's default, often turning it off or to a safe state, especially for non-Apple SSDs where enabling it can fix power drain but disabling it (via default/off) prevents hangs. pci-aspm-enable (or force) is for power savings but risks instability, whereas pci-aspm-default prioritizes stability but might use more power. 

Hello mate, interesting find, I will change my key from default to enable, and see if L1 remains. Again, not sure how this is measurable beyond just being reported...

Thank you very much for your advance research!

[MacKonsti]

OK @deeveedee so I did a check on my Sonoma installation and did find that other PCI devices use "pci-aspm-default" so switched to that one, too.

A simple Terminal line showed the following values (tried to improve it via ChatGPT but failed to show attached devices):

% ioreg -lw0 | grep pci-aspm
    | |   | |   "pci-aspm-default" = 0
    | |   | |   "pci-aspm-default" = <02>
    | |   | |   "pci-aspm-default" = 2
    | |   |     |   "pci-aspm-default" = 258
    | |   |       | |   "pci-aspm-default" = 2
    | |   |       |     |   "pci-aspm-default" = 258
    | |   |       | |   "pci-aspm-default" = 2
    | |   |         |   "pci-aspm-default" = 2
    | |   |             |   "pci-aspm-default" = 258
    | |   | |   "pci-aspm-default" = 2
    | |   |     |   "pci-aspm-default" = <02>
    | |   | |   "pci-aspm-default" = 0
    | |   |     |   "pci-aspm-default" = 256

I also found that whether you inject <integer>2</integer> or <data>Ag==</data> in config.plist text, the result is the same L1 in Hackintool. I added this flag to both my WD NVMe as well as my (embedded) Intel Wireless PCIe adapter (hence why you see twice <02>).
As all other (native?) values in IORegistryExplorer.app are shown as "number" type, I am not sure if this is a bug in OpenCore, because when either <integer> or <data> is used, it results to "data" type being shown in IORegistryExplorer -- and it is strange, as I would have expected this to differ.

I had found about this problem some time ago, when injecting the alc-layout-id as "integer" (24) which also showed as "data".

 

Despite this, both cases/types seem to work, eventually. Just "integer" not treated/seen as "Number" in IORegistryExplorer... any ideas?

 

In any case, L1 is shown for both devices in Hackintool so I can assume the injection of "2" or "0x02" works. Thank you for your tip.

[deeveedee]

@MacKonsti great report!  I, too, have seen discrepancies between the OC injected data type and the type reported in IOReg.  I experimented with different OC-injected types, but they remained stubbornly persistent in IOReg.  So I decided that "if it ain't broke ..."

 

Nice work!

 

EDIT: Thank MaLd0N for the tip - I'm just the messenger.

Edited December 13, 2025 by deeveedee

[MacKonsti]

Finally nailed it... For those of you that want to show which devices contain "pci-aspm" values (and any variants of the key) here's the final command in Terminal:

% ioreg -lw0 | grep -E '@.*IOPCIDevice' -A40 | grep -E '@.*IOPCIDevice|pci-aspm'

    | |   +-o MCHC@0  <class IOPCIDevice, id 0x100000325, registered, matched, active, busy 0 (0 ms), retain 9>
    | |   +-o IGPU@2  <class IOPCIDevice, id 0x100000326, registered, matched, active, busy 0 (867 ms), retain 35>
    | |   | |   "pci-aspm-default" = 0
    | |   +-o PGMM@8  <class IOPCIDevice, id 0x100000327, registered, matched, active, busy 0 (12 ms), retain 9>
    | |   +-o THRM@12  <class IOPCIDevice, id 0x100000328, registered, matched, active, busy 0 (11 ms), retain 9>
    | |   +-o XHC@14  <class IOPCIDevice, id 0x100000329, registered, matched, active, busy 0 (437 ms), retain 14>
    | |   +-o SRAM@14,2  <class IOPCIDevice, id 0x10000032a, registered, matched, active, busy 0 (13 ms), retain 9>
    | |   +-o CNVW@14,3  <class IOPCIDevice, id 0x10000032b, registered, matched, active, busy 0 (414 ms), retain 12>
    | |   | |   "pci-aspm-default" = <02>
    | |   +-o I2C0@15  <class IOPCIDevice, id 0x10000032c, registered, matched, active, busy 0 (9 ms), retain 9>
    | |   +-o I2C2@15,2  <class IOPCIDevice, id 0x10000032d, registered, matched, active, busy 0 (11 ms), retain 10>
    | |   +-o IMEI@16  <class IOPCIDevice, id 0x10000032e, registered, matched, active, busy 0 (95 ms), retain 11>
    | |   +-o SATA@17  <class IOPCIDevice, id 0x10000032f, registered, matched, active, busy 0 (121 ms), retain 24>
    | |   +-o RP05@1C  <class IOPCIDevice, id 0x100000330, registered, matched, active, busy 0 (446 ms), retain 12>
    | |   | |   "pci-aspm-default" = 2
    | |   |   +-o UPSB@0  <class IOPCIDevice, id 0x100000338, registered, matched, active, busy 0 (434 ms), retain 17>
    | |   |     |   "pci-aspm-default" = 258
    | |   |       +-o DSB0@0  <class IOPCIDevice, id 0x100000339, registered, matched, active, busy 0 (428 ms), retain 13>
    | |   |       | |   "pci-aspm-default" = 2
    | |   |       |   +-o NHI0@0  <class IOPCIDevice, id 0x10000033c, registered, matched, active, busy 0 (425 ms), retain 12>
    | |   |       |     |   "pci-aspm-default" = 258
    | |   |       +-o DSB1@1  <class IOPCIDevice, id 0x10000033a, registered, matched, active, busy 0 (4 ms), retain 13>
    | |   |       | |   "pci-aspm-default" = 2
    | |   |       +-o DSB2@2  <class IOPCIDevice, id 0x10000033b, registered, matched, active, busy 0 (35 ms), retain 13>
    | |   |         |   "pci-aspm-default" = 2
    | |   |           +-o XHC2@0  <class IOPCIDevice, id 0x10000033d, registered, matched, active, busy 0 (32 ms), retain 15>
    | |   |             |   "pci-aspm-default" = 258
    | |   +-o RP09@1D  <class IOPCIDevice, id 0x100000331, registered, matched, active, busy 0 (70 ms), retain 12>
    | |   | |   "pci-aspm-default" = 2
    | |   |   +-o PXSX@0  <class IOPCIDevice, id 0x10000033e, registered, matched, active, busy 0 (59 ms), retain 13>
    | |   |     |   "pci-aspm-default" = <02>
    | |   +-o RP14@1D,5  <class IOPCIDevice, id 0x100000332, registered, matched, active, busy 0 (264 ms), retain 12>
    | |   | |   "pci-aspm-default" = 0
    | |   |   +-o PXSX@0  <class IOPCIDevice, id 0x10000033f, registered, matched, active, busy 0 (258 ms), retain 12>
    | |   |     |   "pci-aspm-default" = 256
    | |   +-o LPCB@1F  <class IOPCIDevice, id 0x100000333, registered, matched, active, busy 0 (6 ms), retain 20>
    | |   +-o HDEF@1F,3  <class IOPCIDevice, id 0x100000334, registered, matched, active, busy 0 (1579 ms), retain 12>
    | |   +-o SBUS@1F,4  <class IOPCIDevice, id 0x100000335, registered, matched, active, busy 0 (215 ms), retain 13>
    | |   +-o XSPI@1F,5  <class IOPCIDevice, id 0x100000336, registered, matched, active, busy 0 (6 ms), retain 9>
    | |   +-o GLAN@1F,6  <class IOPCIDevice, id 0x100000337, registered, matched, active, busy 0 (568 ms), retain 12>

This way you can see which devices have it natively, or set (i.e. value <02> that I mentioned before).

In my case, as I mentioned, I set it in config.plist for CNVW (Intel PCIe embedded wireless) and PXSX (WD-Sandisk NVMe)

Good night from Europe.

 

(yes indeed, thanks MaLd0N for the original tip and you for opening my eyes  as I had the other pci-aspm variant)

 

UPDATE: For visual simplicity we can add an extra layer and remove contents between <class... and > in the devices list:

% ioreg -lw0 | grep -E '@.*IOPCIDevice' -A40 | grep -E '@.*IOPCIDevice|pci-aspm' | sed 's/<class[^>]*>//g'
    | |   +-o MCHC@0  
    | |   +-o IGPU@2  
    | |   | |   "pci-aspm-default" = 0
    | |   +-o PGMM@8  
    | |   +-o THRM@12  
    | |   +-o XHC@14  
    | |   +-o SRAM@14,2  
    | |   +-o CNVW@14,3  
    | |   | |   "pci-aspm-default" = <02>
    | |   +-o I2C0@15  
    | |   +-o I2C2@15,2  
    | |   +-o IMEI@16  
    | |   +-o SATA@17  
    | |   +-o RP05@1C  
    | |   | |   "pci-aspm-default" = 2
    | |   |   +-o UPSB@0  
    | |   |     |   "pci-aspm-default" = 258
    | |   |       +-o DSB0@0  
    | |   |       | |   "pci-aspm-default" = 2
    | |   |       |   +-o NHI0@0  
    | |   |       |     |   "pci-aspm-default" = 258
    | |   |       +-o DSB1@1  
    | |   |       | |   "pci-aspm-default" = 2
    | |   |       +-o DSB2@2  
    | |   |         |   "pci-aspm-default" = 2
    | |   |           +-o XHC2@0  
    | |   |             |   "pci-aspm-default" = 258
    | |   +-o RP09@1D  
    | |   | |   "pci-aspm-default" = 2
    | |   |   +-o PXSX@0  
    | |   |     |   "pci-aspm-default" = <02>
    | |   +-o RP14@1D,5  
    | |   | |   "pci-aspm-default" = 0
    | |   |   +-o PXSX@0  
    | |   |     |   "pci-aspm-default" = 256
    | |   +-o LPCB@1F  
    | |   +-o HDEF@1F,3  
    | |   +-o SBUS@1F,4  
    | |   +-o XSPI@1F,5  
    | |   +-o GLAN@1F,6  

This way we see which IOReg devices contain a value. Note: Some names are injected by me in SSDT, like MCHC, PGMM, THRM etc. which are otherwise mentioned as their Device Path.

Edited December 13, 2025 by MacKonsti

[ird]

On 12/8/2025 at 1:27 PM, deeveedee said:

@MacKonsti I should have asked you!     Are you adding the pci-aspm-default property to any other PCIe devices on your NUC?  On my HP Elitebook 850 G7 (laptop), I have added the property to NVMe m.2 SSD and to Wi-Fi.

 

I am not sure "pci-aspm-default = 2" will make any difference on this HP EliteDesk desktop platform.  I only started experimenting with the power management properties to maximize battery life on my laptop.

 

EDIT: @MacKonsti we are using different ASPM properties.  I did a quick search and found this:

 

In macOS, pci-aspm-enable (or force) forcibly turns on PCIe Active-State Power Management for power saving, while pci-aspm-default (or auto/off) lets the system use its firmware's default, often turning it off or to a safe state, especially for non-Apple SSDs where enabling it can fix power drain but disabling it (via default/off) prevents hangs. pci-aspm-enable (or force) is for power savings but risks instability, whereas pci-aspm-default prioritizes stability but might use more power. 

 

So, inspired by you I went a bit wild and enabled default ASPM for both PCIe bridges 0x0 and 0x1 root nodes (and by association to all attached end points). I'm going to test a bit if this causes instability in the next 2 days before I'm away for the rest of this year. Basic testing, I found no differences in CPU, GPU geekbench 6 scores. My dGPU scores were a bit low to start with before this change (I never got the opportunity to debug it). I'll report back if I see any issues enabling L1 ASPM.

 

Spoiler

 

 

 

 

 

 

 

 

Edit: Sorry, I didn't realize this is the non-dGPU thread! I'll leave the dGPU Geekbench 6 scores as-is in the post anyway. The rest of PCIe devices are common between the two configs.

Edited December 14, 2025 by ird

[deeveedee]

New version of IntelMausiEthernet.kext is available from Mieze.  Look for the latest release starting here.

 

EDIT: I am currently testing macOS 26.2 with IntelMausiEthernet.kext 3.0.3.  I no longer need to set Kernel > Quirks > DisableIoMapper = True for fully working Ethernet.  AppleVTD is enabled and Tahoe Ethernet works.

Edited December 15, 2025 by deeveedee

[deeveedee]

For those like me who like to "geek out" on purely cosmetic patches to their hacks, here's a patch that you might like.  A real Mac includes Device MATH in ACPI.  This hack does not enable MATH by default.  The attached config.plist entries and SSDT will enable the MATH device in ACPI on your EliteDesk 800 G4/G5 Mini hacks.  Why?  No good reason that I can think of

 

Merry Christmas and Happy Holidays to everyone.  Very thankful for this hack that will be giving us full support for yet another (and final) major macOS release.

 

 

Archive.zip

[jlrycm]

6 hours ago, deeveedee said:

For those like me who like to "geek out" on purely cosmetic patches to their hacks, here's a patch that you might like.  A real Mac includes Device MATH in ACPI.  This hack does not enable MATH by default.  The attached config.plist entries and SSDT will enable the MATH device in ACPI on your EliteDesk 800 G4/G5 Mini hacks.  Why?  No good reason that I can think of

 

Merry Christmas and Happy Holidays to everyone.  Very thankful for this hack that will be giving us full support for yet another (and final) major macOS release.

 

 

Archive.zip 4.17 kB · 3 downloads

Merry Christmas and Happy Holidays!

[deeveedee]

Easy upgrade from Tahoe 26.1 -> 26.2 using the OC 1.0.6 EFI attached to Post #1 with the following changes:

• Removed boot-arg darkwake=2
• Add pci-aspm-default DeviceProperties for NVMe m.2 SSDs, Ethernet, Audio, SATA

My hack sleeps/wakes perfectly without issues.  I will incorporate these changes into my OC 1.0.7 EFI after OC 1.0.7 is available.

 

For improved UHD630 graphics performance in Tahoe, I continue to enable the following System Settings:

• Accessibility > Display > Reduce Transparency
• Accessibility > Motion > Reduce Motion

 

EDIT: for improved overall responsiveness in Tahoe, upgrade RAM to at least 16GB with 2 equally-sized memory modules (e.g., for 16GB, use 2 x 8GB memory modules)

 

Edited January 14 by deeveedee

[dREAmCaTCHeR]

@deeveedee is it worth upgrading to Tahoe? I have 16Gb ram and i5 8500T, i'm currently on Sonoma. Where things are currently stable, although most apps I have have dropped sonoma support, when I try Sequoia I lose wifi and debating whether Tahoe is worth it.

[deeveedee]

I will need Tahoe for continued XCode support.  It depends on your use cases.  I don't use Wi-Fi on this platform.  Why do you lose Wi-Fi in Sequoia?  On my HackBookPro16,2 I use itlwm for Intel Wi-Fi (no root patches).  Works perfectly (for my limited Wi-Fi use cases) in Sequoia and Tahoe.

[deeveedee]

I have uploaded a new EFI to Post #1.  This new EFI is based on Open Core 1.0.7 and has changes previously discussed in this thread as listed below.  When using this EFI, note the following:

• csr-active-config = <01000000>.  Change this as follows based on your use case:
  • csr-active-config = <01000000> for using and updating VoodooHDA.kext for audio
  • csr-active-config = <03000000> for installing VoodooHDA.kext for the first time
  • csr-active-config = <03080000> for using OCLP
  • csr-active-config = <00000000> for SIP fully enabled
• This EFI does not enable Bluetooth.  If you use Bluetooth, you will need to enable Bluetooth in BIOS, modify USB Map to add Bluetooth USB port (HS14), add NVRAM properties for Bluetooth and add required kexts.  BrcmPatchRAM 2.7.2 is available from Acidanthera.
• I am currently using VoodooHDA.kext 3.1.2 available here for Audio in macOS Tahoe.  I have SIP csr-active-config = <01000000> to allow VoodooHDA.kext in /Library/Extensions.  This version of VoodooHDA.kext is working very well for me with outstanding audio quality and no root patches.  Since I am not using Wi-Fi on this hack, I don't need to re-apply any root patches after updating macOS Tahoe.
• If you are using BluetoolFixup.kext (not included in my posted EFI), you will need to temporarily disable BluetoolFixup.kext to permit incremental macOS updates and then re-enable BluetoolFixup.kext after applying the incremental macOS update.

 

Changes to the new EFI are as follows

 

OC 1.0.7 EFI R01

• Upgrade OC 1.0.6 -> 1.0.7
  • BOOT/BOOTx64.efi
  • OC/OpenCore.efi
  • OC/Drivers/*.* (except HfsPlus.efi)
  • OC/Tools/*.*
• OC/Kexts
  • Upgrade AppleALC.kext 1.9.6 -> 1.9.7
  • Upgrade Lilu.kext 1.7.1 -> 1.7.2
• OC/ACPI
  • Add SSDT-FWHD
  • Remove unnecessary Else conditions in SSDTs
• OC/config.plist
  • Add ACPI > Add > SSDT-FWHD

 

OC 1.0.6 EFI R02 (Not posted)

• OC/config.plist
  • Changed csr-active-config to <01000000> for VoodooHDA.kext
  • Add pci-aspm-default DeviceProperties for NVMe m.2 SSDs, Ethernet, Audio, SATA
  • Remove boot-arg darkwake=2
  • Add ACPI > Add > SSDT-MATH
  • Add ACPI > Patch > Rename MATH._STA -> MATH._XSTA (paired with SSDT-MATH)
• OC/ACPI
  • Add SSDT-MATH
• OC / Kexts
  • Upgrade IntelMausiEthernet.kext 2.5.5d0 -> 3.0.0 Build 3.0.3

 

 

EDIT: Easy upgrade to macOS Tahoe 26.4 RC with this EFI.  This hack is still working perfectly.

Spoiler

 

Edited March 23 by deeveedee

[deeveedee]

I have noticed that, since removing boot-arg darkwake=2, I sometimes need an extra mouse button click to wake displays after waking the hack from sleep.  I believe that is why I had initially added the boot-arg.  I don't plan to re-add boot-arg darkwake=2, so if you experience this issue and it bothers you, experiment with the darkwake boot-args.