ARM Community: Using DS-5 with Gumstix Overo - ARM Community

DS-5 Application Edition can be used to debug a Linux application running on pretty much any ARM Linux target, with a network connection, not just the BeagleBoard that is used in the examples. Ronan, a colleague of mine, saw the cute Gumstix Overo COM (Computer-on-Module) and convinced me I needed to get one and give it a try with DS-5.




First I ordered the Gumstix Overo Water, but any of the Overo models (Earth, Air, Fire) will probably work the same for my purposes here. I also ordered a Gumstix Tobi so that I can easily hook it to Ethernet and/or USB.

The Gumstix developers website has great getting started material. There seem to be at least two other useful Gumstix websites as well: www.gumstix.com, and docwiki.gumstix.com. But the developer site pretty much assumes that your host PC is running Linux. Mine's not but I decided to forge ahead to see how far I could go before I got stuck.

First thing is to mount the Overo on the Tobi. This is easily done. My Overo only came with two plastic spacers and has four mounting holes for them, but maybe two fell out when I opened up the package to show everyone how tiny it was. Anyway I put the two spacers in diagonally opposite corners, checked the orientation and gently seated the Overo COM on the Tobi.

Following the getting started instructions, I found a standard-A to mini-B USB cable (for some reason I have lots of those) and connected the "console" USB OTG port on the Tobi to my Windows XP machine. An LED on the Tobi lit reassuringly. The host detected the USB device and wanted to install two drivers one after the other and then a USB COM5 port showed up. So far so good. I opened PuTTY on the COM5 port and was ready to power on the Overo (the USB OTG can't supply enough current to run the whole Overo/Tobi).

At this point I realized that I had already made my first mistake: I didn't order a power adapter. I have lots of 5V power adapters but the power socket on the Tobi is very fine and most of them didn't fit. I was lucky though and I managed to scrounge around and find one with the right plug (originally for a USB hub that's not currently in use). Then I spent a while trying to make sure my adapter had the correct polarity: I found the Gumstix Tobi schematic and convinced myself that it said "centre positive" was what I needed. I "borrowed" a multimeter and a fine paper clip and determined that my adapter was, in fact, centre positive. Hurray!

I plugged in the power and was greeted by the usual, friendly X-Loader, U-Boot and kernel boot messages in PuTTY. (Well, "usual", if you've played with other OMAP35x devices like BeagleBoards, anyway.) More Hurray!

The initial boot took a few minutes as lots of the packages did their initial configuration; but with some patience I got a login prompt and five keystrokes later was root.

At this point the getting started instructions advise you to download the latest images and update the NAND on the Overo - I decided that was boring and could wait until tomorrow. (Maybe I should start downloading the images though.) The kernel boot messages said it was version 2.6.32 which is recent enough for today.

Next I connected an Ethernet cable. It was a surprisingly tight fit, but I got it in and the link LEDs lit up reassuringly. By the time I could type 'ipconfig' the Overo had gotten an IP address from the local DHCP server.

Next I launched DS-5 on my Windows host, went to Remote Systems and created a new connection using the Overo's IP address and 'sftp' for file transfer. A few clicks later, and using userid=root and empty password, I was able to browse the Overo's file system from Eclipse. I opened an Ssh Terminal in Eclipse and logged in just to prove that worked, too.

A quick browse revealed that there was no /usr/bin/gdbserver. There is a pre-built gdbserver supplied with DS-5, but it needs libthread_db.so which was also missing from the Overo. It turns out that the Overo is running an Angstrom distribution which is based on the Open Embedded build framework so it's easy to install new packages using the opkg tool. Since the Overo is connected to the internet I did opkg update to update the package lists. There were a few complaints about debug lists not being found -- but not enough to worry me. Next I did opkg install gdbserver and sure enough a shiny gdbserver 7.0 was installed.

I created a Debug configuration (gory details below*) and clicked Debug. Soon I was in the DS-5 Debugger, debugging Gnometris to my heart's content.

In summary, it was easy to get DS-5 Application Edition working on an ARM Linux platform that I had never used before.

More Notes:
The Overo comes with a gumstix-logoed, 8GB micro SD card which, following the directions, I had not inserted yet. I decided to backup first thing. The whole card bzip2ed down to 6.6K -- turns out it was just a blank FAT file system.

The micro SD card can be written so that the Overo can boot from it. In fact getting booted from the micro SD card is the first step in updating the built-in NAND flash.

I should update the NAND now, but the postman has just brought me another new target -- maybe I'll have a little play with that first...

Debug configuration details:

Connection: Generic - gdbserver, Download and debug application; chose my RSE connection;


Files: chose the unstripped gnometris as the application to download and checked Load symbols; /home/root as the Target download directory; added stripped/libgames-support.so as another file to download

Since the target doesn't need the symbols, I could have instead saved a little space on the target by downloading the stripped/gnometris and added loading the symbols from the unstripped version.

Debugger: added the top-level gnometris project directory from the workspace as a Shared library search directory.


Arguments: added --display=:0 to have gnometris display on the Overo's X server display (I could have added DISPLAY to the Environment tab instead).

Scott Douglass, Principal Technical Specialist, ARM, Scott works within the ARM tools marketing team and is responsible for putting together demos, workshops and such. For a number of years Scott has worked on compilers (armcc), debuggers and on the Apple Newton, an early ARM-powered PDA. Yet with all his experience Scott still fancies himself a software engineer at heart.

Shortlink to this post: http://bit.ly/ckocZz