Log in

Previous Entry | Next Entry

A tangle of cables...

What happens when you put a geek and a JTAG debugging board in the same room with each other? Mayhem, that's what.

It turns out that gentoo's support for ARM is a bit exaggerated: every time I tried to emerge a new package, it turned out not to be supported on ARM. I don't know enough about gentoo's culture to know why this is, or what it means, but the bottom line was that after bypassing the missing or excluded keywords on about five packages, I came to the conclusion that I was barking up the wrong tree: if gentoo requires me to customize and debug every package I install, why am I bothering with a distribution? Why not just build everything from source ad hoc?

I decided that it was worth seeing if NetBSD would boot on the machine. So I checked out -current and built it on my somewhat sluggish old AMD system. It turned out, after I'd finished building NetBSD from source, that in fact NetBSD does not boot on the machine. But heck, I've got the source, and I've got a JTAG board, and there's no reason not to at least try to figure out why it's not booting, right?

What you see above is the dreamplug (the yellow thing with green lights) plugged into the JTAG board (the little black box with the colored wires coming out of it). It's also plugged into the powered hub, which is on top of the 1T disk drive I mentioned in the previous post. The hub is the thing that's glowing blue.

The white cable plugged into the side of my Macbook is connected to the JTAG board, and gives me both a serial console on the dreamplug and control of the JTAG board for debugging. The blue cable is the ethernet cable, which is directly connected to the Dreamplug, allowing me to transfer files to it over the network.

This probably looks like a frightening tangle, but it's actually pretty slick. Last time I used a low-level hardware debugger, it was an HP logic analyzer, and I had to pull out the CPU to stick the analyzer in between it and the motherboard (this was back when a 12MHz CPU was still respectable, and the CPU in question was a 68020). So this is really a lot neater.

What the JTAG board does is to connect to a control port on the CPU and, under command of my debugger, tell the CPU what to do. It can send a reset. It can stop execution. It can examine registers. It can change memory. All the good stuff that you'd want to be able to do, it can do.

To control it, there's a program called OpenOCD. OpenOCD, aptly named, is the software that actually exerts the control over every detail of the behavior of the CPU by controlling the JTAG board.

OpenOCD is a pretty neat tool, and as the name suggests, it's open source. Unfortunately, the version in the repository didn't work for me. I don't know if it was a 64-bit versus 32-bit issue, or if the Marvell folks made some changes to OpenOCD to get it to work that haven't been integrated into the OpenOCD repository yet. Marvell provides a binary version of OpenOCD that does work, but it wouldn't run on my AMD server, because it's a 32-bit i386 executable, not a 64-bit executable.

So to get OpenOCD to work, I wound up doing a fresh install of Ubuntu on a VMware partition on my laptop. Although it's possible to run 64-bit versions of Ubuntu on the Mac, I installed a 32-bit version so that it would be compatible with the binary from Marvell. This worked: I was able to sync up with the JTAG board using OpenOCD, and control the CPU.

However, OpenOCD is not a debugger--it's just a control layer. The debugger is gdb. Gdb talks to OpenOCD using a standard (ish) network debugging protocol. I had to cross-build gdb to target the arm cpu, since it was running on an i386 version of Linux.

I found that in fact the version of OpenOCD that Marvell is shipping doesn't work perfectly—hardware breakpoints aren't supported. This was a problem because I wanted to stop execution of the kernel after loading it, but the kernel isn't there when I set the breakpoint—it's still at the load position. U-boot copies it into its final position for running when I tell it to start, so there isn't an opportunity to set a breakpoint after it's copied but before it's started.

To get around this, I had to recompile the kernel with a breakpoint as the first instruction on startup. Then I had to mash the program counter to skip it over the breakpoint. This causes gdb to hang, so every time I debug, I have to start OpenOCD, start gdb, load the kernel, run the kernel (which triggers the breakpoint), mash the program counter (set it to 0x8004 to skip over the breakpoint instruction at 0x8000), and then kill it (since it's hung, I can't just quit) and restart it.

*Finally* I can debug the kernel. The weekend's over, but I feel pretty good about getting this far. It wasn't really what I intended to do with the Dreamplug, but it's kind of fun to do a little embedded system work after all this time.


( 5 comments — Leave a comment )
May. 16th, 2011 09:54 am (UTC)
Very cool. I keep toying with the idea of getting an FPGA development board to have similar experiences of pain/fun.

My last gig's lab was truly magnificent: 20GHz scope, PCIe gen 2 analyzer, a Cadence Palladium emulating two chips and an interconnect, and a host of other toys. So incredibly spoiled.
May. 16th, 2011 01:15 pm (UTC)
Nice. I haven't seen any in-circuit emulating tools in real life in a long time--I don't know how they manage with the signal frequencies they're using now. The contraption we used with the 68020 would have been useless at 20Ghz--the wires would have turned into inductors.
May. 16th, 2011 11:38 am (UTC)
Impressively geeky!
Sep. 14th, 2011 01:11 pm (UTC)
still happy ?

for some reasons, I wanted a mini computer that is not x86 based and I wanted to run Net/OpenBSD... well, didn't take me too long to figure out that I was maybe too picky :). However, I am happy to see that someone ported NetBSD on the dreamplug, good job !
Are you still happy with it ? does it work correctly ? Actually, I was thinking about buying the *openrd*, the box looks amazing (maybe a bit overkill for me), but I am kind of afraid not to be able to install an OS (!= linux) on it or not have the correct drivers :/.

Thanks for your reply !

Sep. 14th, 2011 01:46 pm (UTC)
Re: still happy ?
The dreamplug is okay, but not great. I would actually suggest that you look at the Raspberry Pi low-cost ARM PC project. The problems with the dreamplug are:
  • No wifi driver yet on NetBSD
  • ESATA driver isn't reliable
  • The CPU is really slow, slower than you would think at 600MHz
The last issue is the one that I think is most serious. I don't know why performance is so bad, but I'm not alone in thinking that it is. Apparently the Sheeva CPU just doesn't have a lot of oomph, compared to some of the newer ARM CPUs that are available, but the Dreamplug guys decided to go with it anyway.
( 5 comments — Leave a comment )