Experimental Fork of OCLP 3.0.0 Nightly – modern Wi-Fi, AWDL and AppleHDA Fully Working under Tahoe

[kgp]

@carlo_67, for testing purposes I’m trying to run my Intel AX210S with OCLP 3.0.0 Nightly. Wi-Fi works fine using itlwm.kext 2.3.0 together with HeliPort 1.5.
However, no matter what I try, Bluetooth does not work, and OCLP 3.0.0 Nightly only patches Modern Audio.

 

 

 

 

   

 

Is the Intel AX210S simply incompatible with IntelBluetoothFirmware and AirportItlwm?
I see no difference when enabling or disabling AirportBrcmFixup.kext, BlueToolFixup.kext, IntelBluetoothFirmware.kext, or IntelBTPatcher.kext.

It would be awesome if you could check my attached EFI, just to rule out any configuration errors on my side.

Cheers and many thanks in advance,
KGP

 👍

EFI-Intel-OCLP-Nightly-test.zip

Edited December 15, 2025 by KGP-iMacPro

[Pc Bacabal]

23 hours ago, tikizondo94 said:

Você perde a funcionalidade Wi-Fi ao remover amfi=0x80? 

Yes!

[deeveedee]

@KGP-iMacPro OCLP won't install Wi-Fi patches if it doesn't detect your Wi-Fi.  You need to apply an ACPI patch to spoof your Intel as Broadcom.  OCLP inspects IOName of each device to detect patches.  You may be able to apply an ACPI patch that changes your Intel IOName to a Modern Brcm Wi-Fi.

[kgp]

12 minutes ago, deeveedee said:

@KGP-iMacPro OCLP won't install Wi-Fi patches if it doesn't detect your Wi-Fi.  You need to apply an ACPI patch to spoof your Intel as Broadcom.  OCLP inspects IOName of each device to detect patches.  You may be able to apply an ACPI patch that changes your Intel IOName to a Modern Brcm Wi-Fi.

 

Did you have a look to my EFI and the device properties for the X210s, which I added to the config.plist? All properties for other devices are handelt via SSDTs.  If I missed something in my EFI-Folder configuration, I would be glad to receive an update of my EFI with the necessary improvements.. Many thanks in advance  👍 

Edited December 15, 2025 by KGP-iMacPro

[deeveedee]

@KGP-iMacPro Sorry I didn't make the changes for you.  I think you can remove the compatible, device-id, name, subsystem-id, subsystem-vendor-id, vendor-id and specify only the IOName.  Besides the fact that your compatible is not consistent with the other values, the others shouldn't be necessary.  I was actually trying to help, but I see that my assistance wasn't received that way.  I apologize.

Edited December 15, 2025 by deeveedee

[kgp]

3 minutes ago, deeveedee said:

@KGP-iMacPro Sorry I didn't make the changes for you.  I think you can remove the compatible, device-id, name, subsystem-id, subsystem-vendor-id, vendor-id and specify only the IOName.  Besides the fact that your compatible is not consistent with the other values, the others shouldn't be necessary.

 

I just implemented all device properties as proposed by @carlo_67, and I will wait for his reply. Many thanks for your kind help, anyway 👍 For me these tests are only because of curiosity and I have time to wait.. Nothing vital, really! 

Edited December 15, 2025 by KGP-iMacPro

[deeveedee]

@KGP-iMacPro I am deeply sorry that I could not help you.  Please accept my apologies.

 

EDIT: For anyone else who is interested, OCLP inspects only the IOName of the device to detect device properties.  Only the IOName needs to be specified to spoof a device for OCLP.

 

@Stefanalmare I just saw that you had already posted this here.  Sorry for the duplication.  Nice to see that we both remember this from the early OCLP days

Edited December 15, 2025 by deeveedee

[FirstCustomac]

Hello @KGP-iMacPro, First, I would check IOReg to see if the spoofing had worked, but looking at your screenshot above, it looks like bridges to your AX210S are not defined in ACPI. In such case, as far as I know, trying to spoof device parameters that already exist via DeviceProperties injection method does not work. I think you would first need to define theses bridges first with ACPI patching.      

[deeveedee]

@FirstCustomac Very observant!

[schrup21]

@KGP-iMacPro his is my fake device, with which OCLP detects the possible modern WiFi patch – it must be disabled after patching.

you'll need to change the Device Path of course...

 

 

Regarding Bluetooth, the original Intel Bluetooth KEXT requires the boot parameter -lilubetaall because it lacks support for Tahoe. The lshbluesky fork is adapted for Tahoe (actually, only IntelBTPatcher.kext requires Tahoe support).

 

https://github.com/lshbluesky/IntelBluetoothFirmware

