Need help making Bluetooth adapter work in Catalina

[leobas]

Hi there!

I am trying to make a generic Bluetooth adapater work under Catalina. The bluetooth adapters recommended in the buyer's guide are not available in my country, so instead I bought this one which was advertised to work on macs.

When I plugged it without any modifications, nothing showed up under bluetooth in System Information, but it did show up in USB devices:

I managed for macOS to recognize it as Bluetooth by installing BrcmPatchRAM3.kext, BrcmNonPatchRAM2.kext, BrcmFirmwareRepo.kext and BrcmBluetoothInjector.kext (with the product and vendor IDs aded to tthe Info.plist) in L/E. I got the same result by only adding the vendor and product ID to the Info.plist in the BroadcomBluetoothHostControllerUSBTransport.kext contained in IOBluetoothFamily.kext in S/L/E, and also by copying all the IOKitPersonalities from BrcmBluetoothInjector.kext into BrcmFirmwareRepo.kext and removing BrcmBluetoothInjector.kext (this is my current config).

In all these cases this shows up in System Information:

I can access the Bluetooth control panel (though it takes a while for it to load), and it correctly finds my bluetooth devices but it fails to connect to any of them. The next time after I reboot Bluetooth is no longer available (icon appears crossed out in the menu bar), but it comes back if I unplug and replug the adapter.
The adapter works properly in windows.
I'm attaching my troubleshooting info.
¿Do you think you could give me any pointers on what to try? I assume that since my devices actually show up, compatibilty should be possible?

Thank you all very much,

 

[Edhawk]

As you are using a Bluetooth adapter that uses the Cambridge Silicon Radio (CSR) chip you don't need to use any of the BrcmPatchRam series of kexts, as you are not using a Broadcom Bluetooth adapter.

When I used a similar CSR Bluetooth dongle it simply worked in macOS Mojave, without the need for any additional kexts, patches or fixes.

I would recommend you do the following:

1. Delete the Broadcom kexts you added to the /Library/Extensions (/L/E) folder.
2. Repair permissions and Rebuild the kext cache, either with Hackintool, Terminal commands or Kext Utility app.
3. Reboot the system, after repairing the permissions and rebuilding the kext cache!
4. Move the USB dongle to another USB port, one you know works, i.e. test it with a spare USB pen drive.

Have you created a custom USBPorts.kext or USBMap.kext or SSDT-UIAC.aml for your macOS Sierra setup? This could be an issue with the USB as much as it is likely to be an issue with the Bluetooth adapter and any kexts.

I would then suggest you have a read and follow this guide by UtterDisbelief for creating a custom USB configuration for your laptop - https://www.tonymacx86.com/threads/the-new-beginners-guide-to-usb-port-configuration.286553/

 

[leobas]

Hi Edhawk, thanks for your kind reply!

I hadn't realized CSR stood for Cambridge Silicon Radio (facepalm).

I hadn't created a custom USBPorts.kext but I have now, following UtterDisbelief's guide. I have also removed the GenericUSBXHCI.kext I was using to make USB3 work just in case. I followed your instructions to remove all the Broadcom-related kexts and subsequently tried the USB dongle in all the USB ports, but Bluetooth remained unavailable (it doesn't show up now under Bluetooth in System Information, as it did with the Broadcom kexts). The USB ports are all tested and working.

Just in case, I'm on Catalina 10.15.7 (you mention Sierra on your post).

I have also tested both a CSRAppleBluetooth.kext and a GenericCSRBluetooth.kext that I found around forums, and they didn't work either.

¿Could you think of anything else I could try? I'm re-attaching my updated troubleshooting info.

Your help is tremendously appreciated

 

[leobas]

Just to let you all know, I have also tried adding the product and vendor ID to both the CSRBluetoothHostControllerUSBTransport.kext and CSRHIDTransitionDriver.kext whitin IOBluetoothFamily.kext in S/L/E but the Bluetooth wasn't recognized either.

 

[leobas]

Hi there! I still haven't managed to make it work, so I guess I'll be returning this adapater.
¿Could anybody recommend me what to look out for to buy another adapter? Considering that this CSR adapter did not work out of the box for me (or at all), and I also had tried another BT 4.0 that also registered as CSR and also didn't work. The IOgear and GMYLE adapters from the Buyer's List are not available in my country, I did found a Broadcom PCI card but it is way too expensive.

I still wonder why this adapter can't work, and also why it does register as Bluetooth and finds my devices (but can't connect to them) when I force the broadcomm drivers.

