Jump to content
Hervé

Broadcom BCM4350 cards under High Sierra/Mojave

Recommended Posts

Last update: 05 May 2019

 

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
  • Foxconn T77H649.00 (Lenovo part number 00JT494)
  • Lite-on WCBN808B

 

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>

 

  • Like 1

Share this post


Link to post
Share on other sites

Last update: 22 May 2019

 

Dell DW1820A:

DW1820A_M.2_2230.jpg   DW1820A_CN-096JNT.jpg   DW1820A_CN-08PKF4.jpg

                    Ok                                       Ok-ish                                    NOk ?

 


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 3 x different models of the card. Whilst they all carry the same Broadcom id 14e4:43a3, they each carry a different subsystem id:

  • 1028:0021 (part # CN-0VW3T3) -> tested 100% with the 3 x cards I possess
  • 1028:0021 (part # CN-096JNT) -> seems to require AirportBrcmFixup kext + brcmfx-driver=1 boot option otherwise, after ~10mins Ok, CPU overloads and system grounds to a halt/freeze
  • 1028:0022 (part # ?) -> not tested, no report to date
  • 1028:0023 (part # CN-08PKF4) -> several reports of issues (5-10mins Ok, then system freeze). To be tested with AirportBrcmFixup kext + brcmfx-driver=1 boot option; will probably work with those.

 

 

I acquired a Dell DW1820A a few months ago and was able to play with that card on a 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:

  1. rolling back the Yosemite IO80211Family kext to get the card to work, although with instability and regular KPs
  2. 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. Building on Hugotai's success, I seeked to work out an easier solution that would not require kext removal and Info.plist patching but, instead, something that could be implemented through hardware properties injection, either through DSDT patching or Clover configuration.

 

Once Hugotai's solution was verified and confirmed, I worked out the following Clover-based solution for HighSierra/Mojave:

  1. identify the IOReg/ACPI device to which the DW1820A card is attached (use IORegistryExplorer app to that effect). Eg: RP0n@xx,yy->PXSX@0.
  2. 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. Use Clover Configurator app to that effect.
  3. inject the following properties either in DSDT or through Clover (latter recommended):
    • compatibility of the card with Broadcom chips 14e4:4331 or 14e4:4353 that are handled by IO80211Family's PlugIn kext AirPortBrcm4360
    • 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

Clover_Boot_args.jpg

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, only to 40MHz which resulted in a local wireless connection limited to 400Mbps (vs. 867Mbps) and reduced my overall RX rate by about 60% and TX rate by about 10%:

DW1820A_connection_CC=FR.jpg   Wireless_rates_CC=FR.jpg

 

  • 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:

DW1820A_connection_CC=#a.jpg   Wireless_rates1_CC=#a.jpg   Wireless_rates2_CC=#a.jpg

 

  • without AirportBrmfixup, my wireless connection returns a solid TX and RX rates at 300Mbps. 

 

 

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 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,4331"     // Declares compatibility with BCM94331; "pci14e4:4353" for BCM43224 may also be used
                }
            })
        }
    }
}

 

Properties injection through Clover config:

An easier alternative is to inject those properties in Clover via Clover Configurator app. This can be done within the Devices 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, 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:

DevicePciRoot(0x0)/Pci(0x1c,0x02)/Pci(0x0,0x0)

Keycompatible | Value = pci14e4,4353 | Type = STRING

KeyAAPL,slot-name | Value = WLAN | Type = STRING (optional)

Keydevice_type | Value = Airport Extreme | Type = STRING (optional)

Key = name | Value = Airport | Type = STRING (optional)

Keymodel | Value = Dell DW1820 (BCM4350) 802.11ac wireless | Type = STRING (optional)

 

Clover_Properties_injection.jpg

 

Once the device properties are injected in Clover or DSDT, there's nothing left to do but reboot the computer. The DW1820A card will then be fully active and capable to connect to 2.4/5GHz networks at full speed.

 

Results:

DW1820A_lspci.jpg

DW1820A_Connection.jpg

 

DW1820A_throughout.jpg

 

DW1820A_IOReg.jpg

 

 

 

On the Bluetooth side, once the usual Rehabman's Broadcom firmware patching kexts are installed (BrcmFirmwareRepoBrcmPatchRAM2), the BT4.1 module will be fully operational and capable of supporting AirDrop and Handoff! 

 

7490_DW1820A_Handoff#1.jpg     7490_DW1820A_Handoff#2.jpg

 

 

Links:

 

  • Like 6

Share this post


