Jump to content

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


Niko NDP
 Share

97 posts in this topic

Recommended Posts

@1Revenger1 When I upgrade OC, I always Reset NVRAM before booting macOS with the updated EFI.  I assume this is why I have never needed opencore-version in my config.plist.  Just out of curiosity, why doesn't 'NVRAM > Delete > 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 > opencore-version' appear in OC's Sample.plist?

 

EDIT:  @Niko NDP  claims that resetting NVRAM from the OC picker menu does not clear opencore-version (and thus does not allow OC to update opencore-version on the next boot).  @Niko NDP must specifically clear opencore-version with 

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

Do you have any idea why @Niko NDP 's opencore-version would not clear when using Reset NVRAM in the OC picker menu?

 

Thanks for your help.

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

After applying the before mentioned 2 lines to the NVRAM setting; my Bluetooth started working again. Still my  Microsoft mouse model 3600 would not work; it connected and then de-connected.

 

Now the mouse is again working however. The solution turned out to be to boot with Bluetooth active in the old config.plist in OpenCore (0.9.2) where the lines where NOT added yet. It's my guess how this works since I'm not an IT man. My thought is that it functions like some kind of reset of the Bluetooth module. And Bluetooth is now working like before (maybe better even) without the automatic disconnect of the 3600 MickyMouse 👍😀

 

You can try whether this will work for you too. If you backup your EFI you can always switch to the working EFI/config.plist.

 

 

Link to comment
Share on other sites

@deeveedee

Non-volatile means that it is saved in flash and persists when power is removed. Volatile means that it does not persist between restarts/when power is lost. You may need to reset NVRAM from an older version of OC if you had WriteFlash enabled, since it may have been written to flash. This was changed in Feb 2021 to only ever be volatile.

 

Opencore-version is handled internally within OC, why would it need to be in the Sample.plist? It's only needed if you had WriteFlash enabled in 2021 or earlier.

 

I'm not sure why Reset NVRAM wouldn't clear it. Possibly because it would happen after OC sets the version and other values in the boot process.

  • Thanks 1
Link to comment
Share on other sites

@1Revenger1 Thanks.  I'll continue to leave it out of my config.plists.  I got the wrong impression that adding "NVRAM > Delete > 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 > opencore-version" had become a common practice that I missed.

 

@Niko NDP There's something going on with your NVRAM that I don't understand.  I'm out of guesses.

  • Like 1
Link to comment
Share on other sites

@deeveedee thank you for the great help you give me! At the moment I'm demoralized because I think I've tried all your suggestions but to no avail, I'm probably doing something wrong. I'll try to summarize everything I've tested but at the moment the thing that leaves me in doubt is the answer NVRAM -p gives me:

 

bluetoothInternalControllerInfo    %00%00%00%00%00%00%00%00%00%00%00%00%00%00
bluetoothExternalDongleFailed    %01

 

Where bluetoothExternalDongleFailed I believe must be %00

Link to comment
Share on other sites

@Niko NDP That's why I'm confused.  Your NVRAM is behaving as though it is not working properly.  Don't give up!  I will continue to think about this and let you know if I have any ideas.  Hopefully someone else will have some suggestions, too.

 

EDIT: @Niko NDP I was hoping that someone with more NVRAM knowledge would have a suggestion.  I have a guess, but it is only a guess, since I don't know enough about NVRAM.  I am aware that my guess is contradicts the Dortania guide here, so make sure you perform this test on a bootable USB (not the EFI on your SSD) so that you can easily recover if your hack does not boot.


Create a bootable USB stick with a copy of your EFI and make the following config.plist change on the USB EFI:

  • Booter > Quirks > EnableWriteUnprotector: Change to False
  • Booter > Quirks > RebuildAppleMemoryMap: Change to True

 

After you create a USB stick with this modified EFI/OC/config.plist, boot from the USB stick, Reset NVRAM (choose Reset NVRAM from the OC picker) and then boot macOS.  When you issue the command nvram -p, are your Bluetooth keys correct?

Edited by deeveedee
Link to comment
Share on other sites

6 hours ago, Niko NDP said:

@deeveedee thank you for the great help you give me! At the moment I'm demoralized because I think I've tried all your suggestions but to no avail, I'm probably doing something wrong. I'll try to summarize everything I've tested but at the moment the thing that leaves me in doubt is the answer NVRAM -p gives me:

 

bluetoothInternalControllerInfo    %00%00%00%00%00%00%00%00%00%00%00%00%00%00
bluetoothExternalDongleFailed    %01

 

Where bluetoothExternalDongleFailed I believe must be %00

 

