Pierre C.

@Hervé, I'm happy to report that using a FL1100-based card it works OOTB, no kext needed. So it was indeed the Renesas chipset that was problematic, or the driver.

Yes, I understood that. What I meant is: if the BT controller of the Airport card is correctly registering and visible in IOReg, then, IMHO it would suggest that it gets enough power.

OK, so, I just bought an Inateck FL1100-based card. Apparently, this particular chipset is supported OOTB since Mountain Lion. We'll see if that's better.

BUT, as I need a low profile pci-e card for my case, the only model I found with this chipset that has all the needed characteristics (USB3 header, low profile, right chipset, ...) is still self-powered. So let's hope it's not a matter of power...

But, if that was the case (not enough power), don't you think it would not show up as an identified component in ioreg as well as System Profiler?

Are you talking about the Airport card or the USB controller card? If it's the latter, I unfortunately didn't find an existing thread specifically about connecting an airport card via an external pci-e USB controller. That would be ideal 

Good to know. In any case I'm at a loss now. Both drivers work but macOS is still unable to link to the BT controller. I need to find a way to pinpoint the origin of the problem, naming or otherwise, before implementing a solution  I'm sure it's solvable.

 

 

Here is the two drivers compared side by side. GenericUSBXHCI.kext on the left, mXHCD.kext on the right.

I think mXHCD.kext is working best since:

- it has more metadata attached to the device: usbUserClientEntitlement = com.apple.bluetooth.control, for example,

- it reports correctly the new bus and its devices in System Information

 

... still no BT though

 

OK @Hervé, I cached the generic USB3.0 kext and I get the following result in IOReg. The BT controller is shown under RP07 but at at different locationID. Bluetooth is still not recognized by MacOS, so I'd say it's the same result as with my other driver don't you think? Any ideas for what to try next  ?

 

Also, as opposed to my previous driver, this time no new distinct usb bus is shown in System Informations. I can only see my internal bus and its devices. What do you think about that?

 

I'll try that and if everything else fails then what I will do is that I'll swap the front panel USB connector and the Airport USB connector: I'll plug the Airport USB directly to the motherboard (which I know works) and the case USB front panel to the pci-e NEC controller card. This will probably work... I guess. The only problem is that I'll have to buy a USB cable extension for the front panel since the integrated cable is too short. 

 

Nonetheless, it would be a very frustrating solution and will not explain the current behavior

Ok, so if I understand correctly, you tested a NEC card with the kext you mentioned before. Is that right? 
Did you also try pluging an Airport card to it?

Here is my zipped clover folder. I just removed the SMBIOS part of the config file beforehand.

CLOVER.zip

 

the exact model of my card is KALEA-INFORMATIQUE © - Carte... https://www.amazon.fr/dp/B01N0XHLNJ?ref=ppx_pop_mob_ap_share

Hi @Hervé. I just tried this driver you suggested. Unfortunately, the card is not recognized with it. Do you know the chipset(s) of the cards you used with it? Maybe they weren't NEC Renesas (NEC µPD720201) based.

 

At this stage, I still believe that everything installed is mostly correct. If it wasn't the Airport card / BT controller wouldn't show under IOReg, like you said.

 

BUT... my guess is still that macOS is unable to "link" to the BT controller of the Airport card for some reason. And the only reason I can think of is some very specific ACPI / USB bus naming convention or something. Maybe it only looks for Airport card on the internal USB bus for example? This is where I'd like your input: did you ever have any success pluging an Airport card on an external bus? And if so, under which bus was it mounted, PXSX also?

Thanks for the suggestion @Bronxteck, unfortunately Hackintool only exports the configuration pertaining to the XHC bus. I checked both generated AML files and nothing about PXSX

Hi all,

I'm using an original Airport BCM943602CS card with a pci-e adapter. Wifi is working great OOTB but not BT.

Since my motherboard only has a single USB3 header connecter that is used for the front USB connectors of the case, I decided to buy a third-party NEC Renesas based PCI-E USB controller, and to connect the BCM943602CS to it via USB (since USB connection is necessary for the BT part). This is the part that is not working correctly : the BT controller is not correctly detected by macOS -> no BT panel.

The current state is the following:
- In System Information, the bluetooth panel is empty
- In System Information, the USB host controller of the Airport card is visible under the second USB 3.0 bus provided by the NEC Renesas card

- In IORegistryExplorer, it is shown that this USB card is mounted under PXSX@0 - which seems logical since PXSX is used for a generic PCIe device. The Broadcom BT controller is show under PXSX@0. BUT, strangely enough, the USB ports of the cards are not named! Each port has a location (0x00500000, 0x00600000, ...) but no name. I looked at my DSDT and, indeed, there are no named port definitions under the PXSX device. As opposed, say, for the XHC device which has multiple named ports in the DSDT.

