Apple Thunderbolt 2 to FireWire adapter not working

Created attachment 246931
dmesg.log

I use an Apple thunderbolt 3 to thunderbolt 2 adapter to connect Dell XPS 9360 and Apple thunderbolt monitor, but it doesn't work.
The monitor doesn't power on nor flicker at all.
(I've verified the adapter by MBP and the monitor, it works well)

The dmesg shows the adapter is connected before powering up, and then unplug/re-plug the adapter.

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 <email address hidden> is an engineer at Dell who's worked on Thunderbolt compatibility. Amir Levy <<email address hidden> 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 han...

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
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
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
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
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.