BeagleBoard-xM, Rev B: Linux: SPI Devices do not generate any output

[Ueli Niederer]

Hello all

I was searching through the web and especially this group if someone
shares my pain. I noticed there are a lot of people failing to use
SPI3 & SPI4 on the expansion connector and so am I.

I'm trying to write some SPI device drivers for rowboat (Linux Kernel
2.6.32). So I enabled the SPI subsystem in the kernel and followed the
PinMux-Guide in[1], hoping to enable the SPI.

What I got was 3 devices (spidev3.0, spidev3.1 and spidev4.0) in /dev,
so far so good. I set up an oscilloscope monitoring the clock signal
of SPI3 and SPI4. As I tried to write something to one of the devices,
issuing
$ echo test > /dev/spidev3.0
on the commandline, I expected to see the clock on the osc, but
nothing came. Same on spidev4.0.

Searching for people having the same problems, I found a discussion
with a very similar problem[2] what lead me to my first question:

- Is it nescessary to setup the PinMux in u-boot AND the kernel?
As far as I understood, the kernel simply overwrites the PinMux set by
u-boot so I can modify the board-file to set the PinMux for my needs,
right?

My modifications in the pinmux are as follows:
I created two methods, which are called right after the expansionboard
evaluation in "omap3_beagle_init":

static void __init omap3_beagle_config_mcspi3_mux(void)
{
// NOTE: Clock pins need to be in input mode
omap_mux_init_signal("sdmmc2_clk.mcspi3_clk", OMAP_PIN_INPUT);
omap_mux_init_signal("sdmmc2_dat3.mcspi3_cs0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdmmc2_dat2.mcspi3_cs1", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdmmc2_cmd.mcspi3_simo", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdmmc2_dat0.mcspi3_somi", OMAP_PIN_INPUT_PULLUP);
}

static void __init omap3_beagle_config_mcspi4_mux(void)
{
// NOTE: Clock pins need to be in input mode
omap_mux_init_signal("mcbsp1_clkr.mcspi4_clk", OMAP_PIN_INPUT);
omap_mux_init_signal("mcbsp1_fsx.mcspi4_cs0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("mcbsp1_dx.mcspi4_simo", OMAP_PIN_OUTPUT);
omap_mux_init_signal("mcbsp1_dr.mcspi4_somi", OMAP_PIN_INPUT_PULLUP);
}

Both methods are executed and both of them set the pinmux register to
the expected value. To make sure of this, I patched the
"omap_mux_write" method in "mux.c" to output every modification.

For testing purposes I also expanded the "board_mux" table with
following lines:
/* SPI3 */
OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE1 | OMAP_PIN_INPUT), /* SCK */
OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT), /* SOMI */
OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT), /* SIMO */
OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT), /* CS0 */
OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT), /* CS1 */

/* McSPI 4 */
OMAP3_MUX(MCBSP1_CLKR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),

As far as I understand the code, this does the very same as the
methods above do. At least the output of my "hack" in "omap_mux_write"
shows the very same output for both initializations. So here is my
second question: One of these two ways is enough isn't it?

Does anyone of you guys have some pointers for me how to trace down my
problem?

Thank you in advance for your Help
Ueli

[1] http://elinux.org/BeagleBoard/SPI
[2]
http://groups.google.com/group/beagleboard/browse_thread/thread/476ef1a2be830c81/f4e5ef94038ec5dc

[Jim Norton]

I have a post on my blog that you might find helpful.
Beagleboardxm.org and look for the progress spi article.

Sent from my Verizon Wireless 4GLTE smartphone

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[beagleboar...@junix.ch]

Thank you for your respose.

On 23 Jun., 19:33, "Jim Norton" <jimnor...@jimnorton.org> wrote:
> I have a post on my blog that you might find helpful.
> Beagleboardxm.org and look for the progress spi article.

I guess you refer to this one:
http://beagleboardxm.org/blog/2011/03/22/progress-spi-is-working-on-the-beagleboard-xm/

Actually I read this article before and beside the fact that I am
using another distribution (rowboat instead of angstrom) i did exactly
the same thing. :-(
(at least that's what I tought...)

For me, first of all there are those questions:
- Is it correct to set pinmux only at kernel init-time and let u-boot
unmodified?
- Are the changes I made correct?

Regards
Ueli

[ZubairLK]

Uboot is recommended for pinmuxing.
And the kernel pinmux is generally disabled by default.

I got spi working quite a while ago.
Here is the post
http://groups.google.com/group/beagleboard/browse_thread/thread/9846052a550c6483/992b8e311df110e3?lnk=gst&q=SPI#992b8e311df110e3

On Jun 24, 12:05 am, "beagleboard.org_gr...@junix.ch"

<beagleboard.org_gr...@junix.ch> wrote:
> Thank you for your respose.
>
> On 23 Jun., 19:33, "Jim Norton" <jimnor...@jimnorton.org> wrote:> I have a post on my blog that you might find helpful.
> > Beagleboardxm.org and look for the progress spi article.
>

> I guess you refer to this one:http://beagleboardxm.org/blog/2011/03/22/progress-spi-is-working-on-t...

[beagleboar...@junix.ch]

On 24 Jun., 05:35, ZubairLK <zubair.lutful...@gmail.com> wrote:
> Uboot is recommended for pinmuxing.

So if I want to add a expansion board, I have to modify uboot AND the
kernel you say?

> And the kernel pinmux is generally disabled by default.

Actually that seems only to be true for pre 2.6.32 kernels at least
that's what the resource you are linking in your post[1] says that the
kernel does some additional Pinmux. (and telling by hooking up the
write-access to the pinmux registers in kernel I'd say it does)
How does the Pinmux done by the kernel differ from the one done by U-
boot? For me It even seems the kernel overwrites what ever u-boot did
and sets up expansion mux on start using the board_mux-Table...

> I got spi working quite a while ago.

> Here is the posthttp://groups.google.com/group/beagleboard/browse_thread/thread/98460...
Thanks for this pointer. Actually, what you posted there are pointers
to resources I read over and over again to find out where I'm wrong.
So I'm still stuck at the same point.

[Ueli Niederer]

Ok, I think I got it resloved now:
- I did not have to modify u-boot
- Using rowboat, there is code in board-init for initializing mmc-
controller 1 and 2 where 2 is conflicting with SPI3. This one
overwrote the pinmux setting I had.

Removing mmc2 from the list of "devices to be initialized"[1] saved my
Pinmux setup and made it possible to use spidev3.0 @ 1 MHz to write
out data using the echo command:
$ echo test > /dev/spidev3.0

I can also confirm, that it is not nescessary to expand "board_mux" as
I did while writing my first posting if you setup pinmux using
"omap_mux_init_signal". Which one is preferred? Dedicated functions
setting up the pinmux or extending the board_mux table? - From my
point of view the overview is much better if the board_mux-table is
used because conflicts are easier to find.

The last big mystery is now, why neither my own nor the original spike
driver[2] works on these SPI channels while spidev (built in) does...
any SPI kernelmodule specialists here having me a clue? I did the very
same thing as Scott Ellis did.

Thank you all for your help
Ueli

[1] There is an array called "mmc" in the board-init in rowboat. If
you set twl4030_hsmmc_info::mmc to 0 for the entry where
twl4030_hsmmc_info::mmc == 2 the rest of the code will ignore this
entry. I did this, adding following loop to the code calling the SPI
init functions:
for (i = 0;i < ARRAY_SIZE(mmc);i++)
{
if (mmc[i].mmc == 2)
mmc[1].mmc = 0;
}

[2] http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=71&Itemid=67