Edited December 15, 2025 by schrup21

[carlo_67]

1 hour ago, KGP-iMacPro said:

 

I just implemented all device properties as proposed by @carlo_67, and I will wait for his reply. Many thanks for your kind help, anyway 👍 For me these tests are only because of curiosity and I have time to wait.. Nothing vital, really! 

I would change the sequence of the kexts for BT, first firmware then fixup then patcher, in any case the device properties are only used to detect modern wifi, once patched you can also remove and put back the Intel ones,

 

 

 

 

 

 

[deeveedee]

@schrup21 If you change only the IOName, you won't need to disable your spoofing after patching. All the other properties are unnecessary for OCLP patching.

[kgp]

On 12/15/2025 at 6:14 PM, FirstCustomac said:

Hello @KGP-iMacPro, First, I would check IOReg to see if the spoofing had worked, but looking at your screenshot above, it looks like bridges to your AX210S are not defined in ACPI. In such case, as far as I know, trying to spoof device parameters that already exist via DeviceProperties injection method does not work. I think you would first need to define theses bridges first with ACPI patching.      

 

Yes!  My Intel AX210S is now also flawlessly working with the experimental fork of OCLP 3.0.0 Nightly under MacOS 26.2!💫

 

 

 

 

 

DefinitionBlock ("", "SSDT", 1, "KGP", "PC01BR1A", 0x00000000)
{
    External (_SB_.PC01.BR1A.SL01, DeviceObj)
    External (DTGP, MethodObj)    // 5 Arguments

    Scope (\_SB.PC01.BR1A.SL01)
    {
        Device (EGP4)
        {
            Name (_ADR, 0x00100000)  // _ADR: Address
            Device (ANS3)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If ((Arg2 == Zero))
                    {
                        Return (Buffer (One)
                        {
                             0x03                                             // .
                        })
                    }

                    Local0 = Package (0x08)
                        {
                            "AAPL,slot-name", 
                            Buffer (0x07)
                            {
                                "Slot-5"
                            }, 

                            "built-in", 
                            Buffer (One)
                            {
                                 0x00                                             // .
                            }, 

                            "name", 
                            Buffer (0x19)
                            {
                                "Apple SSD Controller III"
                            }, 

                            "model", 
                            Buffer (0x16)
                            {
                                "Apple SSD AP1024M III"
                            }
                        }
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            }
        }

        Device (EGP5)
        {
            Name (_ADR, 0x00080000)  // _ADR: Address
            Device (ARPT)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If ((Arg2 == Zero))
                    {
                        Return (Buffer (One)
                        {
                             0x03                                             // .
                        })
                    }

                    Local0 = Package (0x0A)
                        {
                            "built-in", 
                            Buffer (One)
                            {
                                 0x00                                             // .
                            }, 

                            "AAPL,slot-name", 
                            Buffer (0x07)
                            {
                                "Slot-7"
                            }, 

                            "device_type", 
                            Buffer (0x13)
                            {
                                "AirPort Controller"
                            }, 

                            "model", 
                            Buffer (0x2E)
                            {
                                "Intel AX210 Wi-Fi 6E 802.11ax + Bluetooth 5.3"
                            }, 

                            "name", 
                            Buffer (0x10)
                            {
                                "AirPort Extreme"
                            }
                        }
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            }
        }
    }
}

 

 

 

For bluetooth, I finally used IntelBluetoothFirmware.kext v.2.5.0 and IntelBTPatcher.kext v.2.5.0 of Ishbluesky (thanks @schrup21), and BlueToolFixup.kext 1.7.1 of acidanthera. After changing the USB-port, also Bluetooth now works flawlessly.

 

 

 

 

 

I am done.. Intel AX210S fully working with OCLP 3.0.0 Nightly! Special thanks for help by @carlo_67, @FirstCustomac, @schrup21, and @deeveedee 

 

Attached the final Intel OCLP3.0.0 Nightly EFI-Folder. 

 

Short summery and brief guideline: 

The approach is very simple, if one just knows how to do it:

1.) The baseline was my EFI-Folder for Broadcom-OCLP 
2.) One needs to implement AirportItlwm.kext 2.3.0 for Ventura
3.) One needs to spoof the IOName to pci14e4,43a0 in DeviceProperties of the config.plist with the correct device path obtained from Hackintool. 
4.) One needs an additional ARPT-SSDT for fixing possible spoofing issues induced by PCI-bridges. All one needs to do here is to adopt the correct ACPI-path deduced from IOReg.
5.) For Bluetooth, one needs to implement IntelBluetoothFirmware.kext v.2.5.0 and IntelBTPatcher.kext v.2.5.0 of Ishbluesky, as well as BlueToolFixup.kext 1.7.1 of Dortiana.
6.) Everything else, like also implemented in my EFI-Folder for Broadcom OCLP. 

