Jump to content

Broadcom Bluetooth 20702A


Xeon3D
 Share

123 posts in this topic

Recommended Posts

clover patch

Find 4885C074 5C0FB748 

Replace 41BE0F00 0000EB59 

 

That's the Yosemite handoff patch.  This is supposed to be the El Cap DP1 patch:

 

http://www.insanelymac.com/forum/topic/292542-airport-pcie-half-mini/?p=2143521

 

I say "supposed to be" only because it didn't work for me.  That doesn't mean it doesn't work at all.

Link to comment
Share on other sites

That's the Yosemite handoff patch.  This is supposed to be the El Cap DP1 patch:

 

http://www.insanelymac.com/forum/topic/292542-airport-pcie-half-mini/?p=2143521

 

I say "supposed to be" only because it didn't work for me.  That doesn't mean it doesn't work at all.

 

In 10.11 DP1, Broadcom 20702A only works if you rollback IOBluetoothFamily to 10.10.x, that's why if you want to enable handoff, you need to use the patch for 10.10.x too.

 

I used IOBluetoothFamily 10.10.4 and the patch for 10.10.3 works well.

Link to comment
Share on other sites

I just figure out that in 10.11, the IOProviderClass  has changed from IOUSBDevice (in 10.10-) to IOUSBHostDevice. So if you are using an injector kext, make sure you make the change.

 

Or you can use this injector kext. Make sure you're using 10.11 vanilla IOBluetoothFamily kext, not the one from the link in post above.

WifiInjector10.11.kext.zip

  • Like 3
Link to comment
Share on other sites

I just figure out that in 10.11, the IOProviderClass  has changed from IOUSBDevice (in 10.10-) to IOUSBHostDevice. So if you are using an injector kext, make sure you make the change.

 

Or you can use this injector kext. Make sure you're using 10.11 vanilla IOBluetoothFamily kext, not the one from the link in post above.

When using vanilla IOBluetoothFamily.kext, bluetooth is not available

Link to comment
Share on other sites

Tried latest version but firmware is not loaded. I installed the kext in S/L/E

Open Info.plist inside the kext, search for IOUSBFamily, then change it to IOUSBHostFamily. It does not work for BrcmPatchRAM, but may work for BTFirmwareUploader.

Link to comment
Share on other sites

Hey Guys, i own a HP 2570p with 20702A3 ( 0A5C; 21E1). Got BT working by injecting ID's to IOBluetoothFamily/BroadcomBluetoothHostControllerUSBTransport

The Handoff-Fix from lisai9093 worked perfectly for me  (IOBluetoothFamily; Find: 4885FF7447488B07; Replace: 41BE0F000000EB44)

 

My Problem is, that after wake up from sleep Bluetooth doesn't get recognized anymore. Wanted to try to upload a new Firmware, but no luck with BTFirmwareUploader/BrcmPatchRAM. First move to get the Patch even work was, to change IOUSBDevice to IOUSBHostDevice, but then i get this Error:

Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: Broadcom Standalone Bluetooth controller found
Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: ProductID 0x21e1, VendorID 0xa5c
Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: Provider isn't a USB device!!!
Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: Failed to initialize the device.

Changing IOUSBFamily to IOUSBHostFamily results this, so i assume to leave it with IOUSBFamily is ok.
 

BTFirmwareUploader.kext - no compatible dependency found for com.apple.iokit.IOUSBHostFamily.
BTFirmwareUploader.kext is missing dependencies (including anyway; dependencies may be available from elsewhere)
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BTFirmwareUploader.kext
BTFirmwareUploader.kext - no compatible dependency found for com.apple.iokit.IOUSBHostFamily.
Prelink failed for org.emlydinesh.driver.BTFirmwareUploader; omitting from prelinked kernel.
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/BTFirmwareUploader.kext"
/System/Library/Extensions/BTFirmwareUploader.kext - no compatible dependency found for com.apple.iokit.IOUSBHostFamily.
Can't load /System/Library/Extensions/BTFirmwareUploader.kext - failed to resolve dependencies.
Load org.emlydinesh.driver.BTFirmwareUploader failed; removing personalities from kernel.

any other method to inject Firmware? or make BTFirmwareUploader work? 

Link to comment
Share on other sites

Hey Guys, i own a HP 2570p with 20702A3 ( 0A5C; 21E1). Got BT working by injecting ID's to IOBluetoothFamily/BroadcomBluetoothHostControllerUSBTransport

