BeagleBone userspace SPI interface (spidev) patch

A friend got a pair of BeagleBones and asked me to get the SPI interface up and running and I thought I’d share the quick patch I made. The attached patch allows you to access the SPI interface on the expansion header through the spidev userspace interface (/dev/spidev2.0 i believe, it’s compiled as a module in the current defconfig but I built it in for ease of use on our bones). I’ve verified that it sends data out the SPI interface at 12MHz when echoing to the presented device file.

Anybody know the correct channels to get this in the Angstom repo with the other BeagleBone kernel patches, or are they planning to do all the interfaces via cape configs and custom drivers making this patch moot? If this should go into the image, any code review or suggestions would be appreciated.

Thanks,
-Craig Berscheidt

0001-ARM-omap-am335x-BeagleBone-userspace-SPI-support.patch (1.83 KB)

Hello,

which pin are you using as MOSI ? (beaglebone output, spi device input)

A friend got a pair of BeagleBones and asked me to get the SPI interface up and running and I thought I'd share the quick patch I made. The attached patch allows you to access the SPI interface on the expansion header through the spidev userspace interface (/dev/spidev2.0 i believe, it's compiled as a module in the current defconfig but I built it in for ease of use on our bones). I've verified that it sends data out the SPI interface at 12MHz when echoing to the presented device file.

Anybody know the correct channels to get this in the Angstom repo with the other BeagleBone kernel patches, or are they planning to do all the interfaces via cape configs and custom drivers making this patch moot? If this should go into the image, any code review or suggestions would be appreciated.

It seems like it should go in to me, in lieu of a set of platform data
for device tree, which is where we should be headed.

To push patches into the BeagleBone kernel, start with applying them
to the Angstrom repo via the instructions in the README [2]. Of
course, you'll want to push this into the mainline as well.
linux-omap on vger.kernel.org is one place to find information on the
various ways to push code into the mainline.

I did a quick patch [3] to meta-ti for you that is like what you'd
submit to meta-ti@yoctoproject.org. Once I have some confirmation
from users that this patch works, I'll submit it. Can you try it out?

The prebuilt binaries are at [4].

A quick glance at an earlier source tree [1] at line 517 shows how the
pin muxes will be enabled, though it doesn't show which of d0/d1 is
MOSI/MISO.

  {"mcasp0_aclkx.spi1_sclk", OMAP_MUX_MODE3 | AM33XX_PULL_ENBL
    > AM33XX_INPUT_EN},
  {"mcasp0_fsx.spi1_d0", OMAP_MUX_MODE3 | AM33XX_PULL_ENBL
    > AM33XX_PULL_UP | AM33XX_INPUT_EN},
  {"mcasp0_axr0.spi1_d1", OMAP_MUX_MODE3 | AM33XX_PULL_ENBL
    > AM33XX_INPUT_EN},
  {"mcasp0_ahclkr.spi1_cs0", OMAP_MUX_MODE3 | AM33XX_PULL_ENBL
    > AM33XX_PULL_UP | AM33XX_INPUT_EN},

[1] https://github.com/beagleboard/linux/blob/v3.1-meta-ti-r2f+gitr1d84d8853fa30cf3db2571a5aec572accca4e29d/arch/arm/mach-omap2/board-am335xevm.c#L517
[2] git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
[3] https://github.com/jadonk/meta-texasinstruments/commit/655e2c8dab0b97c7ba2513d2bbcfc3d2a40dc7fa
[4] http://www.beagleboard.org/~share/beaglebone-debug-20120110/

A quick glance at an earlier source tree [1] at line 517 shows how the
pin muxes will be enabled, though it doesn’t show which of d0/d1 is
MOSI/MISO

I asked because, in my tests, I connected the pin in reverse order
wrto the CPU’s reference manual in order to make it work.

I’ve been told that the behaviour is user selectable via a register.

On my board SPI1_D0, pin 29, is connected to MISO of my SPI
chip (an output from the chip and an input to the beaglebone).

hello!

i was wondering if these patches / images had been further tested. i
wasn't able to get spidev working (with [4] above, nor by patching and
building the kernel)

however, i wonder if it's just something i'm missing / doing wrong.
should the device show up in /dev/spidev on boot or is there some
other step involved?

thanks!

eb

hello
Can you tell me how to run this patch?

Roka

hello again,

just an update… so, you see, being totally new to embedded linux, it did not occur to me to run “depmod -a” on the beaglebone to rebuild modules.dep and see the new spidev module.

once a more knowledgable friend suggested this, i was able to see /dev/spidev2.0 using the debug image above. yay!

i comppiled and ran this program:
http://catfact.net/tmp/spitest.c

but was not rewarded with any activity on the expansion header.

i tried to confirm the pinmux settings like so:

root@beaglebone:~# cat /sys/kernel/debug/omap_mux/mcasp0_aclkx
name: mcasp0_aclkx.spi1_sclk (0x44e10990/0x990 = 0x0023), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: mcasp0_aclkx | NA | NA | spi1_sclk | mmc0_sdcd | NA | NA | NA

which, unless i’m mistaken, indicates pin 31 of the P9 expansion header is in MODE 3 and should correspond to spi1 clock?

i’m sure there is something else i’m missing still…

any hints, or indeed any feedback at all, would be much appreciated. many thanks for your valuable time.

  • ezra b

Hi,

I wrote a small blog post on getting the beaglebone SPI working with SPIDEV, have a look here and see if it helps!

http://communistcode.co.uk/blog/blogPost.php?blogPostID=1

Nice write up. Thanks, you saved a lot of people a lot of time...

- Ken -

ah, thanks mr mitchell

the step i was missing was tying pins 18 and 21 on P9... i'm still not
sure (from reading BONE_SR.pdf) why this is needed...?

anyways thanks again
eb

Pins 18 and 21 are MISO (Master Input, Slave Output) and MOSI (Master Output, Slave Input), what tying them together does it send the out from your program, to the input of your program, hence you create a loop just reading what you are writing!

Hope that helps clear things up!

Cheers,

oh jeez, yes, of course! sorry, i am using spi1 not spi0, and therefore a somewhat different patch (closer to the top post in this thread). and only looking at MOSI and the behavior of the slave device.

in short, i have been looking at this way too long… everything is getting blurry

thanks -eb

Jack,

Can I read your post to mean that the defaults are:

MOSI <-> SPIx_D0

MISO <-> SPIx_D1

in BBB lingo?

The BBB RM is somewhat devoid of SPI information. The TI 3358 reference manual (SPRUH73I rev I, August 2013) shows the opposite on pages 4543 to 4544, figure 24-1 and table 24-4.

It appears that D0/D1 are configurable. I do not care to configure it. I want it to just work the way I wire it, so I want the default. Is D0 MISO or MOSI by default?

Cheers,
Joe

Yes, I know it's terribly confusing. I alwayus forget myself. The way I
double check is to look at the dtso and see which pin is input.

spi1_pins_s0: spi1_pins_s0 {
pinctrl-single,pins = <
  0x190 0x33 /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 */
  0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
  0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
  0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
>;
};

As you can see here, spi1_d0 is input, therefore D0 == MISO, D1 == MOSI.

Cheers,