Oh boy. Yes, I spent nearly a year trying to work with the Direct Connect Interface (DCI), Intel's implementation of this. It's a long, complicated, difficult, and frustrating process.

The short version is that, unless you have a corporate contract with Intel, there is so much randomness involved that the time and effort necessary to get it working are probably not worth it.

The main challenge is finding a compatible motherboard. There are three main factors that need to align for a given board to work:

1. The CPU XDP (Extended Debug Probe, includes JTAG) lines need to be routed to the chipset. Because you're actually talking to the chipset via DCI (it's the one that manages the USB ports), if they aren't, you'll only be able to access the chipset in your debugging session (i.e. you'll have no access to the typical debugging stuff that you're probably after), which, without Intel's keys to unlock Yellow and Red mode, isn't super interesting (though I would like to look into it more . . .). It's extremely difficult to guarantee a given board has these routed before getting your hands on it; I wasted some money on a few that didn't. Your best bet is if you can find a schematic buried somewhere on the internet, although even then, this is a part of the board that's likely to change between revisions without notice.

2. You'll want the BIOS to "support" enabling DCI -- In quote marks because I've never encountered one that will just let you do it through the GUI. Instead, most of the time you'll wind up modifying a non-volatile UEFI configuration bank for something called Intermediate Forms Representation (IFR), which is a format that Intel's Firmware Support Package (FSP) uses to store the BIOS configuration options. (Most BIOS GUIs are just skins on top of this.) There are a few options you need to flip in here, so you'll need to use an IFR extractor on your particular BIOS to recover the offsets and such for the appropriate options; once you have them, you'll use something like RU.efi to actually twiddle the bits. It's worth noting that not every BIOS uses this approach. I can't recall who it was, but there was at least one vendor whose BIOS didn't contain any IFR. In that case, you'll likely need to patch the BIOS directly -- an enormously complicated task, worthy of another post. I developed a successful patch once, which would have worked were it not for the third factor . . .

3. The chipset must be configured to serve DCI over a particular USB port. This is the factor I know the least about. There were a few boards I found that were _very_ finicky about which ports they would serve. Obviously, at the bare minimum, you have to connect to a port served _directly_ by the chipset, but it seems that there are factors even beyond that. Perhaps they are configurable in firmware, or maybe they are programmed in eFuses in the chipset -- I'm not sure. In any case, be sure to try all of the available ports, including USB-C. There was one board where I got everything else working, but none of the ports let me in -- absolutely infuriating.

All in all, I evaluated several dozen boards (looking for schematics, downloading and reversing BIOSes) and purchased eight; of those, two worked. The first was a Dell Precision 5520, and the second was a Asus TUF Z370 Plus Gaming. I couldn't get a 8th Gen Intel NUC working (it was behaving as though the CPU wasn't connected, which is odd considering the chipset and CPU are integrated onto one die).

Once you have a board, you'll need Intel System Debugger. (This was previously packaged with Intel's free version of System Studio, but I've heard rumblings that, as of just recently, this is no longer the case.) This part is pretty straight forward -- the documentation should have you covered.

This was definitely one of my favorite projects, but if you're looking for a simple debugging solution, this ain't it.