Jump to content

DW1820a - the general troubleshooting thread


muttonhead411

Recommended Posts

@Naidis - you were spot on about the root cause being firmware uploads not working correctly using rehabman kext. I've managed to upload firmware from windows, and keep it persistent in Mac OS, version 4689 on both windows and Mac.

 

Wireless bluetooth mouse now works correctly. 

 

I'm going to continue to test it out over a few days.

 

image.thumb.png.f0d24672c29f76927d6c358cf700296b.png

image.png.6702d6aff52121ef055ca3b2a229b910.png 

Link to comment
Share on other sites

8 hours ago, muttonhead411 said:

Wireless bluetooth mouse now works correctly. 

 

I'm going to continue to test it out over a few days.

 

Congrats. Hope somebody could figure out why we can't upload the firmware via macOS, while some of us can.

11 hours ago, muttonhead411 said:

am I understanding correctly that with your suggestion, we would need to boot windows first every time before booting mac os?

Well, according to my experience, you won't lose your uploaded/cached firmware unless you shutdown and disconnect the power. Rebooting won't affect it. But this should be related to your power policy which is controlled by motherboard itself.

Link to comment
Share on other sites

Hi lads.

I've managed to make it work. I've got a 1028:0023 one. She worked fine in Linux but when I tried to boot macOS, it either hanged or caused reboot. When I masked pins as Naidis did, macOS started to boot and see the device. Actually she works with both AirPortBrcm4360 and AirPortBrcmNIC but requires AirportBrcmFixup to pass some Apple's checks. There's my config:

<key>PciRoot(0x0)/Pci(0x1c,0x07)/Pci(0x0,0x0)</key>
<dict>
	<key>compatible</key>
	<string>pci14e4,4353</string>
	<key>AAPL,slot-name</key>
	<string>Built In</string>
	<key>name</key>
	<string>pci14e4,43a3</string>
	<key>IOName</key>
	<string>pci14e4,43a3</string>
    <key>model</key>
	<string>Apple Wifi Card</string>
	<key>device_type</key>
	<string>AirPort</string>
</dict>


where Pci(0x1c,0x07) is an IO address, there's Hervé's post about finding thereof. The "compatible" key make it work with AirPortBrcm4360 too. So brcmfx-driver=1 and brcmfx-driver=2 work and you can don't use that boot arg at all.

As for Bluetooth, it seems that the actual problem is that the original BrcmPatchRAM2 uses zipped firmware and it fails. When I tried raw hex, it worked. But I don't keep anything in L/E or S/L/E, my partition is a vanilla macOS. Everything custom is in the EFI partition.

So I took 3 versions of the firmware:
BCM4350C5_003.006.007.0095.1703_v5799
BCM4350C5_003.006.007.0145.2724_v6820
BCM4350C5_003.006.007.0221.4688_v8784

put them into "firmwares" dir of the repo, changed in the script zhx to hex and generated the C++ file with the firmwares.

I compiled against 10.14 BrcmFirmwareData and BrcmPatchRAM2 (the second isn't necessary, just for a good measure).
In BrcmPatchRAM2's plist I removed everything except 0a5c_6412 since it's the matter in hand.

And now everything works from clover/kexts.

If you're going to try it, there's one precaution. It's better to remove and pair again an audio device after loading a new firmware.

brcm_kexts.tar.gz

Link to comment
Share on other sites

Looks like we're making very good progress today... very happy. 

 

For the adventurous who prefer to keep kext in L/E, feel free to try the attached files and report back with your results for bluetooth. If firmware was uploaded successfully, you should see the following version in Sys Info:

1777945945_Screenshot2019-07-18at1_10_38AM.thumb.png.41b32a8ffa199666b939e7cd18abdcdb.png

 

BrcmPatchRAM2.kext.zipBrcmFirmwareRepo.kext.zip

Link to comment
Share on other sites

@muttonhead411, firmware loads successfully, but bluetooth doesn't work, I've also managed to do so with @RehabMan set of kext modifying few things in the .plist of BrcmPatchRAM2 and adding the new firmware to the repo.kext, which btw, as how a version is measured in macOS, the fw version should be v8785 (whatever the last four digits of the firmware version + 4096, then you get fw version to complete data..) I think this info is shared by @darkvoid in some of his post.

 

Did you managed to make bluetooth properly work??

 

Link to comment
Share on other sites

@Aleksander, very very interesting.. Would care just to elaborate a bit the procedure you used to do the kext, I'm not much of knowledge book, but I'd love to understand such procedure and be able to replicate this on my own to share as soon as I got some results.. I did move your kext to /Kext/Other and it seemed to work at first, but once you turn off the device, then on again becomes unstable and looses connection at once.. So I'm still at the same place as before :(

 

Link to comment
Share on other sites

I've been doing further testing on my latitude, and this is still the only reliable way of getting bluetooth to work on DW1820A, via @Naidis

 

I tried extracting the exact .hex file from windows and attempting to upload it on MacOS, but that exhibits the same unstable behaviour as other firmwares unfortunately. 

 

Hopefully we find a better way forward somehow...

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...