• Gumstix

    A Newbie's First Experience

    This is the account of one guy's experience getting started with the Gumstix single-board computers. My goal is to evaluate the effort levels associated with 1) getting the toolchain up and running, and 2) developing code in the resulting framework. My evaluation is on behalf of myself and a small team of robotics enthusiasts with varying levels of development experience. Our eventual goal is to be developing C++ code to run our racing robots.

    I've got very limited experience with Linux, and I'm accustomed to developing code in Visual Studio with Visual Assist installed. Hopefully this account will remain useful despite the slant in perspective associated with its author.

    A word of warning: this report collects some useful resources, but would not make a very good tutorial on getting started, as I made several mistakes, which I dutifully described as they happened.

    Also, apologies for the lack of photos - this has been put together hastily as I've been holding the whole group up with this eval.

    TOC

    Hardware Selection
    Checking the RoboStix for Life Signs
    Checking the Gumstix for Life Signs
    Have You Hugged Your Linux Today?
    Fedora on VMWare
    Connecting to the Gumstix In Linux
    BuildRoot
    Hello Gumstix!
    2) Cross-Compiling
    3) Running on The Gumstix
    1) Replacing the File System
    0) Replacing u-Boot
    My Kingdom for a Stable Build!
    Next Steps
    Conclusions

    Hardware Selection

    We wanted the most powerful processor available, so we ordered a Verdex XL6P. We also know that we're going to need a microcontroller on our robots to run PWMs, provide some general purpose IO pins, and so forth. The RoboStix seems to fit the bill perfectly, and also provides a way to power the gumstix. I think it's quite ingenious, from a marketing point of view, that you need to purchase an expansion board to power your gumstix. The RoboStix also provides access to the console serial port, so we can get started quickly.

    We're going to want access to USB later on (probably via the 24-pin connector on the GumStix), and we'll also want to hook up a CMOS camera, which means either using the USB interface to do so, or (much cooler) using the 120-pin connector and our own custom expansion board to run the cam via the PXA270 processor's "Quick Capture" interface. This is all beyond the scope of this initial evaluation, though.

    Ordering

    Placing the order, the Verdex plus Gumstix expansion board, plus a power supply, screws/standoffs kit, shipping and UPS (Canadian Extortion) fees, plus taxes (charged on delivery) came out to a CDN$315 purchase.

    It showed up pretty quickly, and first impression opening the box: it's even smaller than it looks on the web! I feel like I need an antistatic mat. And tweezers.

    Checking the RoboStix for Life Signs

    To get warmed up, I started with the less expensive board. All of the following is done without connecting the two boards together. Before doing enything else, I filed down the edges of the RoboStix board, which were pretty rough. Yup, I'm a perfectionist.

    I installed a 10-pin AVR ISP header on the board, following the pin descriptions here: docwiki.Gumstix.org/Robostix_I/O_pins#In_System_Programming_.28ISP.29. This is the standard AVR 5x2-pin header. Important: never plug into the ISP while the robostix is mounted on the Gumstix.

    Just to get the thing tested, I decided to program the AVR to blink some LEDs. I already had a setup for programming AVRs, so this part was pretty easy for me. I loaded up AVR studio (which I already had installed), with an AVRIsp MkII programmer plugged into my PC (which I also already had) and downloaded the simple flasher .hex file from here: docwiki.Gumstix.org/Robostix_samples#Simple_samples. Plugged my AvrIsp MkII into the RoboStix (via a 6- to 10- pin adaptor - unnecessary if you have a programmer with 10 pins already), programmed the thing with the .hex file, and powered it up. Voila! Nifty flashing LEDs. Good enough for me - on to the Gumstix!

    Checking the Gumstix for Life Signs

    I plugged the RoboStix onto the Gumstix, and powered it up. The LEDs no longer flashed. Hmm... reading here: docwiki.Gumstix.org/Robostix_u-boot, we find that this is normal, and will require some work later on. For now, I wanted to focus on the Gumstix

    Let's connect to this thing - I installed a header on the 4-pin console UART (aka FFUART) of the RoboStix. This is the 4-pin header just to the right of the ISP, and it connects to the UART that the Gumstix uses for terminal access. Pin descriptions are here: docwiki.Gumstix.org/Robostix_I/O_pins#UARTS.

    The FFUART connector on the Gumstix is at 5V - we need a level shifter to connect to PC. I won't describe this here, but it's pretty easy to build / purchase an RS232 level-shifter. Connect it to your PC's serial port and to the Gumstix console UART. I left the +5V pin on the robostix UART disconnected, and powered my max232 externally. This is probably unnecessary, and I'll be fixing it later.

    Hypterterm

    Time to connect to the Gumstix for the first time. I ran hyperterm and created a new connection as described here: docwiki.Gumstix.org/Connecting_via_Serial_-_Windows. Powered up the Gumstix and - WOW! Linux is booting in my HyperTerm window. More correctly, it's booting on this tiny little thing on my desk that might blow away if the breeze is too strong, using my HyperTerm as a display. Cool! Log in using the instructions at the web site above - username root, password gumstix. There's the Linux prompt. Neat.

    Version Info

    While I'm here, I decide to check the version info. At the command prompt, I issue the command "cat /etc/Gumstix-release | grep RELEASE" to determine the version of the file system. I get "1321". Alternatively, during boot of the Gumstix, press a key to interrupt the boot and get to the u-Boot prompt. This also displays a line, like

    U-Boot 1.1.4 (Mar 1 2007 - 17:10:55) - PXA270@600 MHz - 1321

    Looking through the Gumstix wiki, it seems both my u-Boot and file system versions are outdated.

    That's it for the hardware part of this report, folks: two measly connectors and an RS232 level shifter. The only other change I've made, so far, is to install a switch in the power cord leading from the wall blister to the Gumstix. This saves me having to unplug and replug the tiny little power jack, which I think might bust after several insertion cycles.

    Have You Hugged Your Linux Today?

    One of the first things that strikes you about the gumstix development environment is that you absolutely must be running Linux. Now, this isn't a tutorial on installing and running Linux - I wouldn't be qualified to write such a guide. In fact, anything I say about Linux in general should be taken with a grain of salt. When in doubt, this guide is linked to by the Gumstix wiki: Newbie's Linux Manual

    Your (easy) choices for running Linux are, as I see them:

    1. Install from a live CD, or
    2. Run Linux within Windows.

    Option 1) will let you dual-boot your Windows machine into Linux. It requires that you partition your hard drive in order to dedicate space to Linux. The partitioning experience isn't always a smooth one, and I'd recommend a backup of your cherished data beforehand. Or just buy a second hard drive and use that. I've only ever Live-CD installed Ubuntu onto a dedicated hard drive. It's specifically designed to be easy to install, and it was.

    Option 2) has some distinct advantages, which just about make up for the slogginess of it all. There are some sub-options here, including:

    • a) VMWare running Fedora, or
    • b) CoLinux

    Note that the choice 2c), "Run Linux from within Windows using Cygwin", is not encouraged - the Gumstix website indicates it's possible in theory, but no one seems to know how (or no one is willing to spend the time required) to do it.

    For the purposes of this evaluation, I've opted for 2a, since it a) lets me easily switch between windows and Linux, and b) seemed better documented on the Gumstix site, implying they'd actually tested their process on it. I was scared off of CoLinux because Cygwin is basically unsupported, and CoLinux looked to me to be the same idea. In retrospect, CoLinux does look pretty cool, and I think I will give it a try, as VMWare is, in the end, a little slow, and CoLinux promises to do better. This page might come in handy for those wishing to check it out: Colinux Setup.

    One additional point that came out of my presentation to the team is that VMWare may let us share entire virtual machines - this would mean that one of us could get a working setup configured, then we could all copy his image and be on our way. This is very cool.

    Fedora on VMWare

    Alright, so I'm going to install VMWare (free) and run Fedora Core 6 Linux on a virtual machine from within Windows, as described here: docwiki.Gumstix.org/Buildroot_on_Windows.

    I Downloaded VMWare (I got "Latest Version: 2.0 | 5/09/07 | Build: 45731"), and got the Fedora Core 6 image for VMWare. I didn't get the most recent version just to be failsafe on this first try - v6 is what's described on the Gumstix website, so I know their stuff works on it. Installation worked on the first try. Awesome. Username: "root", password "thoughtpolice".

    Still following the webpage linked to above, and with Fedora running on VMWare, I ran the very long update process to get everything up to date. The update process had an issue - checking the error message, it seemed two packages (gaim and pidgin) were interfering, so I deselected them both, and tried the update again. The main update worked (it took a long time). I then re-ran it, and updated just pidgin, then ran it a last time, and updated just gaim.

    Next I configed the Fedora core to use the PC's serial port as /dev/ttyS0 (still following the web page linked to above - the .vmx file is in the folder where I saved my virtual machine). Also resized the desktop to fit my screen. Also installed the required packages (autoconf, automake, bison, ...) - I had to retry for gcc, as I got an MD5 checksum error on the first try, and the virtual machine locked, requiring a reboot. This lock-up was probably related to some faulty RAM I had just installed, incidentally - I haven't seen VMWare crash once otherwise.

    Connecting to the Gumstix In Linux

    First I closed hyperterm in Windows (so the virtual machine could use it), and made sure the serial port button of VMWare was active. Following the instructions here: docwiki.gumstix.org/Connecting_via_Serial_-_Linux#Connecting_with_Minicom, I ran "minicom -s" as root.

    Alright, that last statement needs some clarification for us n00bs. First off, a word on root: I've learned that logging in as root is evil - you should create an account on Fedora using Sytem->Administration->Users and Groups, and log into that account instead. You should also change the root account's password from its default VMWare value of "thoughtpolice" using Sytem->Administration->Root Password). To get a command prompt, use Application->Accessories->Terminal. To run a command as root, use the "su" command, and enter the root password, then run the command. Don't forget to exit out of root when you're done.

    Using this trick, I completed the instructions on the website above, and ended up at the Gumstix Linux prompt again, with no hitches. Awesome! I also went ahead and tried the instructions for transferring a (small test) file to the Gumstix. Worked like a charm the first time. Issuing the command "cat FileIJustTransferred.txt" on the Gumstix outputs the file's contents to the terminal. Nifty! I'm easily impressed at this stage of the game, and feeling pretty happy about how smoothly things are going.

    BuildRoot

    The whole reason for this Linux thing: The Buildroot (docwiki.Gumstix.org/Buildroot). Like the site says, this is the magic that lets us make an operating system, and programs, for the Gumstix, right from the comfort of our own (virtual) desktop.

    A note, before we start, to the Subversion n00bs (hey, here's something I already knew!). Subversion rocks. Take the time to learn how to use this tool, at least with its easy-to-use Windows client, TortoiseSVN. This will save you mucho time when dealing with your own code. You can buy me a beer later. Go here to get it for Windows: TortoiseSVN (you don't need to install a subversion server, just install TortoiseSVN, and read the TortoiseSVN help; if you want more information, or help with the command-line version, check the SVN book).

    Following the buildroot website's instructions, I got the trunk version of the BuildRoot using SVN:

    svn co http://svn.Gumstix.com/Gumstix-buildroot/trunk Gumstix-buildroot

    This was a mistake. Trunk is not stable. I recommend you identify and check out a version which is known to work, rather than getting the most recent version of trunk. Read on to see how I learnt this the hard way.

    I built using the instructions for "revisions of buildroot from 1445 to present":

    cd Gumstix-buildroot
    make defconfig
    rm .config
    make (entering 12(verdex); speed 4(600MHz) and default settings for any "new" features not documented in the wiki)
    make

    That last command takes a loooong time. Seriously. Hours. And it stopped about half-way, with an error to do with a package called gpsd...something_or_other - the build process aborted. It seems the file was downloaded to the wrong location - directly into Gumstix-buildroot, instead of into Gumstix-buildroot/dl. I moved the file from the buildroot folder into the dl folder, and restarted make. It went on for a couple more hours without errors, and out popped "my shiny new file system". Neat.

    Hello Gumstix!

    Alright, that took a long time (goodbye Sunday afternoon), but now I've got the most recent filesystem built. Just a few more steps to "Hello World":

    1. Flash the new filesystem over to the Gumstix. The binary we make in 2) isn't guaranteed to be compatible with the (older) file system on the Gumstix, so we replace it with the current one. (take this with a grain of salt - see below)
    2. Make a hello.c file and use the buildroot to (cross-)compile it into a binary that will run on the Gumstix.
    3. Reboot the Gumstix with the new filesystem loaded, transfter the binary over, and run it.

    Since I felt like living dangerously, I skipped step 1 in a first go. It seemed to me that a program as simple as "Hello World" would probably not be very different for two different versions of the same file system. Also, doing this first is actually a little less risky, in a sense, as it establishes that the toolchain is cross-compiling correctly before trusting its newly-built filesystem on our precious Gumstix. SO.... without any further ado, here are the steps to "Hello World", taken entirely out of order:

    2) Cross-Compiling

    We need a simple test file, hello.c. If you like, you can just download it from here: docwiki.gumstix.org/Hello_World, but part of my goal here was to set up a workable tool chain, so I decided to code my own - wow, how elite am I, hey? So I started by installing an old friend of mine: emacs. You may prefer to ues vi, or one of the other billions of options open to you for text editing. If I wanted to generate forum traffic, I could start a holy war around this topic, I'm sure.

    For n00bs: to install emacs, I just did "yum install emacs". I'm starting to like this package installer thingy.

    I used emacs to enter a simple hello world, and saved as hello.c. I've chosen to put my files in a folder parallel to the buildroot. Now, following the instructions at the Hello World wiki page, we need a simple makefile. I decided not to do this the hardcore way, and opted instead to download the file off the website.

    I started by running firefox (in windows), finding the file, and realizing I can't cut/paste or share files with the VMWare virtual machine. At least, not easily. Now, why would I run firefox in windows, when it came preinstalled in my Fedora? Running it straight in Linux, and saving the file alongside my hello.c, I've now got a working example.

    Issuing the command "make" in the folder containing hello.c faithfully produces the binary "hello" file. Just to confirm that this is compiled for a different processor (thus "cross-compilation"), I try running the binary ("./hello"), with the result "cannot execute binary file". Good!

    3) Running on The Gumstix

    Repeating the instructions I used to transfer a file using minicom earlier, I transfered my new hello binary over to the Gumstix. Then, at the Gumstix prompt, I tried again "./hello". This time, out popped that fateful phrase:

    Hello Gumstix!

    Having this work thrilled me a little more than I'd like to admit. This basically establishes that, after a quick day of installing Linux, updating it, and installing and building a cross-compilation toolchain, I was able to build an executable that'll run on a computer small enough to, in my opinion, warrant a "choking hazard" label. Spectacular!

    1) Replacing the File System

    I'm about to describe my experience with the most recent version of Trunk. You can save yourself some time by using a stable build.

    A couple days have passed - I still haven't mastered the art of not sleeping, and so an interruption was inevitable. This is not a single-day process. I start the day's activities by changing into the Gumstix-buildroot folder, and issuing the "svn update" command. Hey, some stuff actually changed in the couple days that I've been away. Cool. I then issue the command "make" to build my newly updated stuff... and... crap. An error message:

    ....gumstix-release: Permission denied.

    Crap, what could this be? Well, for a Linux n00b, this single error message could easily represent hours of work to figure out. Turns out, an hour later, I've got my finger on it: I was still logged in as root when I originally built my buildroot. This means I now have to be root any time I want to build it again. Crap. I intend to fix this, some day, by destroying and rebuilding my buildroot (this time, doing the build overnight). For now, I'll log in as root and retry the make. Hey, works fine. Alright!

    To get the filesystem that Buildroot made (it's the .jffs2 file), and the kernel (uImage), onto the Gumstix, I'll follow the instructions here: docwiki.Gumstix.org/Replacing_the_filesystem_image#Flashing_over_serial. I'd recommend reading the whole page through, as no single section contains all the explanatory notes.

    Since I have a uBoot version 1.1.4, I follow the instructions in the section with that heading:

    This was another mistake - read ahead before doing this, as it's probably not what you want to do!

    host> cd ~/gumstix-buildroot
    host> mkdir -p build_arm_nofpu/root/boot/
    host> cp uImage build_arm_nofpu/root/boot/
    host> rm rootfs.arm_nofpu.jffs2
    host> make

    This last make only took a short minute. I think I've just copied the kernel (uImage) into a location where it can piggyback into the filesystem - I'm deducing that anything that gets put into boot folder we just created will end up in the filesystem. Might be wrong. Let's move on.

    Alright, so we run minicom, reboot the gumstix, interrupt the boot by pressing a key, and issue the command

    GUM>loadb a2000000

    Then ask minicom to send a file, but this time I use the kermit option instead of the zmodem option. Nothing happens. Nada. No errors, no progress, nothing. I try again. Nada. I try with zmodem, and get a nifty window telling me it's trying, but of course uBoot isn't listening for zmodem, so this won't work. Alright, I guess they weren't kidding when they said we have to install kermit. Let's go figure that out.

    Installing Kermit

    At the linux prompt, "yum install kermit". Sweet. I add "yum install ckermit" to be sure. It says there's nothing to do. Sounds good to me. "man kermit" should, I understand, give me some help at this point. It does not. Typing "kermit" at the prompt should run something. It, also, does not. I'm left to believe that I haven't really installed kermit - the package manager has tricked me. I try Applications->Add/remove software, looking for kermit or ckermit in any of the views. There's no mention of kermit anywhere. Alright, let's do it the hard way.

    Following the instructions here: www.columbia.edu/kermit/ck80.html#unixbuild, I build myself kermit. I have to admit, the instrucitons are pretty n00b-friendly, although I have no idea where my man directories are, how to assign owner group and permissions, and don't really care to figure it all out right now. The point is, typing "kermit" at the prompt now gets me something, so I'm ready to move on.

    I also create a ~/.kermrc file, as described in the "minicom" section of the "updating your filesystem" wiki page. Careful: I've been running minicom as root, so the .kermrc file referred to by the statement "~/.kermrc" is /root/.kermrc, and not "/home/don/.kermrc". To be safe, I create both anyway.

    I have a sneeking suspicion we need to set up minicom to use the kermit we've just built. I run

    su
    minicom -s
    filenames and paths
    kermit program -> "kermit"
    save as dfl
    exit

    In retrospect, the above was totally useless. I tested, and again, nothing.

    I try a different tack. It seems one can execute the entire process from kermit itself. I follow the instructions on the wiki, and issue the command "kermit -c". It refuses the command line option. It's now midnight, and I'm running out of patience. I follow the instructions here: docwiki.gumstix.org/Tutorial (under "using kermit"):

    kermit -l /dev/ttyS0
    then all the other set commands found on the web page
    connect
    and hey, it actually connects! Let's see if we can send the filesystem over, shall we?
    GUM>loadb a2000000
    ctl-\ c
    kermit>send rootfs.arm_nofpu.jffs2

    Holy SHIT! It's actually transferring a file! Wow!

    Alright, it's done 4 percent in about a minute, and it always assures me it'll be done in about 30 more seconds. Right. I go to get ready for bed. It's done 10 percent. Well, at least I know this might actually work. I'll do it again tomorrow night. For now, I shut it down. Interrupting this should be safe, since the transfer is into the Gumstix RAM - nothing gets written to the flash until the next magic GUM> command is executed. I interrupt it, shut down kermit, and (to check what I said above) restart the gumstix and log in via minicom. Still alive. Cool. À demain.

    Kermit in Minicom

    Okay, it's another day. I'm feeling brave again today, so I start by re-tackling transferring from within minicom. Not sure why - some bizarre sense of pride, or maybe the half-justified notion that minicom is less cumbersome to use than kermit. Anyway, I start my evening with a good find: Minicom trivial fix to talk w/u-boot (scroll down to the big block of instructions starting with "1. install ckermit on a linux machine...").

    I follow the directions. Seems I forgot to replace the %l with %f in the "program" field of the "file transfer protocols" configuration screen, which tells minicom how to launch each type of file transfer. Of course. Also, I preemptively replace /usr/bin/kermit with /usr/local/bin/kermit, since I remember that's where it installed yesterday.

    Okay, let's give it a roll. I exit out of minicom, so as to get a running start. I change to the folder with the filesystem in it (/home/don/buildroot/trunk/gumstix-buildroot), and type pwd, then select and copy the path with ctl-shift-c. This is so I can paste it into minicom when it's time to find a file to send... for some reason, the file selection dialog doesn't start in my current directory when I launch minicom.

    minicom -o (I'm already logged in as root)
    I start the gumstix, and type a key in minicom to get to uBoot
    loadb a2000000
    ctl-a s
    I select kermit, [goto], ctl-shift-v to paste in the path, use the arrow keys to find the magic file (.jffs2), press space to select it, and then enter to go

    %lucking A! It's transferring! And hey, I've only got 30 seconds left. Well... I know that's not true (see last night's experience) but at least the damn thing's working! And all it took was replacing %l with %f. I might devefop an unfortunate habbit of repfacing the fetter f with the fetter f everywhere!

    A note on time: it seems you'd better have lots of it if you want to be replacing your filesystem via the serial link. On top of the hours-long build process, the transfer (it's an 8 meg file going at 115200 bits per second) is pretty long, There are other, faster options, so really I'm just whining at this point.

    While the download goes, I teach my girlfriend some html basics, make some tea, and read up on the next steps in this flashing process. Uhoh. Reading again in the U-Boot version 1.1.4 section, I notice, for the first time, the lines "If your U-Boot is 1.1.4 and compiled u-boot.bin is 1.2.0 ... [replace] U-Boot and then continue with 1.2.0 instructions". Crap. I have just two questions: where's u-boot.bin, and how do I check its version?

    Well, the first is easy: it's in the root gumstix-buildroot folder... good thing I looked. The next question: not so easy. I try finding it in the file explorer ... while I do, the kermit transfer finally finishes. Alright, no problem, the gumstix can wait. Let's find this version. I poke around online for a couple minutes. No dice. I try searching for u-boot using the Fedora file explorer thingy, and notice that there's a u-boot-1.2.0 file someplace in my buildroot tree, but no u-boot-1.1.4. Crap. Guess this means I'm replacing u-Boot.

    0) Replacing u-Boot

    I follow the instructions here: docwiki.gumstix.org/U-boot#Loading_new_stuff_to_flash. I read carefully, as replacing u-Boot, I understand, is risky business. I use the now-familiar minicom process for uploading a file - this one is much faster. I follow the recommendation on the web page and do a CRC check. I start by checking the local file, using the zip trick. 8bb87aaa. Nice. Now I check what the gumstix received. 8bb87aaa. Awesome! {I won't mention that I started out using round braces around the $(filesize) parameter to the gumstix crc32, yielding a result of 00000000, and ended up redoing the whole process just to make sure I wasn't mad. I'm not going to mention that, since I think it makes me look rather dim. Just make sure you use curly braces around ${filesize}. This incident may resuft in some more unfortunate habits on my part, but I digress.}.

    I enter the remaining magic sequence:

    GUM>protect off all (sends a shiver down my spine)
    GUM>era 1:0-1 (even worse)
    GUM>cp.b a2000000 0 ${filesize}
    GUM>reset

    Checking three times that all the braces are the right kind, there are no O's where it should be 0's, and holding my breath after that last enter... and... it reboots. Thank god. I reboot into u-Boot, and issue the "printenv" command to check out the default environment. Yup, looks pretty default to me. I type "saveenv" as directed by the wiki, and then "reset" and let it boot to the filesystem.

    "Bad Magic Number"

    Well, then. "saveenv", "reset".

    "Bad Magic Number"

    This relationship between me and u-Boot is getting off to a rocky start. Let's assume I need to reflash the filesystem for this thing to be happy. I start up the long file transfer again, and as it goes I get the CRC for my .jffs2 file: 75200f68. I also look online for a fanless media pc... my dvd player just bit it and I'm looking for something with wifi, so I can get a seamless experience from the workroom to the living room. At about this point I remember that I have followed the instructions for creating a .jffs2 file for u-Boot 1.1.4, and am now running u-Boot 1.2.0. Crap.

    Really, I've made this much harder on myself than I needed to, but hey, lessons learned and all that. Really just making it up now, I try to undo the first steps of the 1.1.4 instructions. I remove the boot folder's contents, and the folder, and reissue the make command from the build-root. A check of the CRC confirms that something changed. My new magic number is 8076d99b. Great! Let's go back to uploading. Hey, at least I'll remember the process, right? Practice makes perfect!

    minicom, u-Boot, kermit, yadda yadda yadda. More tea, more media pc search. Not a lot on eBay. Anyone know where to get a cheap solution? I basically just need something that'll connect, via wi-fi, to my pc, play mp3s and movies, and maybe accept dvds/cds locally. Huh. 30 seconds left. Go figure.

    crc32 a2000000 ${filesize}

    I note that the crc instructions are excluded from the page on updating the file system. Shame that, as it seems like an important feature. Mine matches. Good!

    pro on 1:0-1 && jera all && cp.b a2000000 40000 ${filesize}

    I make sure it's all correct, but am somewhat less anal than for u-Boot. I know I can redo any of this safely. I get a warning: 2 protected sectors. I assume that's u-Boot busilly NOT getting overwritten. Good thing! It takes a little while for the flash contents to be overwritten. MythTV looks cool. Maybe I can just buy a Fanless PC and run MythTV. Maybe someone else has done this and is selling them....

    So I ended up pressing enter before that previous command completed, and discovered that pressing enter at the GUM> prompt (or during a long process) repeats the previous command (once the long process is done - meaning the long process executes a second time). More web surfing for me. Maybe I just want a dvd player with wifi capability...

    Alright done now (again), I move on, and send the uImage file, and confirm the crc. It's alright. Moving on:

    GUM>katinstall 100000
    GUM>katload 100000
    GUM>bootm

    Hey, it's booting! Uhoh. What's that? I get some pretty funky stuff spitting out at me:

    garbage out

    So here's where I decide this document is long enough, and give you the reader's digest version of the rest.

    My Kingdom for a Stable Build!

    I spent some time in the Gumstix forum and found out that using the current version of trunk is probably not the right thing to do. I did some poking around and found a list of (presumably) working, pre-built file systems here: Dave Hylands' Gumstix-wiki Webspace. I grabbed the most recent one for verdex (verdex-1421), fired it over, and holy crap, the garbage went away! Alright, so this leaves, as I posted in the Gumstix forum, three questions:


    1. If I build 1421 myself, am I going to find the problem comes back?
    2. What's wrong with the new version of trunk that it messes up the display?
    3. Where can I identify stable builds as they become available, so as not to repeat this experience?

    Posting to the Gumstix forum, I got some very helpful comments. The answer I received to that last question - "where are the stable builds" - concerns me: "The official stable builds are the ones on sourceforge. There hasn't been a "stable" build for the verdex yet.".

    I've decided to ignore 2).

    To answer 1), I hunted down 1421 in the appropriate branch (since the Verdex only merged into Trunk as of version 1445) - I found the link on the "Buildroot on Windows" wiki page - it's a now-deprecated user branch. I grab it, and start the process of building it overnight.

    And that's it folks - time's up - I'm preparing this document for presentation to the club now, so I need to draw some useful conclusions with what I've already got done.

    Update: as expected, when I did get a chance to flash my own 1421 build over to the Gumstix, everything still worked fine. Bottom line: I could have saved an awful lot of time by just starting with 1421 instead of working with trunk. This probably seems obvious to even the most n00by n00b, and if not, you've now read it and so you can save yourself some time. You can buy me a beer later.

    Next Steps

    Still within the context of evaluating the Gumstix, I want to do the following:

    • First, I want to get a C++ cross-compilation toolchain working.
    • Next, I want to try out CoLinux, to see if things run any faster.
    • After that, I want to evaluate the speed of the Gumstix in doing some basic image-processing stuff. This should include some floating point stuff, which has to be done with software on the Gumstix, as there's no FPU.

    Once we decide if the Gumstix is right for us, we're going to want to do the following:

    • Getting the RoboStix to boot while strapped to the Gumstix will be nice, and once that's done I can get some basic code running on the AVR to establish communication with the Gumstix.
    • We want to get a USB port working, so we can run a WiFi link - think wireless telemetry, and an end to sloooooow serial communication. This sounds like it might be difficult, as we're already using the 60-pin connector, and I don't see any products out there that'll break out the USB on the 24-pin connector for us.
    • We want to hook up a CMOS camera via the PXA270's camera interface
    • And use a couple existing projects (EmbedCV, Player/Stage) to get us running quickly.

    Conclusions

    Cost

    Money: For the setup I described at the top: $315 Cdn. No usb or camera interfaces yet. We chose the most powerful motherboard, and less costly ones are available.

    Setup Time: Building the file system is a very, very long process. Installing and updating linux was aso pretty lengthy. I estimate that these aren't frequently-executed procedures - thankfully. I still don't have a C++ toolchain going, nor have I messed with the menuconfig option of the make command to customize our file system. I think one could probably spend a lot of time just setting their toolchain set up the way they like.

    Development effort: once the file system is set up to our liking, I anticipate development should be pretty smooth. I said early on that I'm accustomed to Visual Studio with Visual Assist. Emacs is cool too, though. It's a matter of what you're used to. It may be possible to develop in Visual Studio and share the files with Linux, so as to launch a compilation from linux on code developed in Visual Studio, without making the process too cumbersome.

    Disk space: You need to run Linux. You need to build the buildroot. Total disk cost on my setup, using VMWare: 6.9 Gigs.

    Learning Curve

    I had hoped to get much, much more evaluated in the time that I had. I spent an entire weekend, and many evenings, getting as far as I am. This, in itself, speaks volumes. Hopefully it says more about the steep learning curve than it does about the one trying to do the learning!

    Keep in mind, I'm a Linux n00b, and a lot of my time was spent learning things which are not strictly part of the Gumstix product, but which are, nevertheless, requisites for working with the Gumstix.

    Stability

    One of our key motivations to trying out the Gumstix is that it's a well-established, functional and stable platform. The lack of a stable build for the Verdex bulidroot was deeply disappointing. I should think "no stable toolchain available - purchase at your own risk" would be in big red letters on the website where the Verdex is being sold. That said, the situation isn't as hopeless as it sounds, and I expect the version I've got now is at least functional, if not stable. It might fill our needs just fine, with no troubles whatsoever. It's just the unknown factor that bothers me - who knows what little glitches and bugs we're going to be first to find....

    One last note on stability: plugging the RoboStix into the Gumstix stops the RoboStix from booting. Reading this page: docwiki.gumstix.org/Robostix_modifications, it seems some hardware modifications to the RoboStix may be needed. This page: docwiki.gumstix.org/Robostix_u-boot presents some changes to u-Boot associated with these issues. I haven't sorted through which of these changes I need to make, but the overall impression in buying >$300 worth of hardware, hooking it together, and finding it doesn't work together without manual hardware fixes on my part is... well... let's just say it could be better.

    Support

    Community: the folks on the Gumstix forum seem very helpful. I got helpful answers quickly, even with Dave Hylands off on vacation. I even managed to help one person out, with observations pertaining to the serial port made earlier in this report! It seems like a helpful, well-established community.

    Documentation: in order to complete the very minimal tasks described here, I had to refer to at least 10 different pages on the Gumstix wiki, and 6 other websites on how to use Linux, SVN, install kermit, configure minicom, and bail my ass out of that damn garbage out problem. There are (at least) two more pages I need to get through to fix the RoboStix booting problem. Alright, so that's a lot of different sources for what, ultimately, wasn't a lot of information. The kicker is, the information I did get wasn't always consistent or complete across wiki pages - CRCs aren't consistently mentioned on the wiki, the syntax for running kermit differs by page, and so on. Unimpressive.

    Overall

    The helpful community, processing power, and (unconfirmed) ability to easily integrate existing code in a standard toolchain are the Gumstix' main strengths.

    The lack of any centralized / consistent documentation, exacerbated by the steep learning curve, is its main drawback. This is especially true for those with limited Linux experience.

    For our club's needs, it comes down to this: do the benefits outweigh the drawbacks? Our decision had to include the obvious additional factor that if we chose not to go with the Gumstix, we have to find something better, and evaluate it

    I presented the main points of this report to our group a couple days before posting it. Discussion brought to the foreground our priorities, which are a powerful, inexpensive platform that's easily expanded. The fact that it runs Linux, provides plenty of power for what we need to do (despite the lack of FPU), and has a strong existing community means we've decided to bite the bullet and go with it.

    To help us deal with the poor documentation and steep learning curve, we have acquired a copy of "Embedded Linux Primer" by Hallinan (with recommendations), and we'll probably end up relying heavily on the strong community surrounding both embedded linux in general, and the Gumstix in particular.

    This has been the frank account of one newbie's first experience with a Gumstix processor. I hope it's been useful!
    Don

7406 visits