Raspberry Pi Breadboard Madness

So I was working on my Raspberry Pi, getting SD cards and ethernet working over SPI so we can still use mass storage and networking while we rewrite the SD and USB drivers. I looked over at the side of my desk where all of this is on breadboard attached to my RPi and realised the insanity of it.

So let’s play spot the PCB:

• Raspberry Pi. This one’s easy!
• SparkFun FTDI Basic Breakout – 3.3V
• SparkFun Breakout Board for microSD Transflash
• SparkFun DeadOn RTC
• SparkFun Real Time Clock Module
• Olimex ENC28J60-H
• SparkFun PCA9306 Level Translator Breakout
• SparkFun Digital Temperature Sensor Breakout – TMP102
• SparkFun SOIC to DIP Adapter 20-Pin with 2x Atmel AT45DB161D
• Gadget Factory / Dangerous Prototypes Open Bench Logic Sniffer

Phew!

And yes, my Raspberry Pi has two SD cards and two ethernet controllers connected. The kernel and device tree blobs are loaded from the built-in SD and the root filesystem from the SPI SD card. The internet ethernet doesn’t work at the moment because we don’t have a USB driver in this kernel, so the SPI ethernet does the job for now!

A cross compiler is a compiler that runs on one platform/architecture but generates binaries for another platform/architecture. With devices like the Raspberry Pi, where you really don’t have much CPU or memory to work with, if you’re doing any heavy compiling (like when working on the kernel) a cross compiler is the only way to go. For example, I build all my Raspberry Pi kernels on my nice Sandy Bridge Xeon E3 home server where they compile in only a fraction of the time they would on the Pi.

Continue reading →

Update: This is no longer the most current kernel. You can find the latest version on my Raspberry Pi kernel project page.

Well, just as I uploaded my 3.2.17 kernel someone decided it would be a good idea to post 3.2.18. So here it is. It also incorporates a new patch that allows this kernel to be booted on the Raspberry Pi using kexec – previously, trying to do this would hang the Pi. Grab it from:

• Source tree on GitHub
• Pre-built Debian package

Please see my previous post (about the 3.2.17 kernel) for notes regarding the Raspberry Pi firmware.

If you want to use kexec, remember to give your kexec kernel some boot arguments with the --command-line= option, or it will seem like your kernel has crashed. Something like this might be a good idea: kexec --command-line="$(cat /proc/cmdline)" /boot/vmlinuz-3.2.18-rpi1+.

Update: This is no longer the most current kernel. You can find the latest version on my Raspberry Pi kernel project page.

Last bit of Raspberry Pi work this weekend was to update my 3.2-based kernel. This latest update brings it up to 3.2.17 with the latest patches from the official Raspberry Pi kernel (with updates for MMC/SDHCI among others) and includes my SPI and I2C drivers. Grab it from:

• Source tree on GitHub
• Pre-built Debian package

I also highly recommend you update your firmware in your SD card’s boot partition to the latest available version. Note that the default start.elf in that set of files appears to be the 128M variant – you may wish to use the 192M version instead by copying arm192_start.elf as start.elf on your SD card. I tried the 224M variant but that didn’t work at all for me.

With the latest firmware you also don’t need to worry about the first32k.bin being added to your kernel. Just install the kernel package and copy /boot/vmlinuz-3.2.17-rpi1+ to kernel.img on your SD boot partition (/mnt/boot in my Wheezy image).

I’ll be updating my Wheezy image in the next few days to incorporate this latest kernel and a significant number of package updates.

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.