The Handoff-Fix from lisai9093 worked perfectly for me  (IOBluetoothFamily; Find: 4885FF7447488B07; Replace: 41BE0F000000EB44)

 

My Problem is, that after wake up from sleep Bluetooth doesn't get recognized anymore. Wanted to try to upload a new Firmware, but no luck with BTFirmwareUploader/BrcmPatchRAM. First move to get the Patch even work was, to change IOUSBDevice to IOUSBHostDevice, but then i get this Error:

Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: Broadcom Standalone Bluetooth controller found
Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: ProductID 0x21e1, VendorID 0xa5c
Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: Provider isn't a USB device!!!
Jun 14 14:33:10 localhost kernel[0]: BTFirmwareUploader :: Failed to initialize the device.

Changing IOUSBFamily to IOUSBHostFamily results this, so i assume to leave it with IOUSBFamily is ok.

 

BTFirmwareUploader.kext - no compatible dependency found for com.apple.iokit.IOUSBHostFamily.
BTFirmwareUploader.kext is missing dependencies (including anyway; dependencies may be available from elsewhere)
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BTFirmwareUploader.kext
BTFirmwareUploader.kext - no compatible dependency found for com.apple.iokit.IOUSBHostFamily.
Prelink failed for org.emlydinesh.driver.BTFirmwareUploader; omitting from prelinked kernel.
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/BTFirmwareUploader.kext"
/System/Library/Extensions/BTFirmwareUploader.kext - no compatible dependency found for com.apple.iokit.IOUSBHostFamily.
Can't load /System/Library/Extensions/BTFirmwareUploader.kext - failed to resolve dependencies.
Load org.emlydinesh.driver.BTFirmwareUploader failed; removing personalities from kernel.

any other method to inject Firmware? or make BTFirmwareUploader work? 

 

You have to change ONLY IOUSBDevice in IOProviderClass, do not change anything else, or it will break.

 

  • Like 1
Link to comment
Share on other sites

I just figure out that in 10.11, the IOProviderClass  has changed from IOUSBDevice (in 10.10-) to IOUSBHostDevice. So if you are using an injector kext, make sure you make the change.

 

Or you can use this injector kext. Make sure you're using 10.11 vanilla IOBluetoothFamily kext, not the one from the link in post above.

 

 

I couldn't get the Bluetooth Device to get recognized.  I changed USBDevice to USBHostDevice for my BT device (PID 21E3 VID 0A5C) and added the PID/VID in decimal to the info.plist for my BT device.  I tried to do it in 3 different injector kexts.  I am able to get BT working (but not continuity/handoff) by rolling back to 10.10 kext and using BTFirmwareUploader.  

 

On a separate note, I cannot get my wifi to use the AirPortBrcm4360.kext.  It will only load with the AirPortBrcm4331.kext.  If I try to patch my DSDT or use any other method to force wifi to load the 4360 kext, I get a KP with the 4360 kext as the sole kext in backtrace.

 

Any ideas?

 

