Beagleboard xM - SPI

Hey all and thanks for the support. I am a student and I use
Beagleboard xM for the first time.

What I want to do is to establish an SPI communication between a PIC
microcontroller and Beagleboard xM, running on Angstrom. For this
reason, I tried to patch the kernel and recompile it, following
instructions from here:

However, when I try to compile the new kernel with the command

$make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage

I keep getting this message: Error: selected processor does not
support ARM mode `smc #0'

Does anyone have an idea of what I should try to fix it? I am running
xUbuntu 11.10 Oneiric Ocelot on my development machine.

Thank you in advance!

I don't think you need to go patching anything as long as you are
using an up-to-date kernel. You just have to make sure spidev is
turned on in the .config and then in say board-omap3beagle.c setup a
platform driver for the McSPI channel you want. Setup pinux in the
kernel or u-boot for the McSPI channel you want.

Check out:

I'm running the latest 3.0 based kernel and I'm running a spi display
on McSPI3 and I didn't have to patch anything.



Thank you for your quick reply! I am running a 2.6.32 kernel and I
installed Angstrom with a Narcissus build, using these instructions:
. Should I do something different to enable SPI? How can I generally
configure pinux?

I haven't used Narcissus lately but I would think you could pull down
images (and a ready to go toolchain) based on the latest 3.0 kernel,
that way you don't have to patch anything for McSPI.

I usually just work with bitbake and the git repositories. It may
appear overwhelming, but it would be better to run with a new kernel
and if you can't get it from Narcissus then you can clone the git
repository and use bitbake to make whatever image or package you need.
See Koen has
made scripts that makes it easy to clone everything and get setup for
you to type bitbake <something>. I usually start out with bitbake
console-image which will build u-boot, kernel, and a small basic root
filesystem that you just have to populate these images on the SD Card.

To setup your SPI, you are going to have to modify
arch/arm/mach-omap2/board-omap3beagle.c to add that platform driver
struct etc. in the elinux spi link I sent you to setup the particular
McSPI channel you want to use.

If you poke around the elinux site, you will find all kinds of good
info on how to do things with the beagleboard. You can change pinmux
in u-boot or the kernel and the elinux site had examples of how to do

Don't shy away from using bitbake with Angstrom or even Yocto (both
use OE (OpenEmbedded) meta data. It takes effort to get your head
around but the benefits are well worth it.

I'm just giving you the 30,000 foot overview here.

Welcome to Embedded Linux!

Hopefully others will chime in if I'm sending you in the wrong direction.



Thank you very much for your answer! As for Narcissus, is there a
special configuration I should do when I build, so that SPI drivers
are enabled? I am confused and the options for advanced build doesn't
seem helpful at all...

Whatever you do, you are going to need the source so you can rebuild
the kernel. It won't help you to have Narcissus build you an image
because you need to make modifications to it. If you get a recent
kernel, it has support for all the McSPI's.

The default .config for the kernel in Angstrom usually already has
CONFIG_SPI_SPIDEV=y set. So you will just have to add the platform
driver to config the McSPI channel you want to use as in the elinux
SPI example. You also need to setup pinmux according to the McSPI
channel you want to use.

I assume you are going to be hooking to the expansion connector. If
you look in the beagle board system reference manual, each of those
pins can have many different functions. So you setup pinmux to give
the pins the function you want.

I don't know which BB you have but the system reference manuals to all
of them are here



I see. So from the useful information you offered me, what I figured
out is the following:

1) I install the mandatory packages from this site so that
OpenEmbedded works :

2) I build Angstrom using these advice :

3) I make the appropriate configurations for SPI and build a uImage.

What is the final step for booting the BB xM? Sorry for asking a lot
of stuff but I really want to be sure that it will work since I try
something new.
Thank you a lot!

Once you have all the images - MLO, u-boot.bin, uImage … you will put these images on the FAT32 partition of the SDCard. There should be directions on elinux for doing that. The root filesystem files will be untared to a ext3/4 filesystem. Again, elinux has the info.

Your user app will use the /dev/spidev device.

Again, this is high level, you’ll have to dig through elinux for the details.



From Droid Incredible.

I think I'll make it through! Thank you again!! I will come back with
any news on that process!

In fact I would like to ask something last... If I make it work, I
guess that Trainer Board or something of the same style is needed for
the TTL level translation, isn't it?

The tincan tools board would make it easier and less prone to smoke something.

This one:
I had in mind too. Thank you very much indeed, I appreciate your

Yes, that one will work. The BeagleBoard expansion header signals are
1.8V so you'll have to translate to whatever voltage the SPI device
you are attempting to hook up uses. The tincan tools trainer boards
have the voltage level stuff you'll need and a nice breakout board
area for your circuits.

They didn't have these when I did my first BB project ... a EE friend
that was working on the same project had to make basically the same
thing as the trainer board to do the level shifting ... so these
trainer boards are nice and make things a lot easier. They make a
cool JTAG (Flyswatter) debugger interface that works with OpenOCD too.



I see...I also had in mind to start searching around for such a
translator circuit, but since this board does the dirty work, it's not
worth of it...It is very cheap too!

Hello again! I didn't make it out with OpenEmbedded as I get parsing
errors when I am trying to build the MLO file...Seriously is this the
only way I can get SPI working? I saw that in Beagleboard demo files
( there is a new
kernel (3.0.17)... Can I take advantage of that and build somehow a
new kernel?

If it includes the source for the kernel and a cross toolchain to
rebuild it ... then yes. If it is just a kernel image, then no ...
unless someone registered a SPI platform driver in the image. If you
do a ls of /dev/ and see a device called spidevX.X then the kernel has
a SPI driver configured (now you have to figure out which pins it is
using). If you don't see that then you have to modify the kernel code
to register the SPI driver (the elinux SPI example) so the device
shows up in /dev for your userspace app to use.

So with OE, you got to the point where you had all the repos cloned
and an environment setup and were able to do something like bitbake
console-image and MLO failed to build?



I created a folder which, after configuration, contains openembedded,
bitbake, pixhawk and build subfolders. Then I tried to bitbake x-load
but keeps sending a parsing error message. As for the demo beagleboard
repository I linked, there is a uImage of 3.0.17 kernel but when I
download the rootfs, under /boot directory there is a 2.6.32 uImage.
This is what confuses me...Thanks for your patience!

Sorry, it is kind of hard to know best how to advise you. I mean, you
could just checkout the latest kernel from git and then just build the
kernel with an external toolchain like CodeSourcery, but then you
would have to know how to config the kernel, take the kernel modules
and put them in the proper place in your rootfs and have knowledge of
building Linux system from scratch. I'm guessing you don't know all
that so even though it looks probably crazy to you .... I kind of
thought maybe following the Angstrom Getting Started instructions
( would be best
for you. Since it is a well traveled path, you do what is on Koen's
page and you magically get the result you want (almost).

Once you clone the scripts from git and run the setup script, it goes
and gets everything for you.

This is pretty much what you need to do (on the angstrom link above):
MACHINE=beagleboard ./ config beagleboard
MACHINE=beagleboard ./ update
MACHINE=beagleboard ./ bitbake virtual/kernel

Instead of bitbake virtual/kernel, I suggested console-image (you can
do both but console-image is smaller and faster to build)

This takes hours (maybe 6+) depending on how fast your machine and
Internet connection is because it goes off and pulls down the
toolchain and the source for u-boot, kernel, packages in the rootfs
etc. and builds the world for you.

When it completes .... if all goes well ... look for the dir
build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard (this is
the location of my last build I did with Angstrom and should look
similar for you) and that directory will contain all you need to put
on the SDCard ... MLO, u-boot, uImage (all goes in FAT, copy MLO first
after you setup the FAT partition) then untar the rootfs into your
ext3/4 partition on the SDCard. You may have to learn how to write a
boot.scr file but all of this is covered on the elinux site and
elsewhere. But the end state of this procedure is a set of components
that is all known to work together. Once you get that far, you can
edit your kernel to setup the SPI driver (probably McSPI3 as it is on
the expansion connector) and then rebuild the kernel.

About the only way to avoid doing all the above is to find a kernel
uImage that is already configured say for McSPI3 on the expansion
connector and hope that the speed, SPI mode etc. will work with
whatever you are trying to hook to it.

Follow the Angstrom getting started then report back when you get a
console-image etc. built ... then you are almost there. Stay on the
path (the steps on the getting started page), don't go into the weeds
trying to understand all this at the moment because your head will
explode ... it will take you a while to fully absorb what all is going
on behind the scenes of this process.



Hello Brian,

I'm trying to do something very similar on my beagleboard XM. The only
difference is i'm really wanting to use Ubuntu 11.10 on my BBXm, and
not Angstrom, as there are some tools I need in Ubuntu. Does anyone
know of where I can find a build of Ubuntu that can be modified for
SPI? I've spent weeks going over elinux and some forums and blogs. I
came to the conclusion that I would have to compile my own kernel and
such but all the pin mux settings i've seen are for older kernel
versions. Most of these come in the form of a patch that I don't
understand how to apply. Any advice for a novice that wants to learn
more about embedded linux on how to apply a patch on a newer kernel
for Ubuntu to enable SPI?


I'm a big Debian (Ubuntu) fan but I've never tried running it on a ARM
so I just don't have experience there.

What kind of things do you need that Ubuntu has but you think Angstrom
doesn't have? I find the structure of Angstrom/Arago/Yocto very
Debian like and OE core has just about every package I've ever needed.
I would think that since you are wanting to run on a TI processor,
you would want to be using a distro that directly uses those layers
instead of trying to figure out how to back port TI ARM kernel
features to some Ubuntu kernel. I may be totally out of line with
that comment as I admit I don't have experience running the
Debian/Ubuntu ARM ports on TI processors. I'm not sure Ubuntu cares
what it's kernel is ... you very well could take an Angstrom built
BeagleBoard kernel and use with Ubuntu.

If you are wanting to learn embedded Linux using a BeagleBoard, then
you should start with Angstrom or Yocto as both will easily build
running systems once you know a few command. Once you do that, there
is enough meat there to figure out how all this works to keep you busy
for quite a while and give you quite the education. Once you learn
what all the parts are and how to build them individually etc., then I
would think you could pretty much do whatever you want with regard to
mixing various components from other projects.