A working AX201 on latest Monterey does not work on latest Ventura (reports BCM_4350C2)

mackonsti commented 1 year ago

Have you read the docs?

Yes (I have been using your great kext for a long time, now)

macOS Version

Ventura 13.4 (22F66)

Kext Version

v2.2.0

Wireless Adapter Model and USB Product ID

Intel AX201 [8087:0026]

Description

Hello @zxystd @williambj1 one more time, again, many thanks for your great work and continuous effort.

I recently made the jump from Monterey to Ventura, thinking the OS is mature... but I am facing the same early problems reported in #369 but with latest Ventura 13.4 (22F66) where my perfectly working AX201 [8087:0026] reports as being "BCM_4350C2". Originally I thought Hackintool was wrong!

In IORegistry there doesn't seem there's a firmware loaded, string fw_name is empty. USBPorts.kext is long-time created and validated with each new macOS release, the HS10 port is the one where BTLE is usually attached (no change): All needed 2+1 kexts appear loaded and running (via kextstat):

as.acidanthera.BlueToolFixup (2.6.6)
com.zxystd.IntelBluetoothFirmware (2.2.0)
com.zxystd.IntelBTPatcher (2.2.0)

Finally, this is the order in my OpenCore config:

First in OC config: BlueToolFixup.kext Next in OC config: IntelBluetoothFirmware.kext Final in OC config: IntelBTPatcher.kext

Please note: on Monterey it was working very well.

Thank you.

Info in System Report - Bluetooth

Bluetooth Controller:
  Address:  NULL
  State:    Off
  Chipset:  BCM_4350C2
  Discoverable: Off
  Firmware Version: v0 c0
  Supported services:   0x382039 < HFP AVRCP A2DP HID Braille AACP GATT SerialPort >
  Transport:    USB
  Vendor ID:    0x004C (Apple)

System Information > USB > USB 3.1 Bus > Bluetooth USB Host Controller

Bluetooth USB Host Controller:

  Product ID:   0x0026
  Vendor ID:    0x8087  (Intel Corporation)
  Version:  0.02
  Speed:    Up to 12 Mb/s
  Location ID:  0x14600000 / 1
  Current Available (mA):   500
  Current Required (mA):    100
  Extra Operating Current (mA): 0
  Built-In: Yes

Relevant log output

% sudo dmesg | grep -i IntelBluetooth

[    1.004774]: IOUSBHostDevice@14600000: IOUSBHostDevice::setConfigurationGated: IntelBluetoothFirmware selected configuration 1

% sudo dmesg | grep -I IntelFirmware

[    1.004725]: IntelFirmware: Driver init()
[    1.004730]: IntelFirmware: Driver Probe()
[    1.004733]: IntelFirmware: name=IOUSBHostDevice, class=IOService, vendorID=0x8087, productID=0x0026
[    1.004739]: IntelFirmware: Driver Start()
[    1.004753]: IntelFirmware: virtual bool BtIntel::initWithDevice(IOService *, IOUSBHostDevice *)
[    1.004756]: IntelFirmware: virtual bool USBDeviceController::init(IOService *, IOUSBHostDevice *)
[    1.004762]: IntelFirmware: virtual bool USBDeviceController::initConfiguration()
[    1.004765]: IntelFirmware: set configuration to 1
[    1.005164]: IntelFirmware: virtual bool USBDeviceController::findInterface()
[    1.005169]: IntelFirmware: Found interface!!!
[    1.005179]: IntelFirmware: virtual bool USBDeviceController::findPipes()
[    1.005181]: IntelFirmware: Found Interrupt endpoint!
[    1.005385]: IntelFirmware: Found Bulk out endpoint!
[    1.005571]: IntelFirmware: Found Bulk in endpoint!
[    1.005752]: IntelFirmware: BT init succeed
[    1.007198]: IntelFirmware: Read the legacy Intel version information
[    1.007201]: IntelFirmware: Firmware revision 0.0 build 111 week 53 2019
[    1.007206]: IntelFirmware: Frimware is already running, finishing
[    1.008194]: IntelFirmware: Clean up...
[    1.008197]: IntelFirmware: virtual void BtIntel::free()
[    1.008198]: IntelFirmware: virtual void USBDeviceController::free()

Kernel Panic Logs

No kernel panic, thankfully.

HieuNVDSgit commented 1 year ago

I remap usb port and bluetooth working on Ventura but after that i faced new problem:

I can't connect to my iPhone via Bluetooth (only success connect with my Android TV, Pixel3XL Phone and Bluetooth BLE Mouse)
Bluetooth is ON and connected but Discoverable still in OFF state (System Report)

mackonsti commented 1 year ago

Hi @HieuNVDSgit how do you "remap" the USB?

Because my hardware on Monterey in my case used USB10 port, on Ventura I do not know why it should or would change... There is no option in the Intel Visual BIOS of my NUC to do such mapping or attempts.

Are you using OpenCore? What is the sequence/order of loading the kexts, in your config, please?