EDIT:  I revised my DSDT so that instead of having the Vendor/Device 14e4,432b (which is its native ID's) it has 14e4,4353.  Now, I can boot with that DSDT in Yosemite and El Cap but, in Yosemite, that causes me to load the 4360 kext, and in El Cap, it loads the 4331 kext.  I cannot figure out how to force it to load the 4360 kext or what is stopping that.  Again, I'm thinking it's a whitelist issue.  Shouldn't there be a way in Clover to get around that?

Link to comment
Share on other sites

cannot figure out how to force it to load the 4360 kext or what is stopping that.

4353 is in both kexts and whitelisted.  Try pci14e4,43a0 for AirPortBrcm4360.kext.  Suggest "compatible" dsdt property injection.

Link to comment
Share on other sites

4353 is in both kexts and whitelisted.  Try pci14e4,43a0 for AirPortBrcm4360.kext.  Suggest "compatible" dsdt property injection.

 

So pci14e4,43a0 works fine in Yosemite and uses the AirPortBrcm4360.kext.  In El Cap, I get a kernel panic with the 4360 kext in the backtrace.

 

Here's my DSDT patch for wifi:

                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x12)
                        {
                            "AAPL,slot-name", 
                            Buffer (0x08)
                            {
                                "AirPort"
                            }, 
                            "device-id", 
                            Unicode ("*"), 
                            "device_type", 
                            Buffer (0x08)
                            {
                                "AirPort"
                            }, 
                            "model", 
                            Buffer (0x2E)
                            {
                                "Broadcom 802.11 b/g/n Wireless LAN Controller"
                            }, 
                            "subsystem-id", 
                            Buffer (0x04)
                            {
                                0x2B, 0x43, 0x00, 0x00
                            }, 
                            "subsystem-vendor-id", 
                            Buffer (0x04)
                            {
                                0xE4, 0x14, 0x00, 0x00
                            }, 
                            "compatible", 
                            Buffer (0x0D)
                            {
                                "pci14e4,43a0"
                            }, 
                            "IOName", 
                            Buffer (0x0D)
                            {
                                "pci14e4,43a0"
                            }, 
                            "name", 
                            Buffer (0x0D)
                            {
                                "pci14e4,43a0"
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }

I'll probably switch back to 4353 until I can figure this out so that I can use the same DSDT for Yosemite and El Cap.

Link to comment
Share on other sites

So pci14e4,43a0 works fine in Yosemite and uses the AirPortBrcm4360.kext.  In El Cap, I get a kernel panic with the 4360 kext in the backtrace.

 

Here's my DSDT patch for wifi:

                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x12)
                        {
                            "AAPL,slot-name", 
                            Buffer (0x08)
                            {
                                "AirPort"
                            }, 
                            "device-id", 
                            Unicode ("*"), 
                            "device_type", 
                            Buffer (0x08)
                            {
                                "AirPort"
                            }, 
                            "model", 
                            Buffer (0x2E)
                            {
                                "Broadcom 802.11 b/g/n Wireless LAN Controller"
                            }, 
                            "subsystem-id", 
                            Buffer (0x04)
                            {
                                0x2B, 0x43, 0x00, 0x00
                            }, 
                            "subsystem-vendor-id", 
                            Buffer (0x04)
                            {
                                0xE4, 0x14, 0x00, 0x00
                            }, 
                            "compatible", 
                            Buffer (0x0D)
                            {
                                "pci14e4,43a0"
                            }, 
                            "IOName", 
                            Buffer (0x0D)
                            {
                                "pci14e4,43a0"
                            }, 
                            "name", 
                            Buffer (0x0D)
                            {
                                "pci14e4,43a0"
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }

I'll probably switch back to 4353 until I can figure this out so that I can use the same DSDT for Yosemite and El Cap.

I can get my 4352 14E4, 43B1 work with BCM4360 kext.

 

If normal DSDT injection does not work, you should try installing both FakePCIID.kext + FakePCIID_BCM94352Z_as_BCM94360CS2.kext.

Link to comment
Share on other sites

I just figure out that in 10.11, the IOProviderClass  has changed from IOUSBDevice (in 10.10-) to IOUSBHostDevice. So if you are using an injector kext, make sure you make the change.

 

Or you can use this injector kext. Make sure you're using 10.11 vanilla IOBluetoothFamily kext, not the one from the link in post above.

Confirmed working on modified BTFirmwareUploader.kext. I changed the corresponding IOProviderClass in BluetoothDevInfoInjector.kext. So there is no need to change the original IOBluetoothFamily.kext.

Link to comment
Share on other sites

I just figure out that in 10.11, the IOProviderClass  has changed from IOUSBDevice (in 10.10-) to IOUSBHostDevice. So if you are using an injector kext, make sure you make the change.

 

Or you can use this injector kext. Make sure you're using 10.11 vanilla IOBluetoothFamily kext, not the one from the link in post above.

 

Nice find. Do you happen to know what changed with AppleAHCIDiskDriver? I use an injector kext that changes the protocol characteristics in AppleAHCIDiskDriver and it no longer works in 10.11. It seems that some IO classes related to AppleAHCIPort have changed, but I'm not sure which ones.

Link to comment
Share on other sites

Nice find. Do you happen to know what changed with AppleAHCIDiskDriver? I use an injector kext that changes the protocol characteristics in AppleAHCIDiskDriver and it no longer works in 10.11. It seems that some IO classes related to AppleAHCIPort have changed, but I'm not sure which ones.

Please give me your current injector kext.

Link to comment
Share on other sites

 Share

×
×
  • Create New...