Bug 189731

According to the dmesg output the adapter only shows up as a USB device.

On non-Macs the firmware is responsible for setting up PCI tunnels and DisplayPort tunnels over Thunderbolt. Apparently it doesn't do that for devices behind this adapter, so the firmware needs to be extended.

Please ask Dell for a BIOS update. Best case they'll manage to get this working in collaboration with Intel engineers, worst case they'll respond that they don't support Apple's adapter. Mario Limonciello <mario_limonciello@dell.com> is an engineer at Dell who's worked on Thunderbolt compatibility. Amir Levy <amir.jer.levy@intel.com is an engineer at Intel familiar with the Thunderbolt firmware driver.

Thanks, Lukas.  Help me understand the scenario here.  It looks like the adapter was hot-added.  If the firmware is responsible for configuring things behind the adapter, there must be a hook where firmware gets invoked.  Is the ACPI Bus Check event that hook?  Does that mean we must use acpiphp (not pciehp) to support these Thunderbolt devices?  I'm trying to figure out if we can log more intelligent messages for this situation.  The current stuff in dmesg is pretty hard to interpret.

(In reply to Bjorn Helgaas from comment #2)
> Thanks, Lukas.  Help me understand the scenario here.  It looks like the
> adapter was hot-added.

In the dmesg output it can be seen that the adapter was present on boot, then unplugged and replugged. This is also what Acelan Kao wrote above.


> If the firmware is responsible for configuring
> things behind the adapter, there must be a hook where firmware gets invoked.
> Is the ACPI Bus Check event that hook?  Does that mean we must use acpiphp
> (not pciehp) to support these Thunderbolt devices?

I'm only familiar with the situation on Macs, where all of this happens natively: There's an EFI driver to configure tunnels to devices already attached on boot, and there's an OS driver which takes over after ExitBootServices. These drivers recognize when a Thunderbolt device is hotplugged and set up PCI- and DisplayPort-tunnels. Once a PCI-tunnel is set up, pciehp sees a hotplug event. It's important to understand this distinction because most people think Thunderbolt is just PCIe to external devices: It's a packet switching technology and one has to set up PCIe tunnels to actually communicate with devices. Think of it like an MPLS path.

On non-Macs the tunnels are set up by a firmware component dubbed Intel Connection Manager which runs in System Management Mode. When a device is hotplugged, somehow an SCI occurs and the ICM code is executed. To the best of my knowledge, PCI devices are *not* handled by pciehp but by acpiphp.

To make matters even more complicated, Macs newer than 2015 that are booted with Windows will reconfigure the Thunderbolt controller to be managed by ICM rather than natively. This is done by AML code in the DSDT, it writes to a number of MMIO registers of the Thunderbolt controller.

All of this is almost completely undocumented. There's some introductory docs at Apple:
https://developer.apple.com/library/content/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/Basics/Basics.html

Other than that I think the only public source are various Thunderbolt-related patents by Intel, Apple et al.


> I'm trying to figure out
> if we can log more intelligent messages for this situation.  The current
> stuff in dmesg is pretty hard to interpret.

It's kind of hard to improve them as we know so little about all that. :-(

Lukas, thanks for the details and suggestions.
I just want to confirm that you think this issue should be fixed in the BIOS/uEFI, and we don't have to do anything related to the drivers?

BTW, do you think will it work if I install linux on a Mac machine(which has proper EFI driver to handle this device)?

(In reply to AceLan Kao from comment #4)
> BTW, do you think will it work if I install linux on a Mac machine(which has
> proper EFI driver to handle this device)?

Very likely yes, but the adapter has to be plugged in on boot for the EFI driver to set up the tunnels. If it's plugged in after Linux has booted, my expectation is that you get the same behaviour as on the Dell laptop, i.e. just a USB device but nothing else.

In any case you will need this patch to make Thunderbolt work on the 2016 MacBook Pros (the only ones with Thunderbolt 3 so far):
https://gist.githubusercontent.com/l1k/3ffbd63ac337fa85530f6db3e9ee77e9/raw/55b2a520ee6d5e802ce599395886f378a42c89d8/0001-thunderbolt-Support-Alpine-Ridge-4C-controller.patch

(In reply to Lukas Wunner from comment #5)
> In any case you will need this patch to make Thunderbolt work on the 2016
> MacBook Pros (the only ones with Thunderbolt 3 so far):
> https://gist.githubusercontent.com/l1k/3ffbd63ac337fa85530f6db3e9ee77e9/raw/
> 55b2a520ee6d5e802ce599395886f378a42c89d8/0001-thunderbolt-Support-Alpine-
> Ridge-4C-controller.patch

Any plans to bring that patch upstream?

(In reply to Daniel Roschka from comment #6)
> (In reply to Lukas Wunner from comment #5)
> > In any case you will need this patch to make Thunderbolt work on the 2016
> > MacBook Pros (the only ones with Thunderbolt 3 so far):
> >
> https://gist.githubusercontent.com/l1k/3ffbd63ac337fa85530f6db3e9ee77e9/raw/
> > 55b2a520ee6d5e802ce599395886f378a42c89d8/0001-thunderbolt-Support-Alpine-
> > Ridge-4C-controller.patch
> 
> Any plans to bring that patch upstream?

Does it work for you? I've heard from Bernhard Froemel that the driver loads without errors with that patch but I've yet to hear from anyone who's actually tested it with Thunderbolt devices attached.

Yesterday I posted v5 of my series to add runtime PM for Thunderbolt on Macs, this will hopefully land in v4.11. I could submit the patch for Alpine Ridge on top of that if you can provide a Tested-by. We do have to disable runtime PM on Alpine Ridge for now as Apple has made significant changes for these chips which need to be reverse-engineered first. The runtime PM series with the Alpine Ridge patch on top is on this branch, it would be great if you could test the combination of the two:
https://github.com/l1k/linux/commits/thunderbolt_runpm_v5

If you don't have a Linux git repo locally and don't want to clone this (it's a > 1GByte download) I'll be happy to send you the individual patches based on 4.9 or 4.10, whichever you prefer.

Unfortunately I currently also don't have access to Thunderbolt 3 accessories. As soon as I get my hands on some, I'll definitely try out, if they work with your patch.

Are there any news on this topic? I want to use my Apple Thunderbolt 3 to Thunderbolt 2 adapter on a Gigabyte Z170N-Gaming 5 mainboard. I can provide the adapter to a developer if this is helpful.

I too would like to use a Thunderbolt 2 device using a 3-to-2 adapter.  What is the status of this problem?

+1

I have a Thunderbolt 3 to Thunderbolt 2 adapter, and then a Thunderbolt 2 to FireWire at the end of that. I can see the adapter, but I don't know if that means anything:

---
$ cat /sys/bus/thunderbolt/devices/0-1/device_name
Thunderbolt to FireWire Adapter
---

firewire_ohci doesn't find it..

Anything I can do to help? Test? Play with patches?

Actually, this does work, it's just that the device I used wasn't authorized. Take a look at the comment here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/6

So I've spent way too much time trying to get this adapter to work, and here's what I discovered. I have an XPS 13 9360 laptop, BIOS 2.8.2, Thunderbolt NVM 21.0, and kernel 4.17.14. The Thunderbolt security is disabled in BIOS, and all access control settings are as relaxed as possible.

First, a few words about the adapter.

I have opened it, which was remarkably complicated. If you want to do so, I suggest using a rotary tool with an abrasive disc to first cut off the end caps of the adapter body, then cut it longitudally using three cuts, two on the sides and one below (the top is where the lightning bolt is). The adapter has a copper shield glued to the plastic, so don't afraid if you hit metal, you can't harm the PCB yet.

Now, you are staring at a 0.5 mm thick metal can spot welded in something like 80 places and soldered to the PCB through four protrusions. You will need to grind away every weld to separate the halves of the can, and then grind away the PCB protrusions. This needs to be done carefully because there are critical components less than 0.5 mm from the metal can.

Now, you are looking at a huge mass of thermal compound, something similar to silicone. It cannot be chemically removed (with anything I tried, anyway) and I recommend using a small plastic spatula to cut and scrape it until all necessary areas are exposed. It does not adhere strongly to PCB solder mask or components anyway, it just gets stuck in crevices.

My adapter PCB has the following markings: 09 C1646 820-00689-A. The bottom of the adapter has the power supply but no logic. It has a lot of test points but I have not been able to identify any activity on them by probing with an oscilloscope while doing USB software resets. 

The top of the adapter houses logic as well as one more power supply. All of the ICs appear to carry Apple-proprietary markings. The USB PD controller is marked (TI logo) CD3215B03 6ACKCTT G1 010, identical to the photo in [1]. This is likely a remarked TI TPS65983 [2]; they have an identical ball pattern. The PD controller has an SWD debug port that is routed to an unpopulated Apple-proprietary debug header on the PCB. Although it doesn't seem to be documented by TI in [2], these PD controllers usually have a Cortex-M0 core inside. The PD controller has no built-in flash, but I haven't yet been able to identify the type (SPI or I2C) or part number of the flash IC.

The IC near the Thunderbolt connector is marked CD3211 A1 TI 5AI CKSN, which is yet another case of Apple-proprietary markings. It is in a VQFN-20 package. The only TI chip with a Thunderbolt function in a VQFN-20 package is TPS22981, and a continuity check of ground pins in the pinout appear to confirm the match.

The others aren't very interesting. There's a Fairchild FET bearing Apple-proprietary markings, and a Linear buck bearing Apple-proprietary markings, but they aren't really relevant.

Now, let's talk about software.

Under the assumption stated above in the thread that this is an ACPI hotplug issue, I've disassembled DSDT [3] and reverse-engineered much of the Thunderbolt hotplug code. It consists of two general parts, the wrapper for communicating with the SMI handler, and a bastardized version of PCI enumeration code that, upon detecting a hotplug, tells the OS to rescan the bus.

Some ACPI endpoints of interest are: \_SB.TBFP (Bool), which forcibly disables the Alpine Ridge controller power savings, making the Thunderbolt NHI PCI device appear on the bus. (This is what the intel-wmi-thunderbolt module eventually pokes.) \_GPE.OSUP, which communicates with the SMM part of Thunderbolt hotplug code via a mailbox. \_GPE.XTBT, which is the body of the Thunderbolt hotplug handler. And \_GPE._E42, which invokes the hotplug handler and I'm guessing is triggered by EC or SMM.

After plugging the Apple adapter, you can invoke (e.g. via acpi_call.ko) \_SB.TBFP(1), which will cause the Thunderbolt NHI device to appear and enumerate [4]. (The log in [4] was taken with pci=realloc intel_iommu=off. For some reason it is only able to assign the bridge BARs if I supply both pci=realloc and intel_iommu=on, but this doesn't appear to affect anything else.)

As can be seen, only the root Thunderbolt switch is enumerated on the bus. Nothing else appears. This doesn't change if I plug the adapter before or after force-enabling the controller, if I boot with the adapter plugged in, whether there's a cable in the adapter, whether there's a Thunderbolt device on the other end of the cable, nothing.

After this, I thought that possibly a rescan of the Thunderbolt bus needs to be triggered through SMM. For this, the ACPI call \_GPE.TINIT 0x01 can be done. This actually generates an ACPI hotplug event, and Linux rescans the bus, but it doesn't generate a *Thunderbolt* hotplug event, which is what's necessary to update the Thunderbolt topology. On the other hand, given that the Thunderbolt hotplug events arrive via the NHI ring buffer, is ACPI involved here at all?Additionally, the thunderbolt module scans and configures every switch it can discover when it's loaded, and loading it well after the Thunderbolt NHI interface was force-enabled and the adapter plugged in doesn't let it discover anything beyond the root switch, so I suspect ACPI and SMM aren't at all at fault here.

The only remaining avenue that I see is to desolder the USB PD controller, read its firmware, and reverse-engineer it. In the thread [1] Dell support also appears to blame the Apple PD controller chip.

Unfortunately, there's an issue with it.

Let me say it straight. The TI documentation lists the minimum flash size for the USB PD firmware as 1 Mbyte. I am not going to reverse-engineer one megabyte of shitty vendor Thumb code. Also, everyone involved in Thunderbolt and USB C engineering is batshit insane. Every technology in this stack is opaque, overcomplicated, underdocumented, and has hidden dependencies on at least one (usually more) other opaque overcomplicated underdocumented technologies. I give up. I'm probably just going to take all the Thunderbolt hardware I bought in hoping to get it to work and put it in the trash, because the only thing I can feel towards it anymore is utter disgust.

Anyway, if someone else is interested in REing the adapter, I can probably dump its firmware with minimal effort, though I'm not set up for BGA and 0402 reworking right now and it'll probably destroy the PCB given the rather compact assembly, which is why I still haven't done it. Well, that, and what the previous paragraph says. But let me know.

[1]: https://store.rossmanngroup.com/c6-cd3215a-u3100.html
[2]: http://www.ti.com/lit/ds/symlink/tps65983.pdf
[3]: https://gist.github.com/whitequark/932717e712d4e89a0468c3351fb1bbf4
[4]: https://gist.github.com/whitequark/383a349ba6e7717b4f917baede7084e7

Sorry, the Dell support thread link in the previous post should be [5].

[5]: https://www.dell.com/community/Laptops-General/XPS-15-9550-Thunderbolt-NVM-firmware-issue-with-Thunderbolt-3-to/m-p/5102920

Created attachment 278223 [details]
adapter firmware (TI TPS65983)

OK, I desoldered the flash and dumped the firmware. The chip is indeed a remarked TPS65983 (possibly TPS65983B, it's not entirely clear) and out of the 1 MiB flash capacity, slightly less than 70 KiB is used by the firmware. Which is still not very small but could be manageable. I've attached the firmware, have fun.

I've also mapped out all the debug interfaces, in case anyone's interested.

Created attachment 278257 [details]
USB PD trace

I've sniffed the USB PD communication (see attachment) that happens when the adapter is plugged in. It goes as follows:

-> REQ Disc Ident SVID:0xff00
<- ACK Disc Ident SVID:0xff00 VDO:0x6c0005ac VDO:0x00000000 VDO:0x16570348 VDO:1000000a (this carries the USB VID/PID and identifies the dongle as an alternate mode adapter)
-> REQ Disc SVID SVID:0xff00
<- GOOD CRC
<- ACK Disc SVID SVID:0xff00 VDO:0x808705ac VDO:0x00000000
-> GOOD CRC
-> REQ Disc Mode SVID:0x8087
<- GOOD CRC
<- ACK Disc Mode SVID:0x8087 VDO:0x00010001
-> GOOD CRC

No further communication happens. I'm not yet sure why the PD controller in XPS13 doesn't send an Enter Mode command.

Created attachment 278265 [details]
UCSI trace

It looks like on XPS13, the UCSI notifications are broken. Attached is a ftrace log that shows what happens if I enable UCSI tracing, plug in the device, insmod ucsi_acpi, then remove the device, then plug it back in. The ACPI notification works, but after the first notification, the UCSI SET_NOTIFICATION_ENABLE command fails:

<disconnect>
           rmmod-5920  [001] .... 846293.522800: ucsi_command: control=00010005 (SET_NOTIFICATION_ENABLE)
     kworker/0:1-4132  [000] .... 846293.695298: ucsi_notify: CCI=00000002 Connector Change
           rmmod-5920  [002] .... 846298.845856: ucsi_run_command: SET_NOTIFICATION_ENABLE -> FAIL (err=-110)
     kworker/0:1-4132  [000] .... 846298.845870: ucsi_command: control=00010012 (GET_CONNECTOR_STATUS)
     kworker/0:0-31458 [000] .N.. 846299.011370: ucsi_notify: CCI=80000902 Event pending (command completed)
     kworker/0:1-4132  [000] .... 846299.043161: ucsi_ack: ACK command
     kworker/0:0-31458 [000] .N.. 846299.213819: ucsi_notify: CCI=20000000 ACK completed
     kworker/0:1-4132  [000] .... 846299.213823: ucsi_run_command: GET_CONNECTOR_STATUS -> OK (err=0)
     kworker/0:1-4132  [000] .... 846299.213824: typec_set_pwr_role <-ucsi_connector_change
     kworker/0:1-4132  [000] .... 846299.213824: typec_set_data_role <-ucsi_connector_change
     kworker/0:1-4132  [000] .... 846299.213825: ucsi_ack: ACK event
     kworker/0:1-4132  [000] .... 846299.239159: ucsi_connector_change: port0 status: change=4040, opmode=1, connected=0, sourcing=0, partner_flags=0, partner_type=1, request_data_obj=00000000, BC status=1

Created attachment 278267 [details]
UCSI altmode support patch

The previous comment isn't entirely correct. UCSI notifications are broken, but the command failure I quoted has nothing to do with it, it was just an artefact. I do not know why they are broken.

It looks like the Linux UCSI driver does not support alternate modes. I wrote a patch against kernel tag 4.17 (attached) that adds support for requesting and setting alternate modes, if advertised by UCSI. It's hacky (more than one MID per SVID is probably broken, and activating modes via port partner sysfs node doesn't work) but it's sufficient for testing.

Here's what I get in dmesg with the patch when plugging in the adapter:

[856816.978580] ucsi_acpi USBC000:00: con1: found port altmode 8087:00000001
[856816.978606] ucsi_acpi USBC000:00: con1: found port altmode ff01:00001c46
[856817.128092] ucsi_acpi USBC000:00: con1: found port altmode 413c:00000001
[856817.282308] ucsi_acpi USBC000:00: con1: in altmode index 0
[856818.277557] ucsi_acpi USBC000:00: con1: found partner altmode 8087:00000001

It looks like the USB PD controller in XPS13 ignores the 05ac SVID in the ACK Disc PD message, and doesn't even try to request the altmode list for that SVID. This makes sense, because it doesn't support any Apple-specific altmodes.

I'm now looking into reflashing the adapter such that it would advertise some SVID:MID pair that is recognized by XPS13. I don't actually know if there's any; if you know what other Thunderbolt adapters use, please share.

@whitequark I was struggling to get stuff to work with the Apple Thunderbolt 3 to 2 adapter, but when I replaced it with the Startech Thunderbolt 3 to 2 I got it working. Read about other's recommending it online as well.