BeagleBone userspace SPI interface (spidev) patch

[Craig Berscheidt]

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

[Alessandro Zummo]

Hello,

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

[Jason Kridner]

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 met...@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/

[Alessandro Zummo]

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).

[emb]

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

On Jan 10, 2:04 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> On Sun, Jan 1, 2012 at 4:52 PM, Craig Berscheidt
>

> <craig.bersche...@gmail.com> wrote:
>
> > 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 thespidevuserspace 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...@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+gitr1d84d8...
> [2] git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
> [3]https://github.com/jadonk/meta-texasinstruments/commit/655e2c8dab0b97...
> [4]http://www.beagleboard.org/~share/beaglebone-debug-20120110/

[Roka]

hello
Can you tell me how to run this patch?

Roka

> 0001-ARM-omap-am335x-BeagleBone-userspace-SPI-support.patch
> 2K表示ダウンロード

[emb]

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

[Jack Mitchell]

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

[K.Keller]

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

- Ken -

[emb]

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

[Jack Mitchell]

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,

--
Jack Mitchell
Embedded Systems Engineer
http://www.embed.me.uk

[emb]

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

[jhg...@gmail.com]

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

[Jack Mitchell]

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,

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


--
Jack Mitchell (ja...@embed.me.uk)
Embedded Systems Engineer
Cambridgeshire, UK
http://www.embed.me.uk
--