Thank you all, any help will be greatly appreciated.

 

[Edhawk]

I'm just going through the EsentialsList folder you provided in post #3 and have noticed that you have two CLOVER folders in your system. Neither of which make good reading, as can be seen in the screenshot taken form the '-Overview-.txt' file:

Contents and locations of the two Clover folders on your system.

These are located in the EFI on disk0s1 and disk3s5. I have no idea which one you are using to boot but would hope it is the first/top folder and it is on disk0s1.

You should really only have one CLOVER folder and it shouldn't have CLOVERX64.efi and BOOTX64.efi files from different versions of Clover bootloader, which the top CLOVER folder has.

The Kexts in the first/top folder are out of date, but at least they are present. The Kexts are totally missing from the second/bottom folder.

Neither folder uses any Custom SSDT's, which is usually a pre-requisite for running Catalina on a Hack.

The second/bottom /CLOER/ACPI/patched folder contains what I assume is a Power Management SSDT. As this is missing from the first CLOVER folder it is not being used by the system. I don't know if this is a good or a bad thing.

The second folder lacks a number of essential drivers in the UEFI folder. (AptioMemoryFix and VirtualSMC.efi)

You have a duplicate of Lilu.kext in your /Library/Extensions folder, it is also an older version than the one in the /CLOVER/kexts/Other folder. This is not needed and should be removed, with the system permissions repaired and kext cache rebuilt - BEFORE YOU REBOOT THE SYSTEM.

Kext 110 in the 'kextstat.txt' file shows the system is using com.apple.iokit.CRSBluetoothHostControllerUSBTransport with your CRS Bluetooth dongle. So it should be active in your system.

It also shows that the kexts in the /EFI/CLOVER/kexts/Other folder on disk0s1 are being used by the system.

The system bootleg (bdmesg.txt) looks OK, it shows the system setup could be improved but that is a different issue.

Neither config.plist is well constructed, with common rename patches, ACPI fixes and settings missing, incorrect and unnecessary boot arguments, poorly set device and graphics options, the wrong SMBIOS for your Sandy Bridge system running Catalina or no SMBIOS in the second config.plist.

The nvram.plist shows that you have a lot of settings hanging over from when you were using FakeSMC.kext. As you are now using VirtualSMC.kext I would recommend you clear the NVRAM on your system, to remove these old unused Nvram settings. You can clear the Nvram while on the Clover boot screen by pressing the 'F11' key. The system should reboot automatically and when you next boot the system it should be set to use the current Nvram settings only.

There is plenty of things for you to do and think about while you are waiting for the replacement BT dongle!

 

[leobas]

Hi Edhawk, I am astonished by your kindness in taking your time to provide such a thorough look at my system, and the corresponding advices for my messy config. Thank you very much for your patience.

I'm just going through the EsentialsList folder you provided in post #3 and have noticed that you have two CLOVER folders in your system.

The second CLOVER folder apparently belonged to a failed Clover update, I have deleted it now.

You should really only have one CLOVER folder and it shouldn't have CLOVERX64.efi and BOOTX64.efi files from different versions of Clover bootloader, which the top CLOVER folder has.

I tried updating Clover to the latest version, but my system always failed to boot afterwards (with no information displayed whatsoever in a verbose boot). I understand that new versions of Clover need "Quirks" and further configs, so I stayed in version 5103 and unified that version number for CLOVERX64.efi and BOOTX64.efi.

The Kexts in the first/top folder are out of date, but at least they are present.