I just bought a new WiFi/Bluetooth card for my laptop - a Dell DW1830 for $20.  It has the 94360 chipset which was supposed to work with macOS 13.x.  After installing it, it did not work.  The device was not recognized.  I reset the NVRAM and then it worked.  But as soon as I rebooted, it stopped working unless I reset the NVRAM every time.  Using NVRAM -p in Terminal, I could see that I was getting "bluetoothExternalDongleFailed 01" instead of "00".  I think that is the situation you are having now.  I was able to fix it using Hackintool.  In the NVRAM tab, I found the bluetoothExternalDongleFailed entry.  I highlighted it and then deleted it.  Without even rebooting, the bluetooth device started working.  It has since worked consistently, even after waking up from sleep.  Along the way, I also added the BrcmNonPatchRAM2.kext but I don't know that it is doing anything.  I will try to remove it and see if it still functions as well.  Hopefully, using Hackintool will help you too.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

EUREKA!!!

Finally here we are!

I'll explain the steps: thanks to @mnfesq's suggestion I manually changed the value of the bluetoothExternalDongleFailed variable in Hackintool from 0x01 to 0x00. Bluetooth activated immediately!

Trying to restart, however, the bluetoothExternalDongleFailed value returned to 01 and here the NVRAM problem recurred.

So I changed some settings:

EDIT:

in Misc -> Boot -> PickerAttributes:  I had 145 and here it says to set 17 and so I did:

 

910058125_Screenshot2023-05-31alle20_13_24.png.bf240b6e6b4287401064db01428f0cb8.png

 

I then tried to figure out where the NVRAM reset was and added in

Misc -> Tools -> CleaNvram.efi  -> FullNvramAccess ->  TRUE

Misc -> Tools -> ResetSystem.efi  -> FullNvramAccess ->  TRUE

 

1583723236_Screenshot2023-05-31alle20_14_15.thumb.png.5aefec35ef9a3f2bc8a45cbbb4e152ba.png

 

And finally the bluetooth works perfectly even restarting! (At least for now 🤣 )
I don't know why for a few reboots it worked, then nothing.
Thanks to @deeveedee who didn't give up and to all those who participated in finding the solution. 🙏

Edited by Niko NDP
  • Like 2
Link to comment
Share on other sites

@Niko NDP Congratulations and thank you for teaching me about those FullNvramAccess options!  I didn't even know they existed.  Great team work!

 

EDIT: I see that FullNvramAccess was added as a tool attribute in OC 0.8.4 with default value of False.  Looks like you discovered a case when setting it to True is necessary.  Great detective work!

 

EDIT2: The most important thing is that you did not give up.  Well done.

Edited by deeveedee
  • Like 2
Link to comment
Share on other sites

@Niko NDP Do your EFI testing on a bootable USB while you keep your baseline EFI on your SSD.  Once you are certain that the updated EFI on the USB is working, copy the USB EFI to your SSD (to become your new baseline).

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

8 hours ago, Niko NDP said:

I sang victory too soon! 😞

 

Now I can't boot due to changing settings in an attempt to fix the problem. 🤦🏻 
 

 

Me too, I guess.  When I updated to macOS 13.5 beta 2, the dongle failed returned to 01.  I had to change it to OO and reboot, then turn on BT and it worked again.  Let's just call this a temporary fix made easier by Hackintool.  As for your settings changes, I hope you keep a USB flash drive with a working bootloader for cases such as this.

  • Like 1
Link to comment
Share on other sites

5 hours ago, deeveedee said:

@Niko NDP Do your EFI testing on a bootable USB while you keep your baseline EFI on your SSD.  Once you are certain that the updated EFI on the USB is working, copy the USB EFI to your SSD (to become your new baseline).

 

Yes yes guys, I know very well! 😂😂 I just messed around like a rookie!

I fixed it right away. 😉

 

However we have centered the problem. Now we need to figure out what sets bluetoothExternalDongleFailed to 01.

I understand that 01 = off and 00 = on

Link to comment
Share on other sites

13 minutes ago, Niko NDP said:

However we have centered the problem. Now we need to figure out what sets bluetoothExternalDongleFailed to 01.

I understand that 01 = off and 00 = on

 

Maybe it's just semantics but 01=True and 00=False.  In other words, when bluetoothExternalDongleFailed is at 01, it is saying that the dongle did in fact fail.  We want it to say that it did not fail.

  • Like 1
Link to comment
Share on other sites

1 hour ago, mnfesq said:

 

Maybe it's just semantics but 01=True and 00=False.  In other words, when bluetoothExternalDongleFailed is at 01, it is saying that the dongle did in fact fail.  We want it to say that it did not fail.

 

Exactly.... but I have no more ideas.

Link to comment
Share on other sites

3 hours ago, Niko NDP said:

 

Exactly.... but I have no more ideas.

 

My thought is that, ideally, we could edit NVRAM to make sure that bluetoothExternalDongleFailed is set to 00 and then lock NVRAM so that nothing can change that.  I'm not sure how that is done but I suspect it can be done. Alternatively, we could try using bluetoothExternalDongleFailed=00 as a boot arg and then it would load on every boot.

 

UPDATE:  I tried the boot arg method and it failed using  . . .Failed=0x00, . . .Failed=0, and . . .Failed=00.  I'm wondering if we could create some type of spoof to make it seem like the BT chip is internal and not a 3rd party dongle (since it's not). What does system information for BT show on a real Mac? I'm sure its not a 3rd party dongle.

 

