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

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

Thank you for your respose.

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. :frowning:
(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

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

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.

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