That's all. Just use EFI-KGP-public-v.1.1.3-OCLP-Intel of my EFI-Folder Distribution and besides the usual system adaptation, also carefully consider points 3.) and 4.) above. Due to boot-arg "amfi=0x80", some applications (e.g., Firefox) may fail to run. To likely circumvent these issues, also add the boot-arg "ipc_control_port_options=0" (credits to @badbrain). 

Good luck

 

Edited April 22 by kgp

[deeveedee]

@KGP-iMacPro Nice job!  You can simplify Method _DSM by removing the DTGP() call.  This code at the beginning of _DSM eliminates the need to call DTGP:

 

                    If ((Arg2 == Zero))
                    {
                        Return (Buffer (One)
                        {
                             0x03                                             // .
                        })
                    }

Your new _DSM would be:

Spoiler

                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If ((Arg2 == Zero))
                    {
                        Return (Buffer (One)
                        {
                             0x03                                             // .
                        })
                    }

                    Local0 = Package (0x08)
                        {
                            "AAPL,slot-name", 
                            Buffer (0x07)
                            {
                                "Slot-5"
                            }, 

                            "built-in", 
                            Buffer (One)
                            {
                                 0x00                                             // .
                            }, 

                            "name", 
                            Buffer (0x19)
                            {
                                "Apple SSD Controller III"
                            }, 

                            "model", 
                            Buffer (0x16)
                            {
                                "Apple SSD AP1024M III"
                            }
                        }

                    Return (Local0)
                }

 

 

Edited December 15, 2025 by deeveedee

[deeveedee]

And now a word from the OCLP Dev

https://forums.macrumors.com/threads/macos-tahoe-26-on-unsupported-macs-discussion.2458481/post-34338105

Edited December 15, 2025 by deeveedee

[Thebes Knossos]

Glad for you all. Not sure I will see a day a version compatible with Haswell + Tahoe

Edited December 16, 2025 by Thebes Knossos

[deeveedee]

@Thebes Knossos I guess we could say that for just about everything.  OCLP Devs have already said that they have legacy metal working in their test environment.  I'd say your chances are fairly good.

[arsradu]

On 12/15/2025 at 6:22 PM, deeveedee said:

@KGP-iMacPro OCLP won't install Wi-Fi patches if it doesn't detect your Wi-Fi.  You need to apply an ACPI patch to spoof your Intel as Broadcom.  OCLP inspects IOName of each device to detect patches.  You may be able to apply an ACPI patch that changes your Intel IOName to a Modern Brcm Wi-Fi.

Indeed. I had this issue when hackintoshing my old Lenovo L450 with Intel WiFi.

 

You can read more about my journey here.

 

In short, you will need SSDTTime, add device path and create an SSDT-Bridge.aml which will be injected through OC (under ACPI). Apparently OC can patch a device if it's already defined, but it won't add it if it's not already present.

 

Took me a while to figure this out.

 

