On 03/14/2010 10:44 PM, Ben Gamari wrote:
Hey all,
As I've mentioned here in the past, I am currently putting together a board for
doing analog data acquisition on the BeagleBoard platform. Unfortunately, I
have wasted nearly the entire weekend trying to accomplish the (one would
think) simple goal of recieving data with the McSPI controllers (in particular,
run a loop-back test on McSPI3 with spidev_test).
For some reason you need to set the clock pin as an input. Here is the
config for mcspi1 that is working for me:
MUX_VAL(CP(MCSPI1_CLK), (IEN | PTD | DIS | M0)) /*McSPI1_CLK*/\
(from u-boot)
Philip
While I can reliably see a signal sent on the SIMO line, I have not once been
able to recieve anything but zeros in return. I have verified that the the SOMI
ball works as expected as a GPIO input. I have tried every pinmux configuration
imaginable (using both the kernel and u-boot) and yet I have still met no
success. It seems like this has been an issue in the past[1] and it seems that
at one point SPI was working[2], yet I have been completely unable to reproduce
this result.
When measuring the SIMO signal on the expansion connector with my daughterboard
connected, I noticed that the daughterboard's level shifter appeared to be
driving the signal higher than it should, to ~2.9 Volts. I then checked the
1.8V rail voltage and found that it too was higher than expected, again at 2.9
volts. When I unplug the daughterboard, the 1.8V rail voltage returns to its
expected value.
I'm both perplexed and concerned with this behavior. I completely fail to
see how my board is raising the voltage on the 1.8V rail (schematic available
at [3]). While the BeagleBoard seems quite stable, I'm very concerned that
perhaps the daughterboard over-drove the SIMO ball and burned out some subset
of the OMAP. Regardless, as mentioned earlier, I have verified the
functionality of the same ball as a GPIO input. Thus, I am thoroughly confused.
Is it possible that the ball's GPIO receiver could remain functional while the
McSPI receiver is burned out?
I am using a 2.6.32 kernel and can see in debugfs that the pinmux is configured
correct, with only the sdmmc2_dat0 pin exposing the McSPI3_SOMI signal. The
kernel patch I'm using to configure the muxes and spi controllers is included
below. As can be seen, I've also tried using the spi-gpio driver, but
unfortunately I wasn't even able to get it producing data on SIMO.
I've tried this using two daughterboards on two different Beagles (a B7 and a
new C4) with identical results on both. If anyone has any ideas at all, I would
love to hear them. I am really unsure of how to proceed at this point and I'm
quickly running out of time to devote to this project. I've included my kernel
patch below and the daughterboard design is available in Eagle format at [3].
Thanks,
- Ben
P.S. It seems to me that SPI is one of the more important interfaces on the
BoardBoard. As such, it would be really nice if there was a standard test of
SPI functionality. It seems many people have struggled to get SPI working on
the BeagleBoard and not too many have succeeded. A standard prescription would
be extremely useful.
P.P.S. Is it just me or does the omap_pinmux interface need some refinement.
Using it has been an exercise in frustration, between extremely sparse
documentation, quirky behavior (I still haven't figure out how to get gpio_130
configured. omap_mux_init_gpio fails with multiple paths for gpio130 whereas
omap_mux_init_signal fails to even recognize the signal name), and general
complexity. The idea behind the interface seems excellent, but it seems it
hasn't been used enough not to be a complete pain in the ass to figure out and
use.
[1]
http://markmail.org/message/2vbfuz7bltvrk6g3#query:beagle%20spi%20zeros+page:1+mid:wduqfhs4ur373ehp+state:results
[2]
http://groups.google.com/group/beagleboard/browse_thread/thread/42988f0e14db0f01/816397901ec999c4?lnk=gstq=Balister+pli=1
[3] http://goldnerlab.physics.umass.edu/git?p=tracker-board.git;a=summary
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 231cb4e..b23c5a5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -12,6 +12,10 @@
* published by the Free Software Foundation.
*/
+//#define BEAGLE_GPIO_SPI
+
+
+
#includelinux/kernel.h
#includelinux/init.h
#includelinux/platform_device.h
@@ -28,6 +32,7 @@
#includelinux/mtd/partitions.h
#includelinux/mtd/nand.h
+#includelinux/spi/spi.h
#includelinux/regulator/machine.h
#includelinux/i2c/twl.h
@@ -372,6 +377,159 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
keys_gpio,
};
+#ifndef BEAGLE_GPIO_SPI
+
+static void __init omap3_beagle_config_mcspi3_mux(void)
+{
+ omap_mux_init_signal(sdmmc2_clk.mcspi3_clk, OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(sdmmc2_dat3.mcspi3_cs0, OMAP_PIN_OUTPUT);
+
