[Solved] Update to Ventura 13.4 - bluetooth no longer works ( BCM94352HMB )

[mnfesq]

I can report that the problem I have with BT is that it is not discoverable once my laptop has woken up from sleep.  The only time my BT works is after a reboot and before the laptop goes to sleep.  

 

I can also report, although it might only be cosmetic, that when I have BluetoolFixup.kext enabled, BT works as described above but the device does not show up in Hackintool under System->Peripherals.  When I disable BluetoolFixup.kext, BT does not work at all (System Information shows that I do not have a BT device) but it does show up in Hackintool.

 

I tried purchasing a BT/Wifi combo card with the chipset that Slice suggested but I found that the BT device would connect for a couple seconds and then disconnect and then reconnect for a couple seconds and so forth.  It was very annoying and not tolerable.  I may try another BT/Wifi Combo card.

Edited May 24, 2023 by mnfesq

[Niko NDP]

On 5/23/2023 at 8:31 PM, deeveedee said:

@Niko NDP Very strange.  Sorry I couldn't help.  Good luck with this!  Looking forward to seeing your progress.

 

EDIT: @Niko NDP I took a quick look at your config.plist and see that there is a boot-arg I'm using that you might try: -btlfxallowanyaddr

 

EDIT2: @Niko NDP I don't know if kext order matters in config.plist (I don't think it should), but you might try moving your BrcmPatchRAM3.kext injection after your map USB.  Since your USB mapping doesn't need Lilu, you should be able to move USB mapping to the beginning of your Kernel > Add list.

 

This is my kext loading order for Bluetooth

  Reveal hidden contents

 

 

Thanks @deeveedee, I've been trying all of them but to no avail. Thanks again for your availability!

[Niko NDP]

3 hours ago, mnfesq said:

I can report that the problem I have with BT is that it is not discoverable once my laptop has woken up from sleep.  The only time my BT works is after a reboot and before the laptop goes to sleep.  

 

I can also report, although it might only be cosmetic, that when I have BluetoolFixup.kext enabled, BT works as described above but the device does not show up in Hackintool under System->Peripherals.  When I disable BluetoolFixup.kext, BT does not work at all (System Information shows that I do not have a BT device) but it does show up in Hackintool.

 

I tried purchasing a BT/Wifi combo card with the chipset that Slice suggested but I found that the BT device would connect for a couple seconds and then disconnect and then reconnect for a couple seconds and so forth.  It was very annoying and not tolerable.  I may try another BT/Wifi Combo card.

 

Thanks @mnfesq for your input. 🙏

[BarryBar]

If you read through this github topic https://github.com/acidanthera/bugtracker/issues/1821   you will see that similar problems with Bluetooth where present in Monterey. I think the best solution will be to get a wifi bluetooth card that is really compatible.

[BarryBar]

3 hours ago, mnfesq said:

I can report that the problem I have with BT is that it is not discoverable once my laptop has woken up from sleep.  The only time my BT works is after a reboot and before the laptop goes to sleep.  

 

I can also report, although it might only be cosmetic, that when I have BluetoolFixup.kext enabled, BT works as described above but the device does not show up in Hackintool under System->Peripherals.  When I disable BluetoolFixup.kext, BT does not work at all (System Information shows that I do not have a BT device) but it does show up in Hackintool.

 

I tried purchasing a BT/Wifi combo card with the chipset that Slice suggested but I found that the BT device would connect for a couple seconds and then disconnect and then reconnect for a couple seconds and so forth.  It was very annoying and not tolerable.  I may try another BT/Wifi Combo card.

This I recognize very much. It is not possible to switch on Bluetooth only a reboot helped. In the posted Github page however I found this command "sudo killall -9 BlueTool bluetoothd" that restarts Bluetooth without reboot.

[deeveedee]

@Niko NDP Did you ever figure out why your OC version is reported at 0.7.7?  If not, is it possible that you did not upgrade OC binaries EFI/OC/OpenCore.efi and EFI/OC/Drivers/OpenRuntime.efi?

[Niko NDP]

13 ore fa, deeveedee ha scritto:

@Niko NDP Hai mai capito perché la tua versione OC è riportata alla 0.7.7? In caso contrario, è possibile che tu non abbia aggiornato i binari OC EFI/OC/OpenCore.efi e EFI/OC/Drivers/OpenRuntime.efi?

 

@deeveedee no, i can't figure out why. Everything has been updated but still reports OC version 0.7.7.

 

 

🤷‍♂️

 

[vanquybn]

On 5/22/2023 at 5:24 PM, t2m said:

Can you check the config.plist? it should look like this

 

 <key>bluetoothExternalDongleFailed</key>
 <data>AA==</data>
 <key>bluetoothInternalControllerInfo</key>
 <data>AAAAAAAAAAAAAAAAAAA=</data>

 

Confirmed, this work for me: 13.4

[Niko NDP]

36 minutes ago, vanquybn said:

Confirmed, this work for me: 13.4

 

@vanquybn please could you attach your EFI? Thank you.

[deeveedee]

3 hours ago, Niko NDP said:

