June 2009 Archives

In addition to the information on the wiki, here are my instructions for getting GDB to work with an OpenMoko debug board for the purposes of debugging the kernel.

Debugging requires three things: libftdi (the library which facilitates access to the JTAG chip used in the debug board), OpenOCD (which turns GDB-speak into JTAG-speak) and a GDB which understands ARM-speak.

First, download gdb-6.8.tar.bz2 from the GDB homepage.  That's the latest stable version at the time of writing.  Later versions, if and when available, should also work.  Configure GDB to target an ARM processor running a Linux kernel and using the GNU EABI, and get it compiling:

$ ./configure --disable-werror --target=arm-linux-gnueabi
$ make

While that's cooking, get libftdi and libftdi-devel from your distro repositories.  Version 0.8 or later is required.  Version 0.13, as found in Ubuntu Jaunty (9.04) works fine.  Failing that, get the source code and build it yourself.  Having installed that, get OpenOCD from the SVN repository and compile it.  Revision 130 is known to work.  The syntax of the configuration file has been changed in later versions - the wiki has some information about how to use the new format as well.  You must tell OpenOCD that you want to enable ft2232 via libftdi:

$ svn checkout -r130 svn://svn.berlios.de/openocd/trunk openocd
$ ./bootstrap
$ ./configure --enable-ft2232_libftdi
$ make
$ sudo make install

By the time you've done that, GDB has hopefully finished compiling.  Install it in the usual way - the name of the executable will be prefixed with the host triplet, i.e. it will be called "arm-linux-gnueabi-gdb", so you don't need to worry about overwriting your "conventional" GDB version already installed:

$ sudo make install

You're all set for some debugging action.  To run GDB, first connect the debug board to the phone using the FPC cable (otherwise known as the Flimsy Plastic Cable - take care with it), connect the debug board to a USB socket on your computer, start the phone then start OpenOCD.  If you got your permissions right, you won't have to run it as root:

$ sudo openocd

If you don't get error messages from OpenOCD, it's working.  Note that the debug board must be powered up and the phone switched on before OpenOCD can be started.  If you're debugging things which happen soon after startup, you just have to get quick at doing this and the next step.

Now start GDB, giving it the path to the "vmlinux" file which corresponds to your running uImage:

$ gdb GTA02_drm-kms/vmlinux

Tell GDB to connect to OpenOCD with

(gdb) target remote localhost:3333

and you should see GDB halt the processor at a particular point, with it telling you where that is.

Note that you can do all of this whilst watching the serial console with a terminal emulator such as GtkTerm.

I noticed there were some big holes in the OpenStreetMap the area around here, so I took my FreeRunner out and acquired some GPS traces using TangoGPS.  Using a script from the OpenStreetMap wiki, it was simple to convert from the log file format of TangoGPS into a GPX file for import into OpenStreetMap.  Then I could draw over the lines to create this nice-looking map of the area.  I also tweaked a few other features around the town in the map.  It's not perfect, but it's much better than the large empty patch which previously existed in the west of the town.

I found the map-making process to be quite fun.  I found out a few things I didn't realise about the shapes of roads and areas, and even discovered one or two streets I never knew existed.

Now that I've got rid of my thesis, it's time to dig my teeth into some fun stuff.  I came across a problem with our current DRI architecture for the FreeRunner, which involves trying to combine DRI2 with an existing fbdev-based X driver.  The problem arises because we tell EXA that we will allocate memory for pixmaps ourselves (in this case using our GEM interface through libdrm).  But, in that case, the X server will attempt to allocate the "screen pixmap", by which I mean the main front buffer which contains what's on the screen, with the same mechanism.  This wouldn't be a problem if we could tell, at the time of allocation, that the pixmap being allocated is the screen pixmap, but we can't.  At least, not in the tests I've performed.

The "right" way to make this all work is to use kernel modesetting, KMS, to submit the screen pixmap - at a later time - to the lower-level graphics system for display.  The execution flow goes something like this:

1. Tell EXA we'll handle pixmap allocation.
2. At an unspecified point, the screen pixmap gets created via our mechanism.
3. Later on, we submit the screen pixmap (in fact, just its GEM handle) to KMS.
4. KMS programs the graphics hardware to display the contents of the buffer on the screen.

Currently, we have this:

1. Open /dev/fb0, mmap() it.  That's what's on the screen.
   
2. Tell EXA we'll handle pixmap allocation.
3. At an unspecified point, the screen pixmap gets created via our mechanism.
4. Contents of /dev/fb0 are not the same as the screen pixmap.
5. Whoops.

KMS is really deeper than I (or rather we, thanks to welcome help from Andreas) wanted to dig into the Openmoko graphics system.  Essentially it constitutes a re-writing of the entire kernel framebuffer (glamo-fb) and the X.org driver (since we would need a new driver based on xf86-video-modesetting to take advantage of KMS).  However, there is also a possibility that moving complete control of the graphics hardware to the kernel will help stabilise some things.  At least in the long term.

I took advantage of Truebox's half price deal on debug boards, not knowing how I'd managed to get this far without one.  The kit came complete with screwdriver and guitar plectrum for opening the case (sooo much better than the cheap screwdriver and credit card combination I was using before), and they were kind enough to throw in a spare battery at no extra cost.  Thanks Truebox!

Ok, so it took me a little while to announce it, but I submitted my PhD thesis last Friday.  That means I never, ever, have to write another thesis again.

This is a good thing.

I'm still here, I've just been busy with thesis. For the time being, enjoy this video which I came across just now.