- In Hackintool, both controllers are shown but only the ports of the main Intel controller are listed (HS01-14, USR1-2, SS01-10) - For testing purpose i'm using USBInjectAll and port-limit disabling hacks. So where are the ports of PXSX?!


So, how is it possible that the BT controller is clearly visible on the secondary USB bus (even in System Information / USB panel) but not detected as such by macOS? Is it because it can only be connected on the primary USB controller/bus?

The Airport card is indeed working and is not the problem: if I plug it directly on the motherboard USB3 header it shows up instantly in macOS and everything is working great. So, clearly, the problems is with the connection through a 3rd party USB controller card.

I'm using the following driver for the NEC USB controller card: https://github.com/chris1111/USB-3.0-NEC. I tried switching it with GenericUSBXHCI.kext to see if this driver handle ports differently, but the card is not even recognized with this one.

At this stage, the only ideas I have are:
- try to add names to PXSX ports - in a patched DSDT I suppose, but I have no idea where to start.
- try to rename PXSX to something else in order to please macOS (XHC0, XHC1 maybe?)

Any suggestion is appreciated. Thanks for your help!

Hi all! I found the solution to my problem. Albeit being very specific to my case, I'm putting the information there in case it's useful to someone else.

 

So, my 'wake to black screen' issue on Catalina 10.15.4 was related to the modified version of acidanthera's BrcmPatchRAM I was using to make my DW1820A work.

These problematic drivers on 10.15.4 were https://osxlatitude.com/forums/topic/12392-solved-7490-catalina-dw1820a-bluetooth-problem/

 

Since they are the only drivers that work correctly with DW1820A today, there is no more readily available / fully-working solution for this particular card on 10.15.4. AFAIK, this modified version of the drivers was loading a more recent FW to the DW1820A than the one still used by the official BrcmPatchRAM.

 

I switched to a new DW1830 card and used the latest official release of acidanthera's BrcmPatchRAM. And now everything is working mostly smoothly: sleep/wake, wifi and bt.

 

So, even if you don't have a DW1820A card, if you have this wake to black screen issue on 10.15.4, it may well be related to your wifi card + driver combo. Make sure to update to the latest version of acidanthera's BrcmPatchRAM.

 

 

Thanks for the suggestion. Unfortunately I’m already using OCQirks and AptioMemoryfix is not installed. 

but weren't you saying you had problem on only one of your machines? Did you see a lot of complaints on the various forums?

Ok, thanks Hervé.... strange for sure

Hi Guys. Anyone else having issues with sleep on 10.15.4? When it wakes from sleep, the screen is either black (but OS is running - it beeps and boops if I press on the keyboard), or desktop is shown but no wifi, bluetooth (DW1820) and everything expect cursor is frozen (impossible to switch windows, ...). It looks like some kexts are not loaded/loading anymore after sleep?

 

I upgraded my fully working Lenovo X250 from a fully working 10.15.3 yesterday and having these issues ever since (Clover 5108, all kexts updated before update, OCQirks 20.1, VirtualSMC-1.1.1).

 

Is there a particular list of things to check when issues concerning sleep arise? Check NVRAM? Kexts?

 

Thanks!

In that case I'm at a loss. It probably looks like interference but is something else.

Ok good! So, then the question is... how to repackage this particular driver into BrcmPatchRAM2. It hasn't been updated in a long time. I know some people have manually done so but it involves a few steps and tools. I think there are forum posts here regarding this very topic. @Hervé can you point @The Riddle in the right direction? It would also interest me in fact

 

... also, when you have 5799 under MacOS, does it solve your problems?

It would be useful to know what is the version when in windows too. Did you do a cold boot (not reboot from windows) when you tested the kexts in L/E? Because c5799 could be the driver loaded onto the card by windows that wasn't flushed out if you did a reboot from windows just before. What I'm getting at is that maybe you have better reception in windows because the version loaded by the windows drivers is more efficient. But to be sure we have to compare versions.

No luck then. Sorry  Do you know if it's the same version of the driver used in windows and macos ? In MacOS it's easy enough to know, you just press option-shift and click on the bt icon in your menubar.

Maybe it will be relevant to your case, not sure : I noticed on my own setup that depending how the relevant kexts are installed, I'll have spotty bluetooth connection or not. On my end, if kexts are injected by Clover at boot then it works great, but if I install them in L/E then it looks like I have interferences. I haven't been able to find why though

absolutely wonderful. Thanks for the help @Hervé. Now I need to understand why this particular version of the kexts works