Link to post
Share on other sites

Last update: 22 May 2019

 

I've had no issues whatsoever with the 2 x DW1820A cards I possess. Both carry subsystem id 1028:0021 and Dell part # CN-0VW3T3.

IMG_2107.JPG

 

IMG_2108.JPG

 

IMG_2109.JPG

 

IMG_2119.JPG

 

 

Thanks to @sniderjc, it was confirmed that DW1820A CN-08FKP4 carries subsystem id 1028:0023. This model was reported to cause issues such as rapid severe system slowdown, leading to system freeze. It is therefore not suitable to Hackintoshes.

 

Edit: CN-08PKF4 now requires to be further tested with AirportBrcmFixup kext + boot option brcmfx-driver=1.

DW1820A_CN-08PKF4.jpg   08PKF4_rear.png

Share this post


Link to post
Share on other sites

Last Update: 22 May 2019

 

Foxconn T77H649.00:

T77H649.00.jpg   T77H649_Rear1.jpg   T77H649_Rear2.jpg

                      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.

 

@zogthegreat tested the card and it proved to behave exactly like the Dell DW1820A CN-08PKF4, i.e. rapid severe system degradation and system freeze. Zogthegreat was kind enough to mail me the card for testing in case there was a matter of config adjustment or SMBIOS but I reproduced the exact same issues in my Latitude 7490, having fitted the card in place of the perfectly working DW1820A CN-0VW3T3. It had a broken AUX antenna connector but I do not believe this is the cause of the issues.

 

So, like the DW1820A CN-08PKF4 model, this card is not suitable for Hackintoshes either.

 

Edit: As per the DW1820a CN-096JNT model, this Foxconn T77H649 actually appears to work perfectly when caching/injecting AirportBrcmFixup kext and using boot option brcmfx-driver=1. In addition, unlike what I experienced with my CN-096JNT card, I've had no wireless disconnections at all and the card proved to work perfectly with the above setup: 802.11ac, DFS 5GHz 80MHz, 867Mbps connection to my wireless router. However, after well over 1hr of usage, I've now experienced the following twice: wireless disconnection, system dead slow. I don't know if this would be affecting all such cards or itf it's just something specific to this partially damaged card.

 

 

Share this post


Link to post
Share on other sites

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.

Lenovo_00JT493.jpg   WCBN808B.jpg

                 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

 

This would have to be further assessed but it may the key to cards that are compatible with macOS...

 

Share this post


Link to post
Share on other sites

Last update: 22 May 2019

 

I received the CN-096JNT. Once plugged in, I was actually surprised to see it carry subsystem id 1028:0021, not 1028:0022 as expected (I've modified post #2 to that effect). Once fitted in, the card seemed to perfectly Ok without any issue at all in my Latitude 7490, just like my other 2 x CN-0VW3T3.

 

However, after 5 to 10mins, CPU got clogged up to full speed and laptop grounded to a near-halt and became unusable. This was reproduced systematically as previously reported for the CN-08PKF4 model. Further to a report by @DalianSky here, I can confirm that the workaround is to cache or inject AirportBrcmFixup and use brcmfx-driver=1 boot option. The card can then be used without killing its host although some occasional brief and unexplained wireless disconnections may be experienced. These can be expected to be accompanied by brief USB disconnections/freezes until wireless network is reconnected.

 

MAC address OUI for that card is AC:E0:10.

 

DW1820a_096JNT.jpg     096JNT_Rear.jpg

        -> Ok-ish

 

096JNT_connection.jpg     096JNT_subsystem-id.jpg

 

'beginning to wonder if manufacturer's OUI wouldn't have a part to play in all this too...

Share this post


Link to post
Share on other sites

Further to new information posted here, it appears that calling on AirportBrcmFixup with boot option brcmfx-driver=1 (to force BRCM4360 kext rather than BrcmNIC) allows to run Ok with some if not all those DW1820a cards that were reported to cause performance degradation and system freeze after a few minutes.

 

Using that add-on kext + boot option allows me to use the CN-096JNT card without clogging the Hackintosh too a halt. I only experienced 2 x brief wireless disconnections during which system appeared to briefly freeze or, at least, the USB ports froze (hence mouse frozen) but all resumed after wireless automatically reconnected a few seconds later.

 

I've updated the above posts accordingly.

 

Foxconn T77H649 card would seem to go in the same direction but the partially damaged model I have on-loan appears to go south after > 1hr. <_< So, it's a little difficult to rule on this model once and for all...

  • Like 1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...