But I see that you, too, get the wrong IDs being reported, just like me. It says Apple as vendor, not sure this is expected @zxystd and @williambj1 ? Even Hackintool reports "Apple" as vendor on Ventura, not the case on Monterey... Thanks in advance for your input.

zxystd commented 1 year ago

@mackonsti Fimware driver is working well, from the ioreg I don't see the bluetoothd process was attached, so it is probably a bluetoothd related problem. You can try my fork . https://github.com/zxystd/BrcmPatchRAM

zxystd commented 1 year ago

@HieuNVDSgit

I can't connect to my iPhone via Bluetooth (only success connect with my Android TV, Pixel3XL Phone and Bluetooth BLE Mouse)

You can use Google or Apple forums to get the answer.

Bluetooth is ON and connected but Discoverable still in OFF state (System Report)

Keep open the bluetooth search panel, it will display as ON.

I think you need to Google or experience a real mac first before asking questions.

mackonsti commented 1 year ago

@mackonsti Fimware driver is working well, from the ioreg I don't see the bluetoothd process was attached, so it is probably a bluetoothd related problem. You can try my fork . https://github.com/zxystd/BrcmPatchRAM

Thank you @zxystd for your kind assistance. Your fork points to BrcmPatchRAM so which component do you advise me to use? Isn't this for Broadcom? 😬

Do you require further logs from my system? You say that bluetoothd process was not attached, perhaps some further logs can provide a reason? What kext is responsible for this process to be attached, please? (so that I can check)

非常感谢！

zxystd commented 1 year ago

Thank you @zxystd for your kind assistance. Your fork points to BrcmPatchRAM so which component do you advise me to use? Isn't this for Broadcom? 😬

only replace the bluetoolfixup.kext

Do you require further logs from my system? You say that bluetoothd process was not attached, perhaps some further logs can provide a reason? What kext is responsible for this process to be attached, please? (so that I can check)

log show --last boot | grep bluetooth>log.log

mackonsti commented 1 year ago

Hello @zxystd for the sake of your information and in case someone else reads here, here is what I did and achieved after your suggestion.

In my OpenCore configuration, per ticket #435 I added the 2 new NVRAM keys:
```
<key>bluetoothExternalDongleFailed</key>
<data>AA==</data>
<key>bluetoothInternalControllerInfo</key>
<data>AAAAAAAAAAAAAAAAAAA=</data>
```
...in config section NVRAM → Add → 7C436110-AB2A-4BBB-A880-FE41995C9F82

I rebooted whilst having installed the latest official stable BlueToolFixup.kext 2.6.7 and I realized the BTLE of AX201 was now detected as THIRD_PARTY_DONGLE. It could detect and connect to my Original (v1) AirPods, but I had 2 issues:

a) could not turn ON the Bluetooth after I turned it OFF. b) somehow, some frequent refresh of the BTLE module made the AirPods disconnect, like some kind of connection reset. It was obvious during music playback (e.g. MP3).

As I don't have Xcode installed (was a clean installation) thankfully I used the Actions found on your repository and was able to get the "Artifacts" zip file of your latest commit Remove unused patch, it is replaced by searchAndPatchWithMask code from which I extracted BlueToolFixup.kext and replaced the recent released one (i.e. 2.6.7 from acidanthera/BrcmPatchRAM )

Rebooted. This time:

a) I coud well turn OFF and then back ON the Bluetooth, the Magic Mouse could reconnect automatically soon after ✅ b) For using audio playback, it seems that a song played well up to 1 minute, then AirPods disconnected again... 🛑 c) An old Magic Mouse 2 that I could connect, seems to keep working fine, no apparent disconnections ✅

P.S. I did not change my OpenCore loading order of the kexts, it's still in this order:

BlueToolFixup.kext
IntelBluetoothFirmware.kext
IntelBTPatcher.kext

System Information > Hardware > Bluetooth

  Bluetooth Controller:
    Address:        <removed>
    State:          On
    Chipset:        THIRD_PARTY_DONGLE
    Discoverable:       Off
    Firmware Version:   v256 c256
    Supported services: 0x382039 < HFP AVRCP A2DP HID Braille AACP GATT SerialPort >
    Transport:      USB
    Vendor ID:      0x004C (Apple)
  Connected:
    Original AirPods:
        Address:        <removed>
        Vendor ID:      0x004C
        Product ID:     0x2002
        Left Battery Level: 100%
        Right Battery Level:    87%
        Firmware Version:   6.8.8
        Minor Type:     Headphones
        RSSI:           -66
        Serial Number:      <removed>
        Services:       0x880019 < HFP AVRCP A2DP AACP ACL >
      White Magic Mouse:
        Address:        <removed>
        Vendor ID:      0x004C
        Product ID:     0x0269
        Firmware Version:   1.0.7
        Minor Type:     Mouse
        RSSI:           -41
        Services:       0x800020 < HID ACL >
  Not Connected:
    My iPhone:
        Address:        <removed>
        RSSI:           -57

