Launchpad has imported 15 comments from the remote bug at https://bugzilla.kernel.org/show_bug.cgi?id=189731.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2016-12-06T07:25:34+00:00 acelan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/0 ------------------------------------------------------------------------ On 2016-12-28T14:38:38+00:00 lukas wrote: 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_limoncie...@dell.com> is an engineer at Dell who's worked on Thunderbolt compatibility. Amir Levy <amir.jer.l...@intel.com is an engineer at Intel familiar with the Thunderbolt firmware driver. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/1 ------------------------------------------------------------------------ On 2016-12-29T18:26:30+00:00 bhelgaas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/2 ------------------------------------------------------------------------ On 2016-12-29T19:25:43+00:00 lukas wrote: (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. :-( Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/3 ------------------------------------------------------------------------ On 2017-01-03T02:30:32+00:00 acelan wrote: 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)? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/4 ------------------------------------------------------------------------ On 2017-01-03T10:28:06+00:00 lukas wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/5 ------------------------------------------------------------------------ On 2017-01-15T21:51:28+00:00 danielroschka+kernel wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/6 ------------------------------------------------------------------------ On 2017-01-16T04:59:44+00:00 lukas wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/7 ------------------------------------------------------------------------ On 2017-01-16T20:16:28+00:00 danielroschka+kernel wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/8 ------------------------------------------------------------------------ On 2017-11-25T10:44:39+00:00 johnny.casales wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/12 ------------------------------------------------------------------------ On 2018-01-22T18:45:40+00:00 pfpschneider wrote: I too would like to use a Thunderbolt 2 device using a 3-to-2 adapter. What is the status of this problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/15 ------------------------------------------------------------------------ On 2018-01-28T14:34:37+00:00 kristian wrote: +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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/17 ------------------------------------------------------------------------ On 2018-02-03T13:39:18+00:00 kristian wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/20 ------------------------------------------------------------------------ On 2018-08-22T14:11:00+00:00 whitequark wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/21 ------------------------------------------------------------------------ On 2018-08-22T14:12:40+00:00 whitequark wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726299/comments/22 ** Changed in: linux Status: Unknown => Confirmed ** Changed in: linux Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1726299 Title: Apple Thunderbolt 2 to FireWire adapter not working To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1726299/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