UPDATE2: On my daughter's Mac, the only difference in the BT system info is the chipset and firmware version.  

 

Her's is:

Chipset: BCM_4364B0

Firmware Version: v122 c4439

 

Mine is:

Chipset: THIRD_PARTY_DONGLE

Firmware Version: v8453 c4518

Edited by mnfesq
Link to comment
Share on other sites

47 minutes ago, deeveedee said:

@mnfesq I think that @Niko NDP has an NVRAM problem.  Do you both have the same motherboard?  Does my suggestion here work for you?

 

I have the same problems as @Niko NDP.  We do not appear to have the same motherboard.  I used your suggestion and, without that, I wouldn't have gotten to first base.  Now the problem is that the bluetoothExternalDongleFailed=00 setting in my config.plist does not stay put in my NVRAM and instead changes from 00 to 01 on its own.  That's what we're trying to deal with now.  I wouldn't have had any luck at all had I not added the two NVRAM settings you suggested.

Link to comment
Share on other sites

@mnfesq As an experiment, you may want to try emulating NVRAM.  OpenCore has the hooks built-in for emulated NVRAM.  Once configured, your hack will work exactly as before (but with emulated NVRAM instead of your motherboard's NVRAM).  It would be interesting to see if emulated NVRAM fixes the problem.

Link to comment
Share on other sites

21 hours ago, mnfesq said:

 

My thought is that, ideally, we could edit NVRAM to make sure that bluetoothExternalDongleFailed is set to 00 and then lock NVRAM so that nothing can change that.  I'm not sure how that is done but I suspect it can be done. Alternatively, we could try using bluetoothExternalDongleFailed=00 as a boot arg and then it would load on every boot.

 

UPDATE:  I tried the boot arg method and it failed using  . . .Failed=0x00, . . .Failed=0, and . . .Failed=00.  I'm wondering if we could create some type of spoof to make it seem like the BT chip is internal and not a 3rd party dongle (since it's not). What does system information for BT show on a real Mac? I'm sure its not a 3rd party dongle.

 

UPDATE2: On my daughter's Mac, the only difference in the BT system info is the chipset and firmware version.  

 

Her's is:

Chipset: BCM_4364B0

Firmware Version: v122 c4439

 

Mine is:

Chipset: THIRD_PARTY_DONGLE

Firmware Version: v8453 c4518

 

For me:
Chipset:    BCM_4350C2
Versione firmware:    v0 c0

 

The problem I think is not caused by the NVRAM but by something that sets or changes the bluetoothExternalDongleFailed setting from 00 to 01, which I cannot figure out.

Link to comment
Share on other sites

Another small observation: I tried to remove the string from the config.plist

bluetoothExternalDongleFailed  DATA 00

Opening Hackintool the string is in its place with 01.

What does this string produce?

Link to comment
Share on other sites

On 5/24/2023 at 3:58 PM, BarryBar said:

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.

 

In Ventura 13.4, I found that I could only turn Bluetooth on and off once before requiring a reboot.  If I turned on Bluetooth and then turned it off, Bluetooth would not work again until I rebooted.  Executing this (in terminal) allows me to turn Bluetooth on again after I turn it off.

sudo pkill bluetoothd

EDIT: My SMBIOS model is MBP6,2.  My Wi-Fi/Bluetooth device is BCM94352HMB.

 

EDIT2: This is a summary of the Bluetooth solution that is working for me in Ventura 13.4:

 

EDIT3: With BrcmPatchRAM 2.6.7 package (including updated BlueToolFixup.kext), I no longer need to kill bluetoothd before turning Bluetooth back on.

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

@deeveedee I tried all your solutions but it doesn't bring me any positive result. I activate bluetooth by changing the 00 to 01 from Hackintool. But I must say that a strange thing has already happened to me a couple of times: in a totally random way, when I turned on the PC, I found bluetooth active. I really don't know why. I hadn't changed the settings.

Link to comment
Share on other sites

@Niko NDP My summary didn't offer anything that wasn't already discussed in this thread, so I'm not surprised that it still doesn't work for you.  If I think of anything new, I'll post again here.  Glad that you're still remaining patient and persistent.  If you have time, I think it's worth your time to implement NVRAM emulation to rule out an NVRAM problem.

  • Like 1
Link to comment
Share on other sites

@deeveedee I'm someone who doesn't give up and in my part they say "it takes time, said the water to the rock, but in the end I'll pierce you". 😄

I think I found the solution that works.

Searching around, I found someone more experienced and capable than me who found the solution: the BlueToolFixup.kext version 2.6.7 has been modified, the author is

https://github.com/zxystd

I then replaced the kext and tried booting and rebooting, bluetooth works perfectly.

I invite @mnfesq and everyone else to try it and let us know if it works for him too.

I attach the .kext that works and thank you so much zxystd.

BlueToolFixup.kext.zip

Edited by Niko NDP
  • Like 1
  • Thanks 3
Link to comment
Share on other sites

 Share

×
×
  • Create New...