- Joined
- Apr 28, 2019
- Messages
- 18
Install Dell DW1820A (Broadcom BCM94350ZAE) Wireless AC/Bluetooth 4.1 PCIE In Mojave (Successfull) ***Almost STABLE Currently Testing New Methods***
Hey guys I just wanna let you know I tapped out and I won't be searching on this topic anymore I went another route. I bought an actual airport card the BCM94360CS card along with an NGFF a/e adapter and I installed it, everything works beautifully. It works immediately and loads AirPortBrcmNIC without any issues. I did a fresh install of Mojave with it and everything went perfectly it even detected it in the installer. I got both pieces off of amazon with same day delivery for 50 bucks and it was well worth it. I'm only saying it to let you guys know about an option that works exactly how it does on a real Mac. Best of luck with the card if you do continue to work on this!
Credit goes to Rehabman for his Broadcom bluetooth files which make up two of the kexts I've included for this to work.. The IO80211 kext is from macOS Yosemite so credit goes to Apple I guess. And whomever made the Kext Helper app I've included gets the credit for that one
OK I managed to get it running at damn near useable quality. I haven experienced a panic/restart that's been associated with this cards drivers in far longer than the normal amount of time it would usually happen in. I did a couple of things different this time.
First I'm still using the IO80211Family.kext from Yosemite (macOS 10.10) along with the AirPortBrcm4360.kext which can be found as a plugin inside of IO80211.
Second, I disabled all kext patches which are pointed at the AirPortBrcm4360 driver, including the Favco patch. I've instead opted for using AirPortBrcmFixup.kext (Installed in /L/E along with all of my other kext files) alone for the proper patches and fixes because of the fact that it was designed to do just that across multiple cards and kext files.
Next I got rid of IO80211FamilyV2.kext from /S/L/E along with BCMWLANFirmware4355_Datastore.kext, BCMWLANFirmware4355_Hashstore.kext, BCMWLANFirmware4364_Datastore.kext, and BCMWLANFirmware4364_Hashstore.kext which are also found in /S/L/E. I don't really have a reason for doing this, other than the fact that I had read up on issues that were directly related to the malfunctioning of Broadcom cards in official Mac hardware that is experiencing issues related to the systems ability to properly detect the temperature of internal components which it would normally be able to read. My Hackintosh does not have the proper thermal configuration for system temperature regulation outside of what's available and so I'm thinking that this Waitq panic may have something to do with the temperature readings as well.
Next I changed my SMBIOS identity from MacBook Pro 12,1 to MacBook Air 7,2. I also read a few posts about the real MacBook Pro 12,1 experiencing this same Invalid Waitq panic because of heating issues in a defective device which Apple actually swapped out for the individual who posted the information concerning the problem. Heads up there is in fact a whitelist for the MacOS Sierra 10.12 IO80211Family.kext with APBC4360 which designates MBP 4,1 MBP11,5 iMac 17,1 and a few other devices as authorized to load the Kext for pci14e4,43a3 and I also read online a few people using macOS Sierra with iMac 17,1 SMBIOS who were able to get the card running no problem. I attempted to mess around with these identities but had no luck getting the driver to load.
I mad a few other changes to my plist like dropping all OEM SSDTs which I was supposed to be doing in the first place and had never enabled the option. Whenever you choose static patching you have to drop the OEM SSDTs, if you decide to HotPatch and use Clover Configurator to patch your DSDT on the fly then you don't drop the OEM SSDTs. Make sure you have a good understanding of all aspects of the Configuration of clover based on whichever methods you're using because that also plays a big role in the overall functionality of things. For instance changing the dark wake option to darkwake=8 fixed my sleep/wake issues along with the shutdown issues I was having where the system would shutdown but the power light would remain on and require me to hold the button to power off the computer and this would result in the error message about restarting when the computer would first boot up.
I also dropped my video memory config from 512mb to 256mb from the setting in the Bios. One thing I've always been aware of was the affect the the card seemed to have on the systems ability to load the video drivers when the AirPortBrcmNIC kext is present within my system. This is the current designated kext for this device and it will not load the card when its present in the system, nor will the system properly load up. I can curb this behavior by messing with the IONAME using FakID in Clover along with DTGP and Airport hot patches or using SSDT/DSDT patches which do the same and change the cards identity to prevent the kext from loading. This has at the benefit of allowing the system to properly load up during fresh installs and first boot without the need to disable the wifi from the bios in order to remove AirportBrcmNIC.kext in order to allow the system to start up normal with the card active.
I also re-patched my DSDT (which was needed after changing video memory anyway) but this time I ensured that I knew exactly what I was doing and I applied the changes I wanted via patches which I found or created myself for the desired changes. I had a bad habit of making really sloppy edits to the DSDT which included the information of other areas which I would change out with whatever I was attempting to alter but I didn't understand the whole Buffer setup and I would leave those alone or default to (0xAA) when I would get an error, but then I read up on the proper way to do everything and I compiled all the edits into a single patch so that maciASL does all of the editing and I only load the patch to ensure that all changes are done the correct way and not the ghetto way I was doing them. This actually solved my batter issue which was driving me crazy. I would patch the battery but it would only work one way per restart. So if it started plugged in then it would only increase the battery level and then get stuck whenever I would disconnect and remain at the level I unplugged it at and vice versa, now its functioning properly both ways and that is literally because I fixed the buffers so I imagine its possible that it was affecting more than just the battery.
I also renamed all of the devices in my DSDT to match those devices that are found within genuine Mac hardware. I'm not sure if it makes much of a difference or if its purely cosmetic, but the GPUs power management requires the device name to be IGPU for proper functionality, same with HDEF for AppleALC audio functioning so I made sure all of the listed devices were named properly. This includes the PCI device that was used by the Airport card. It was originally Named EXP2 and had no extra PXSX node present for any of the Patches for Airport functionality to work. So I renamed all EXP devices to RP0 devices (RP02 in this case) then I added the PXSX device nodes to each of the RP0x device points and then renamed the PXSX for RP02 to ARPT which is how official AirPort card are designated in IOREG listings. I thin gave it the proper _DSM Method injections:
into method label _DSM parent_label ARPT remove_entry;
into device label ARPT parent_label RP02 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
Store (Package () {\n
"AAPL,slot-name", Buffer() { "Built In" },\n
"vendor-id", Buffer() { 0xE4, 0x14, 0x00, 0x00 },\n
"device-id", Buffer() { 0xA3, 0x43, 0x00, 0x00 },\n
"subsystem-id", Buffer() { 0x01, 0x31, 0x00, 0x00 },\n
"subsystem-vendor-id", Buffer() { 0x6b, 0x10, 0x00, 0x00 },\n
"vendor-id", Buffer() { 0xE4, 0x14, 0x00, 0x00 },\n
"name", Buffer() { "pci14e4,43a3" },\n
"model", Buffer() { "Apple Wifi Card" },\n
"device_type", Buffer() { "AirPort" },\n
"IOName", Buffer() { "pci14e4,43a3" },\n
"built-in", Buffer() { 0x00 },\n
}, Local0)\n
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
Return (Local0)\n
}\n
end;
I pulled all of that info off of an IOREG which contained the official Apple pci14e4,43a3 branded card present in Macbook8,1 and so I just replicated what was important and injected it in a maciASL patch (make sure your device name and nodes match or it won't change anything when you try and apply it)
And last I made a few changes with the Kexts I used. First I got rid of HibernationFixup.kext and disabled Hibernation all together using the command that Rehabman suggests along with the option in Clover configurator. And I got rid of FakeSMC.kext along with its plugins and the SMCHelper driver and instead I started using VirtualSMC along with its kexts (which I've been using for over a month now but I figured its worth mentioning in case it plays some role in the whole thing. And I also created a proper USB Configuration SSDT instead of using the USBINJECTALL.kext. I even made a kext injector to use in place of usbinjectall along with the properly configured SSDTs for usb port injecting. I also added CPUFriend.kext for dynamic CPU power management which I think may actually be a big part of what's changed with the stability of this card.
The last thing I did was apply the patch for the Invalid WaitQ panic which a member of one of the forums posted for this issue. I hadn't had success with it before but it could've been because I had issues in my system which I wasn't aware of. Thats the only patch that is active in clover as well, including kernel and kext patches because AirPortBrcmfixup.kext is handling the proper patches for the Airport device:
(KernelToPatch) Clover Configurator
Find: 488D3D04 F1720031 C04889DE
Replace: B8040000 00E9A700 00009090
Comment: disable panic("Invalid waitq: %p", waitq), 10.14
MatchOS: 10.14.x
This is absolutely everything I did and as of right now it's been perfect the entire time (except for one panic the very first time the drive loaded after adding IO80211Family.kext) which I did in the middle of everything and had made more changes to the system following that. But that's the only time its done that and Ive restarted and switched wifi networks along with using the device for a long period of time and haven't experienced any panics at all which I would've usually had at least 4 or 5 by now. Maybe the issue is just a confiiguration problem
I'm attaching a new set of files and a script to help automate a good amount of what I've changed, I'm also including the maciASL patch I compiled for my device however its basically universal as it only contains the generic fixes, device renames and a few other modifications such as the addition of BAT C (I have dual battery device and it has to be patched and then combined into a new separate Battery in the system which is BATC in order for the battery to function properly) Make sure If you decide to try it out that you first check through the contents and void out any entries that are specific to my device (BATC, Battery Patch, DSM Injections, BLTH Device, FNPR Device, Function Keys, PNLF Graphics, HDEF Audio, PEG to PEG0, PEG.VID to PEG.IGFX, PCI0.VID to PCI0.IGPU, Intel Series 9 Fixes) That should be all but its your responsibility to make sure! My device is a Lenovo ThinkPad T450 but this patch should be ok to use on most Broadwell based Lenovo devices such as Gen 3 X1 Carbon, as well as the T450s without the need to really void out anything). Run the script I've included and it will do most of the heavy lifting and then match the settings in the config.plist with your own (mainly the kexttopatch and kerneltopatch area along with the ACPI settings). And make sure you try and replicate as much of what's described above as possible and this should be good enough to get the device to function properly in Mojave. I haven't tested it with any other macOS versions except Yosemite which it functions OOB without any need to mess with settings. Its functioning from the Yosemite installer as well and without any panics during the time I used it.
View attachment
View attachment
View attachment
Hey guys I just wanna let you know I tapped out and I won't be searching on this topic anymore I went another route. I bought an actual airport card the BCM94360CS card along with an NGFF a/e adapter and I installed it, everything works beautifully. It works immediately and loads AirPortBrcmNIC without any issues. I did a fresh install of Mojave with it and everything went perfectly it even detected it in the installer. I got both pieces off of amazon with same day delivery for 50 bucks and it was well worth it. I'm only saying it to let you guys know about an option that works exactly how it does on a real Mac. Best of luck with the card if you do continue to work on this!
Credit goes to Rehabman for his Broadcom bluetooth files which make up two of the kexts I've included for this to work.. The IO80211 kext is from macOS Yosemite so credit goes to Apple I guess. And whomever made the Kext Helper app I've included gets the credit for that one
OK I managed to get it running at damn near useable quality. I haven experienced a panic/restart that's been associated with this cards drivers in far longer than the normal amount of time it would usually happen in. I did a couple of things different this time.
First I'm still using the IO80211Family.kext from Yosemite (macOS 10.10) along with the AirPortBrcm4360.kext which can be found as a plugin inside of IO80211.
Second, I disabled all kext patches which are pointed at the AirPortBrcm4360 driver, including the Favco patch. I've instead opted for using AirPortBrcmFixup.kext (Installed in /L/E along with all of my other kext files) alone for the proper patches and fixes because of the fact that it was designed to do just that across multiple cards and kext files.
Next I got rid of IO80211FamilyV2.kext from /S/L/E along with BCMWLANFirmware4355_Datastore.kext, BCMWLANFirmware4355_Hashstore.kext, BCMWLANFirmware4364_Datastore.kext, and BCMWLANFirmware4364_Hashstore.kext which are also found in /S/L/E. I don't really have a reason for doing this, other than the fact that I had read up on issues that were directly related to the malfunctioning of Broadcom cards in official Mac hardware that is experiencing issues related to the systems ability to properly detect the temperature of internal components which it would normally be able to read. My Hackintosh does not have the proper thermal configuration for system temperature regulation outside of what's available and so I'm thinking that this Waitq panic may have something to do with the temperature readings as well.
Next I changed my SMBIOS identity from MacBook Pro 12,1 to MacBook Air 7,2. I also read a few posts about the real MacBook Pro 12,1 experiencing this same Invalid Waitq panic because of heating issues in a defective device which Apple actually swapped out for the individual who posted the information concerning the problem. Heads up there is in fact a whitelist for the MacOS Sierra 10.12 IO80211Family.kext with APBC4360 which designates MBP 4,1 MBP11,5 iMac 17,1 and a few other devices as authorized to load the Kext for pci14e4,43a3 and I also read online a few people using macOS Sierra with iMac 17,1 SMBIOS who were able to get the card running no problem. I attempted to mess around with these identities but had no luck getting the driver to load.
I mad a few other changes to my plist like dropping all OEM SSDTs which I was supposed to be doing in the first place and had never enabled the option. Whenever you choose static patching you have to drop the OEM SSDTs, if you decide to HotPatch and use Clover Configurator to patch your DSDT on the fly then you don't drop the OEM SSDTs. Make sure you have a good understanding of all aspects of the Configuration of clover based on whichever methods you're using because that also plays a big role in the overall functionality of things. For instance changing the dark wake option to darkwake=8 fixed my sleep/wake issues along with the shutdown issues I was having where the system would shutdown but the power light would remain on and require me to hold the button to power off the computer and this would result in the error message about restarting when the computer would first boot up.
I also dropped my video memory config from 512mb to 256mb from the setting in the Bios. One thing I've always been aware of was the affect the the card seemed to have on the systems ability to load the video drivers when the AirPortBrcmNIC kext is present within my system. This is the current designated kext for this device and it will not load the card when its present in the system, nor will the system properly load up. I can curb this behavior by messing with the IONAME using FakID in Clover along with DTGP and Airport hot patches or using SSDT/DSDT patches which do the same and change the cards identity to prevent the kext from loading. This has at the benefit of allowing the system to properly load up during fresh installs and first boot without the need to disable the wifi from the bios in order to remove AirportBrcmNIC.kext in order to allow the system to start up normal with the card active.
I also re-patched my DSDT (which was needed after changing video memory anyway) but this time I ensured that I knew exactly what I was doing and I applied the changes I wanted via patches which I found or created myself for the desired changes. I had a bad habit of making really sloppy edits to the DSDT which included the information of other areas which I would change out with whatever I was attempting to alter but I didn't understand the whole Buffer setup and I would leave those alone or default to (0xAA) when I would get an error, but then I read up on the proper way to do everything and I compiled all the edits into a single patch so that maciASL does all of the editing and I only load the patch to ensure that all changes are done the correct way and not the ghetto way I was doing them. This actually solved my batter issue which was driving me crazy. I would patch the battery but it would only work one way per restart. So if it started plugged in then it would only increase the battery level and then get stuck whenever I would disconnect and remain at the level I unplugged it at and vice versa, now its functioning properly both ways and that is literally because I fixed the buffers so I imagine its possible that it was affecting more than just the battery.
I also renamed all of the devices in my DSDT to match those devices that are found within genuine Mac hardware. I'm not sure if it makes much of a difference or if its purely cosmetic, but the GPUs power management requires the device name to be IGPU for proper functionality, same with HDEF for AppleALC audio functioning so I made sure all of the listed devices were named properly. This includes the PCI device that was used by the Airport card. It was originally Named EXP2 and had no extra PXSX node present for any of the Patches for Airport functionality to work. So I renamed all EXP devices to RP0 devices (RP02 in this case) then I added the PXSX device nodes to each of the RP0x device points and then renamed the PXSX for RP02 to ARPT which is how official AirPort card are designated in IOREG listings. I thin gave it the proper _DSM Method injections:
into method label _DSM parent_label ARPT remove_entry;
into device label ARPT parent_label RP02 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
Store (Package () {\n
"AAPL,slot-name", Buffer() { "Built In" },\n
"vendor-id", Buffer() { 0xE4, 0x14, 0x00, 0x00 },\n
"device-id", Buffer() { 0xA3, 0x43, 0x00, 0x00 },\n
"subsystem-id", Buffer() { 0x01, 0x31, 0x00, 0x00 },\n
"subsystem-vendor-id", Buffer() { 0x6b, 0x10, 0x00, 0x00 },\n
"vendor-id", Buffer() { 0xE4, 0x14, 0x00, 0x00 },\n
"name", Buffer() { "pci14e4,43a3" },\n
"model", Buffer() { "Apple Wifi Card" },\n
"device_type", Buffer() { "AirPort" },\n
"IOName", Buffer() { "pci14e4,43a3" },\n
"built-in", Buffer() { 0x00 },\n
}, Local0)\n
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
Return (Local0)\n
}\n
end;
I pulled all of that info off of an IOREG which contained the official Apple pci14e4,43a3 branded card present in Macbook8,1 and so I just replicated what was important and injected it in a maciASL patch (make sure your device name and nodes match or it won't change anything when you try and apply it)
And last I made a few changes with the Kexts I used. First I got rid of HibernationFixup.kext and disabled Hibernation all together using the command that Rehabman suggests along with the option in Clover configurator. And I got rid of FakeSMC.kext along with its plugins and the SMCHelper driver and instead I started using VirtualSMC along with its kexts (which I've been using for over a month now but I figured its worth mentioning in case it plays some role in the whole thing. And I also created a proper USB Configuration SSDT instead of using the USBINJECTALL.kext. I even made a kext injector to use in place of usbinjectall along with the properly configured SSDTs for usb port injecting. I also added CPUFriend.kext for dynamic CPU power management which I think may actually be a big part of what's changed with the stability of this card.
The last thing I did was apply the patch for the Invalid WaitQ panic which a member of one of the forums posted for this issue. I hadn't had success with it before but it could've been because I had issues in my system which I wasn't aware of. Thats the only patch that is active in clover as well, including kernel and kext patches because AirPortBrcmfixup.kext is handling the proper patches for the Airport device:
(KernelToPatch) Clover Configurator
Find: 488D3D04 F1720031 C04889DE
Replace: B8040000 00E9A700 00009090
Comment: disable panic("Invalid waitq: %p", waitq), 10.14
MatchOS: 10.14.x
This is absolutely everything I did and as of right now it's been perfect the entire time (except for one panic the very first time the drive loaded after adding IO80211Family.kext) which I did in the middle of everything and had made more changes to the system following that. But that's the only time its done that and Ive restarted and switched wifi networks along with using the device for a long period of time and haven't experienced any panics at all which I would've usually had at least 4 or 5 by now. Maybe the issue is just a confiiguration problem
I'm attaching a new set of files and a script to help automate a good amount of what I've changed, I'm also including the maciASL patch I compiled for my device however its basically universal as it only contains the generic fixes, device renames and a few other modifications such as the addition of BAT C (I have dual battery device and it has to be patched and then combined into a new separate Battery in the system which is BATC in order for the battery to function properly) Make sure If you decide to try it out that you first check through the contents and void out any entries that are specific to my device (BATC, Battery Patch, DSM Injections, BLTH Device, FNPR Device, Function Keys, PNLF Graphics, HDEF Audio, PEG to PEG0, PEG.VID to PEG.IGFX, PCI0.VID to PCI0.IGPU, Intel Series 9 Fixes) That should be all but its your responsibility to make sure! My device is a Lenovo ThinkPad T450 but this patch should be ok to use on most Broadwell based Lenovo devices such as Gen 3 X1 Carbon, as well as the T450s without the need to really void out anything). Run the script I've included and it will do most of the heavy lifting and then match the settings in the config.plist with your own (mainly the kexttopatch and kerneltopatch area along with the ACPI settings). And make sure you try and replicate as much of what's described above as possible and this should be good enough to get the device to function properly in Mojave. I haven't tested it with any other macOS versions except Yosemite which it functions OOB without any need to mess with settings. Its functioning from the Yosemite installer as well and without any panics during the time I used it.
View attachment
View attachment
View attachment
Last edited by a moderator:
