List of Intel Titan Ridge Thunderbolt 3 Devices
 
Notifications
Clear all

List of Intel Titan Ridge Thunderbolt 3 Devices  

 of  25
  RSS

goalque
(@goalque)
Noble Member Admin
Joined: 5 years ago
 
Posted by: karatekid430

You sound like you know a lot about this stuff. Are you a firmware engineer?

I am planning on taking courses for X86 architecture, UEFI and PCIe to learn enough to break this stuff apart.

Are you at a level such that you would understand this?  https://www.linuxboot.org/

The goals I want to achieve:
-Understand if there is anything for which there is a good reason why the OS kernel cannot manage it (why it has to be in firmware)
-Move as much stuff out of firmware as possible
-Cripple ME to bare minimum, completely wipe out SMM, AMT and ACPI (emulate bare minimum ACPI needed for Windows, hand over control of as much as possible with OSC, etc)
-Thunderbolt handling from SMM -> OS kernel, allow for the AIC to work on any slot, including CPU lanes
-Try and coerce target OS into allocating with IOMMU to avoid problems finding contiguous memory regions, and also for security.
-Although far fetched, if it is possible to make a universal firmware that works on almost all motherboards, then I would be interested

Clearly this is a vast amount to learn, but I am willing to pursue a career with low level architecture and design.

The LinuxBoot project looks promising, but it only loads at the DXE phase. This means there is still garbage that is motherboard-specific before it loads.
Also, I am not sure if kexec syscall preserves bus initialisation - I would hope it is possible to load the target kernel into RAM, completely reset all of the bus states, and hand over to the other OS with a perfectly clean slate - so that the target OS is free to allocate things in the best way for its needs - rather than it being dictated.

If you know about this stuff then I would love to talk about it more if that is okay with you. Cheers!

I've been a regular software engineer for over a decade and have a MSc degree, my field of specialisation was information processing tech so wasn't a big leap to learn from Intel PDFs. I didn't know anything about GPUs or (U)EFI programming a couple of years ago.

Unfortunately Intel's Thunderbolt documents are under NDA, and I have no access to these.

IOMMU is explained in detail here:

https://www.duo.uio.no/bitstream/handle/10852/44802/larsbk-pcie-device-lending.pdf

"One thing that both the PC and the Macs had in common was that they reserved space for additional devices on the hotplug slot as well as all upstream bridges as described in 2.2.2. This is in contrast to what most firmwares do, and what the Thunderbolt systems did for all non-Thunderbolt bridges. In these other cases, only the exact amount necessary is allocated. The extra resources for the Thunderbolt bridges allows the kernel to find room for the new devices."

So it's all about fitting eGPU BARs within the bridge resource windows. I remember reading that macOS algorithm was more intelligent and that's why we can easily use multiple eGPUs.

Thunderbolt/PCI code is not part of the open source version of the XNU kernel. The best starting point is to look at Linux kernel patches:

https://patchwork.ozlabs.org/patch/409994/

Linux kernel developers have contacts to a software engineering manager at Intel (Thunderbolt developer platform software team).

EDIT: Oops... seems that these emails are confidential.

automate-eGPU EFIapple_set_os.efi

Mid 2015 15-inch MacBook Pro eGPU Master Thread

 
2018 13" MacBook Pro [8th,4C,U] + Radeon VII @ 32Gbps-TB3 (ASUS XG Station Pro) + Win10 1809 [build link]  


ReplyQuote
joevt
(@joevt)
Noble Member
Joined: 4 years ago
 

I believe we have access to macOS's PCIe configuration algorithm. You can find all the Thunderbolt settings for a PC bios, including many hidden settings that describe the slot used for an add-in card, force power, etc.

Posted November 24, 2017
Posted February 16
Posted February 26

The Hopper disassembler has improved since the last time I looked at this. You can find Thunderbolt drivers source for Linux now on github.

I would like to see some command line utilities in macOS to do the same kind of stuff you can do in Linux.

Mac mini (2018), Mac Pro (Early 2008), GA-Z170X-Gaming 7, Sapphire Pulse Radeon RX 580 8GB GDDR5, Radeon Pro W5700, Sonnet Echo Express III-D, Trebleet Thunderbolt 3 to NVMe M.2 case


goalque liked
ReplyQuote
ha1o2surfer
(@se12897)
Trusted Member
Joined: 4 years ago
 

 

Posted by: karatekid430

