It may not be everyone’s idea of a good time, but I was delighted to receive a MinnowBoard Turbot for Christmas. I hooked it up to my copy of SourcePoint, and the results were pretty cool.
Imagine my surprise when I unwrapped one of my gifts to find a MinnowBoard Turbot inside. This little PCB is an affordable open-source hardware platform for makers and hackers; think of it as the Intel version of the Raspberry Pi. It sports a dual-core 64-bit Intel® Atom™ E3826 (code name “Bay Trail-I”) system-on-a-chip (SoC) with support for 2GB RAM, USB 2.0, USB 3.0, HDMI, Ethernet, GPIO, SATA2, MicroSD, and a number of other interfaces and built-in capabilities. The entire hardware design is open source, and set it up with a USB keyboard and HDMI monitor and it boots right up into the EFI shell so you can play with it right away. It’s easy enough to add support for a higher-level OS, such as Debian Linux, Windows IoT, Yocto, or others.
But the really cool thing about the MinnowBoard is that it supports a high-speed expansion (HSE) 60-pin connector on the bottom side of the board. This interface is used to connect to a variety of breakout board “Lures” for fast prototyping and tinkering. One of these Lures is the “Debugger Lure” from Tin Can Tools. The Debugger Lure is an expansion board that adds a JTAG debugging interface for the Intel XDP. It is designed to work with Intel's In-Target Probe (ITP) XDP JTAG debugger, but of course it just hooks up to the standard JTAG/XDP interface, so it works with ASSET’s SourcePoint debugger too. I was really excited about hooking it up to my ECM-XDP3 hardware emulator and debugging UEFI on the MinnowBoard. Hooked together, it looks like this:
The emulator plugs into the standard 60-pin XDP header on the Debugger Lure, which in turn plugs into the HSE header on the bottom of the MinnowBoard. It was very easy to set up.
Once you have the hardware set up, getting SourcePoint configured is simple. I just opened up a New Project, imported the target configuration file for 2-core Bay Trail, powered on the target, and then powered on the emulator. Everything came up the very first time, and after a couple of minutes I had the target halted and in debug mode, with full display of the processor status, x86 registers, memory dump, and disassembled code window.
So, what’s next? Well, this is just the beginning. I’m planning on getting full source code and symbols display down on my PC so I can single-step through code and use some of the trace features on the Bay Trail to see how UEFI behaves. Maybe I’ll make some changes to the UEFI code underneath and break stuff and see what happens. I also plan on adding Debian Linux to the platform so I’ll be able to tinker with the Linux kernel and use SourcePoint to do some OS-aware debugging. I’ll write about my adventures (or misadventures) in upcoming blogs.
Go here for Episode 2!
If you want to know more about SourcePoint, please feel free to visit our website here. There’s an excellent video of the GUI which shows the ease-of-use and power of the tool on that page. You can also request a live demo here.