Contribute
Register

<< Solved >> Bluetooth stopped working after updating to 10.15.1 (BCM943602CS)

Status
Not open for further replies.
I got it to work

I have my kexts installed in /L/E, not in EFI/kexts/Other

I made several different attempts:
  1. Removed all Brcm*kexts and rebooted - >no Bluetooth device recognized
  2. Removed AirportBrcmFixup.kext -> Bluetooth not working
  3. Restored all Brcm*kexts, and AirportBrcmFixup.kext - EXCEPT BrcmPatchRAM2.kext - Bluetooth device seen, turned it on, all all devices connect.
So let me summarize. In /L/E I have:

AirportBrcmFixup.kext
BrcmBluetoothInjector.kext
BrcmFirmwareRepo.kext
BrcmPatchRAM3.kext

I do NOT have BrcmPatchRAM[1,2].kext. I do NOT have BrcmNonPatchRam*.kext.

In the end this makes sense to me as Catalina needs BrcmBluetoothInjector.kext, and ONLY one, the latest, PatchRAM3.
 
So let me summarize.

AirportBrcmFixup.kext
BrcmBluetoothInjector.kext
BrcmFirmwareRepo.kext
BrcmPatchRAM3.kext

In the end this makes sense to me as Catalina needs BrcmBluetoothInjector.kext, and ... BrmcPatchRAM3.


@tecemac and all,

Catalina removed some IOCatalogue methods including the ones used by @RehabMan's BrmcPatchRAM2 kext.

@headkaze first addressed the issue and created BrmcPatchRAM3 and BrcmBluetoothInjector as posted here :-


@headkaze passed the code on to the Acidanthera team who now maintain it here :-


Your summary above is the correct method for enabling WiFi and BT on Catalina.

Cheers
Jay
 
Please note that 10.15.1 does not break this Broadcom chipset

if it is the genuine 05AC_8290. And if it was working with 10.15.0, then it seems unlikely you would need to flash the firmware.

I am unable to identify "f007".
Now, when bluetooth is not working, it's showing Product ID: 0xf007, Vendor ID: 0x05ac (Apple Inc.).
I don't know what Product ID was before - when bluetooth worked on 10.14.0 - 10.15.0 versions of Mac.
If Product ID was 0xf007, which i believe is a wrong one, why has it been working on 10.14.0 - 10.15.0 versions of Mac? That's why i believe that 10.15.1 update bricked it, and that ID might have been 8290.

Using USB2 ports on the EHC controller, as you are doing, with the port and cable you previously used, should be fine. Your motherboard has four internal Intel USB2 ports to choose from.
No, my Motherboard has 2 internal USB2 headers and 1 USB3 header. I'm have attached an extender (like this) to one of the USB2 headers. Bluetooth is connected straight to one of the two motherboard headers. While i have NZXT Watercooling block, Corsair PSU and Front USB2 connected to the extender ports. That's why you might see 4 USB2 headers. I tried both of the USB2 headers (connecting straight to the Motherboard)

1) Because bluetooth is not working, check which kexts you have installed - screengrabs show differences between Hackintool and Finder L/E (in case of conflicts). Did you remove FakePCIID_XHCIMux.kext? If so, good :thumbup:
Well, differences between L/E and EFI/Clover/kexts/Other are understandable. I don't know why Hackintool doesn't show all of the kexts, that is in EFI/Clover/kexts/Other. FakePCIID_XHCIMux.kext was there (it was just not shown in Hackintool), now i removed it while following your directions. No success.

2) Try removing your SSDT and instead using a port-limit removal patch to test again.
Done that too. No success.

3) Consider re-checking your choice of UsbConnector value for the header/port type you are using.
You mean before removing SSDT and checking with Port limit removal patch? I've done both, edited SSDT to UsbConnector value of 255 (internal), i tried editing portType to 2 also (as it's suggested on top of the SSDT template). I removed SSDT altogether and added port limit removal patch - no success.

4) Check the Intel Vendor/Device IDs used in the SSDT
You mean this part of SSDT - ""8086_8xxx""?

And of course, it is always possible that your hardware has become faulty, but if not, then it should just be a USB configuration issue.
There's no better time to become faulty, than during the update to 10.15.1 :D

So, in general - no success.

Thank you for your suggestions.
 
I got it to work

I have my kexts installed in /L/E, not in EFI/kexts/Other

I made several different attempts:
  1. Removed all Brcm*kexts and rebooted - >no Bluetooth device recognized
  2. Removed AirportBrcmFixup.kext -> Bluetooth not working
  3. Restored all Brcm*kexts, and AirportBrcmFixup.kext - EXCEPT BrcmPatchRAM2.kext - Bluetooth device seen, turned it on, all all devices connect.
So let me summarize. In /L/E I have:

AirportBrcmFixup.kext
BrcmBluetoothInjector.kext
BrcmFirmwareRepo.kext
BrcmPatchRAM3.kext

I do NOT have BrcmPatchRAM[1,2].kext. I do NOT have BrcmNonPatchRam*.kext.

