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.
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.
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?
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!
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.
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!
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
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?