Wednesday, 14 April 2010

Cross Compilers for the lpuck

Firstly, I should apologise for this blog post because it's not about the usual PlayerStage stuff. It's instead about how I made a cross compiler for a specific bit of hardware that we have in the York robot swarm and at BRL. It's not really useful for anyone but me...


Useless background information

In both these places we use epucks to do our research, however the processing power of the epuck is limited. To fix this Wenguo Liu at BRL designed an extension that runs linux (emDebian), which can be attached to the robots so that they can do all their processing onboard (so they can run Player!). The result is called an L-Puck.

Back to the point...

Anyway, these linux boards run emDebian on the AT91SAM9260 processor which is an ARM architecture. To compile stuff locally on the robots takes FOREVER, and some of our Player code is pretty big. Anyway, I've been trying to make a cross-compiler which can compile the player code on the computer so that we just have to copy over a binary. Much faster!

My Learnings About Cross Compilers

  • The stuff you use to turn code into an executable binary is called a toolchain. For linux systems this isn't just gcc but g++, ar, as, strip, ranlib and a whole bunch of other things too, all of which are important even if you don't think you use them.


  • Crosstools is a very useful tool for building cross-compiler toolchains, but it's not updated very often and I had to revert to an old version of gcc to get it to work. Not to mention numerous other troubles like stack overflows and stuff that running it caused. I did get it to build a generic ARM compiler, but it didn't work for me.


  • TomTom (the satnav company) provide a very useful pre-built version of the arm-linux- toolchain here, but that also didn't work for me.


  • This is the most important thing: if your processor is running some kind of embedded linux, stuff compiled for your processor to run just won't work. Your binary is going to be run by your OS not by the chip


  • Scratchbox and Qemu are useless because there's absolutely no information (that I could find anyway) about how to actually use them once they're installed.


  • The embedded debian project is very well documented and good!


  • How I actually built the cross compiler

    After realising that compiling stuff for the ARM processor wasn't going to get me anywhere I looked at how to compile stuff for emDebian, and there's loads of information about making emdebian cross compilers for ARM chips. RESULT!
    In a nutshell, I followed the instructions here: http://wiki.debian.org/EmdebianToolchain and it worked. Where they say $ARCH I used "armel". Doing $ apt-cross -a armel -u didn't update anything for me, and I skipped the $ apt-cross -a armel -i $LIBRARY step because I don't have any libraries that I want to install. Doing this will install the arm-linux-gnueabi toolchain, so to cross compile you use arm-linux-gnueabi-gcc instead of gcc. It should have installed the binaries (or symlinks to binaries) in the /usr/bin folder so you don't need to specify any kind of path.

    I tested the arm-linux-gnueabi toolchain with a simple helloworld program, cross compiled it, copied it onto the robot and it worked!

    1 comment:

    1. Thanks for this post Jenny, I had a quick look at cross compiling and gave up just where you decided to check out emDebian :)

      ReplyDelete