Administrators Hervé Posted February 10, 2019 Administrators Share Posted February 10, 2019 Last update: 6th Jan 2020 Questions around this Broadcom BCM4350 chipset (in particular the Dell DW1820A) have resurfaced again so I digged into the matter since most people reported it did not work. Outside the model fitted to Apple MacBooks (subsystem id 106b:0131, rev. 05), Wikidevi lists a few cards cards for this chipset, including: Dell DW1820A (several models with different part numbers) Foxconn T77H649.00 (Lenovo part number 00JT494) Lite-on WCBN808B (Lenovo part number 00JT493) All those cards carry PCI id 14e4:43a3 and normally offer high speed 802.11ac wireless + Bluetooth 4.1 services. Broadcom BCM4350 chipset is supported since Yosemite 10.10 and its hardware id is listed in the Info.plist file of IO80211Family's PlugIn kext AirPortBrcm4360 up to macOS Sierra 10.12, then AirPortBrcmNIC since macOS High Sierra 10.13: <key>Broadcom 802.11 PCI</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AirPort.BrcmNIC</string> <key>IOClass</key> <string>AirPort_BrcmNIC</string> <key>IOMatchCategory</key> <string>IODefaultMatchCategory</string> <key>IONameMatch</key> <array> <string>pci14e4,43ba</string> <string>pci14e4,43a3</string> <string>pci14e4,43a0</string> </array> <key>IOProbeScore</key> <integer>1241</integer> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>TruePowerOff</key> <true/> </dict> - - - - - - - - - - Edit: 06 Jan 2020 Removed the warning about DW1820/BCM4350 cards following tests confirming that disabling ASPM does fix the stability issues previously encountered by most users. 2 3 Link to comment Share on other sites More sharing options...
Administrators Hervé Posted April 8, 2019 Author Administrators Share Posted April 8, 2019 Last update: 28th Jan 2020 Dell DW1820A: Ok Ok Ok DW1820A is a pretty good combo card providing 2.4/5GHz 802.11ac wireless at 867Mbps + Bluetooth 4.1. As stated at Wikidevi, there appears to be a few different models of the card. Whilst they all carry the same Broadcom id 14e4:43a3, they each carry a different subsystem id/part #: 1028:0021 (part # CN-0VW3T3) -> 100% Ok with ASPM disabled (originally tested 100% Ok on my Latitude 7490 without ASPM tuning) 1028:0021 (part # CN-096JNT) -> 100% Ok with APSM disabled 1028:0022 (part # CN-096JNT) -> 100% Ok with APSM disabled 1028:0023 (part # CN-0VW3T3) -> 100% Ok with APSM disabled 1028:0023 (part # CN-08PKF4) -> 100% Ok with APSM disabled I acquired a Dell DW1820A a few months ago and was able to play with that card on a Latitude 7490 laptop (fitted with an M.2 2230 Key A+E WLAN slot) that I targeted for Mojave. The model I received was CN-0VW3T3. Before it was later established that not all DW1820A were equal, I purchased a 2nd one and, as it turned out to be, was lucky to receive another 0VW3T3 model. /!\ The 1st thing I want to report is that I encountered difficulties booting my Mojave USB installer and installing macOS with the card plugged in. I had to disable wireless in BIOS to be able to install Mojave. Once it was installed, booting Mojave with wireless enabled in BIOS would cause quite severe lag and performance degradation once at the desktop, as if the card just clogged up CPU ressources. This was because I had not applied any particular tuning for the card and, of course, this was resolved once I implemented the necessary fix detailed below. /!\ Searching through the Web for that DW1820A/BCM4350, I came accross a few forum posts/threads that mentionned: rolling back the Yosemite IO80211Family kext to get the card to work, although with instability and regular KPs removing AirPortBrcmNIC plugin kext from IO80211Family kext, patching AirPortBrcm4360 plugin kext with the id of the DW1820A and installing AirportBrcmFixup kext with a couple of parameters (Credits to Hugotai, cf. his post @Voldemort's place, 2nd Dec 2018) Whilst I did not really contemplate doing the 1st thing, I did envisage the 2nd one and started to look at the differences between Yosemite's version of IO80211Family kext and Mojave's. The main difference I had already noticed was that device id 14e4:43a3 was handled by AirPortBrcm4360 up to Sierra 10.12 and by AirPortBrcmNIC since High Sierra 10.13. Further reading and experimenting showed me that AirPortBrcmNIC kext was the root cause of the problem. Building on Hugotai's success, I seeked to work out an easier solution to bypassing AirPortBrcmNIC kext that would not require kext removal and Info.plist patching but, instead, something that could be implemented through hardware properties injection, either through DSDT/SSDT patching or bootloader (Clover or OpenCore) configuration. Once Hugotai's solution was verified and confirmed, I worked out the following Clover-based solution (because that's what I was using) for HighSierra/Mojave: identify the IOReg/ACPI device to which the DW1820A card is attached (use IORegistryExplorer app to that effect). Eg: RP0n@xx,yy->PXSX@0. in the absence of individual ACPI device entry under the PCI bridge for the card, select "FixAirport" ACPI Fix in Clover. That'll create a device "ARPT" @0 under the bridge and that's what you'll inject properties to. This may also require to select "AddDTGP" ACPI Clover fix if your DSDT does not possess any DTGP method. If running with Clover, use Clover Configurator app to that effect. inject the following properties either in DSDT or through bootloader config (latter recommended): compatibility of the card with Broadcom chips 14e4:4353 or 14e4:4331 that are handled by IO80211Family's PlugIn kext AirPortBrcm4360 ASPM disabling (required for most cards to avoid CPU clogging and system freeze) optionally, add SysProfiler's cosmetic info such as PCIe Slot, card's make and model, etc. and that's it ! Nothing to do to IO80211Family kext or its PlugIns which all remain untouched/unmodified/full vanilla in /S/L/E. It really could not be simpler... NB: if your card's country code absolutely requires to be changed, say for full 5GHz/80MHz operations, add the following steps: install AirportBrcmFixup kext in /L/E + repair permissions + rebuild your cache or inject it through Clover's EFI/CLOVER/kexts/Other add boot argument brcmfx-country=XX (where XX is the target value, eg: US, FR, #a, etc.) to the Boot section of your Clover config but, beware, I found that using AirportBrcmFixup (v1.1.9 at time of writing) with country code other than default's US setting of the card impacted my wireless performance (fluctuating and reduced RX/TX rate). For instance, with country code set to FR (for France), I would not connect at 80MHz on my 5GHz Wireless network, only at 40MHz which resulted in a local wireless connection limited to 400Mbps (vs. 867Mbps) and reduced my overall Internet RX rate by about 60% and TX rate by about 10%: with country code set to #a (to get full 80MHz connection), I could not obtain DFS channel mode to my local router and I noticed fluctuating/unstable RX/TX rates: without AirportBrmfixup, my wireless connection runs solid at 867Mbps and SpeedTest returns a solid TX and RX rates at 300Mbps (i.e. the maximum speed of my Internet connection). Properties injection through DSDT: On my laptop, the DW1820A was found attached to device RP03.PXSX located at IO address 0x001C0002, i.e. 1C,2. The DSDT patch required to inject properties could look like this (devices names will differ from one computer to another of course!): Device (RP03) // PCIe Root Bridge { name (_ADR, 0x001C0002) [...] [...] [...] Device (PXSX) // DW1820A card attached to this device (FixAirport Clover ACPI fix required if such device is missing) { Name (_ADR, Zero) [...] [...] [...] Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package () { "AAPL,slot-name", // Optional Buffer () { "WLAN" }, "device_type", // Optional Buffer () { "Airport Extreme" }, "name", // Optional Buffer () { "Airport" }, "model", // Optional Buffer () { "Dell DW1820A 802.11ac wireless" }, "compatible", // Mandatory Buffer () { "pci14e4,4353" // Declares compatibility with BCM43224; "pci14e4:4331" for BCM94331 may also be used }, "pci-aspm-default", // Mandatory for most cards Buffer (One) { 0x00 // Disables ASPM for PCIe device } }) } } } Properties injection through bootloader config: An easier alternative is to inject those properties in bootloader config (for Clover via Clover Configurator app for instance). This can be done within the Devices properties section by injecting the desired properties in the Properties sub-section: In the left part, add the PCIe address of the targeted device in the form PciRoot(0x0)/Pci(<root device address>)/Pci(<actual device address>) In the right part, add the above properties in single lines and with the right types (String, Data, Number) For instance, in the case of my laptop booting with Clover, the target device will be PciRoot (0x0)/Pci(0x1C,0x02)/Pci(0x0,0x0) for PCI0@0->RP03@1C,2->PXSX@0. Then, properties will be injected as lines of keys of 3 x possible types: strings, hex data blocks or numbers. For instance, to declare compatibility with 14e4:4353, the line will consist of Property Key set to compatible, Key Value set to pci14e4,4353 and Key Type set to STRING. The complete properties injection will be: Device = PciRoot(0x0)/Pci(0x1c,0x02)/Pci(0x0,0x0) Key = compatible | Value = pci14e4,4353 | Type = STRING Key = pci-aspm-default | Value = 0 | Type = NUMBER Key = AAPL,slot-name | Value = WLAN | Type = STRING (optional) Key = device_type | Value = Airport Extreme | Type = STRING (optional) Key = name | Value = Airport | Type = STRING (optional) Key = model | Value = Dell DW1820 (BCM4350) 802.11ac wireless | Type = STRING (optional) Once the device properties are injected in bootloader config or DSDT, there's nothing left to do but reboot the computer. The DW1820A card will then be fully active and able to connect to 2.4/5GHz networks at full speed. Results: On the Bluetooth side, once the usual Broadcom firmware patching kexts are installed (eg: Rehabman's BrcmFirmwareRepo + BrcmPatchRAM2 for instance), the BT4.1 module will be fully operational and capable of supporting AirDrop and Handoff! Links: Clover Configurator app Rehabman's Broadcom Firmware patching kexts Acidanthera AirportBrcmFixup kext - - - - - - - - - - Edit: 06 Jan 2020 Updated with freshly found ASPM disabling property injection that fixes all outstanding stability issues. DW1820A #096JNT and Foxconn T77H649 now tested 100% Ok. DW1820A #08PKF4 should be just the same. - - - - - - - - - - Edit: 28 Jan 2020 Finally got to test a DW1820A #08PKF4 and it's also 100% Ok with ASPM disabled. 8 2 Link to comment Share on other sites More sharing options...
Administrators Hervé Posted May 3, 2019 Author Administrators Share Posted May 3, 2019 Last Update: 6th Jan 2020 Foxconn T77H649.00: Ok Foxconn T77H649.00 appears mostly offered with Lenovo laptops and carries Lenovo FRU (i.e. part #) 00JT494. The cards carries the usual Broadcom PCI id 14e4:43a3 and subsystem id 17aa:075a. - - - - - - - - - - Edit: 06 Jan 2020 This Foxconn T77H649 works perfectly with ASPM disabled through bootloader property injection under the associated device address: Key = pci-aspm-default | Value = 0 | Type = NUMBER ASPM disabling appears mandatory with this card to avoid CPU overloading and system freeze after a few minutes. 1 Link to comment Share on other sites More sharing options...
Administrators Hervé Posted May 3, 2019 Author Administrators Share Posted May 3, 2019 Lite-On WCBN808B: According to Wikidevi, DW1820A are manufactured by Lite-On with part # WCBN808B. I was not able to verify this for certain and could not find any specific info for a Lite-On WCBN808B card but this number is printed at the back of my Dell DW1820A 0VW3T3 cards. I also found a Lenovo card (FRU 00JT493) carrying that WCBN808B reference on its front label. That card is definitely based on BCM4350 chipset. Afaik, it's not been tested yet but I'll try to get one too. Untested So, as it turns out so far, WCBN808B reference is printed on: Dell's CN-0VW3T3 Dell's CN-096JNT Dell's CN-08PKF4 Lenovo's 00JT493 It is not printed on: Foxconn's T77H649 Link to comment Share on other sites More sharing options...
Administrators Hervé Posted January 6, 2020 Author Administrators Share Posted January 6, 2020 I was contacted by member @plastikman about a potential universal fix for the troublesome DW1820a cards. Hugotai posted again at Voldemort's place early december 2019 about a property injection that apparently fixed the stability issues encountered with so many DW1820a on so many laptops. Said property is pci-aspm-default and the value to inject is 0. Hugotai explained that he derived the solution from this guide he found on the Net and in which the author explained that, in order to use the DW1820A card, he had disabled PCIe ASPM power in BIOS. A quick search on the Net revealed to me that ASPM means Active-State Power Management and relates to PCIe devices. Basically it's a protocol that offers dynamic power management through different possible states ranging from idle to powersave or performance. I also understand there is a default state which usually means power is controlled by BIOS, not the OS/kernel. This is totally unknown territory until I read more about it but setting ASPM default state to 0 probably means ASPM is disabled. On reading a little further, I came across writings that mentioned potential conflicts between idle timers or that ASPM compliance varied according to device. So, the troubles experienced by so many people may indeed come from that. Anyway, I tried the property injection with the other 2 x DW1820a/BCM4350 cards I still possess and that did not properly work in my Latitude 7490: the 096JNT model (subsystem 1028:0021) and the T77H649 (subsystem 17aa:075a). Results were as follows: 096JNT: Without injection of ASPM property CPU load up to the roof after a few minutes, system freeze as expected and experienced before. IOReg reveals pci-aspm-default parameter natively set to 0x102 under the wireless card's ACPI device. With injection of ASPM defaut set to 0 All Ok, was able to use the laptop without any issue, performance degradation of wifi problems for well over 1hr. IOReg confirms pci-aspm-default parameter set to 0 under the wireless card's ACPI device. T77H649: Without injection of ASPM property CPU load up to the roof after a few minutes, system freeze as expected and experienced before. IOReg reveals pci-aspm-default parameter natively set to 0x102 under the wireless card's ACPI device. With injection of ASPM defaut set to 0 All Ok, was able to use the laptop without any issue, performance degradation of wifi problems for well over 1hr. IOReg confirms pci-aspm-default parameter set to 0 under the wireless card's ACPI device. I remind everyone that all I use, in order to declare compatibility with Broadcom chips 14e4:4331 or 14e4:4353, is the Clover property injection detailed in post #2; no AirportBrcmFixup plugin kext, no bcrmfx-driver boot argument and no pin masking. So, it would seem we now have a definitive solution for DW1820A/BCM4350-based cards. I've updated the above posts to reflect on the good news. All credits to the author of this guide that caught the attention of Hugotai who derived the property to inject as a fix. 4 Link to comment Share on other sites More sharing options...
Administrators Hervé Posted January 28, 2020 Author Administrators Share Posted January 28, 2020 Disabling ASPM does not void the need to inject compatibility property to bypass AirPortBrcmNIC; running off this default kext still causes occasional glitches/freezes of the wireless service. So stick to the guidance posted above. Link to comment Share on other sites More sharing options...
Administrators Hervé Posted December 17, 2020 Author Administrators Share Posted December 17, 2020 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- /!\ Big Sur, Monterey and Ventura /!\ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Big Sur dropped support for Broadcom BCM4331 and BCM43324 which results in the disappearance of AirPortBrcm4360 kext! This basically extended death to DW1820A when using the solution detailed above. A 1st workaround is to call on a patched version of Catalina's IO80211Family kext where only AirPortBrcm4360 has been retained as PlugIn. See here for details. With OpenCore, the patched kext can be placed in the OC kexts folder and added to the list of add-on kexts in the OC config. Add minimum kernel set to 20 if the config is also used for previous macOS version(s). IO80211Catalina.kext.zip A 2nd workaround is to call on Acidanthera's AirportBrcmFixup kext (its injectors are not required/used) + injecting compatibility with pci14e4,43ba (BCM43602) or pci14e4,43a0 (BCM4360). This was tested and verified under OpenCore by enabling only the parent kext of the fixup kext v2.1.2 and leaving both of its injector PlugIns disabled. The adjusted IOProbeScore value of the Fixup kext seems to be the key here. Others (it was my case) will find that, in Big Sur and later, injecting compatibility with pci14e4,43a0 (Broadcom BCM4360) + disabling ASPM does suffice. Link to comment Share on other sites More sharing options...
Administrators Hervé Posted January 20 Author Administrators Share Posted January 20 -+-+-+-+-+-+-+-+-+-+ /!\ Sonoma and later /!\ -+-+-+-+-+-+-+-+-+-+ Sonoma dropped all official support for what Apple calls legacy cards that remained supported up to Ventura; this includes cards based on the BCM4350 chipset. The above solution for Big Sur, Monterey and Ventura remains applicable in Sonoma but comes as a complement to the solution required to support legacy wireless cards in macOS 14 and which is explained here. Link to comment Share on other sites More sharing options...
Recommended Posts