Thunderbolt 1 and 2 Compatibility Issues

I am trying to get a Thunderbolt 2 device working with my Framework Laptop 13 (12th gen Intel, Windows 11, purchased August 2022).

From my research, it seems that Intel has broken compatibility with TB 1/2 devices via BIOS updates on 12th gen and later processors. However, some are still reporting success by downgrading their BIOS firmware or drivers to previous versions. (https://asusproart.medium.com/thunderbolt-on-pc-is-a-nightmare-of-intels-own-making-edd3141cc03f)

Anyone have experience getting TB 1/2 devices working on Framework laptops? Does anyone know if legacy BIOS\driver versions might help and where I would get a hold of these? (I can only seem to find the latest ones on the Framework website.)

Thanks!

Only experience I have is that USB4 even on my 11th gen Surface Pro 8 does not work with the Apple TB3 to TB2 and TB2 to Firewire adapter. It also didn’t work on a Thinkpad X12 detachable. You need a Thunderbolt 3 device from what I understand. It’s possible that some USB4 implementions actually support backwards compat but neither of my devices do. What ended up working for me was the OWC dock with a built in FireWire port.

Thanks. Yeah, I’ve heard conflicting reports on whether the Apple TB2/3 adapter works on newer PCs. Some don’t seem to have any issues with it. I’ve also seen people who were able to adjust TB4 security settings to allow backwards compatibility with earlier versions, but I can’t find any way to do that on the Framework laptop.

I’ve heard of a few workarounds in mind, but not sure if they are reliable enough to invest money into. It’s kind of frustrating, because it feels like a planned obsolescence thing. Plenty of good Firewire and early Thunderbolt devices that are basically useless because of a lack of support.

I think that post TB3 those parts of the standard are optional. Old stuff is just janky. Someone could probably make a new adapter

Not quite. Intel has stated since forever that TB4 is not backwards compatible to TB1/2.
Their external Maple Ridge controller was at some point still backwards compatible. With older firmware with other bugs, long updated with that support removed (For Maple Ridge we know NVM31 still had TB2 support, NVM36 no longer).
The update that killed that support was of the TB controllers firmware. Which some manufacturers may have integrated into BIOS updates. But the BIOS does not matter for that.
Maple Ridge also relies on the old legacy Thunderbolt (Thunderbolt control center) drivers and firmware that was already in use with TB3 and probably included that compatibility by default.

Our 12th gen integrated USB4 controllers do not have the same type of firmware that handled it autonomously, because the OS is intended to replace that mess (and actually does pretty well).

Most CPU-integrated USB4 controllers run using an OS-based connection manager, like Windows 11’s USB4 drivers. Those have never supported TB2 or older, because USB4 itself is not at all backwards compatible to that. It is unclear if the USB4 spec is even compatible with supporting TB2/1 devices or if that would be breaking the USB4 spec. That might even be the reason that Intel announced this compatibility break. And Microsoft itself seems to have never officially supported any Thunderbolt prior to TB3 on Windows as well. So anything using Windows USB4 drivers will never add that.

If you need that compatibility, go Apple. They are the ones that introduced and popularized TB1 & 2 in the first place and apparently are keeping it alive a little longer.

If there are those settings, then its probably not even proper TB4. Because those security levels are replaced by just universal DMA protection with TB4. Mostly seems to be on AMD systems that just never have been certified for TB and where the TB control center even tells you that DMA protection is not working.

@Ray519 Thanks! Plenty of helpful information here. I’ll probably end up just replacing my older devices, but it’s good to have the technical background on how we ended up here.

FWIW, my FW13 was working with my TB1 monitor (an LG34UM95) via an apple TB3/USB-C to TB2 adapter just fine since I got it (Batch 3), right up until the 3.20 BIOS update, so IME, if you can get/hold onto an 11th gen with older firmware, you’re golden, but you can’t update to 3.20 (and apparently, I can’t downgrade now :sob:)

Which drivers was it using before and after the upgrade? I am just curious if this only worked / matches what we saw with Intel’s external controllers. Because the one 11th gen host I have access to initially had its TB controller show up like an external one. But recently got a BIOS update that makes the controllers how up like they always did on 12th gen, compliant with Windows’ USB4 requirements. But still using the legacy TB drivers.

i’m running linux so i don’t know if there’s an analogous comparison, afaict the drivers are the same but the behavioral change is outside of them (there is no driver activity now when i plug in the adapters, it seems the controller firmware doesn’t even present them to the OS)

Yeah, You’re right. Linux started out with a “legacy” TB driver, but extended it to be a full USB4 driver with proper software connection manager still under the old “thunderbolt” driver.
What you would need to find out is, if you are using a software or firmware connection manager. Because the legacy stuff (whatever uses the TB drivers under Windows) uses a firmware connection manager. Where most decisions are made in the controller itself. While anything proper USB4 uses the OS-based connection manager.

I do not have handy how to find that out under Linux. I know the driver checks for that and switches which code to use internally.
There may some /sys/bus/thunderbolt sysfs thing that just tells you directly. Not sure.

It can probably be gleaned from the full logs, but that logging needs to be enabled first

sudo rmmod thunderbolt
sudo modprobe thunderbolt dyndbg

Then the driver will log a whole lot to dmesg. For me, with software connection manager, you can see it configuring each tunnel (DP, per hop, USB3) and see all of the bandwidth allocation, which I do not think it would for firmware-managed controllers.
If you’d boot Linux with that debug option enabled, it would probably also log the driver picking in which mode it runs.