Please explain what you mean. From what it sounds like, what you are claiming to have done is impossible (TB3->TB2 adapters do not support DP alt-mode; only DP through Thunderbolt protocol). Like please map out the device chain, adapters, MST hub and monitors.

I think ha1o2surfer's statement is missing some punctuation and needs some slight rewording, like this:
I use a TB3 > TB2 adapter. After a couple of TB2 devices, a MST hub is used and it works fine with 3 monitors 3 ways down the chain.

The TB3->TB2 adapter passes a Thunderbolt encapsulated DisplayPort stream that a Thunderbolt controller in a Thunderbolt device later in the chain can convert to DisplayPort. The MST hub must be connected to a Thunderbolt controller's DisplayPort output.

So the device chain must be like this: Thunderbolt 3 computer -> Thunderbolt 3 to Thunderbolt 2 adapter -> first Thunderbolt 2 device -> ... -> last Thunderbolt 2 device -> MST hub ->>> three displays. This can support 2560 x 1440 + 2560 x 1440 + 1920 x 1200 all at 60 Hz using just one DisplayPort connection. Thunderbolt can support two DisplayPort connections, but maybe his motherboard only has one DisplayPort connection to the Thunderbolt controller (like in my Gigabyte Z170X-Gaming 7).

Yes this is correct! I am missing that period at the end of the first sentence. I'm using my HP x360 laptop and since I assumed my USBc to mDP adapter supports MST I figured I'd try it over a TB connection as well so I can have 7 monitors total with one connection to my laptop (with a TB2 "eGPU" as the ending of the chain with an MST adapter in the "eGPU" passthrough TB port)

FYI, changed my display name.

2020 13" HP EliteBook 830 G7 [10th,6C,U] + RTX 2070 @ 32Gbps-TB3 (AORUS Gaming Box) + Win10 20H2 [build link]  

ReplyQuote
joevt
(@joevt)
Noble Member
Joined: 4 years ago
 
Posted by: SE12897

Yes this is correct! I am missing that period at the end of the first sentence. I'm using my HP x360 laptop and since I assumed my USBc to mDP adapter supports MST I figured I'd try it over a TB connection as well so I can have 7 monitors total with one connection to my laptop (with a TB2 "eGPU" as the ending of the chain with an MST adapter in the "eGPU" passthrough TB port)