@deeveedee no, i can't figure out why. Everything has been updated but still reports OC version 0.7.7.

 

 

Maybe this?

 

EDIT: @Niko NDP and maybe this?

Edited May 26, 2023 by deeveedee

[Niko NDP]

On 5/26/2023 at 1:56 PM, deeveedee said:

 

Maybe this?

 

EDIT: @Niko NDP and maybe this?

 

@deeveedee Small step forward at least for the version of OC shown in Hackintool.
A known issue solved by clearing NVRAM or more selectively :

sudo nvram -d 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version

e così finalmente:

[deeveedee]

@Niko NDP Very interesting.  I haven't seen the need for that before.  Could that be an indicator that your hack's NVRAM isn't working as it should?  I'm definitely not the expert on NVRAM, since I've only experience two cases: on very old legacy hacks that require NVRAM emulation and modern hacks where NVRAM worked well and required no NVRAM emulation.  The NVRAM keys that we're inserting to fix this bluetooth issue may not be properly available in your hack because of a problem with NVRAM.  Maybe that's what is preventing this Bluetooth fix from helping you?

 

When you execute 'nvram -p' (in terminal) on your hack, do you see the bluetooth keys

Edited May 28, 2023 by deeveedee

[Niko NDP]

10 hours ago, deeveedee said:

@Niko NDP Very interesting.  I haven't seen the need for that before.  Could that be an indicator that your hack's NVRAM isn't working as it should?  I'm definitely not the expert on NVRAM, since I've only experience two cases: on very old legacy hacks that require NVRAM emulation and modern hacks where NVRAM worked well and required no NVRAM emulation.  The NVRAM keys that we're inserting to fix this bluetooth issue may not be properly available in your hack because of a problem with NVRAM.  Maybe that's what is preventing this Bluetooth fix from helping you?

 

When you execute 'nvram -p' (in terminal) on your hack, do you see the bluetooth keys

 

@deeveedee I believe the problem is really related to the reset from NVRAM. In fact, although what is indicated in the config.plist is correct, some parameters are not updated:

 

As also results from the nvram -xp command

Since I can't delete all the nvram because it won't let me, I think I have to use the specific command like I did for the OC version: nvram -d (variable name).

I try it and I tell you.

 

[Niko NDP]

Unfortunately nothing, I managed to delete the nvram for bluetoothExternalDongleFailed but it keeps giving me this value:

Edited May 28, 2023 by Niko NDP

[deeveedee]

@Niko NDP Please post your latest config.plist in your current EFI

[Niko NDP]

1 hour ago, deeveedee said:

@Niko NDP Please post your latest config.plist in your current EFI

 

Here it is.

EFI.zip

[deeveedee]

@Niko NDP I added the two new BT keys to NVRAM > Delete in your config.plist (attached).  Does this make any difference for you?  I am not familiar with OC NVRAM tweaks, so if there is something wrong with the way your NVRAM is working, maybe someone else has an idea.

 

config.plist.zip

[Niko NDP]

12 hours ago, deeveedee said:

@Niko NDP I added the two new BT keys to NVRAM > Delete in your config.plist (attached).  Does this make any difference for you?  I am not familiar with OC NVRAM tweaks, so if there is something wrong with the way your NVRAM is working, maybe someone else has an idea.

 

config.plist.zip 6.42 kB · 3 downloads

 

@deeveedee Unfortunately still nothing, the Bluetooth icon has disappeared from the bar. 😕 It still does not work.

[deeveedee]

@Niko NDP After booting with my version of your config.plist, what do you see when you type 'nvram -p' in terminal?

[Niko NDP]

6 hours ago, deeveedee said:

@Niko NDP After booting with my version of your config.plist, what do you see when you type 'nvram -p' in terminal?

 

@deeveedee The same parameters:

 

It also tells me it can't connect to iCloud and I need to reconnect to Apple ID. Very strange!

[deeveedee]

@Niko NDP Your PC is behaving as though you have installed 2 EFIs.  Is it possible that you have 2 drives and you're making EFI changes on one drive, but you're actually booting from the other?  The change I made had nothing to do with iCloud.

Edited May 29, 2023 by deeveedee

[Stefanalmare]

On 5/27/2023 at 10:33 PM, Niko NDP said:

 

@deeveedee Small step forward at least for the version of OC shown in Hackintool.
A known issue solved by clearing NVRAM or more selectively :

sudo nvram -d 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version

e così finalmente:

Used always:

 

[Stefanalmare]

If somebody use Clover and need to insert those values, it can be done in Hakintool -> NVRAM -> (+) sign. I've done that and the bluetooth started without reboot. Kind a strange...... In a laptop running Ventura 13.5 and BCM94352HMB.

[deeveedee]

4 hours ago, Stefanalmare said:

Used always:

 

I've never used it.  It's not in the OC Sample.plist.  When did anyone start using it?

Edited May 29, 2023 by deeveedee

[1Revenger1]

"opencore-version" is set by OpenCore when "ExposeSensitiveData" is set in the config.plist with bit 1 set.
If it is already exists in NVRAM as non-volatile, then it won't be set by OpenCore (since it tries to set it as a volatile value).