Well I²C was the obvious next candidate for a driver. Another active Raspberry Pi coder, Frank Buss, wrote some nice driver code but sadly didn’t integrate it with Linux’s own i2c driver framework. It worked, though not as I wanted it. He did the hard work. I then took his code (with his permission of course) and wrote a Linux i2c driver for it today. It works! You can grab it at:

https://github.com/bootc/linux/tree/rpi-i2cspi

This tree contains the latest SPI and I²C code. Here’s how to use it:

Continue reading →

I’ve kept working on my Raspberry Pi SPI driver and the last few updates should be quite interesting to people following this. Aside from fixing a silly bug a few days ago (I was releasing the chipselect lines when I shouldn’t have been), I’ve done some work to no longer require the switchPinCtrl tool and to implement IRQ mode.

IRQ mode means that the driver no longer uses 100% of the CPU when doing transfers, running a busy loop checking the flags to read/write the FIFO. Instead, it waits until the SPI hardware tells it that it needs to do something, and means other software can get on and do things at the same time. In testing SPI transfers to/from some AT45DB161D flash memory chips, I’m using less than 5% of the Raspberry Pi’s CPU including the top process.

I’m testing the SPI with those chips at 7.8 MHz (250 MHz ÷ 32) and it is working very reliably indeed, with no data errors reading and writing random data. At 15.6 MHz the process was quite unreliable, but I think that’s more to do with my jumble of jumper wires just not managing those sorts of speeds which is rather predictable. I have also tested with a DS3234 RTC chip which works very well.

I’ve also incorporated a small snippet of code to put the SPI pins in the correct ALT mode (ALT 0) so that the SPI hardware can drive them, instead of them being set up as GPIO pins. Previously I asked that folks run a command-line tool to do this but this was leading to a great deal of confusion (especially on my part!) so I put the code into my driver. This is not where the code belongs, really this should be in a pinmux/pinctrl driver, but it’ll do for now.

Update: Updated the link to the git branch, now points at the branch with both the I2C and SPI drivers in.

Over the last few days I have been writing a driver for the Raspberry Pi’s SPI peripheral. This driver will let you use the SPI pins on the GPIO header properly rather than relying on bit-banging. Someone already wrote a driver but it was incomplete and I didn’t much care for the code, so I decided to roll my own.

One of the primary advantages of my code at the moment is that the clock speed on the SPI port can be set properly, rather than being hard-coded to an invalid value. The SPI clock speed is determined by dividing the SPI peripherals reference clock (250 MHz) by a power-of-2 divider between 2 and 65536. This gives you a number of speeds from 3.8 KHz to (theoretically) 125 MHz. Given a clock rate in Hz, my driver will pick the fastest speed possible less than or equal to the given speed, so if you request 500 KHz, you get 488 KHz instead (250 MHz ÷ 512).

You can find all the necessary patches in the rpi-spi branch on my GitHub.

Please note: If you want to use this code you’ll need to download switchPinCtrl from the person who wrote the other SPI driver to put the SPI pins into the right mode. If you don’t do this, the pins will remain set up as GPIOs and you will not get anything from the SPI driver on those pins. This will be fixed when I get round to writing a pin control driver so that this can be managed from within the kernel. This is on the TODO list.

Also on the TODO list for this driver is interrupt-driven mode which should greatly reduce the CPU load.

Raspberry Pi Serial Console

I’ve had a few questions about how I wired up my serial console on my Pi, so here’s a quick post about it.

The best place to start is the page on elinux.org that details the pins on the GPIO header (RPi low-level peripherals). You’ll notice you need pins 8 and 10 for the Pi’s TX and RX pins, you’ll also need a ground point which you can find on pin 6. You can then hook those straight into a 3.3V USB to serial converter’s GND, RX and TX pins and get a console running. Note that you need to connect the TX pins to the RX pins or you won’t be getting any output. Do not use a 5V cable. Do not connect the power pin on the FTDI adapter to any of the Pi’s power pins either.

Continue reading →

I’ve updated my Raspberry Pi Minimal Wheezy image to fix the problem with udev and network interfaces:

wheezy-mini-2012-05-11.img.gz (113MB)

The root password is unchanged from last time: raspberrypi

Change Log

• Removed my Raspberry Pi’s eth0 from /etc/udev/rules.d/70-persistent-net.rules

Please note: If you used my 2012-05-08 image and have fixed the rules file there is no need to upgrade.

Continue reading →

I was lucky enough to finally receive my Raspberry Pi last Friday. I ordered it from Farnell as early as I possibly could, and my order was dated 08:34:24 29/02/2012. Of course I’ve been playing with it since, and have mostly been working on the kernel – getting things cleaned up a bit and upgraded a bit. So the first thing to announce is I’ve got a little stash of Raspberry Pi-related stuff available for people to try.

Linux 3.2.16 kernel

The main improvement is that you can boot the compressed kernel and that early printk works. Using either of these caused the RPi to hang at boot due to the early console code being badly broken, but my changes (available on GitHub) initialise the serial port (115200 Kbps 8n1) if you boot the compressed image and give you serial output as soon as possible. This is very useful for debugging the kernel.

I’ve also rebased the 3.1.9-based official tree against 3.2.16 to bring it more into line with what Debian Wheezy expects at the moment. Simon has his own tree where we’re working on 3.3 and more recent kernels, ideally aiming for mainline inclusion at some point in the future. This is a big job though.

So without further ado, grab yourself the pre-built 3.2.16 kernel and install it like this (as root):

1. dpkg -i linux-image-3.2.16-rpi1+_1_armel.deb
2. Backup your /boot/kernel.img.
3. cat first32k.bin /boot/vmlinuz-3.2.16-rpi1+ > /boot/kernel.img
4. Reboot

Please let me know if you have any issues with this kernel (that you don’t also have with the stock kernel)!

Minimal Debian Wheezy disk image

In my travels with the Raspberry Pi I found that the official Debian image wasn’t to my liking. Not only does it have lots of unnecessary (for me) software installed, but certain configuration files are badly mangled (such as /etc/passwd and family). The image is also based on Squeeze, though I admit it’s easy enough to dist-upgrade to Wheezy. Regardless, I decided to start from scratch using debootstrap (and working around some interesting issues) I built a minimal Debian Wheezy image.

This has the bare minimum changes from a plain debootstrapped system to get a working Raspberry Pi. It runs DHCP on eth0 at boot and runs ntpd, but does not have openssh-server installed. It starts consoles on both the serial port (115200 8n1) and the HDMI display. The time zone is set to UTC. The kernel, of course, is my 3.2.16 kernel from above.

Update 2012-05-11: I have updated my image to fix the udev problem mentioned below. Please see my latest post about it.

Download wheezy-mini-2012-05-08.img.gz (113M). The root password is raspberrypi.

Please note: There is one known issue with the above image which means that your eth0 will be renamed to eth1 and networking will not be brought up automatically. This is easy to fix: just edit /etc/udev/rules.d/70-persistent-net.rules and remove the two sets of rules with their comments at the end of the file, then reboot. I have created an updated image that fixes this problem.