Just remember that connecting displays to a Thunderbolt port (or a DisplayPort of a Thunderbolt controller of a Thunderbolt device) reduces H2D bandwidth to any eGPU in that Thunderbolt chain (unless it's a Blackmagic eGPU) because the laptop's GPU is using the bandwidth to send Thunderbolt DisplayPort signals to those displays. This causes a performance decrease in games.

Mac mini (2018), Mac Pro (Early 2008), GA-Z170X-Gaming 7, Sapphire Pulse Radeon RX 580 8GB GDDR5, Radeon Pro W5700, Sonnet Echo Express III-D, Trebleet Thunderbolt 3 to NVMe M.2 case


ReplyQuote
ha1o2surfer
(@se12897)
Trusted Member
Joined: 4 years ago
 

Yeah. I only use this setup to gain more displays not to game. But this setup results in 800ishMB/s in H2D transfers so you'd be right lol

2020 13" HP EliteBook 830 G7 [10th,6C,U] + RTX 2070 @ 32Gbps-TB3 (AORUS Gaming Box) + Win10 20H2 [build link]  

ReplyQuote
wimpzilla
(@wimpzilla)
Honorable Member
Joined: 5 years ago
 

As always being bad at software, can't really give any useful opinion about.
Even if starting to learn assembly language and computer science helped a lot lately.

But from what i know and what the hardware say, there is already malicious code allowed to flow by tech manufacturer.
For example, Intel ME and the AMD secure enclave role is mainly to enforce DRM policies or any policy that companies want to impose at hardware level.
And from what i understood about, not much can be done at the code level, no code change, removal would solve the issue.

So there is absolutely no chance in future to see these practices of hidden code execution left aside, only a major worldwide security crisis would get rid of it.

Edit: I mean, no major crisis happened direly related to in the last 10 years, the time it needed to stop bothering about transistor count built into a die.
Would not have been so simple more than 10 years ago, to dope the die adding some more transistors to build something running it's own kernel outside the main Ring 0 protected OS kernel.

2012 13-inch Dell Latitude E6320 + R9 270X@4Gbps-mPCIe (EXP GDC 8.4) + Win10
E=Mc²

 
2012 15" Lenovo ThinkPad T530 [2nd,4C,Q] + R9 270X @ 4Gbps-mPCIe2 (EXP GDC 8.4) + Win10 [build link]  


ReplyQuote
karatekid430
(@karatekid430)
Estimable Member
Joined: 4 years ago
 
Posted by: wimpzilla

As always being bad at software, can't really give any useful opinion about.
Even if starting to learn assembly language and computer science helped a lot lately.

But from what i know and what the hardware say, there is already malicious code allowed to flow by tech manufacturer.
For example, Intel ME and the AMD secure enclave role is mainly to enforce DRM policies or any policy that companies want to impose at hardware level.
And from what i understood about, not much can be done at the code level, no code change, removal would solve the issue.

So there is absolutely no chance in future to see these practices of hidden code execution left aside, only a major worldwide security crisis would get rid of it.

Edit: I mean, no major crisis happened direly related to in the last 10 years, the time it needed to stop bothering about transistor count built into a die.
Would not have been so simple more than 10 years ago, to dope the die adding some more transistors to build something running it's own kernel outside the main Ring 0 protected OS kernel.

That almost made sense, but I failed to parse the sentence structure.

To do: Create my signature with system and expected eGPU configuration information to give context to my posts. I have no builds.

.

ReplyQuote
karatekid430
(@karatekid430)
Estimable Member
Joined: 4 years ago
 
Posted by: joevt

I believe we have access to macOS's PCIe configuration algorithm. You can find all the Thunderbolt settings for a PC bios, including many hidden settings that describe the slot used for an add-in card, force power, etc.

Posted November 24, 2017
Posted February 16
Posted February 26

The Hopper disassembler has improved since the last time I looked at this. You can find Thunderbolt drivers source for Linux now on github.

I would like to see some command line utilities in macOS to do the same kind of stuff you can do in Linux.

Any chance they can run that disassembler over tbt100x.sys in Windows and a couple of dozen instances of tbtsmm EFI module? Or is it somehow specific to Mac drivers?

To do: Create my signature with system and expected eGPU configuration information to give context to my posts. I have no builds.

.

ReplyQuote
joevt
(@joevt)
Noble Member
Joined: 4 years ago
 
Posted by: karatekid430
Posted by: joevt

I believe we have access to macOS's PCIe configuration algorithm. You can find all the Thunderbolt settings for a PC bios, including many hidden settings that describe the slot used for an add-in card, force power, etc.

Posted November 24, 2017
Posted February 16
Posted February 26

The Hopper disassembler has improved since the last time I looked at this. You can find Thunderbolt drivers source for Linux now on github.

I would like to see some command line utilities in macOS to do the same kind of stuff you can do in Linux.

Any chance they can run that disassembler over tbt100x.sys in Windows and a couple of dozen instances of tbtsmm EFI module? Or is it somehow specific to Mac drivers?

It works on Windows files too. There are better (more expensive?) disassemblers for Windows anyway (IDA?). I think working with the EFI might be easier, because most of it is open source. Every EFI file has the same kind of entry. The EFI GUIDs are easy to find so you know what's referring to what. You don't have to worry about OS specific code. The EFI contains all the info on the BIOS settings so you can easily make data types for everything and use them in the disassembly to find the code that uses the settings you care about (I started working on a script to create those types from the EFI information). You may need to convert the TE type files to PE type before disassembling (I made a script for that). This kind of work takes a long time though.

Mac mini (2018), Mac Pro (Early 2008), GA-Z170X-Gaming 7, Sapphire Pulse Radeon RX 580 8GB GDDR5, Radeon Pro W5700, Sonnet Echo Express III-D, Trebleet Thunderbolt 3 to NVMe M.2 case


ReplyQuote
wimpzilla
(@wimpzilla)
Honorable Member
Joined: 5 years ago
 

@karatekid430 

It does not need to have a sense.

These are facts, facts do not need a sense.
You can work as you want on the software that run on the cpu, but still the cpu itself is a black box with security features one can't leverage. 

I apologies tho for my poor English.

2012 13-inch Dell Latitude E6320 + R9 270X@4Gbps-mPCIe (EXP GDC 8.4) + Win10
E=Mc²

 
2012 15" Lenovo ThinkPad T530 [2nd,4C,Q] + R9 270X @ 4Gbps-mPCIe2 (EXP GDC 8.4) + Win10 [build link]  


ReplyQuote
 of  25