Jump to content

DW1820A: no wifi in Big Sur, only Bluetooth (Latitude 3400)


Laptudinal

Recommended Posts

  • Administrators

Are you sure? I tried this on my Toshiba R50-B and it causes systematic KP and laptop reset (ASPM was still being disabled through property injection in OC). Loading AirportBrcmNIC always was an issue with this card and I don't believe this has changed in Big Sur...

 

But, given that AirportBrcmNIC offers native support for Broadcom chips BCM43602 (14e4:43ba), BCM4350 (14e4:43a3) and BCM4360 (14e4:43a0), I guess there must be differences in terms of handling in the kext's code.

Link to comment
Share on other sites

  • Administrators

Hmm, according to Acidanthera's documentation, the associated boot arg behaves as follows:

brcmfx-driver=0|1|2|3 enables only one kext for loading,
0 - AirPortBrcmNIC-MFG, 1 - AirPortBrcm4360, 2 - AirPortBrcmNIC, 3 - AirPortBrcm4331,
also can be injected via DSDT or Properties → DeviceProperties in bootloader

To me the Fixup kext's Brcm4360 injector and its boot arg should therefore be useless on Big Sur given the absence of kexts such as AirPortBrcmNIC-MFG, AirPortBrcm431 and AirPortBrcm4360 in macOS 11.x. However, the IOProbeScore associated with the device ids are different than the vanilla values. Maybe that contributes to fixing the issues (along with disabling ASPM).

  • Big Sur vanilla AirPortBrcmNIC -> IOProbeScore=1400
  • AirportBrcmFixup -> IOProbeScore 6000
  • AirportBrcmFixup.AirPortBrcmNIC_Injector -> IOProbeScore 2048
  • AirportBrcmFixup.AirPortBrcm4360_Injector -> IOProbeScore 1110

 

Please note that injecting device id 14e4:43a3 is of no use/benefits given that it's the card's own native id.

 

Anyway, I went back on the Toshiba and removed the Catalina patched kext to try the Fixup kext v2.1.2; the card was indeed operational. All I changed in terms of injected properties was the device id which I set to 14e4:43a0; not boot arg used. It also worked if I injected compatibility with pci14e4,43ba. With the card's default device-id (i.e. no device-id injection), macOS boots very slowly (takes several minutes) and I had no wireless thereafter. Carried further testing with the Fixup kext and found that its injectors are not required, something I was expecting. It therefore looks like the IOProbeScore value adjustment is the key here.

 

So, whatever the solution, it involves injecting a kext + the compatible property, i.e.:

1) patched IO80211Catalina kext + compatible=pci14e4,4353 (or pci14e4,4331)

or

2) AirportBrcmFixup kext (without its injectors) + compatible=pci14e4,43a0 (or pci14e4,43ba)

Link to comment
Share on other sites

3 hours ago, Hervé said:

1) patched IO80211Catalina kext + compatible=pci14e4,4353 (or pci14e4,4331)

 

I've tried this. When I use, pci14e4,4331 the WiFi icon goes into a loading loop and never connects or shows access points.

 

Using pci14e4,4353 does give me basic WiFi connectivit, but the system detects it as Generic WiFi Device instead of as an Airport device.

 

Strange that my laptop boots normally and WiFi works properly when I inject the device's default device-id, 43a3. I'm going to try removing the boot flat and injecting 43a0 or 43ba instead.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...