Jump to content

Pierre C.

Members
  • Posts

    26
  • Joined

  • Last visited

Pierre C.'s Achievements

Corporal

Corporal (4/17)

1

Reputation

  1. @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.
  2. 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.
  3. 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...
  4. 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?
  5. 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
  6. 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.
  7. 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
  8. 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?
  9. 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
  10. 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?
  11. 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
  12. 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?
  13. 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
  14. 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!
  15. 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.
×
×
  • Create New...