About my blog
I am multithreaded, and sometimes the threads get tangled.
- December 2012 (1)
- March 2012 (1)
- December 2011 (1)
- May 2011 (1)
- April 2011 (1)
- March 2011 (1)
- January 2011 (1)
- December 2010 (1)
- October 2010 (2)
- September 2010 (1)
- June 2010 (1)
- May 2010 (1)
- April 2010 (3)
- February 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- August 2009 (2)
- July 2009 (1)
- June 2009 (2)
- May 2009 (1)
- April 2009 (2)
- March 2009 (6)
- February 2009 (5)
- January 2009 (3)
a Studiolab production.
the wind I am enjoying
I am writing this, of course for my own purposes, which include controlling a large number of outputs. I would like, as a first exercise in controlling stuff from the FoxBoard, to take over one of Daniel Saakes Lampan lamps (read the instructible) and control the individual lamp units. This means -for now- 12 output ports. The ports will be provided by the Foxboard LX, a single board computer that runs Linux – in other words a quiet, cheap, silent and hackable computer smaller than a postcard.
To have an idea of the size of the board, keep in mind that the big metal thing in front is an Ethernet socket and the two meta ports on the right are USB sockets (perfectly working, by the way).
To develop on the Foxboard LX you need to use a development machine that runs a specialized SDK environment. This is where you do most of the programming and configuring. The results of your effort are converted into an "image" file, that consists of a complete image of the board’s filesystem. The image is then written into the flash memory of the board. The board then boots in about three seconds and does what it has been told to. To get to this, there are a few hoops to be jumped through.
Setting up the development machine
in my case is a standard DELL desktop box with really slow video hardware and 150 Gb of disk. Not that it matters: any box will do. On a very old/slow machine you will find that the image building becomes slow. This is a pure CPU + disk bound task, so you get what you paid for… I have installed Ubuntu 8.10, but again the distro should not be too critical.
Before anything, download for your psychological reassurance a "known good" system image from ACME, and put it somewhere safe. Flashing a FOX board is described in detail here by ACME, so I will not repeat it. Some background information is useful to write down, though: when you fflash the board you lose all content and configuration. It is equivalent to reformatting and reinstalling a desktop computer from scratch. Development on the FOX can proceed in two ways, mutually exclusive:
- build an image on the development machine, and then flash it to the board.
- Drawback: long turnaround time. You can’t really run code compiled for the FOX’s peculiar hardware on a common PC.
- Advantage: easy to turn into an industrial operation, you get to work on a full blown computer with a nice graphical interface.
- develop directly on the FOXboard.
- Drawnback: very limited environment, no fancy IDE. Limited storage space. Slow hardware.
- Advantage: realism! It is the delivery system.
Keep also in mind that certain elements of the configuration of the FOX are possible only through 1), such as recompiling the kernel and reflashing the board (e.g. the assignment of certain ports and the activation of components like WiFi or webcam drivers). Plus, the board cannot host its own C compiler (among other things).
In order to adapt the board environment (hardware setup, operating system and installed packages) to my needs I need an SDK. There are various possibilities for the SDK, and you can find them described on this ACME page. I have tried the Phrozen SDK with the FoXServe patches, And this is exactly what we are going to install!
First of all, let’s install the Phrozen SDK. Go the documentation page, pick the relevant instructions and proceed. If you are running Ubuntu, instructions consist of installing some tools with apt-get, downloading a package and then installing it with sudo dpkg -i cris-dist_1.63-1_i386.deb
Please don’t do all this with a root shell. Use a regular shell: every time you overuse a root shell, God kills a kitten. Think of the kittens. Additionally, you will end up with a mess of permissions that only root will ever be able to run properly. Not good.
Keep following the instructions until the end, when you will have a fully operational SDK. Notice that so far nothing has been done to your board, all this song and dance has been happening on the development system.
To download FoXServe stuff you need to register, but this is relatively painless. Go to KDEV’s site (FoXServe’s author) and read. Then go to the page that tells you how to patch the SDK and follow the instructions. Notice that the make command will take ages the first time you run it. This is completely normal, just relax.
Rebuilding the image
It goes beyond the scope of this document to explore the (hundreds) of options provided by menuconfig and kernelconfig. One important thing, though, is that you should check in the .config file (typically through make menuconfig in the Network settings section) that the IP address and MAC address are correct.
Differently from the desktop computer we are all used to, the MAC address of the FOXboard is very easy to configure. And if you don’t have the IP address of the board, you can’t really reach it from the outside. In this case, wireshark could be your friend.
If you have never built a Linux kernel through something like menuconfig or kernelconfig, it will be a surprising trip in a world of sickly-colored arborescent text menus. But don’t despair and keep backups of the configurations and images that work.
Reflashing the board
Notice also that the boot_linux tool that you can use to reflash the board requires that the development machine and the board be connected to the same Ethernet segment. Some office networks that are a little bit too smart for our purposes use switched network that effectively relegate each machine to its own little segment. Hence, you will find yourself forced to either use other techniques for flashing, or to use a local Ethernet hub (the dumber, the better).
Is it there?
Start by pinging the board, Then marvel at the fancy webserver that runs on it. Then ssh into it.
I am including a .config file that sets up the whole port G for output (lofty desires) and a configuration that more or less works on the TUDelft network. I am still not fully convinced that DHCP works the way it is supposed to. But anyway, for now I am using a static address that is exactly the one the DHCP server would give me. Same difference, you see?