What is it?
This is a small (3" x 3") board with a TI OMAP3530 processor, two USB ports,
UART port, DVI video (1280x800 max), SD/MMC slot, audio I/O and an expansion
port. I'm interested in hardware interfacing, especially for audio and SDR
When you get one it comes without any firmware. You'll need to prepare an
SD card with the bootloader, kernel amd root filesystem before you can do
anything with it. Here are some links that I've found useful:
For my purposes, the expansion header is key. This provides access to a number
of direct connections to the ARM SoC, including GPIO, SPI, I2C, SD/MMC. The
trick is that you need to tweak the bootloader and/or kernel to get access
to these functions.
The newer bootloaders and kernels provided at the sources above have all
been patched to provide the I/O functions required for some of the more general
expansion cards, like the Tin Can Tools Zippy board which provides a 2nd SD/MMC
slot and a SPI-based 10baseT Ethernet port. That's great if you need these
functions, but gets in the way if you're trying to do something else. So, you'll
need to build a kernel with custom I/O assignments. Here's how I did it:
I used OpenEmbedded to build a simple test kernel and root system. That gets
me started with a known-working kernel, albeit one which doesn't have the
hardware setup I wanted. Instructions for setting that up are here:
Building a Kernel
Once you've got OE installed and a working test system running, you'll need to
build your own kernel. It's possible to do that within OE/Angstrom, but it adds
and extra layer of cruft that I didn't want to deal with right now. Instead,
I built my kernel stand-alone using the directions found here:
I tweaked the process a bit - in the list of patches I included those that
are specifically for the Beagleboard, but left off the ones that set up the
Zippy board. Before applying the patches with quilt, I started a new git
branch as a reference point for a clean kernel. After applying the patches
I did a 'git checkin -a' to add all the changes that the patches made.
Using the new kernel is as simple as copying it to the boot partion of the
test system SD card. You may want to rename the original kernel so you've got
it around - just in case your new kernel doesn't work.
When you follow those directions you'll end up with source for the kernel in
the OE branch you've chosen to follow. In my case that's the Angstrom stable
branch, which at the time of writing was using linux-omap 2.6.29. There are
newer kernels available (up to 2.6.33 rc?? at this time) which have more
bugfixes and features that I'll have to investigate at some point in the
Adding SPI to the Kernel
There are a lot of suggestions out there for how to get SPI added to the
kernel. I studied some of them and came up with an amalgam that seems to work
for me. Helpful links are here:
There are 3 key components to making this work:
Enable CONFIG_OMAP_MUX in the kernel configuration.
This provides the code necessary to set the mux selects and
pin functions of the expansion port pins that your SPI port will use.
This is generally handled by the bootloader, but the kernel can do it
as well and this option enables that.
You'll find the option in menuconfig under:
System Type -> TI OMAP Implementations
Add SPI data structures and code to the board init file.
This is the code that invokes the pin setup and creates the data
structures which define how you want the SPI port to connect to the
Add Pin configuration data to the mux.c and mux.h files.
You'll need to give the mux setup code some data which tells
it how to configure the pins you're using. That isn't passed in at
runtime, but rather is just indexed from a pre-built table.
I've got a patch that includes all the changes I made to the kernel
source in order to get SPI port 4 working:
First order of business after building the new kernel is to see if the
SPIDEV devices are available. Look in the /dev directory for entries of
the form "spidevx.y". You should see 'spidev3.0', 'spidev3.1' and 'spidev4.0'.
In order to see if SPI is working, you'll need user space
code that can send data to the device. There is source for a simple test
program provided in the kernel documentation and I've got an ARM executable
here: spidev_test.zip. Uncompress
this and copy it to the root filesystem of your SD card. Run the test with
this command line:
./spidev_test -D /dev/spidev4.0
That should spit out a bunch of FF data. If you short pins 12 to 18 of
the expansion connector together you'll loopback from SOMI to SIMO and some
of that FF data should change.
FPGA Expansion board
I'm working on an FPGA-based expansion board for the Beagle. Find out
more about it here: Beagle FPGA
Return to Embedded page.