A few questions with yes/no answers, to help you quickly reply (when you have the time) so we can learn from you, please? 🙏

a) Is the above kext order OK for OC config? Do you have a better/correct order to suggest?

b) Do we need to add bluetoothExternalDongleFailed and bluetoothInternalControllerInfo in the NVRAM config, if we use your patched BlueToolFixup.kext ?

c) Is this working fix a workaround for Ventura or a permanent fix? I mean, are we now always getting THIRD_PARTY_DONGLE solution shown? (we need to see Ventura 13.5....)

d) Is the solution to try to "fool" i.e. fake macOS Ventura thinking that we're using an external USB BTLE stick instead or treating is as an internal device now? (→ meaning good USB mapping!)

e) I saw that you suggested your fixes in the main repository of BrcmPatchRAM. Any idea of they are going to be merged and officially used, for a next acidanthera version? Or we should keep using your BlueToolFixup.kext ?

Thank you very much for spending time on this.

ax201_konsti.log.zip

P.S. After searching more, I realized there are a lot of people here (on your repo) reporting this same issue on Ventura; perhaps it makes sense to have a mention/reference on your main README.md for this problem, and inform people of the steps; let me know if I can help write it with you, I'd be happy to do this.

Xie Xie

HieuNVDSgit commented 1 year ago

Hi @HieuNVDSgit how do you "remap" the USB?

Because my hardware on Monterey in my case used USB10 port, on Ventura I do not know why it should or would change... There is no option in the Intel Visual BIOS of my NUC to do such mapping or attempts.

Are you using OpenCore? What is the sequence/order of loading the kexts, in your config, please?

But I see that you, too, get the wrong IDs being reported, just like me. It says Apple as vendor, not sure this is expected @zxystd and @williambj1 ? Even Hackintool reports "Apple" as vendor on Ventura, not the case on Monterey... Thanks in advance for your input.

I was remap usb with usbtoolbox in Windows:

Delete detected data;
Change Setting to Use native classes and disable Blind companions
Map all USB2 port to 0 and all companions of it (USB3) to 3
Map Bluetooth and Webcam port to internal (255)
Build USBMap.kext and update to OC Kernel (remove USBToolbox.kext if exist, no need to use in case Native classes enabled)

I'm using OC 0.9.3 and my order of kext loading is:

Bluetoolfixup.kext
IntelBluetoothFirmware.kext
IntelBTpatcher.kext but I think it's not important, I tried to change this order many time but no affect (with my Intel card)

zxystd commented 1 year ago

@mackonsti

a) Is the above kext order OK for OC config? Do you have a better/correct order to suggest?

The functions are not related to the loading order.

b) Do we need to add bluetoothExternalDongleFailed and bluetoothInternalControllerInfo in the NVRAM config, if we use your patched BlueToolFixup.kext ?

it is not needed, but you can add them, perhaps.

c) Is this working fix a workaround for Ventura or a permanent fix? I mean, are we now always getting THIRD_PARTY_DONGLE solution shown? (we need to see Ventura 13.5....)

every USB transport type of bluetooth are THIRD_PARTY_DONGLE, don't be mind.

d) Is the solution to try to "fool" i.e. fake macOS Ventura thinking that we're using an external USB BTLE stick instead or treating is as an internal device now? (→ meaning good USB mapping!)

No, we need to handle more things since bluetoothd sends much Vendor Specific commands to the bluetooth, which make things more complicated.

e) I saw that you suggested your fixes in the main repository of BrcmPatchRAM. Any idea of they are going to be merged and officially used, for a next acidanthera version? Or we should keep using your BlueToolFixup.kext ?

Now the two patches are already merged into official BrcmPatchRAM repo, you can use them. https://github.com/acidanthera/BrcmPatchRAM/commit/82031e48dfe6c3ab14dbc0263ec1a7632d28d06e and https://github.com/acidanthera/BrcmPatchRAM/commit/4a1a9601b0e8a6e9499a9317a5f690178d7279cd

Thank you very much for spending time on this.

ax201_konsti.log.zip

P.S. After searching more, I realized there are a lot of people here (on your repo) reporting this same issue on Ventura; perhaps it makes sense to have a mention/reference on your main README.md for this problem, and inform people of the steps; let me know if I can help write it with you, I'd be happy to do this.

I think the problems will disappear after they upgrade BlueToolFixup.kext to the version v2.6.8, and this is what the BlueToolFixup.kext should do, not this repo.

thx.

mackonsti commented 1 year ago

Again, thank you @zxystd for your time and comments. All was very clear.

A final question: The audio playback that gets disconnected after approx. 1 minute, you think that it has chances to be resolved? I can try tomorrow a BT speaker, but old 1st generation AirPods seem to have this problem.

As you say, this repo deals with loading Firmware to BTLE for Intel, so perhaps indeed for this audio disconnection issue, the new BlueToolFixup.kext can fix things 🙏

OpenIntelWireless / IntelBluetoothFirmware