Coldsteak Posted October 31, 2019 Share Posted October 31, 2019 2 hours ago, Coldsteak said: OH I completely forgot about my specs, my bad. So I'm on a laptop, Asus Vivobook (F510UA) CPU: Core i5 8th gen GPU: Intel UHD Graphics 620 Wireless: DW1560/BCM20702A0 Motherboard: N/A because it's a laptop, ASUS BIOS I didn't upload my EFI folder initially because it's too big to upload here, I put it on my cloud storage: https://1drv.ms/u/s!Asm7qfyxvd1LgeIU681JYtSgRzjLyQ And I just want to reiterate from my reddit post, when this started to happen I have made no hardware or software changes. Just got a kernel panic one day and then it started happening. Found the problem, it was ACPIBatteryManager.kext Not sure how a battery related extension could cause such a thing, but I'm kind of a hackintosh newbie so what do I know? Thanks for your advice about trying to use the bare minimum kexts @fallen00sniper! Link to comment Share on other sites More sharing options...
fallen00sniper Posted November 1, 2019 Author Share Posted November 1, 2019 Glad that helped, if you get stuck while thinning how many kexts you are using, feel free to pm me. Link to comment Share on other sites More sharing options...
brshooterz Posted November 9, 2019 Share Posted November 9, 2019 Hello, i bought a DW1830, and it came with pc id: 14e4:aa52, and i cant find a way to make it work on Mojave 10.14.6, i know that DW1830 should work OOB, i dont know whats wrong the wifi works fine on linux, i didnt tried on windows can someone help me? Link to comment Share on other sites More sharing options...
SavageAUS Posted January 30, 2020 Share Posted January 30, 2020 Is it normal for versions to be null? CLOVER.zip Link to comment Share on other sites More sharing options...
darthsian Posted January 30, 2020 Share Posted January 30, 2020 (edited) After Mojave's last "Security Update 2020-001" macOS won't boot because AirportBrcmFixup error. Anyone have same problem? Edit: Its with DW1820A BCM94350ZAE card. Edited January 30, 2020 by darthsian Link to comment Share on other sites More sharing options...
MacKonsti Posted July 4, 2020 Share Posted July 4, 2020 (edited) Hello everyone, I am hoping to reach a developer of AirportBrcmFixup as I would like to report and confirm an issue facing with a BCM4350 card (supposedly DW1820A). I didn't pay attention to the part number when ordering from a well-known Asian website, and eventually I received the version T77H649.00 variant for my Lenovo. The card is not detected out-of-the-box in Catalina (in AirPortBrcmNIC I think) and it prevents booting the system without tweaking. Now, when booting with the card enabled (in BIOS) and vanilla AirportBrcmFixup.kext in Clover (kexts/Other folder) the system at some points stops loading, just like that. The only way to manage to reach the Catalina 10.15.5 desktop is to inject some device properties in Clover, namely: <key>PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>WLAN</string> <key>compatible</key> <string>pci14e4,4353</string> <key>device_type</key> <string>AirPort Extreme</string> <key>name</key> <string>AirPort</string> <key>pci-aspm-default</key> <integer>0</integer> <key>model</key> <string>Broadcom BCM4350 Wireless Network Adapter</string> </dict> Any other "compatible" ID such as 14e4:4331 will result to a KP during boot or just freezing. Is it normal to need to inject such device properties for my card, so that AirportBrcmFixup can work? Anyone else having such a BCM4350 / DW1820A that absolutely needs properties like that? The card works well, I am just puzzled that we need to fake to make a third-party kext work My card details are PCI ID 14e4:43a3 and subsystem ID 106b:075a not sure why not 17aa:075a per other threads found :/ Can anyone let me know if we can add these details to the code of AirportBrcmFixup so that some next official release would work with just the vanilla AirportBrcmFixup.kext? Thank you in advance @vit9696 @lvs1974 Edited July 5, 2020 by MacKonsti Link to comment Share on other sites More sharing options...
fallen00sniper Posted July 4, 2020 Author Share Posted July 4, 2020 (edited) 6 minutes ago, MacKonsti said: Hello everyone, I am hoping to reach a developer of AirportBrcmFixup as I would like to report and confirm an issue facing with a BCM4350 card (supposedly DW1820A). I didn't pay attention to the part number when ordering from a well-known Asian website, and eventually I received the version T77H649.00 variant for my Lenovo. The card is not detected out-of-the-box in Catalina (in AirPortBrcmNIC I think) Thank you in advance @vit9696 @lvs1974 Lenovo bios usually have a whitelist for hardware, is the card detected in bios and by another os? i had to get my bios modded to use a Broadcom card on my yoga s1. I would think since the hardware id is the same it should work if the bios is allowing it. I’ll find the guys email if you need it, but it’s a little bit of a process to flash the modded bios. Edited July 4, 2020 by fallen00sniper Link to comment Share on other sites More sharing options...
MacKonsti Posted July 4, 2020 Share Posted July 4, 2020 (edited) 57 minutes ago, fallen00sniper said: Lenovo bios usually have a whitelist for hardware, is the card detected in bios and by another os? Thanks for your reply. Yes I read some stuff about "whitelisting" on Lenovos... not sure what is really happening under the hood, however. My BCM4350 card T77H649.00 variant is supposed to be for Lenovo (shows P/N 00JT494) according to @Hervé post over at OSX Latitude and yes: The BIOS still has an option to enable/disable the card, after replacing it (but I doubt it would get hidden if the card was blacklisted somehow?) but it does control the hardware (confirmed it); Another disk running Windows 10 has the card working fine; Catalina with Clover device properties injection above + AirportBrcmFixup.kext works great (including BTLE via other kexts of course). It's just my surprise that this card blocks booting (in vanilla) and that I need Clover to inject a compatible device for AirportBrcmFixup.kext to work instead having AirportBrcmFixup.kext do this automatically... What we need @fallen00sniper is to find the Lenovo hidden BIOS settings and how to enable them that may possibly provide some further understanding/unlocking but I have not found them for IdeaPad... only for some others Edited July 4, 2020 by MacKonsti Link to comment Share on other sites More sharing options...
lvs1974 Posted July 5, 2020 Share Posted July 5, 2020 (edited) 11 hours ago, MacKonsti said: Hello everyone, I am hoping to reach a developer of AirportBrcmFixup as I would like to report and confirm an issue facing with a BCM4350 card (supposedly DW1820A). I didn't pay attention to the part number when ordering from a well-known Asian website, and eventually I received the version T77H649.00 variant for my Lenovo. The card is not detected out-of-the-box in Catalina (in AirPortBrcmNIC I think) and it prevents booting the system without tweaking. Now, when booting with the card enabled (in BIOS) and vanilla AirportBrcmFixup.kext in Clover (kexts/Other folder) the system at some points stops loading, just like that. The only way to manage to reach the Catalina 10.15.5 desktop is to inject some device properties in Clover, namely: <key>PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>WLAN</string> <key>compatible</key> <string>pci14e4,4353</string> <key>device_type</key> <string>AirPort Extreme</string> <key>name</key> <string>AirPort</string> <key>pci-aspm-default</key> <integer>0</integer> <key>model</key> <string>Broadcom BCM4350 Wireless Network Adapter</string> </dict> Any other "compatible" ID such as 14e4:4331 will result to a KP during boot or just freezing. Is it normal to need to inject such device properties for my card, so that AirportBrcmFixup can work? Anyone else having such a BCM4350 / DW1820A that absolutely needs properties like that? The card works well, I am just puzzled that we need to fake to make a third-party kext work My card details are PCI ID 14e4:43a3 and subsystem ID 106b:075a not sure why not 17aa:075a per other threads found :/ Can anyone let me know if we can add these details to the code of AirportBrcmFixup so that some next official release would work with just the vanilla AirportBrcmFixup.kext? Thank you in advance @vit9696 @lvs1974 It has been down in the latest commit, you can also test it with attached debug kext. AirportBrcmFixup-2.0.8-DEBUG.zip It was a bit harder than just setting pci-aspm-default to 0, since it is too late and PCI bus is already initialised by this moment (AirportBrcmFixup start) with non-zero ASPM. So, I had to call pciDevice->setASPMState(provider, 0) explicitly. Edited July 5, 2020 by lvs1974 1 Link to comment Share on other sites More sharing options...
MacKonsti Posted July 5, 2020 Share Posted July 5, 2020 2 hours ago, Hervé said: @MacKonsti, you're kind of re-inventing the wheel here... To clarify the matter: BCM4350-based Foxconn T77H649.00 is indeed a card Lenovo used for their FRU part# 00JT494. If yours is that Lenovo piece of hardware, you should see the part# on the label. A card being a Lenovo part does not necessarily mean it's included in the whitelist of any given particular Lenovo laptop model. If your laptop had a BIOS whitelist that did not support the card you use, you'd never be able to get past BIOS POST. Clearly it's not the case so any questioning or discussion about whitelist is irrelevant here. Yes, those properties injection are mandatory as explained at great length in my guide. If you do not use them, especially the ASPM-related one, you will experience issues such as those you listed. Your subsystem id gets changed from 17aa:075a to 106b:075a after the Broadcom kext has loaded. You probably did not realize that vendor ids 17aa=Lenovo and 106b=Apple. I'll let you conduct your own research on PCI vendor id/device id, subsystem id and the values used by actual manufacturers and/or OEM suppliers. Nothing else really, you found the guide and, as long as you follow it (as you appear to have done with success), you'll be able to use your BCM4350 card. There is no other workaround at the present time as far as I know. If you don't inject the required properties, you'll experience the issues you encountered and that were very clearly stated in my BCM4350 guide. It's all there, there's nothing new to report or discover here. The issues you've listed and the questions you raised are already described and answered in details in my guide if you read it properly and with all due attention... Salut @Hervé and thank you again in person for your guide. I am not trying to re-invent the wheel, I was merely asking why faking a device compatibility to be used by a third-party kext where we have (as community) control Yes that T77H649.00 variant card of mine does show P/N 00JT494 but as you know, many vendors fake the items and put fake stickers... so we can never be sure. But what you wrote is indeed very helpful that I did not find in your guide: "If your laptop had a BIOS whitelist that did not support the card you use, you'd never be able to get past BIOS POST. Clearly it's not the case so any questioning or discussion about whitelist is irrelevant here." I didn't know about betting beyond the BIOS POST, thanks (and of course no whitelist talk was initiated, I was merely referring to BIOS hacks that allow other Lenovos to access hidden settings). So to cut a long story short, as you saw my Clover device properties injection, I am indeed using your guide and after few reboots, I did confirm that these work great.. And thanks for confirming that the "subsystem id gets changed from 17aa:075a to 106b:075a after the Broadcom kext has loaded. You probably did not realize that vendor ids 17aa=Lenovo and 106b=Apple" as I had noted it down but was curious as to why that changed when checking again in IORegistry Explorer before making my post. Very useful info, merci. 13 minutes ago, lvs1974 said: It has been down in the latest commit, you can also test it with attached debug kext. It was a bit harder than just setting pci-aspm-default to 0, since it is too late and PCI bus is already initialised by this moment (AirportBrcmFixup start) with non-zero ASPM.So, I had to call pciDevice->setASPMState(provider, 0) explicitly. Hi @lvs1974 thanks for posting this good news update. Is your commit referring to only pci-aspm-default only or also includes the above card details i.e. PCI ID 14e4:43a3 and subsystem ID 17aa:075a too? Link to comment Share on other sites More sharing options...
lvs1974 Posted July 5, 2020 Share Posted July 5, 2020 @MacKonsti: if (vendorID == 0x14e4 && deviceID == 0x43a3 && subSystemVendorID != 0x106b) 1 Link to comment Share on other sites More sharing options...
MacKonsti Posted July 5, 2020 Share Posted July 5, 2020 (edited) 1 hour ago, lvs1974 said: @MacKonsti: if (vendorID == 0x14e4 && deviceID == 0x43a3 && subSystemVendorID != 0x106b) Thank you VERY much for your work on a Sunday morning, it works straight away with and without my Clover injection! First, I replaced the kext in Clover/Other and booted, while keeping the existing device-properties injected; booted OK sans KP. Then, I removed the device-properties completely, and booted again without issues. Works great for PCI ID 14e4:43a3 and subsystem ID 17aa:075a as ASPM is shown disabled in Hackintool, I also see pci-aspm-default set to 0 in IORegistryExplorer. I will keep testing the beta kext for stability checking. Currently, CPU idle utilisation seems as low as before. I hope this code-fix will make it to the official release! Here is my kernel output since boot time and attaching a screenshot of IORegistry Explorer for renamed device ARPT. Merci, thank you, gracias, Danke, graze, Спасибо, ευχαριστώ. Spoiler BCM4350.log Edited July 5, 2020 by MacKonsti 1 Link to comment Share on other sites More sharing options...
Pavo Posted July 5, 2020 Share Posted July 5, 2020 Just wanted to report a small issue on latest AirportBrcmFixup build when using kernel collection boot method. The kext loads but does not enable wifi, using the same kext and booting with prelinkedkernel method works. Here is a debug log from latest commits from Lilu and AirportBrcmFixup builds. Lilu_1.4.6_20.0.txt Link to comment Share on other sites More sharing options...
SavageAUS Posted July 14, 2020 Share Posted July 14, 2020 (edited) I notice in the new AirportBrcmFixup.kext we have 2 plugins, AirPrtBrcm4360 & AirPrtBrcmNic. Using propertree to snapshot my OC folder these plugins were not "injected" into my config.plist. Do these plugins need to be specified in the config.plist for them to load? I just did the same snapshot in Big Sur and it seems to have added the correct items in my config.plist BUT no wifi. I am using a DW1820A Solved by changing device id Spoiler Spoiler Edited July 14, 2020 by SavageAUS Link to comment Share on other sites More sharing options...
headkaze Posted July 27, 2020 Share Posted July 27, 2020 On 11/4/2018 at 3:32 AM, lvs1974 said: On the screenshot you will find the working example how to fake id to 43ba (my original is 43b1). For some reason when I moved to OpenCore my Brcm 43b1 WiFi stopped working (even with AirportBrcmFixup.kext). Faking 43ba appeared to work for me too. ie. <key>DeviceProperties</key> <dict> <key>Add</key> <dict> <key>PciRoot(0x0)/Pci(0x1C,0x0)/Pci(0x0,0x0)</key> <dict> <key>device-id</key> <data>ukMAAA==</data> <key>name</key> <string>pci14e4,43ba</string> <key>compatible</key> <string>pci14e4,43ba</string> </dict> </dict> </dict> Link to comment Share on other sites More sharing options...
FredWst Posted July 27, 2020 Share Posted July 27, 2020 (edited) 1 hour ago, headkaze said: For some reason when I moved to OpenCore my Brcm 43b1 WiFi stopped working (even with AirportBrcmFixup.kext). Faking 43ba appeared to work for me too. ie. <key>DeviceProperties</key> <dict> <key>Add</key> <dict> <key>PciRoot(0x0)/Pci(0x1C,0x0)/Pci(0x0,0x0)</key> <dict> <key>device-id</key> <data>ukMAAA==</data> <key>name</key> <string>pci14e4,43ba</string> <key>compatible</key> <string>pci14e4,43ba</string> </dict> </dict> </dict> "my Brcm 43b1" I've same id wifi board. You need to inject one injector provide with AirportBrcmFixup.kext in my case with Catalina AirportBrcmFixup.kext/Contents/Plugins/AirPortBrcm4360_Injector.kext. With BS AirPortBrcmNIC_Injector.kext Fred Edited July 27, 2020 by FredWst Link to comment Share on other sites More sharing options...
lvs1974 Posted July 27, 2020 Share Posted July 27, 2020 @headkaze: 43ba is officially is unsupported in AirPortBrcm4360 or AirPortBrcmNIC, so it makes sense to use device-id of some supported device. Link to comment Share on other sites More sharing options...
pkdesign Posted August 4, 2020 Share Posted August 4, 2020 v2.0.8 breaks my wireless. If I go back to 2.0.7 it works. I have a BCM4352 in a Fenvi FV 101 PCIe adapter. Not sure what i need to do (other than roll back to 2.0.7) Link to comment Share on other sites More sharing options...
MacKonsti Posted August 5, 2020 Share Posted August 5, 2020 (edited) Hi mate @pkdesign please for our information can you share more complete details like IDs vendor/model etc.? Thanks. Edited August 5, 2020 by MacKonsti Link to comment Share on other sites More sharing options...
pkdesign Posted August 5, 2020 Share Posted August 5, 2020 (edited) 0x14e4 Vendor 0x43B1 Device 0x106b Sub Vendor 0x2154 Sub Device Broadcom BCM4352 PciRoot(0x0)/Pci(0x1C,0x7)/Pci(0x0,0x0) IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP08@1C,7/IOPP/ARPT@0 Config Entry: Spoiler <dict> <key>BundlePath</key> <string>AirportBrcmFixup.kext</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/AirportBrcmFixup</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> <dict> <key>BundlePath</key> <string>BrcmFirmwareData.kext</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/BrcmFirmwareData</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> <dict> <key>BundlePath</key> <string>BrcmPatchRAM3.kext</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/BrcmPatchRAM3</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> <dict> <key>BundlePath</key> <string>BrcmBluetoothInjector.kext</string> <key>Enabled</key> <true/> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string></string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> Devices Entry: Spoiler <key>PciRoot(0x0)/Pci(0x1c,0x7)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>Slot 4</string> <key>device_type</key> <string>Network controller</string> <key>model</key> <string>BCM4352 802.11ac Wireless Network Adapter</string> </dict> Edited August 5, 2020 by pkdesign Link to comment Share on other sites More sharing options...
tmbt Posted August 6, 2020 Share Posted August 6, 2020 (edited) 23 hours ago, pkdesign said: 0x14e4 Vendor 0x43B1 Device 0x106b Sub Vendor 0x2154 Sub Device Broadcom BCM4352 PciRoot(0x0)/Pci(0x1C,0x7)/Pci(0x0,0x0) IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP08@1C,7/IOPP/ARPT@0 Config Entry: Hide contents <dict> <key>BundlePath</key> <string>AirportBrcmFixup.kext</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/AirportBrcmFixup</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> <dict> <key>BundlePath</key> <string>BrcmFirmwareData.kext</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/BrcmFirmwareData</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> <dict> <key>BundlePath</key> <string>BrcmPatchRAM3.kext</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/BrcmPatchRAM3</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> <dict> <key>BundlePath</key> <string>BrcmBluetoothInjector.kext</string> <key>Enabled</key> <true/> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string></string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict> Devices Entry: Hide contents <key>PciRoot(0x0)/Pci(0x1c,0x7)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>Slot 4</string> <key>device_type</key> <string>Network controller</string> <key>model</key> <string>BCM4352 802.11ac Wireless Network Adapter</string> </dict> Hello, i tried 2.0.8 and broken wifi for me too with a very similar card : 0x14e4 Vendor 0x43B1 Device 0x17aa Sub Vendor 0x0623 Sub Device Broadcom BCM4352 PciRoot(0x0)/Pci(0x1D,0x0)/Pci(0x0,0x0) IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP09@1D/IOPP/PXSX@0 Switching back to 2.0.7 solved the problem ... Thanks Mattia EDIT : If you follow Headkaze solution your card will work using the new kext 2.0.8. You've to fake 0x43BA Device instead of the one we have as suggested few posts before. Edited August 6, 2020 by tmbt Fixed Link to comment Share on other sites More sharing options...
pkdesign Posted August 6, 2020 Share Posted August 6, 2020 (edited) Didn’t quite know what I was doing but @tmbt and @headkaze are right. I added headkaze's keys to my device properties for my card and it works. This is what I have in mine: <key>PciRoot(0x0)/Pci(0x1c,0x7)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>Slot 4</string> <key>compatible</key> <string>pci14e4,43ba</string> <key>device-id</key> <data> ukMAAA== </data> <key>device_type</key> <string>Network controller</string> <key>model</key> <string>BCM4352 802.11ac Wireless Network Adapter</string> </dict> It now shows up as "BCM43602 802.11ac Wireless LAN SoC" in Hackintool. I'm guessing that the <model> key isn’t making a difference. I might delete it and see what it does. Although in System Profiler it does indeed show up as "BCM4352 802.11ac Wireless Network Adapter" so I guess that is where that key is showing up. Purely cosmetic, I know. EDIT 11/04/20 I made a light adjustment to the device-id and compatible keys. This now shows up as "BCM4350 802.11ac Wireless Network Adapter" in Hackintool. I know it’s a small adjustment but it better reflects the actual card I have. <key>AAPL,slot-name</key> <string>Slot 4</string> <key>compatible</key> <string>pci14e4,43a3</string> <key>device-id</key> <data> o0MAAA== </data> <key>device_type</key> <string>Network controller</string> <key>model</key> <string>BCM4352 802.11ac Wireless Network Adapter</string> Edited November 4, 2020 by pkdesign Revision 1 Link to comment Share on other sites More sharing options...
Tiem Posted August 7, 2020 Share Posted August 7, 2020 5 hours ago, pkdesign said: Didn’t quite know what I was doing but @tmbt and @headkaze are right. I added headkaze's keys to my device properties for my card and it works. This is what I have in mine: <key>PciRoot(0x0)/Pci(0x1c,0x7)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>Slot 4</string> <key>compatible</key> <string>pci14e4,43ba</string> <key>device-id</key> <data> ukMAAA== </data> <key>device_type</key> <string>Network controller</string> <key>model</key> <string>BCM4352 802.11ac Wireless Network Adapter</string> </dict> It now shows up as "BCM43602 802.11ac Wireless LAN SoC" in Hackintool. I'm guessing that the <model> key isn’t making a difference. I might delete it and see what it does. Although in System Profiler it does indeed show up as "BCM4352 802.11ac Wireless Network Adapter" so I guess that is where that key is showing up. Purely cosmetic, I know. Still not quite right: <key>PciRoot(0x0)/Pci(0x1C,0x7)/Pci(0x0,0x0)</key> <dict> <key>AAPL,slot-name</key> <string>Builtin</string> <key>device_type</key> <string>Network controller</string> <key>model</key> <string>BCM43602 802.11ac Wireless Connection</string> </dict> All PCI devices that aren't the GPU should inherit Builtin string. Model is indeed respected. Link to comment Share on other sites More sharing options...
LockDown Posted October 28, 2020 Share Posted October 28, 2020 Hi @Hervé In your own opinion, with the latest AirportBrcmfixup v2.1.0, do you still recommend to use properties injection instead of the said kext, specifically on Mojave & Catalina? Link to comment Share on other sites More sharing options...
maxb2000 Posted November 13, 2020 Share Posted November 13, 2020 On 10/28/2020 at 3:46 PM, Hervé said: I've no recommendation to make on the matter. As I've said before, I do not use AirportBrcmFixup kext on my hacks fitted with DW1820A cards because it impacts performance so I stick to properties injection. One less add-on kext to load/cache/inject also gets my own personal preference... Make your own experiments and choices. What patches or injection did you make ? I have the same model but the 5 GHz band doesn’t work at all. Link to comment Share on other sites More sharing options...
Recommended Posts