I have now updated all the kexts to it's latest version from Clover Configurator, except for RealtekRTL8111.kext which failed to download.

You have a duplicate of Lilu.kext in your /Library/Extensions folder, it is also an older version than the one in the /CLOVER/kexts/Other folder. This is not needed and should be removed, with the system permissions repaired and kext cache rebuilt - BEFORE YOU REBOOT THE SYSTEM.

This was actually "Lulu.kext", which I'm guessing belongs to the LuLu firewall, so I'm leaving it there for now.

The nvram.plist shows that you have a lot of settings hanging over from when you were using FakeSMC.kext. As you are now using VirtualSMC.kext I would recommend you clear the NVRAM on your system, to remove these old unused Nvram settings. You can clear the Nvram while on the Clover boot screen by pressing the 'F11' key. The system should reboot automatically and when you next boot the system it should be set to use the current Nvram settings only.

I pressed F11 at Clover boot but no automatic reboot happened. It just stood there. I tried "F3" to show hidden partitions to see if the F keys were working and they were. ¿Maybe the NVRAM was reset nonetheless? I do not kknow.

Neither folder uses any Custom SSDT's, which is usually a pre-requisite for running Catalina on a Hack.

I tried creating a custom SSDT last year, following this guide, but got stuck as Piker Alpha's ssdtPRGen script gave me the following error.

Error: board-id [Mac-27ADBB7B4CEE8E61] not supported by Sandy Bridge – check SMBIOS data / use the -c option

I understand that the guide was written when Sandy Bridge was still compatible with current OS's. I've searched the forums and even created my own topic asking about this but found no answers. ¿Could you help me in finding out how to procede to create my custom SSDT?

Neither config.plist is well constructed, with common rename patches, ACPI fixes and settings missing, incorrect and unnecessary boot arguments, poorly set device and graphics options, the wrong SMBIOS for your Sandy Bridge system running Catalina or no SMBIOS in the second config.plist.

I was on iMac 14,2 SMBIOS, and have now changed to MacPro 6,1. The system seems to be working alright, but I do not know if this is the correct one for my rig. I've googled about this and couldn't find much, I've actually got the MacPro recommendation from an OpenCore guide which probably doesn't apply. ¿Should I try another SMBIOS? I was hoping this one would make Piker Alpha's ssdtPRGen script work, but it still gave me this error:

ssdtPRGen.sh v0.9 Copyright (c) 2011-2012 by † RevoGirl
             v6.6 Copyright (c) 2013 by † Jeroen
             v15.6 Copyright (c) 2013-2021 by Pike R. Alpha
-----------------------------------------------------------
Bugs > https://github.com/Piker-Alpha/ssdtPRGen.sh/issues <

gDataPath: /Users/leo/Library/ssdtPRGen/Data
System information: Mac OS X 10.15.7 (19H15)
Brandstring 'Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz'

Scope (_PR_) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a 'MacPro6,1' with board-id [Mac-F60DEB81FF30ACF6]
Sandy Bridge Core i7-2600K processor [0x206A7] setup [0x0703]
With a maximum TDP of 95 Watt, as specified by Intel
Number logical CPU's: 8 (Core Frequency: 3400 MHz)
Number of Turbo States: 4 (3500-3800 MHz)
Number of P-States: 23 (1600-3800 MHz)
Injected C-States for CPU0 (C1,C3,C6,C7)
Warning: 'cpu-type' may be set improperly (0x0703 instead of 0x0a03)

Error: board-id [Mac-F60DEB81FF30ACF6] not supported by Sandy Bridge – check SMBIOS data / use the -c option

Finally, I see that there's much to improve in my config.plist. My system has looked very stable so far, so I never guessed that my settings were so off. Of course I never undestood the workings of Clover properly, so I'm guessing I have a lot to catch on. I do not want to abuse your patience, but if you could point me in which direction to start fixing this, I'll be on it.

I think that's all. I'm re-attaching my updated troubleshooting info to reflect all the latest changes.

Thank you very, very much for your time, your support is truly great.