syscl
Bios Versions / USB-C Thunderbolt Dongle Hotswap / Dell Docking Stations
Would you please add what version BIOS you've coded this for to the Readme? I see 1.4.4 as the most popular but I'm working on getting the WD15 dock working well and it recommends the 1.4.12 BIOS. If you're working with 1.4.4 still I'm happy to downgrade to be compatible with the project.
This is a great project.
@thiscodedbox I use 1.4.12 with default setting, the only thing I change is RAID -> AHCI.
You should keep using the latest BIOS, that's the reason why I create deploy.sh to auto patch ACPI tables when BIOS get updating.
Note: ACPI tables are sensitive to BIOS setting change as well. Once you change settings in BIOS, re dump your ACPI tables through pressing F4/Fn+F4 under Clover, then run deploy.sh. There's very few projects have such a convenient script to keep their laptops syncing to latest BIOS, latest ACPI patches. Thus deploy.sh is proven to be robust.
syscl
That's great to hear - I'm glad we can continue to get BIOS updates. Wow. Robust indeed!
Fantastic. Thanks @syscl !
FYI my 9350 is an i7-6560u with 16GB and a 1TB SM961 if you have any need for testing. I also use a Dell WD15 Dock and a generic USB-C Dongle that has 1xUSB3.0 1xHDMI 1xEthernet and USB-C Power Input (PD).
@thiscodedbox Thank you, I want to check if the USB-C work as expect.
Could you please give me the screenshot from DPCIManager once you plug in HDMI?
Thank you, syscl
This is with the WD15 Dell Dock connected. Everything works on it AFAIK.
@thiscodedbox I am really appreciate the detailed information you provide, thank you!
BTW, if you remove the USB-C dongle, what's the screenshot of the DPCIManager->Status?
Could you provideioreg+origin ACPI tables when HDMI plugin for me? Thank you.
Use ioreg from here
Thank you, syscl
@syscl If we do plug in a USB-C adapter of any kind, such as to HDMI, do we need to dump origin and rerun the script, to make it work correctly?
Also just as a side note.- Did you know you left your serial number that was generated for SMBIOS in the config.plist or is that just generic one? I read that if others use the same one that you could possibly get it blacklisted and then have problems with Apple sign in, message service or iCloud. (If you use those.) I generated a new one just in case.
@R1MnTnA, no you don't need to do that any time you plug in USB-C adapter.
Actually you should go to AppleStore and capture SMBIOS information in System Report->Hardware Overview. That's best for your laptop :)
syscl
Hi, hope its okay to hijack this post with different USB-C dongles (btw reinstalled and running fine on latest deploy). First of all: USB-C Network and USB-Hub do only work if they are plugged in and the device is booted. If I try to plug in this USB-C Hub from Anker when the system was booted without, nothing happens. My USB-C HDMI Adapter from Aukey is working fine when not plugged at boot.
I attached two pictures:
-
Anker USB-C Hub: 3x USB3.0 + Gigabit RJ45, model A8303 https://www.amazon.com/Anker-Ethernet-Including-ChromeBook-Aluminum/dp/B00XU6PM68
-
Aukey USB-C HDMI Adapter, model DE-CB-C40 https://www.amazon.com/AUKEY-Adapter-Supported-MacBook-Chromebook/dp/B00W98IC88/
@furrybanana Thank you, could you please provide screenshot of Thunderbolt?
Though I found on a real MacBook9,1, there's no device in Thunderbolt. But I am still curious:)
Thank you, syscl
@furrybanana How about plug in thunderbolt then boot your laptop? Still blank in thunderbolt?
syscl
I've reopened the issue and changed the title to include both things to keep us on topic. I will get the ioreg information to you @syscl soon. @furrybanana it would be awesome if we can solve the USB-C hotplug issue (usb not working when plugged in after startup) I move around with the notebook and plug into the Dell USB-C WD15 dock when I sit at my desk. it exhibits the same behavior that you describe.
@syscl - hopefully this is enough data. Let me know if you want more. I'm going to go digging in the DSDT to see if there's a method that applies to USB3.0 but not to USB3.1, but I'm still learning about ACPI. thiscodedbox_ioreg_1_26_2017_XPS_13_9350_10_12_3.zip
on the XPS 15 9550 the USB-C port in windows (much like the TB3 port) supposedly turns (fully) on when something is plugged into it. It stood to reason the XPS 13 9350 is the same way. The guys in this thread claim to have hotplug working: http://www.insanelymac.com/forum/topic/319764-guide-dell-xps-15-9550-sierra-10122-quick-installation/page-2
They found the the USB-C port creates a bridge device on RP15 on the XPS 15. Same on the XPS 13, but it's RP01 instead.
I took their SSDT-TB, compiled it, and replaced RP15 with RP01. I also tossed in their three relevant patches from their Clover config.plist
I had to remove SSDT-4 as a lot of the code was repeated from there and it was doing weird stuff. After I rebooted I saw the USB 3.1 controller as a removable PCI device - like an ExpressCard used to be in OSX (I used one for firewire on my old x230 so I recognized it). When I 'powered it off' from the menu it killed USB-C, and even the 3.1 controller disappeared from the system entirely!
Alas - still no hot swap - but it seems like this is at least addressing it. Might be able to finagle their SSDT-TB work into our different XPS 13 ecosystem.
Also, I noticed a difference in IOreg when the USB-C is plugged back in after being removed (attempted hotswap.) IOreg has different properties for AppleUSBXHCIPCI. This is even without the SSDT-TB.aml I was using.
before (working) / after (not working):
CapabilityFlags 0x8000 / 0x10000 CurrentPowerState 0x3 / 0x2 DesiredPowerState n/a / 0x3 MachineState n/a / 0x8
Just FYI. I'm still understanding ACPI etc. So I'm not sure how useful this is. attached is my modified SSDT-TB-RP01.aml
Here are the patches I tried (Credit all those in the thread above):
<dict>
<key>Comment</key>
<string>rename _RMV to XRMV</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>
X1JNVg==
</data>
<key>Replace</key>
<data>
WFJNVg==
</data>
</dict>
<dict>
<key>Signature</key>
<string>SSDT</string>
<key>TableId</key>
<string>xh_rvp10</string>
</dict>
dict>
<key>Comment</key>
<string>10.12.2 fudge USB 3.1 device ID</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<string>30783135623638303836</string>
<key>InfoPlistPatch</key>
<true/>
<key>Name</key>
<string>AppleUSBXHCIPCI</string>
<key>Replace</key>
<string>30783135623538303836</string>
</dict>
@thiscodedbox The problem is _RMV -> XRMV, it is very possible this method will affect other devices as well(_RMV lies in other devices as well). Thus not a good solution. I will try to find better solution.
syscl
Are you suggesting we should patch the specific _RMV entities in the ssdt directly via maciasl rather than hotpatching all of ACPI?
@thiscodedbox try this SSDT SSDT-4.aml.zip
-
Drop xh_rvp07
-
Apply 10.12.2 fudge USB 3.1 device ID patch you provided above.
Report if this work, syscl
@syscl Kernel Panic on AppleUSBXHCIPCI with and without 10.12.2 fudge usb patch.
I noticed that the fudge patch patches 0x15b68086 to 0x15b58086.
the USB 3.1 device as detected on my system (and @furrybanana 's system from his screen shots above) is 0x15b58086 already - do you know if the fudge patch is meant to patch the a plist for the driver to attach to our device, or is it supposed to patch the system's detection (Inject a FakePCIid?)
If the latter, should the patch be reversed? Or, should we make a custom fakePCIID.kext to patch our system?
@thiscodedbox What cause the panic? The SSDT-4 or the kext patch?
OK, thank you for the information, I will refine it later today. I have due tomorrow.
Indeed, the kext patch need to be refined to fit our USB 3.1 device.
syscl
@thiscodedbox So, when AppleUSBXHCIPCI causes panic? Could you please give me some more details?
Thank you, syscl
Sorry - I think I had a partial script run issue, I redid my config.plist and no KP anymore, but, unfortunately, no hotplug either.
@thiscodedbox Thank you, due to the id you mention above, I think we need to change the patch code.
syscl
I did read some wikis on arch and they had the same issues mention.
https://wiki.archlinux.org/index.php/Dell_XPS_13_(9350)
a bug report for linux kernel: https://bugzilla.kernel.org/show_bug.cgi?id=115121
a patch/ fix: http://marc.info/?l=linux-acpi&m=145929159015853&w=2 confirming its working: https://bugzilla.kernel.org/show_bug.cgi?id=115121#c27
it's above my skill but what is possible with the information? can somebody port it? thank you both @syscl and @thiscodedbox
Tested my Fantec ALU-25U31 USB 3.1 USB-C Case. It only works when booting plugged in. After ejecting the drive it won't be recognized again. I didn't do any benchmark because I just had a spare 250gb SATA-II HDD installed. I will benchmark it with a 500gb Samsung Evo SSD later when I find the time. It is connected with a Belkin F2CU030BT1M-BLK 3.1 USB C to USB C cable (0,9m).
http://www.belkin.com/us/F2CU030-Belkin/p/P-F2CU030/
http://www.fantec.de/en/products/storage-devices/hard-drive-cases/25-inch-hard-drive-cases/produkt/details/artikel/1795_fantec_alu_25u31/
Hi @syscl, not sure if this is any help to this topic, but I found this on the forums. - https://www.tonymacx86.com/threads/usb-c-hotplug-questions.211313/
If it's of any help, a USB to HDMI dongle I have seems to be working fine for the most part, except for sometimes the external display will not wake up at all after booting.
I do not see a trace of it anywhere in the System Information and the Graphscs/Displays section reports as if it was connected via Thunderbolt.
Can get more information if needed.
