sonicthehedgehog2 Posted July 18, 2019 Share Posted July 18, 2019 On 7/17/2019 at 6:45 AM, sonicthehedgehog2 said: No longer working after update to 10.15 Beta (19A512f). System reports Firmware version as v14 c4096 using BCM94352HCM. When I have more time, I'll investigate further. I initially tried reinstalling the kexts that were working, which proved unsuccessful. Hunting around I tried these kexts, which worked for me Link to comment Share on other sites More sharing options...
headkaze Posted July 18, 2019 Author Share Posted July 18, 2019 9 hours ago, dolgarrenan said: Unfortunately for me moving to Catalina is not an option yet (apps and whatnot) but I need this bluetooth functionality.. Then just use RehabMan's kexts without the injector from here. They work perfectly fine for Mojave and below. 8 hours ago, sonicthehedgehog2 said: I initially tried reinstalling the kexts that were working, which proved unsuccessful. Hunting around I tried these kexts, which worked for me What kexts are you using? I have 19A512f installed but need to perform a cold boot to see if the uploading is still working. 1 Link to comment Share on other sites More sharing options...
sonicthehedgehog2 Posted July 18, 2019 Share Posted July 18, 2019 7 minutes ago, headkaze said: Then just use RehabMan's kexts without the injector from here. They work perfectly fine for Mojave and below. What kexts are you using? I have 19A512f installed but need to perform a cold boot to see if the uploading is still working. According to the page linked in my post, I’m using the Mojave kexts Link to comment Share on other sites More sharing options...
chris1111 Posted July 18, 2019 Share Posted July 18, 2019 Thank you for the Forks its work on my HP ProBook 6570B Forks 2 Link to comment Share on other sites More sharing options...
headkaze Posted July 18, 2019 Author Share Posted July 18, 2019 1 hour ago, sonicthehedgehog2 said: According to the page linked in my post, I’m using the Mojave kexts Yes but you still need custom kexts to upload new firmware right? So are you using Mojave kexts along with these ones? BTW I just did a cold boot with my 10.15 Beta (19A512f) machine and it uploaded just fine: 2019-07-18 11:33:07.087305-0700 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0a5c:216f]: USB [184F32F341D4 v274] "BCM20702A0" by "Broadcom Corp" 2019-07-18 11:33:07.620854-0700 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0a5c:216f]: Firmware upgrade completed successfully. Link to comment Share on other sites More sharing options...
sonicthehedgehog2 Posted July 18, 2019 Share Posted July 18, 2019 2 minutes ago, headkaze said: Yes but you still need custom kexts to upload new firmware right? So are you using Mojave kexts along with these ones? BTW I just did a cold boot with my 10.15 Beta (19A512f) machine and it uploaded just fine: 2019-07-18 11:33:07.087305-0700 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0a5c:216f]: USB [184F32F341D4 v274] "BCM20702A0" by "Broadcom Corp" 2019-07-18 11:33:07.620854-0700 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0a5c:216f]: Firmware upgrade completed successfully. Honestly, I’m not sure anymore. I might be - if I do they are leftover from previous installs. My problem is /s/l/e is locked and I can’t clean up with backing up and wiping. I’ll do it sometime for sure. Probably when official release is out but I’m a little busy these days. According to System Report my firmware version is v14 c5575. Really sorry I can’t be more help. Let me know if you need more info. Link to comment Share on other sites More sharing options...
headkaze Posted July 18, 2019 Author Share Posted July 18, 2019 8 minutes ago, sonicthehedgehog2 said: My problem is /s/l/e is locked and I can’t clean up with backing up and wiping. You can use Hackintool to disable Gatekeeper and mount your disk as RW. 2 Link to comment Share on other sites More sharing options...
sonicthehedgehog2 Posted July 18, 2019 Share Posted July 18, 2019 16 minutes ago, headkaze said: You can use Hackintool to disable Gatekeeper and mount your disk as RW. Nice, I didn’t know about this…I shall download and give it a try sometime. Thanks Link to comment Share on other sites More sharing options...
headkaze Posted July 18, 2019 Author Share Posted July 18, 2019 13 hours ago, dolgarrenan said: I have looked over at the Dell website and the latest I could find is the 12.0.1.1105 I've updated the firmware to 12.0.1.1105 which updates 0a5c:6412 to v4689. You could give it a try? 1 Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 19, 2019 Share Posted July 19, 2019 18 hours ago, headkaze said: Then just use RehabMan's kexts without the injector from here. They work perfectly fine for Mojave and below. I have already tried, they are a no go with DW1820A, bluetooth is impossible, wifi works correctly. I'm going desperate.. Link to comment Share on other sites More sharing options...
headkaze Posted July 19, 2019 Author Share Posted July 19, 2019 (edited) 7 hours ago, dolgarrenan said: I have already tried, they are a no go with DW1820A, bluetooth is impossible, wifi works correctly. I'm going desperate.. I still recommend trying the latest release. Also is your USB set up correctly? Is your Bluetooth adapter set to "Internal"? EDIT: I misread what you wrote. If you're on Mojave and RehabMan's release doesn't work then my release is unlikely to work also. I would still check your USB config though. Edited July 19, 2019 by headkaze 1 Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 22, 2019 Share Posted July 22, 2019 On 7/19/2019 at 5:56 PM, headkaze said: I still recommend trying the latest release. Also is your USB set up correctly? Is your Bluetooth adapter set to "Internal"? EDIT: I misread what you wrote. If you're on Mojave and RehabMan's release doesn't work then my release is unlikely to work also. I would still check your USB config though. Hi there, thank you for all your help so far! Yep, on Mojave there is just no way this damn DW1820A activates the BT after cold boot. The only way seems to be pre-loading firmware in W10, then booting up macOS.. @RehabMan has been a no show, so i'm guessing he is tired of all the wining and complaining from people, so I guess it will have to be a Catalina upgrade at a sooner-than-expected time.. Well, I hope someone smart can really figure out what is going on and how to fix it. Link to comment Share on other sites More sharing options...
headkaze Posted July 22, 2019 Author Share Posted July 22, 2019 (edited) 7 hours ago, dolgarrenan said: Hi there, thank you for all your help so far! Yep, on Mojave there is just no way this damn DW1820A activates the BT after cold boot. The only way seems to be pre-loading firmware in W10, then booting up macOS.. @RehabMan has been a no show, so i'm guessing he is tired of all the wining and complaining from people, so I guess it will have to be a Catalina upgrade at a sooner-than-expected time.. Well, I hope someone smart can really figure out what is going on and how to fix it. Well we know it's an IO error (0xe00002ed) when calling BrcmPatchRAM2::hciCommand. What you could do next is use the debug versions so you can get more detailed debug output so we can find out exactly what command is failing. So I would suggest you do that. Also can you actually answer my questions... Did you ever have the firmware uploading working in macOS? Is your USB set up correctly? Is your Bluetooth adapter set to "Internal"? Did you try my latest release (2.2.12)? While it is a big loss that @RehabMan appears to have left the scene (for now at least) there are always people who will step up to take on the challenge (this project is a case in point) which was actually started by @darkvoid so let's not forget his contribution either. That being said just because it works in Windows for you doesn't mean there is a problem with BrcmPatchRAM. It could be some other configuration issue in macOS but if you don't answer my questions or give me the info I request I can't even attempt to help you. Edited July 22, 2019 by headkaze 2 Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 22, 2019 Share Posted July 22, 2019 40 minutes ago, headkaze said: Well we know it's an IO error (0xe00002ed) when calling BrcmPatchRAM2::hciCommand. What you could do next is use the debug versions so you can get more detailed debug output so we can find out exactly what command is failing. So I would suggest you do that. Thank you for the advice, here is the output of log. 41 minutes ago, headkaze said: Also can you actually answer my questions... Did you ever have the firmware uploading working in macOS? Is your USB set up correctly? Is your Bluetooth adapter set to "Internal"? Did you try my latest release (2.2.12)? Lol, I'm so sorry if I haven't! firmware has loaded correctly on several instances and different FW versions as I was trying stuff, I'm currently on v4689, the latest, but weirdly enough, when the firmware loads shows v4689 instead of v8785 which is the resulting of latest firmware version number + 4096 as stated initially by @darkvoid. My USB are correctly implemented, I actually a .kext made with hackintool and is set to internal. I'm also using your latest set of kext, like you mentioned. Now to the funny stuff.. I have (in a desperate attempt) used BrcmFirmwareData.kext, BrcmPatchRAM2.kext, BrcmBluetoothInjector.kext and AirportBrcmFixup.kext in C/K/O instead of L/E (which was the usual for @RehabMan set of kext) and it works-ish.. If I put everything into C/K/O, remove everything from system regarding this set of kext (BRCM Stuff) and do a cold boot, it works smoothly.. Disconnect, connect, BT audio, long range, no hiccups, everything is plastic fantastic, but as soon as I do another cold boot, thats it, no more BT.. So I have to remove, btIjnector, restart the pc, install again btInjector in C/K/O, do a cold boot again and back to business.. This is even more strange than having a non working BT... Maybe you can make some sense out of this nonsense. Here is a log from second attempt cold boot (when it doesn't work any more) I'll try to use your debug version from now on so I can record everything with more data. Link to comment Share on other sites More sharing options...
headkaze Posted July 22, 2019 Author Share Posted July 22, 2019 (edited) 6 hours ago, dolgarrenan said: Thank you for the advice, here is the output of log. Notice it says "Update not needed". That means the firmware is already uploaded. 6 hours ago, dolgarrenan said: If I put everything into C/K/O, remove everything from system regarding this set of kext (BRCM Stuff) and do a cold boot, it works smoothly.. Disconnect, connect, BT audio, long range, no hiccups, everything is plastic fantastic, but as soon as I do another cold boot, thats it, no more BT.. The instructions in the first post tell you to copy the files to EFI/CLOVER/kexts/Other. If you want to try Library/Extensions then you should be using BrcmFirmwareRepo.kext instead of BrcmFirmwareData.kext. But I have not done any testing with BrcmFirmwareRepo.kext or copying to L/E. 6 hours ago, dolgarrenan said: Here is a log from second attempt cold boot (when it doesn't work any more) That is the log of a successful firmware upload. What do you mean by "it doesn't work any more"? Do you have a BT device listed in About This Mac->System Report... Bluetooth? After BrcmFirmwareData.kext/BrcmPatchRAM2.kext successfully uploads the firmware (or detects that it's already been uploaded) it's the job of BrcmBluetoothInjector.kext to load Apple's BT drivers. I'm guessing by this log it's BrcmBluetoothInjector.kext failing to load Apple's drivers not the firmware upload itself. EDIT: One thing you could also try is removing the following from BrcmBluetoothInjector.kext/Contents/Info.plist <key>OSBundleRequired</key> <string>Root</string> Edited July 22, 2019 by headkaze 1 Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 23, 2019 Share Posted July 23, 2019 (edited) 20 hours ago, headkaze said: Notice it says "Update not needed". That means the firmware is already uploaded. I've seen it, but still works funny. 20 hours ago, headkaze said: The instructions in the first post tell you to copy the files to EFI/CLOVER/kexts/Other. Thats where the kext are located, thats what I meant by C/K/O 20 hours ago, headkaze said: That is the log of a successful firmware upload. What do you mean by "it doesn't work any more"? Do you have a BT device listed in About This Mac->System Report... Bluetooth? After BrcmFirmwareData.kext/BrcmPatchRAM2.kext successfully uploads the firmware (or detects that it's already been uploaded) it's the job of BrcmBluetoothInjector.kext to load Apple's BT drivers. I'm guessing by this log it's BrcmBluetoothInjector.kext failing to load Apple's drivers not the firmware upload itself. I mean that once I cold reboot even if prior to cold boot it was working, it just stops working, BT loads but "connected devices" don't work, they just show as connected and, for instance, the magic mouse 2 shows erratic battery percentage, goes from full, to empty, to disconnected to connected and so forth, but It doesn't work.. 20 hours ago, headkaze said: EDIT: One thing you could also try is removing the following from BrcmBluetoothInjector.kext/Contents/Info.plist Tried that and it is a no go, no difference so far. I've tried to replicate the "working" method without success again, I wanted to capture a log of when the device is working properly but I just haven't been able.. I've done everything the same way I did yesterday without even one success.. At any rate, I've done several trials and have saved all the logs. Every log has a little explanation of what was used when the log was created. Every log was recorded after a cold boot, to have things from scratch (removed power for 30 secs and made sure the was nothing connected to the pc), all kext where located at C/K/O, nothing in L/E. Hope they help somehow, today is even worse than yesterday Logs.zip EDIT: it worked once after a reboot and adding couple of arguments on plist (brcmfx-driver=2 and compatible device 14e4,43a0), below the log. Cold booted again and no BT joy... Again Log BrcmFWData+BrcmRAM2+BrcmBTInjector release version - BT loaded and working.rtf Edited July 23, 2019 by dolgarrenan Link to comment Share on other sites More sharing options...
headkaze Posted July 23, 2019 Author Share Posted July 23, 2019 (edited) 5 hours ago, dolgarrenan said: Thats where the kext are located, thats what I meant by C/K/O I know what C/K/O means. The instructions for this release say to use this location but you were using S/E. I'm not entirely sure if you're using the "--last boot" log parameter but judging by the timestamp it looks as if you have multiple kexts installed. When you removed the ones from S/E did you rebuild kext cache? Also as I mentioned earlier if you're not having any luck with RehabMan's release on Mojave I really doubt these will work for you either. All my release does is a few Catalina specific tweaks as well as use BrcmBluetoothInjector to load the native driver. You never clearly answered my question on whether or not you had this device working on a prior version of macOS; "firmware has loaded correctly on several instances" I assume means it has never worked consistently. In any case it may just be incompatible hardware and so I would suggest you try something else. Edited July 23, 2019 by headkaze 1 Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 23, 2019 Share Posted July 23, 2019 4 minutes ago, headkaze said: I know what C/K/O means. The instructions for this release say to use this location but you were using S/E. I'm pretty sure you do lol, it was just the way you formulated the paragraph sort os looked like a notice about the location, I was making sure haha. Indeed I was using L/E up until now for .kext location, but I moved to C/K/O according to your indications. 7 minutes ago, headkaze said: I'm not entirely sure if you're using the "--last boot" log parameter but judging by the timestamp it looks as if you have multiple kexts installed. When you removed the ones from S/E did you rebuild kext cache? What do you mean by "--last boot" log parameter?? I use your hackintool for log, if I use "cat /var/log/system.log | grep -i brcm[fp]" nothing shows up in terminal dunno if I'm doing something wrong or the log shows up somewhere else... Everytime I have done a cold reboot (with all the kext changes in C/K/O) I have performed a .kext rebuild, even deleted all kext cache and done a rebuild then. 17 minutes ago, headkaze said: Also as I mentioned earlier if you're not having any luck with RehabMan's release on Mojave I really doubt these will work for you either. All my release does is a few Catalina specific tweaks as well as use BrcmBluetoothInjector to load the native driver. You never clearly answered my question on whether or not you had this device working on a prior version of macOS; "firmware has loaded correctly on several instances" I assume means it has never worked consistently. In any case it may just be incompatible hardware and so I would suggest you try something else. Unfortunately I'm not having luck with rehabman's set of tools, but his .kext have quite old firmware.. I have manually updated the FW and loaded the kext in L/E with no luck. Every time firmware shows correctly updated (but bluetooth doesn't work properly). This module has never worked correctly in my build, it only does after I load W10 and then reboot into macOS. So long I don't cold boot the module works fine, as soon as I do, thats it, it start pissing around. I would believe it is incompatible if after loading W10 the outcome would be negative, but after seeing how well it works after FW has been loaded on W10 I'm not sure.. There must be something done on W10 that "really" loads FW... I'm going nuts hahaha Again, thank you so much for your help! Link to comment Share on other sites More sharing options...
headkaze Posted July 23, 2019 Author Share Posted July 23, 2019 (edited) 1 hour ago, dolgarrenan said: I'm pretty sure you do lol, it was just the way you formulated the paragraph sort os looked like a notice about the location, I was making sure haha. Indeed I was using L/E up until now for .kext location, but I moved to C/K/O according to your indications. No worries Sometimes I just expand the full path so others know what we're talking about. 1 hour ago, dolgarrenan said: What do you mean by "--last boot" log parameter?? I use your hackintool for log, if I use "cat /var/log/system.log | grep -i brcm[fp]" nothing shows up in terminal dunno if I'm doing something wrong or the log shows up somewhere else... Everytime I have done a cold reboot (with all the kext changes in C/K/O) I have performed a .kext rebuild, even deleted all kext cache and done a rebuild then. If you're using Hackintool to output the log then it should have "Last Boot" option on by default. So what I'm seeing is that your system is loading the same kext twice in one boot. You can see it here: 2019-07-23 09:42:29.919877+0200 localhost kernel[0]: (kernel) BrcmPatchRAM2: Version 2.2.12 starting on OS X Darwin 18.7. ... 2019-07-23 09:42:42.630806+0200 localhost kernel[0]: (kernel) BrcmPatchRAM2: Version 2.2.12 starting on OS X Darwin 18.7. I've never seen this before. The BrcmPatchRAM2 firmware uploader kext unloads after probe exits and has uploaded (or attempted to upload) the firmware but I don't think it's normal for it to do it twice. In fact after BrcmPatchRAM2 has done its job BrcmBluetoothInjector is supposed to attach to your BT device (this order should be determined by IOProbeScore) which subsequently should load BroadcomBluetoothHostControllerUSBTransport. If you search the log for BroadcomBluetoothHostControllerUSBTransport do you get something like this? Timestamp (process)[PID] 2019-07-22 21:57:58.910325-0700 localhost kernel[0]: (BroadcomBluetoothHostControllerUSBTransport) <BroadcomBluetoothHostControllerUSBTransport`BroadcomBluetoothHostControllerUSBTransport::start(IOService*)> **** [BroadcomBluetoothHostControllerUSBTransport][start] -- calling retain() on mBluetoothUSBHostDevice -- Matched on device **** 2019-07-22 21:57:58.910336-0700 localhost kernel[0]: (BroadcomBluetoothHostControllerUSBTransport) <BroadcomBluetoothHostControllerUSBTransport`BroadcomBluetoothHostControllerUSBTransport::start(IOService*)> **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed (matched on Device) -- 0xd000 **** 1 hour ago, dolgarrenan said: This module has never worked correctly in my build, it only does after I load W10 and then reboot into macOS. Yeah it does seem to point to an upload issue with BrcmPatchRAM2 doesn't it? Perhaps you should try messing with some of the kernel delay flags? Quote bpr_probedelay: Changes mProbeDelay. Default value is 0. bpr_initialdelay: Changes mInitialDelay. Default value is 100. bpr_preresetdelay: Changes mPreResetDelay. Default value is 20. bpr_postresetdelay: Changes mPostResetDelay. Default value is 100. The only other issue I can think of right now is the parsing of the firmware is not quite right for your device. ie. BrcmFirmwareStore::parseFirmware needs to be modified to add some additional record_type's or something. Maybe researching BT update for DW1820A on Linux will point us in the right direction? I'm happy to make any changes necessary if that's the case. EDIT: I just tried parsing BCM4350C5_003.006.007.0222.4689.hex with BrcmFirmwareStore::parseFirmware and I get a correct checksum and no unknown record_type's. So it appears the parsing is not the issue in this case. EDIT2: Also tried unpacking and parsing the BCM4350C5_003.006.007.0222.4689_v8785.zhx just to make sure it's not the zlib compression causing a corrupt firmware and again no issues there. Indeed it would be useful to get @RehabMan's take on this. Edited July 23, 2019 by headkaze 1 Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 24, 2019 Share Posted July 24, 2019 (edited) 14 hours ago, headkaze said: I've never seen this before. The BrcmPatchRAM2 firmware uploader kext unloads after probe exits and has uploaded (or attempted to upload) the firmware but I don't think it's normal for it to do it twice. In fact after BrcmPatchRAM2 has done its job BrcmBluetoothInjector is supposed to attach to your BT device (this order should be determined by IOProbeScore) which subsequently should load BroadcomBluetoothHostControllerUSBTransport. Weird indeed, I didn't notice tbh! this is nuts... 14 hours ago, headkaze said: If you search the log for BroadcomBluetoothHostControllerUSBTransport do you get something like this? and this is the output from log with hackintool 2019-07-24 08:57:47.752615+0200 localhost kernel[0]: (BroadcomBluetoothHostControllerUSBTransport) <BroadcomBluetoothHostControllerUSBTransport`BroadcomBluetoothHostControllerUSBTransport::start(IOService*)> **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed (matched on Device) -- 0xc000 **** There is only one mention, and not even the same value as yours 14 hours ago, headkaze said: Yeah it does seem to point to an upload issue with BrcmPatchRAM2 doesn't it? Perhaps you should try messing with some of the kernel delay flags? I will this a shot and see what comes up, also I'd like to mess around with the "how to" explanation you have in your github repo 14 hours ago, headkaze said: EDIT: I just tried parsing BCM4350C5_003.006.007.0222.4689.hex with BrcmFirmwareStore::parseFirmware and I get a correct checksum and no unknown record_type's. So it appears the parsing is not the issue in this case. EDIT2: Also tried unpacking and parsing the BCM4350C5_003.006.007.0222.4689_v8785.zhx just to make sure it's not the zlib compression causing a corrupt firmware and again no issues there. I don't think that is an issue either.. Prior to writing in this post, I tried also to remove (with rehabman's set of kext) all other instances of frimwares and id's, just to leave the one I need and use the uncompressed .hex (which should work) and nothing happened.. BTW, why it only shows v4689 instead of v8785?? that is an odd behaviour isn't it? EDIT: Today, as I turn on the pc it welcomes with a working BT.. I'm very confused, it didn't work last night when I turned off the computer... Here is the log, but as you mentioned, it still loads BcrmPatchRAM2 twice¿?¿? BrcmFWData+BrcmRAM2+BrcmBTInjector release V 24-07 - BT loaded and working.rtf EDIT: Tried a complete power cycle and reboot, again, BT detected but only working for 30 seconds, after it stops BT functionality.. here is the log BrcmFWData+BrcmRAM2+BrcmBTInjector release V 24-07 - BT loaded not working.rtf An here is the log of BroadcomBluetoothHostControllerUSBTransport 2019-07-24 09:34:02.848833+0200 localhost kernel[0]: (BroadcomBluetoothHostControllerUSBTransport) <BroadcomBluetoothHostControllerUSBTransport`BroadcomBluetoothHostControllerUSBTransport::start(IOService*)> **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed (matched on Device) -- 0x3000 **** Edited July 24, 2019 by dolgarrenan Link to comment Share on other sites More sharing options...
dolgarrenan Posted July 25, 2019 Share Posted July 25, 2019 (edited) Hello @headkaze I ended up updating to Catalina, just for the sake of seeing if this thing works.. Well, it results the module works (more less). I can connect my magic mouse 2 (because it needs to tether through the lightning cable), once I disconnect, mouse works but with very limited range, like 50cm away from the antenna starts chopping and ends up loosing connection and can't discover new devices (a set of BT headphones in my case), FW version shows correct version. I have tried with both BrcmFirmwareData (in C/K/O) and BrcmFirmwareRepo (in L/E) in both instances I had done a power cycle, removed kext cache and rebuilt permissions with kextutility. This is the log from Hackintool with mentioned kext in L/E. Result with set of kexts in C/K/O was the same in log and behaviour. BrcmPatchRAM2 loads twice still... Weird... Log Brcm Catalina.rtf I really hope this helps, we are getting closer Edited July 25, 2019 by dolgarrenan Link to comment Share on other sites More sharing options...
liming Posted August 2, 2019 Share Posted August 2, 2019 (edited) My bluetooth id is 0489:e07a by using BrcmFirmwareData and BremPatchRAM2 and it's always working well in 10.14.x. Last week I start to upgrade to 10.15 beta 4 and it didn't work well. I found @headkaze github and used it, but it didn't work well. This is my combination in 10.15: 1. Use BrcmFirmwareData and BremPatchRAM2, it didn't work most time. Maybe one or two time were successfully, my hackintosh cold start and reboot twice, the bluetooth work well suddenly. After reading the thread, I know that if the firmware upgrade success by BremPatchRAM2, my bluetooth will work well. But, most of time the upgrade process is failed. I have tried the delay arguments, it looks like not helpful. 2. Use BrcmBluetoothInjector only, Bluetooth show normal in system but it has disconnect issue. The log used BrcmFirmwareData and BremPatchRAM2. If the log show firmware version keeps in v4096, the bluetooth device will lost in my system. Edited August 3, 2019 by liming Link to comment Share on other sites More sharing options...
liming Posted August 9, 2019 Share Posted August 9, 2019 Quote Timestamp (process)[PID] 2019-08-09 10:58:52.300333+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211Controller::init(OSDictionary*)> AirPort_BrcmNIC::init AirPortFamily_kexts-1555 "AirPortFamily_kexts-1555" Jul 23 2019 01:28:42 2019-08-09 10:58:52.300671+0800 localhost kernel[0]: (AirPortBrcmNIC) <AirPortBrcmNIC`osl_iolog_withtimestamp> ARPT: 1.300669: AirPort_Brcm43XX:probe:, this[0xa2459d70539c7e99] score[2048] 2019-08-09 10:58:52.300835+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211Controller::init(OSDictionary*)> AirPort_Brcm4360::init AirPortFamily_kexts-1555 "AirPortFamily_kexts-1555" Jul 23 2019 01:28:42 2019-08-09 10:58:52.301856+0800 localhost kernel[0]: (AirPortBrcm4360) <AirPortBrcm4360`osl_iolog_withtimestamp> ARPT: 1.301855: AirPort_Brcm43XX:probe:, this[0xcc0bfb16e89adf1b] score[1110] 2019-08-09 10:58:57.969682+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211Controller::init(OSDictionary*)> AirPort_BrcmNIC::init AirPortFamily_kexts-1555 "AirPortFamily_kexts-1555" Jul 23 2019 01:28:42 2019-08-09 10:58:57.976990+0800 localhost kernel[0]: (AirPortBrcmNIC) <AirPortBrcmNIC`osl_iolog_withtimestamp> ARPT: 8.289585: AirPort_Brcm43XX:probe:, this[0xa2459d705516de99] score[2048] 2019-08-09 10:58:57.977125+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211Controller::init(OSDictionary*)> AirPort_Brcm4360::init AirPortFamily_kexts-1555 "AirPortFamily_kexts-1555" Jul 23 2019 01:28:42 2019-08-09 10:58:57.977296+0800 localhost kernel[0]: (AirPortBrcm4360) <AirPortBrcm4360`osl_iolog_withtimestamp> ARPT: 8.289895: AirPort_Brcm43XX:probe:, this[0xcc0bfb16ea138f1b] score[1110] 2019-08-09 10:58:58.834019+0800 localhost kernel[0]: (AirPortBrcmNIC) <AirPortBrcmNIC`osl_iolog_withtimestamp> ARPT: 9.146619: BRCM tunables: 2019-08-09 10:59:03.432539+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211Controller::logDebug(char const*, ...)> AirPort_BrcmNIC::getSSIDData(): Get failure: APPLE80211_IOC_SSID: 6 2019-08-09 10:59:03.454149+0800 localhost kernel[0]: (kernel) BrcmPatchRAM: Unable to locate BrcmFirmwareStore configured firmwares. 2019-08-09 10:59:03.456955+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0489:e07a]: USB [ACD1B8DF2A16 v274] "BCM20702A0" by "Broadcom Corp" 2019-08-09 10:59:03.675424+0800 localhost kernel[0]: (kernel) BrcmPatchRAM: Unable to locate BrcmFirmwareStore configured firmwares. 2019-08-09 10:59:03.682188+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0489:e07a]: Firmware upgrade failed. 2019-08-09 10:59:03.682548+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: Processing time 12.35 seconds. 2019-08-09 10:59:03.683672+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: Version 2.2.12 starting on OS X Darwin 19.0. 2019-08-09 10:59:06.495953+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: [0489:e07a]: BrcmPatchRAMResidency does not appear to be available. 2019-08-09 10:59:06.541314+0800 localhost kernel[0]: (kernel) BrcmPatchRAM: Unable to locate BrcmFirmwareStore configured firmwares. 2019-08-09 10:59:06.554559+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: uploadFirmware could not open the device! 2019-08-09 10:59:06.567288+0800 localhost kernel[0]: (kernel) BrcmPatchRAM2: Processing time 2.71 seconds. 2019-08-09 10:59:06.604652+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211VirtualInterface::init(IO80211Controller*, ether_addr*, unsigned int, char const*)> IO80211VirtualInterface::AirPort_BrcmNIC_P2PInterface::init name <p2p0> role 1 2019-08-09 10:59:06.713832+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211P2PInterface::init(IO80211Controller*, ether_addr*, unsigned int, char const*)> AirPort_BrcmNIC_P2PInterface::init <p2p> role 1 2019-08-09 10:59:06.922190+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211VirtualInterface::init(IO80211Controller*, ether_addr*, unsigned int, char const*)> IO80211VirtualInterface::AirPort_BrcmNIC_P2PInterface::init name <awdl0> role 4 2019-08-09 10:59:06.922196+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211P2PInterface::awdlAttachToBpf()> AirPort_BrcmNIC_P2PInterface::awdlAttachToBpf name <awdl0> role 4 successful attach to bpf type 147 2019-08-09 10:59:06.923701+0800 localhost kernel[0]: (IO80211Family) <IO80211Family`IO80211P2PInterface::init(IO80211Controller*, ether_addr*, unsigned int, char const*)> AirPort_BrcmNIC_P2PInterface::init <awdl> role 4 2019-08-09 10:59:25.447126+0800 localhost kernel[0]: (AirPortBrcmNIC) <AirPortBrcmNIC`osl_iolog_withtimestamp> ARPT: 34.957774: AirPort_Brcm43xx::syncPowerState: WWEN[disabled] Here is my log BT firmware version in system is still v14 c4096 Link to comment Share on other sites More sharing options...
headkaze Posted August 9, 2019 Author Share Posted August 9, 2019 19 hours ago, liming said: Here is my log BT firmware version in system is still v14 c4096 You have BrcmFirmwareData.kext installed in EFI/Clover/kexts/Other? Link to comment Share on other sites More sharing options...
liming Posted August 10, 2019 Share Posted August 10, 2019 (edited) 2 hours ago, headkaze said: You have BrcmFirmwareData.kext installed in EFI/Clover/kexts/Other? no, I use BrcmFirmwareRepo.kext. Follow the README, choose one of BrcmFirmwareRepo and BrcmFirmwareData, right? Update: I'm confused now, I try to use BrcmFirmwareData.kext in E/C/K/O and BT works! I try to cold start twice and it still woks! Amazing! I tried BrcmFirmwareRepo many days ago, but the difference is kexts put in different dictionary. I follow the README to put kext in correct dictionary or only use BrcmBluetoothInjector without other kexts, BT didn't work or be not stable. Anyway, I put BrcmFirmwareData, BrcmBluetoothInjector and BrcmPatchRAM2 the three kexts in E/C/K/O and BT works now. It looks like that I can't believe the README. Edited August 10, 2019 by liming 1 1 Link to comment Share on other sites More sharing options...
Recommended Posts