In the end this makes sense to me as Catalina needs BrcmBluetoothInjector.kext, and ONLY one, the latest, PatchRAM3.
Good for you! No success for me. Could you please attach all four kexts in a zip. I'm not sure if i'm using the latest ones. Thanks.
 
...
No, my Motherboard has 2 internal USB2 headers and 1 USB3 header. I'm have attached an extender (like this) to one of the USB2 headers. Bluetooth is connected straight to one of the two motherboard headers. While i have NZXT Watercooling block, Corsair PSU and Front USB2 connected to the extender ports. That's why you might see 4 USB2 headers. I tried both of the USB2 headers (connecting straight to the Motherboard)


If it is the same motherboard as in your profile, then you have 2x USB2.0 headers - each header is 2x ports. So a total of 4x USB2.0 ports on internal headers, as I said. The X99 actually has more but Gigabyte only implements those on your board.


Well, differences between L/E and EFI/Clover/kexts/Other are understandable. I don't know why Hackintool doesn't show all of the kexts, that is in EFI/Clover/kexts/Other. FakePCIID_XHCIMux.kext was there (it was just not shown in Hackintool), now i removed it while following your directions. No success.


I just wanted to point out FakePCIID_XHCIMux.kext is not needed because your motherboard does not have enough Intel USB ports to need it. Your total (ignore the Renesas chip) is 4x Intel USB3.0 ports. Total configurable Intel ports 4+4+8 = 16. There is no advantage moving USB2 off the XHC controller, for those 4x ports.


You mean before removing SSDT and checking with Port limit removal patch? I've done both, edited SSDT to UsbConnector value of 255 (internal), i tried editing portType to 2 also (as it's suggested on top of the SSDT template). I removed SSDT altogether and added port limit removal patch - no success.


Okay, show us your SSDT template and your Hackintool USB panel so we get a clearer picture.

You mean this part of SSDT - ""8086_8xxx""?


Yes.

There's no better time to become faulty, than during the update to 10.15.1 :D


It would be unfortunate. I have exactly the same ABWB Justop combination wifi/bluetooth card as you have. I run Catalina 10.15.1 - I did not have to change any kexts and I did not have to flash firmware. :)
 
Last edited:
Thank you, doesn't work in my case.
Use this tool and upload your problem reporting files:

maybe someone can help you better :)
 
I just wanted to point out FakePCIID_XHCIMux.kext is not needed because your motherboard does not have enough Intel USB ports to need it. Your total (ignore the Renesas chip) is 4x Intel USB3.0 ports. Total configurable Intel ports 4+4+8 = 16. There is no advantage moving USB2 off the XHC controller, for those 4x ports.

