A few days ago I complained a bit about the profusion and confusion around the Linux drivers for the PiBorg LEDBorg multi-colour LED. With a bit of renewed energy, I thought I’d have a go at improving the situation by including a test for board revisionin the driver and ensuring that the correct GPIO pins are used for the different board revisions.

I have my LEDBorg currently plugged in to my Rev 1 Raspberry Pi, so it seemed reasonable to start by downloading the Rev 2 driver with the aim of making it also work with the Rev 1 board. The source code for the driver is helpfully provided by PiBorg for download as a zip file, and the installation web site contains some instructions for how to build the driver from source.

So, following the instructions, I downloaded and unzipped the source code:

mkdir ~/ledborg-source
cd ~/ledborg-source
wget -O source.zip http://www.piborg.org/downloads/ledborg/source-rev2.zip
unzip source.zip

Looking at the code there are two source directories, driver and basic-driver (as well as a GUI, but I’m not interested in that at the moment.) The basic driver is a user-space program with a limited feature set and which needs root privileges to run, so I chose to build the main driver. cd driver followed by make tried to build it but complained about missing headers. This was not unexpected, and the PiBorg instructions say that the next step in this case is sudo apt-get install linux-headers-$(uname -r).

Unfortunately, this is where it all began to go wrong. apt-get could not find the headers. My Pi is running version 3.2.27+ of Raspbian “wheezy”, and it seems as if these headers are simply not in the deb repository. Undeterred, I began looking around the web and eventually found a discussion on the Raspberry Pi forum about this issue which gave some pretty clear (if a bit complicated) instructions on how to get headers and symbols to enable building drivers. I followed the steps:

sudo bash
cd /usr/src
wget  https://github.com/raspberrypi/linux/tarball/rpi-3.2.27
tar xzf rpi-3.2.27

and

cd raspberrypi-linux-*
zcat /proc/config.gz > .config
make oldconfig
make modules_prepare

then

wget https://github.com/raspberrypi/firmware/raw/master/extra/Module.symvers

and eventualy

KSRC=`pwd`
pushd /lib/modules/`uname -r`
ln -s ${KSRC} source
ln -s ${KSRC} build
popd

pushd /usr/src
ln -s ${KSRC} linux-`uname -r`
ln -s ${KSRC} linux
popd

At this point I even got a bit excited. Running make in the LEDBorg driver directory actually got all the way to building a kernel module!

My excitement was short-lived, though. Despite everything I could think of to try, the kernel refused to load the module, giving Invalid module format.

Am I missing something obvious here? On every other Linux machine I have used, recompiling kernels and modules was very much “business as usual”, but Raspbian “wheezy” seems to make this ridiculously complicated. If this were a distribution for some sort of proprietary, closed, hardware, then I’d understand, but this is for a Raspberry Pi. If ever there was a Linux platform which is going to be extended with unknown hardware it’s this one. Surely making and running new drivers should be easier on a Raspberry Pi, not stupidly harder.

Please somebody tell me that there is some simple step that I have overlooked.

Meanwhile, just to prove to myself that I am not completely useless, I did successfully build the basic-driver, and was able to do: sudo ledborg-basic 002 to light up the blue LED. My next step will be to add the board revision detection to the basic driver, at least, but if anyone can help with a working way to build kernel drivers I would very much appreciate it!