I recently read an interesting article about debugging using Direct Connect Interface (DCI).
Now I wanted to try it out for myself, I first tried my old laptop (6700K) which has the DCI control register writable , which had some promising signals. After flipping the bit DCI was detected and the CPU cores where seen. But I didn’t manage to suspend the CPU’s in any meaningful way without the system crashing and DAL console giving errors that it failed to freeze.
So, I tried my other system (lenovo E570) but there it was sadly locked and no way to downgrade the bios to an earlier version where it was apparently unlocked (too new hardware) and I couldn’t find out any way to edit/flash the bios (Even the EFI vars where write protected)
So then finally I decided to mod my Asus x299-deluxe (with a I9-7960X CPU)
AmiBCP sadly enough didn’t work on this ROM file, but after extracting the setup and sending it through a parser I found the efivar address for DCIen and enabled that.
But that one gave even less results that my first test. DCI is detected and active, but DAL console only tells me "No enabled processor threads found in the platform"
I thought it was due to MSR IA32_DEBUG_INTERFACE (0xc80) being locked and disabled (even after setting in the bios to enable it), so I edited to boot part of the ROM and injected some code to enable Silicon Debug feature (Had to use the flashback option to get it to load as flash tools didn’t work properly) after boot it was properly set (active, and still booting up)
But still, no cpu’s detected.
Is it that ASUS didn’t wire in the CPU ? Or did I forget to change a setting somewhere ? Or it it a CPU issue ? (It’s true only U cpu’s support it ?)
Also, anyone knows a mainboard with this feature enabled (or at least accessible in the BIOS and functional?) I REALLY like to give this a try (Would help a lot when writing kernels) and I don’t mind spending some money on this
For those interested in this,
I bought a Gigabyte brix, GB-BKi3HA-7100 (still available)
In that one the setup efi variables are not locked.
Just set the following Setup offsets to this:
0x58f(Debug Interface): 1
0x591(Direct Connect Interface): 1
0x590(Debug Interface Lock): 0
0x889(DCI enable (HDCIEN)):1
And setup DAL config KBL_KBP_OpenDCI_DBC_Only_ReferenceSettings config
2
3
4
5
6
7
>>? itp.halt()
[KBL_C0_T0] Halt Command break at 0x38:0000000083FE6FB9
[KBL_C0_T1] MWAIT C1 break at 0x38:000000000009E1DE
[KBL_C1_T0] MWAIT C1 break at 0x38:000000000009E1DE
[KBL_C1_T1] MWAIT C1 break at 0x38:000000000009E1DE
(the fist laptop I tried probably also works, but I didn't feel like messing that one up as it's one of my main work systems)
Can you share the deatils on howto enable the 4 variables in the BIOS?
I have a GB-BKi5HA-7200 and tried to mod it with AMIBCP 5.02
and reprogrammed it with an external SPI programmer.
However the DCI never came up when I connected the USB
debug cable.
check the USB cable you use, I started out with a “USB 3 Debug cable” but that one just did not work at all and almost gave up(Perhaps just a broken cable, or those may not work at all). But then I found a fully wired USB3 cable (A-A) (on which they say that it can damage your system if you use it) and it actually works. (Though it may trigger some power protections at boot depending on what host system you use, or light up mainboard leds and usb peripherals even when no power is connected, so ‘could be’ they’re right, but at least everything still works here
anyhow:
first I dumped the BIOS
Then used uefitool to extract the setup
Then used the universal IFR extractor to convert the setup to text
In there I looked for the varoffsets of: "Debug Interface, Direct Connect Interface and DCI enable (HDCIEN)"
Then I used the handy RU.EFI tool to edit the Setup vars accordingly. To get there press alt+= and then search for the Setup store (there may be two setup blocks, it’s usually the 2nd bigger one) Then just scroll to the offsets you want to change, and change them (usually just change from 00 to 01) When done, press ctrl+w
And that was enough to enable DCI for me
Also, since the gigabyte brix doesn’t have a serial port(it may have but I never figured out what cable connector it was and those pins are too small for my bad soldering skills), and I really like having one, I got a Gigabyte GA-Q170M-D3H mainboard and did the exact same things and am using it right now for debugging. (You need to use KBL_SPT_OpenDCI_DBC_Only_ReferenceSettings for that one, and for that you do need to set itp.jtagonlymode(0,True) unlike the brix which does support full debugging)
(I have never ever updated the BIOS files of either system)
tools:
https://github.com/LongSoft/UEFITool/releases (to extract the setup. Tip: do a textsearch for one of the variables you’re interested in to find it easily)
https://github.com/LongSoft/Universal-IFR-Extractor/releases (to decode the setup and find the var offsets)
http://ruexe.blogspot.nl/ (easy to use var reader/editor (efi version recommended))
Hi scribly, eiselekd (I hope you still read this forum :)), and everyone else.
I’m trying to enable DCI and use the python DAL console on my Brix GB-BKi5HA-7200.
I’m using this USB 3.0 debuging cable: https://www.datapro.net/products/usb-3-0…ging-cable.html
I didn’t enable DCI using the exact same steps as you, but instead using “Intel CSME System Tools”:
- dumped my flash using “Flash Programing Tool”
- opened the dump in “Flash Image Tool”, and set DCI to “yes” under the “Debug” tab
- built the new flash image and flash it using “Flash Programing Tool” (after disabling Bios region protection in the Bios)
That’s one of the way of enable DCI, according to “Tapping to the core” presentation from last year (https://www.slideshare.net/phdays/tappin…he-core#slide21)
After that, on the debugger host side (I’m using Windows 10 x64) I can see that DCI is enabled because:
- In UsbView.exe, I see a new USB device called “Intel USB Native Debug Class Devices”
- In Device Manager I see a new device "Intel DCI Transports(USB-Based)
However, the python DAL console does not react properly. The “itp.halt()” command returns errors saying “Unable to halt processor thread: …”, which is very strange since my target machine seems to be in fact halted (mouse and keyboard unresponsive).
I’m using profile KBL_SPT_OpenDCI_DBC_Only_ReferenceSettings
Here is the full output:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
>>> itp.jtagonlymode(0, True)
>>> itp.status()
Status for : KBL_C0_T0
Processor : Running
Processor mode : Unavailable while running
Status for : KBL_C0_T1
Processor : Running
Processor mode : Unavailable while running
Status for : KBL_C1_T0
Processor : Running
Processor mode : Unavailable while running
Status for : KBL_C1_T1
Processor : Running
Processor mode : Unavailable while running
>>? itp.halt()
ExecutionControlUnableToHaltAllException:
Unable to halt processor thread: KBL_C0_T0
Unable to halt processor thread: KBL_C0_T1
Unable to halt processor thread: KBL_C1_T0
Unable to halt processor thread: KBL_C1_T1
>>?%
Do you have an idea of what could be wrong with my setup? Any help would be greatly appreciated ! :)
You also need to enable the processor’s “Debug Interface” (enable debug and halt for the cpu)
and disable “Debug Interface Lock” (make bios not lock the bit). There might also be a conditional
variable that guards the “Debug Interface” and “Debug Interface Lock”, use the Universal-IFR-Extractor
method described in https://gist.github.com/eiselekd/d235b52…c6b3912731ab9b2 to find out
and set if present.