Precision M6400 High Sierra Botched Upgrade

[griftopia]

Herve BCM92046 is what I got. Which is what I was looking for. You said BCM02046. I was grep-ing for string with 9 and don't find it. Now if they are from the same "family" then I have been schooled.

 

So then I do find "Broadcom2046Family" (no 0 and no 9), however it is on 2 kexts inside IOBluetoothFamily - BroadcomBluetooth20703USBTransport.kext and BroadcomBluetoothHostControllerUSBTransport.kext

 

Assuming I have identified correctly, do I need to patch both kexts? Else I'm sorry but what's obvious to you is not obvious to me.

 

Previously I have patched kexts to make them work and aware of syntax changes, but I was also able to identify kext easily. This time I'm not. Previously it was very obvious because there was only ONE kext that could be it, now there seem to be more than one, and again I'm not sure I'm matching the key in the kext with the card I have because it's not exact.

 

PS - I always appreciate all of you trying to teach me how to fish, but this one time I'm asking if you can just give me the fish.

[griftopia]

Hi Herve,

 

I have confirmed BroadcomBluetoothHostControllerUSBTransport is the correct kext plist to patch. I have done this for my BT on my E6330. However while I see my BT in IOReg and it says "No information available" in System Preferences (different than you don't have BT message). This tells me laptop knows I have BT. However my menu icon still says "No Bluetooth".

 

Can you think of why this may be?

[Bronxteck]

try this one I put together for my dw1550

BRCMInjector.kext.zip

[griftopia]

@Bronxtech, I am going to try replicating and updating following node for my PID / VID - 8158 (33112) / 413C (16700)

 

 

        <key>413c_8143</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.iokit.BroadcomBluetooth20703USBTransport</string>
            <key>CFBundleIdentifier - 2</key>
            <string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string>
            <key>IOClass</key>
            <string>BroadcomBluetooth20703USBTransport</string>
            <key>IOClass - 2</key>
            <string>BroadcomBluetoothHostControllerUSBTransport</string>
            <key>IOProviderClass</key>
            <string>IOUSBHostDevice</string>
            <key>IOProviderClass - 2</key>
            <string>IOUSBHostInterface</string>
            <key>Built-in</key>
            <true/>
            <key>LMPLoggingEnabled</key>
            <true/>
            <key>bConfigurationValue</key>
            <integer>1</integer>
            <key>bInterfaceNumber</key>
            <integer>2</integer>
            <key>idProduct</key>
            <integer>33091</integer>
            <key>idVendor</key>
            <integer>16700</integer>
            <key>Compatible-idProduct</key>
            <integer>16868</integer>
            <key>Compatible-idVendor</key>
            <integer>17201</integer>
            <key>HandoffSupported</key>
            <true/>
            <key>InstantHotSpotSupported</key>
            <true/>
        </dict>
 

 

Appreciate if you can confirm this is the way to go.

 

EDIT : The kext as you gave even without modification did not load from CkO. So I put it in LE and when I rebuild cache, it says kext is not valid and will be omitted. Maybe I need to tweak more things? Like OS to 10.13 from 10.12?

 

If it helps here's output when trying to load kext manually

 

kextload -v BRCMInjector.kext
Requesting load of /Users/griftopia/Downloads/BRCMInjector.kext.
/Users/griftopia/Downloads/BRCMInjector.kext failed to load - (libkern/kext) not privileged; check the system/kernel logs for errors or try kextutil(8).

[Bronxteck]

that's weird since i made it for high sierra on high sierra using xcode 9. i believe i have in in clover/kexts/other. did you also fix the kexts permissions when you ran your rebuild script

[griftopia]

@bronxtech. Yes. chmod, chown, touch then kextcache. No mistake there.

 

However still need to know whenever I can figure out why I get this error, the way for me to modify the plist. If you can please confirm that.

[Bronxteck]

do you have trim enabled?

 I saw a few reports it can cause errors with kexts not loading when running the kextcache rebuild scripts and thats why the scripts need to be run a few times until it comes up with no error. how true that is I dont know as I have not had that issue. might only affect APFS with trim enabled machines but also I am not sure. that might need further looking into.

 

 yes you can try replacing with your id's.

[griftopia]

This laptop I don't have SSD, but regular HD. Thanks for confirming my plist changes look sound.

I'm googling for anyone else experiencing same problem as I am having. No luck so far

 

EDIT:

 

I know what's happening. The kext will not load from CkO but messes something up. If I think remove for CkO, put in LE and repair, I get the error. If I remove from LE and repair, error goes away. Good. Then I reboot.

 

After rebooting I can put in LE and repair and I do not get error.

 

So I removed it again from LE, repaired, and went through entire procedure 3 times. Same symptoms.

 

So now I have the kext in LE. It STILL does not load. I've attached my modified version. You did say you compiled with 10.13 but the info.plist still says 10.12. Not sure if issue. Also I'm on 10.13.1 - not sure if that matters.

BRCMInjector.kext.zip

[griftopia]

@Bronxtech. Here's one thing I see with all my kexts in CkO which is diff from BRCMInjector.kext

 

The permissions for all my kexts is drwxrwxrwx@. This is consistent with 777, but I dunno how that happened. I guess the kexts I downloaded already were at 777

The permissions for BRCMInjector kext is drwxr-wr-w@. This is actually consistent with 755 and should be sufficient. I think...

 

Just to be consistent with everything else I changed BRCMInjectorkext to 777. Then I tried to load explicitly with kextload. I STILL get error saying I don't have privileges.

 

I don't get it. It's not about CkO or LE or SLE, something is up with permissions on this kext somehow. For system kexts I have this script I use all the time that's never failed me.

 

sudo chmod -Rf 755 /S*/L*/E*
sudo chmod -Rf 755 /L*/E*
sudo chown -Rf 0:0 /S*/L*/E*
sudo chown -Rf 0:0 /L*/E*
sudo touch -f /S*/L*/E*
sudo touch -f /L*/E*
sudo kextcache -Boot -U /

 

PS: One thing different I notice in this kext structure which I haven't seen before is a _CodeSignature folder with a CodeSignature executable under it.

[Hervé]

RE: post #24, trying to declare device 413c:8158 compatible with device 413c:8143 through your envisaged code...

<key>413c_8143</key>
<dict>
[....]
    <key>CFBundleIdentifier</key>
    <string>com.apple.iokit.BroadcomBluetooth20703USBTransport</string>
    <key>CFBundleIdentifier - 2</key>
    <string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string>
    <key>IOClass</key>
    <string>BroadcomBluetooth20703USBTransport</string>
    <key>IOClass - 2</key>
    <string>BroadcomBluetoothHostControllerUSBTransport</string>
    <key>IOProviderClass</key>
    <string>IOUSBHostDevice</string>
    <key>IOProviderClass - 2</key>
    <string>IOUSBHostInterface</string>
[...]
    <key>idProduct</key>
    <integer>33091</integer>
    <key>idVendor</key>
    <integer>16700</integer>
    <key>Compatible-idProduct</key>
    <integer>16868</integer>
    <key>Compatible-idVendor</key>
    <integer>17201</integer>
[...]
</dict>

... well, hmm... would be quite exotic and -of course- completely, how to say this?, wacky! Did just simply make that up?   Kexts and kexts patching are no cocktails in which you add/mix ingredients and then shake, you know.

So, no that would not be the way to go. Why? Well, because:

• the way it's written, it would attempt to declare device 413c:8143 (i.e. DW1550 BT module) compatible with device 413c:8158, i.e. the other way around.
• it would try to refer to 2 x separate kexts (BroadcomBluetooth20703USBTransport + BroadcomBluetoothHostControllerUSBTransport)
• it would try to declare multiple same parameters in series (CFBundleIdentifier & -2, IOClass & -2, IOProviderClass & -2)
• it would try to declare invented parameters (Compatible-idVendor and Compatible-idProduct)

 

What you need to do to inject your device was explained several years ago in post #4 of this thread or here in my E6220 guide. As it happens, you already have all the necessary information to do this. The patch does not even have to be made to the Bluetooth transport kext itself but can be injected in FakeSMC in the same fashion tat was described here for AGPM tuning for instance.

 

If your module is a BCM2070x device, you may need to apply Rehabman's firmware patches too, though I did not see yours in there list. But it's quite an old device after all...