I’ve updated my Raspberry Pi 3.2.18 kernel with some patches and slight configuration changes since the last one:

• The USB code is now built-in instead of being a module. This means that people who want to keep their root filesystem on a USB hard disk or similar can do so.
• Some fixes for my I2C driver that prevent it reading/writing further than it should have. This caused at least one user to experience a kernel panic.

I have not yet reverted the MMC/SD commit that I suspect is causing many people issues. So far I have had only one conclusive report that it has helped. If you have had trouble with an SD card in my kernel but not in the official kernel and have the opportunity to build a kernel with commit 84045e4 reverted, please let me know the outcome.

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

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 →