I just did a fresh reinstall of 10.15.1, as i wanted to start everything clean. Previously all of my kexts were in Clover/kexts/Other in EFI. This time i moved (with Hackintool) all of them to L/E (i read that it's a better practice), and i left just FakeSMC.kext in Clover/kexts/Others in EFI. macOS booted with just FakeSMC.kext in Clover/kexts/Others in EFI, however, i tested if i could use Recovery mode with just FakeSMC.kext in Clover/kexts/Other in EFI. And i found out, that i needed both - FakePCIID, and FakePCIID_XHCIMux.kext for Mouse and Keyboard to work in Recovery mode.

As for the count of ports, the situation is this
FRONT PANEL:
2 x USB2 ports: both of them HP21 (see more in internel motherboard headers section)
2 x USB3 ports: HP12/SS02, SP11, SS01

BACK PANEL:
4 x USB2 ports: HP23, HP24, HP25, HP25
4 x USB3 ports: all of them are HP15/SS05
2 x USB3 ports: HP13/SS03, HP14/SS04

INTERNAL MOTHERBOARDHEADERS:
2 x USB2 headers:
First motherboard header: HP18 - Bluetooth adapter connected to this, straight to motherboard
Second motherboard header is used for extender which created additional 4 headers, three of which are used, and one is not used. It looks like this:
6AE30188-1A67-4F7D-A4A2-DB3AB5466511.jpeg

HP21 is used for two Front USBs, and for Corsair Link.
HP22 is used for NZXT Watercooler.

Not counting USB3 ports, as all of them have their own USB2 version number, there is 12 ports visible (although, some of the physical ports has the same HPxx names, there's 4 ports with same HP15 name for example).

Okay, show us your SSDT template and your Hackintool USB panel so we get a clearer picture.
Here's the current situation of my Hackintool USB panel. And i attached my SSDT files to the post (patched.zip). I know that my USB in Hackintool USB panel looks not really good, but all of the ports are working, as well as USB3.
Screenshot 2019-11-11 at 01.16.36.png


All of my USB2 ports are under PR11 and PR21.
PR11 - HP11, HP12, HP13, HP14, HP15, HP18 (there's no HP16 and HP17)
PR21 - HP21, HP22, HP23, HP24, HP25, HP26

All of the USB3 ports are under XHCI@14000000.



P.S. I didn't see your answer straight away, as it was edited, just noticed it now. Thank you @UtterDisbelief for your patience and help!

As for problem reporting generator tool - don't want to use it really, as there's Serial numbers (linked with iCloud), personal emails, usernames, names, Mac computer names. I tried to generate it and replaced most of such sensitive information, but there was just too many codes, texts and files to check all of it.
 

Attachments

  • patched.zip
    1.7 KB · Views: 90
Last edited:
I just did a fresh reinstall of 10.15.1, as i wanted to start everything clean. Previously all of my kexts were in Clover/kexts/Other in EFI. This time i moved (with Hackintool) all of them to L/E (i read that it's a better practice), and i left just FakeSMC.kext in Clover/kexts/Others in EFI. macOS booted with just FakeSMC.kext in Clover/kexts/Others in EFI, however, i tested if i could use Recovery mode with just FakeSMC.kext in Clover/kexts/Other in EFI. And i found out, that i needed both - FakePCIID, and FakePCIID_XHCIMux.kext for Mouse and Keyboard to work in Recovery mode.

As for the count of ports, the situation is this
FRONT PANEL:
2 x USB2 ports: both of them HP21 (see more in internel motherboard headers section)
2 x USB3 ports: HP12/SS02, SP11, SS01

BACK PANEL:
4 x USB2 ports: HP23, HP24, HP25, HP25
4 x USB3 ports: all of them are HP15/SS05
2 x USB3 ports: HP13/SS03, HP14/SS04

INTERNAL MOTHERBOARDHEADERS:
2 x USB2 headers:
First motherboard header: HP18 - Bluetooth adapter connected to this, straight to motherboard
Second motherboard header is used for extender which created additional 4 headers, three of which are used, and one is not used. It looks like this:
View attachment 435415
HP21 is used for two Front USBs, and for Corsair Link.
HP22 is used for NZXT Watercooler.

Not counting USB3 ports, as all of them have their own USB2 version number, there is 12 ports visible (although, some of the physical ports has the same HPxx names, there's 4 ports with same HP15 name for example).


Here's the current situation of my Hackintool USB panel. And i attached my SSDT files to the post (patched.zip). I know that my USB in Hackintool USB panel looks not really good, but all of the ports are working, as well as USB3.
View attachment 435398

All of my USB2 ports are under PR11 and PR21.
PR11 - HP11, HP12, HP13, HP14, HP15, HP18 (there's no HP16 and HP17)
PR21 - HP21, HP22, HP23, HP24, HP25, HP26

All of the USB3 ports are under XHCI@14000000.



P.S. I didn't see your answer straight away, as it was edited, just noticed it now. Thank you @UtterDisbelief for your patience and help!

As for problem reporting generator tool - don't want to use it really, as there's Serial numbers (linked with iCloud), personal emails, usernames, names, Mac computer names. I tried to generate it and replaced most of such sensitive information, but there was just too many codes, texts and files to check all of it.


Hello. Thank you for the extra info.

Right.

The aspect I am working on now is USB port configuration. Your Bluetooth failure since 10.15.1 may, or may not, be related to this. Usually it is. However, if your ports all work perfectly under Windows, but Bluetooth is not working there either, this does signal an adapter problem - if the correct Broadcom drivers were installed etc. I do know of one other case where this has happened to an X99-based build.

On the possibility that Catalina 10.15.1 flashed firmware to your BCM943602CS and 'bricked' it, is worrying if true. This chipset has been used in a lot of real Macs so it just seems unlikely. My own wifi/BT card is this one:

Wifi-2.jpg

... which from your description, sounds like yours too. Catalina 10.15.1 has had no affect on this card whatsoever. All working perfectly as before. This is what made me think your problem is USB.

However, in the Hackintosh world, anything is possible ...

So, for now, I'll carry on with the topic of USB configuration:

To start with a couple of points:

1) No ports attached to a physical "hub" can be configured beyond the original USB port. So you may well see 4x ports with HP15 as a designation, or similar.

2) Your back-panel ports contain 4x USB3.0 ports controlled by a 3rd-party Renesas chip. These are not part of the XHC or EHC controllers (which are Intel). So my guess is -

BACK PANEL:
4 x USB2 ports: HP23, HP24, HP25, HP25 <---- Intel EHC
4 x USB3 ports: all of them are HP15/SS05 <---- Renesas ports - these are a HUB.
2 x USB3 ports: HP13/SS03, HP14/SS04. <---- Intel XHC

Usually 3rd-party ports appear on the PR** or even RP** IORegistryExplorer tree nodes. Obviously, I don't know which port designation any of your ports have. You will know that from your discovery :thumbup:

As you can see in your Hackintool screengrab of the XHC controller, it is a mixture of Intel (SS**) and other ports.

Looking at your SSDT-UIAC.aml I can see a couple of issues:

Your "port-count" values for the EH01, EH02 and 8086:8xxx might be causing problems =

You have 0x08 for EH01 and 0x06 for EH02, but each only has 0x01 port.
You have 0x15 for 8086_8xxx but it only has 0x14 port as max.

This might cause the system to create extra, spurious ports. Maybe worth changing the values.

:)
 
Last edited:
Status
Not open for further replies.
Back
Top