So, if you want to spoof Broadcom WiFi for Intel WiFi hardware, it is possible, it does work (haven't tested it under Tahoe though, but it should be the same), but first you need to make sure everything is properly recognised. Otherwise OC will not patch it and you won't see the device recognised as "Broadcom", which will also not display the patch for Modern WiFi in OCLP (since that one is not meant for Intel WiFi).

Edited December 16, 2025 by arsradu

[kgp]

1 hour ago, arsradu said:

Indeed. I had this issue when hackintoshing my old Lenovo L450 with Intel WiFi.

 

You can read more about my journey here.

 

In short, you will need SSDTTime, add device path and create an SSDT-Bridge.aml which will be injected through OC (under ACPI). Apparently OC can patch a device if it's already defined, but it won't add it if it's not already present.

 

Took me a while to figure this out.

 

So, if you want to spoof Broadcom WiFi for Intel WiFi hardware, it is possible, it does work (haven't tested it under Tahoe though, but it should be the same), but first you need to make sure everything is properly recognised. Otherwise OC will not patch it and you won't see the device recognised as "Broadcom", which will also not display the patch for Modern WiFi in OCLP (since that one is not meant for Intel WiFi).

 

 

[arsradu]

Yep, I saw the message after posting mine.  All good then. Thank you!

[kgp]

With my Intel AX210S and the same EFI-Folder with OCLP 2.4.1 under Sequoia:

 

 

 

 

 

For regular OCLP2.4.1 under Sequoia, one can remove amfi=0x80 and use AMFIPass.kext, like in case of Broadcom.
I am having issues with bluetooth under Sequoia though. Devices do not properly connect.

 

 

Maybe one needs to use IntelBluetoothFirmware.kext and IntelBTPatcher.kext from here instead? Nope.. This kext version definitely does not work on my system. When adding -lilubetaall, my system stalls during boot or boots into a black screen.   

 

@carlo_67, btw.. I did not know that a very similar approach has been published on Github before for Sequoia. 🤨 

 

 

Edited December 17, 2025 by KGP-iMacPro

[carlo_67]

On 12/17/2025 at 9:19 PM, KGP-iMacPro said:

With my Intel AX210S and the same EFI-Folder with OCLP 2.4.1 under Sequoia:

 

 

 

 

 

For regular OCLP2.4.1 under Sequoia, one can remove amfi=0x80 and use AMFIPass.kext, like in case of Broadcom.
I am having issues with bluetooth under Sequoia though. Devices do not properly connect.

 

 

Maybe one needs to use IntelBluetoothFirmware.kext and IntelBTPatcher.kext from here instead? Nope.. This kext version definitely does not work on my system. When adding -lilubetaall, my system stalls during boot or boots into a black screen.   

 

@carlo_67, btw.. I did not know that a very similar approach has been published on Github before for Sequoia. 🤨 

 

 

yes, only it doesn't work in tahoe, if you don't put oclp nightly and the kdk 25c56, that they create glitter in App store, and it doesn't serve any  the devices-id  and SSdt

and you don't need lilubetaall

config copia.plist.zip

[arsradu]

Just wanted to say thank you for this initiative. Installed on my system successfully (well, not without a fair share of small but annoying issues, reboots and machine not booting, all of them caused by me forgetting one thing or the other from the step by step in the first post).

But yeah, so far so good.

Audio and WiFi are working. Nothing else needs patching on my system in its current state. Until we have an "official" build, I'm ok using this. Works fine on my machine.

Thank you!

Edited December 20, 2025 by arsradu

[kgp]

Status update:

Hi everyone, just a quick note: the current HEAD of Izhoang2801’s GitHub repository for the experimental OCLP 3.0.0 Nightly fork is not working on my system (AppleHDA fails, and as a consequence, Modern Wi-Fi is not patched either).

The last working state was based on amfi=0x80, but it’s no longer available upstream. I only have a local copy.

Recommendation: New users should avoid using the current HEAD and stick with a known stable version or use OCLP-Mod 3.1.1 instead. For the latter, you can use the same EFI-Folder, only remove boot-arg "amfi=0x80", enable AMFIPass.kext 1.4.1 and add boot-arg "-amfipassbeta". 

I’ll post updates here as soon as our friend Izhoang2801 shares any news. Thanks for your patience! 👍

Edited December 27, 2025 by KGP-iMacPro

[Henties]

@KGP-iMacProSome feedback from my side:

 

Of 4 hacks, each multi booting into either Sequoia or Tahoe, OCLP generally does a great job, wow the developer(s) have churned out magic code indeed.

 

For patching the 4 Sequoia boot option(s) I use OCLP 2.4.1 on each of the 4 hacks, whereas for patching Tahoe I use OCLP 3.1.1 with  the exact same EFI folder I am using with Sequoia,  the only difference being the addition of -amfipassbeta as a boot arg. which can however be left in place even when booting into Sequoia, as it has no noticeable detrimental side effect on the Sequoia boot process.

 

The 4 Tahoe boot options are:

 

Tahoe on 1 x Skylake hack

Tahoe on 2 x Comet Lake hacks

Tahoe on 1 x Alder Lake hack

 

All are working the way they should except the Tahoe boot option of the Alder Lake hack, which reboots immediately with every run-up attempt as soon as the Tahoe OC menu boot option has been selected. 

 

This instant Tahoe reboot can be prevented on the Alder Lake hack by merely disabling the IOSkywalkFamily.kext with a MaxKernel value of 24.99.99, of cause root patching will then be inhibited.

 

An activated IOSkywalkFamily.kext has not detrimental effect on any of the hacks, not even on the Alder Lake platform, provided one is merely selecting to boot into Sequoia. 

 

Therefore the only combination where under the IOSkywalkFamily.kext is troublesome is when one tries to boot Tahoe on an Alder Lake based hack.

 

Booting into Sequoia, on the same Alder Lake hack with the same IOSkywalkFamily.kext, poses no problems whatsoever.

 

Go figure !!!

 

I have now exhausted all possible "tricks" known to me in order to get to the bottom of this problem but to no avail.

 

Would appreciate some assistance to finally solve this nagging problem.    

 

Greetings Henties

 

 

 

Edited December 28, 2025 by Henties