DCI Debug on the AAEON UP Xtreme i11 board

Finally! A publicly available board with Intel Direct Connect Interface (DCI) working out of the box. With our SourcePoint JTAG-based debugger, it is now possible to explore the inner workings of low-level firmware with all the power of CPU-hardware-assisted run-control and trace features, including Intel Processor Trace and Architectural Event Trace.

Readers may recall the series of blogs on using DCI with the AAEON UP Squared board as a great learning and research vehicle for UEFI and low-level firmware. The blogs are listed below:

Open Source Firmware explorations using DCI on the AAEON UP Squared board

The UP Squared Chronicles Episode 2: Building the UEFI Image

The UP Squared Chronicles Episode 3: Intel Processor Trace

The UP Squared Chronicles Episode 4: Using Intel Processor Trace with POST Codes

The UP Squared Chronicles Episode 5: Installing and Debugging Windows 10

The UP Squared board, equipped with an Apollo Lake processor, made a great learning platform for open-source UEFI firmware research. Much like its “predecessor”, the MinnowBoard, there was access to a debug image of UEFI source and symbols on Intel’s firmware site. So, with a serial console, you were able to see all the “printf” statements that were coming out of the code, and correlate that to the function and module as the board booted up. And, doing the appropriate tweaks, Intel Direct Connect Interface (DCI) could be used as a debug access mechanism. This latter meant that, in conjunction with a hardware-assisted, source-level debugger like SourcePoint, developers could have visibility to the internals of UEFI and other boot firmware to an unprecedented extent.

Unfortunately, the Apollo Lake-based AAEON UP Squared board had quite a few limitations, when it came down to using it in the latter fashion. Among these were:

  1. The only way to (that I know of) to get the necessary debug image down on the board was to build it yourself, and then flash the board. This required a high skill level, some specialized equipment, and many hours of work to accomplish. See the first two blogs listed above, for the directions.
  2. SourcePoint run-control was problematic during board reset and power cycles. To really be able to debug from reset and perform useful debugging, run-control must be rock-solid through these transitions.
  3. Apollo Lake is an Atom-based, older chip; it lacks some of the more advanced Trace features that are extremely useful debugging aids, such as easy support of the Intel Trace Hub.

In just the last few weeks, AAEON released the UP Xtreme i11, which is based on the new Tiger Lake, 11th Generation Intel® Core™ Processor (that I think was originally named the Tiger Lake UP3). I purchased the UP Xtreme i11 i3 version, which is the cheapest one available, but still around $500 (note: don’t buy the i11 Celeron version, which is cheaper, but I don’t think suited to this purpose).

On the UP Xtreme i11 i3, just a few open BIOS settings need to be set to activate DCI and allow SourcePoint to connect to it. I’ll publish these in an upcoming blog.

The one downside to this platform is that there is no set of simple directions to build a debug image with source and symbols, as was available with the MinnowBoard and with the UP Squared. But, stay tuned; you never know what might become subsequently available. And, besides, a lot can be gleaned from just from looking at the assembly language and using Trace features to get access to the boot flow events. And, if you have access to a source tree yourself, you can build a debug image and flash the platform yourself at your leisure. It doesn’t have to be UEFI; have a look at Slim Bootloader, or coreboot. And if you’re into hypervisor development or working with the OS kernel, or just plain doing research, the lack of source and symbols shouldn’t get in the way. Look at the below screen shots of Intel Processor Trace, and Architectural Event Trace (AET) with interleaved MSR Read/Writes, PORT IN/OUT, IRET and HW_INTR events:

I think that having access to a publicly available, reasonably inexpensive board with DCI access, and coupled with excellent tools, should open up x86 firmware to more people, and make it more accessible. Stay tuned for more in this space! We have a big announcement coming soon.

Alan Sguigna