I’d been using a rather old Sandy bridge system (Intel DQ67EP + i7 2600S) to test my work on meta-measured for a long time. Very nice, very stable system. But with Intel getting out of the motherboard business I started eyeing their new venture: the NUC.
The DC53427HYE vPro IVB NUC
Everything is getting smaller and thankfully Intel has finally caught on. Better yet they’re supporting TXT on some of these systems and so when the Haswell NUC was released over the summer the price on thevPro Ivy Bridge NUC (DC53427HYE) finally dropped enough to put it in my price range. Intel opted to skip the vPro NUC for Haswell anyways so it was my only option.
Let the fun of testing TXT on a new system begin! Like any new system we hope it works “out of the box”. But with TXT, odds are it won’t. My SNB system was great but this NUC … not so much, yet. The kicker though is that as systems get smaller something’s got to give. Space ain’t free and … well who needs a serial port anyways right?
Where’s my serial?
So without serial hardware, debugging TXT / tboot is pretty much a lost cause. Sure you can slow down the VGA output with the
vga_delay command line option. But if you want to actually analyze the output you need to be able to capture the text somehow and setting
vga_delay to a large value and then copying the output by hand doesn’t scale (and it’s a stupid idea to boot). So the search for serial output continues.
To get TXT we must … ::cough:: … endure the presence of the Management Engine (ME) and it’s supposed to have a serial console built in. The docs for the system even say you can get BIOS output from the ME serial console. But for whatever reason, I spent an afternoon messing about with it and made no progress.
I’ve no way to know where the problem with this lies. There are tools for accessing the ME serial console for Linux but I couldn’t get early boot output. Setting up a serial console login for a bare metal Linux system worked but no early boot stuff (BIOS, grub or tboot). Judging by the AMT docs for Linux: you can’t count on the ME serial interface for much. The docs state that if you use Xen then the ME will get the DHCP address all messed up and that setting a static address in the ME interface just doesn’t work. So long story short, the ME serial interface is limited at best and these limitations preclude getting early boot messages like those from tboot.
Now that the ME bashing is done we must fall back on real serial hardware. Thankfully this thing has both a half height and a full height mini-PCIe slot and a market for these arcane serial things still exists. StarTech fills this need with the 2s1p mini PCIe card. This is a great little piece of hardware but the I/O ports aren’t the default (likely to prevent conflict with on-board serial hardware) so we’ve gotta do some work before tboot will use it for ouput messages.
We have serial! Now what?
With some real serial hardware we’re half way there. Now we need to get tboot to talk to it. Unfortunately just adding
serial to the
logging= parameter in the boot config isn’t sufficient. The default base address for the serial I/O port used by tboot is
0x3F8 (see the README). This address corresponds to the “default serial port” aka COM1. So our shiny new mini-PCIe serial hardware must be using a different port.
tboot will log to an alternative port but we need to find the right I/O port address for the add on card. If you’re like me you keep a bootable Linux image on a USB drive handy for times like these. So we boot up the NUC and break out
lspci to dump some data about our new serial card:
02:00.0 Serial controller: NetMos Technology PCIe 9912 Multi-I/O Controller (prog-if 02 ) 02:00.1 Serial controller: NetMos Technology PCIe 9912 Multi-I/O Controller (prog-if 02 )
Not a bad start. This card has two serial ports and it shows up as two distinct serial devices. To get the I/O port base address we need to throw some
lspci. I’ll trim off the irrelevent bits:
02:00.0 Serial controller: NetMos Technology PCIe 9912 Multi-I/O Controller (prog-if 02 ) Subsystem: Device a000:1000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: I/O ports at e030 [size=8] Region 1: Memory at f7d05000 (32-bit, non-prefetchable) [size=4K] Region 5: Memory at f7d04000 (32-bit, non-prefetchable) [size=4K] Capabilities:  MSI: Enable- Count=1/8 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 . . .
02:00.1 Serial controller: NetMos Technology PCIe 9912 Multi-I/O Controller (prog-if 02 ) Subsystem: Device a000:1000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 18 Region 0: I/O ports at e020 [size=8] Region 1: Memory at f7d03000 (32-bit, non-prefetchable) [size=4K] Region 5: Memory at f7d02000 (32-bit, non-prefetchable) [size=4K] Capabilities:  MSI: Enable- Count=1/8 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 . . .
The lines we care about here are:
Region 0: I/O ports at e030 [size=8] Region 0: I/O ports at e020 [size=8]
So the I/O port address for
0xe020. The 9 pin headers on the board are labeled
S2 so you can probably guess which is which. With the NUC booted off my Linux USB key we can dump more data bout the hardware so we know for sure but with a serial cable hooked up to
S1 I just threw some text at the device to see if something would come out the other end:
echo "test" > /dev/ttyS0
Sure enough I got
"test" out. So I know my cable is hooked up to
ttyS0. Now to associate
/dev/ttyS0 with one of the PCI devices so we can get the I/O port. Poking around in sysfs is the thing to do here:
ls /sys/bus/pci/devices/02:00.0/tty/ ttyS0
With all of this we know we want tboot to log data to I/O port
0xe030 so we need the following options on the command line:
Now that I’ve got some real serial hardware and a way to get tboot to dump data out to it I can finally debug TXT / tboot. We’ll save that for next time.