SPI on Beagle xM Rev C - Research/Reading done.

[Jack Mitchell]

Hello everyone,

I'm tearing my hair out at the moment trying to get SPI working on a
CircuitCo Rev C Beagleboard xM. I have read the wiki and all the
literature I can get my hands on. I am using the build system Yocto
(Poky) which is based on OpenEmbedded.

I have taken the route of muxing the pins in u-boot and disabling
CONFIG_OMAP_MUX at kernel compile.

I am running kernel 2.6.37 and u-boot 2011.06 and have applied the
following patches:

u-boot for pin muxing:
http://pastebin.archlinux.fr/434099

kernel for spidev config and loading of the driver:
http://pastebin.archlinux.fr/434100
http://pastebin.archlinux.fr/434101

However I cannot get a device node registering at /dev/spi*

Could someone please point me in the right direction or assist me in
solving this problem?

Kind Regards,
Jack.

[ZubairLK]

Just a guess.. Cause i faced this myself. And literally tore my hair!

The uboot you are using. I think it points to the ext3 partition.
And checks the uImage in /boot directory.
And you are updating uImage in the fat partition.

So old uImage that lies in the ext3 partition.
And new uImage is unused.

Hope this is it and it solves your headache.
:)

On Sep 20, 7:01 pm, Jack Mitchell <jmdontca...@gmail.com> wrote:
> Hello everyone,
>
> I'm tearing my hair out at the moment trying to get SPI working on a
> CircuitCo Rev C Beagleboard xM. I have read the wiki and all the
> literature I can get my hands on. I am using the build system Yocto
> (Poky) which is based on OpenEmbedded.
>
> I have taken the route of muxing the pins in u-boot and disabling
> CONFIG_OMAP_MUX at kernel compile.
>
> I am running kernel 2.6.37 and u-boot 2011.06 and have applied the
> following patches:
>
> u-boot for pin muxing:http://pastebin.archlinux.fr/434099
>

> kernel for spidev config and loading of the driver:http://pastebin.archlinux.fr/434100http://pastebin.archlinux.fr/434101

[Jack Mitchell]

Thank you for the advice however u-boot is defnitely using the new
uImage as I don't even have a uImage in my /boot directory! I have
altered my patches a little bit since yesterday but still no luck!
Please find my new changes below:

Kernel 2.6.37 spidev init patch
http://pastebin.archlinux.fr/434111

Kernel config patch:
http://pastebin.archlinux.fr/434112

U-Boot 2011.06 patch:
http://pastebin.archlinux.fr/434114

Thank you for taking the time to help me!

[Jack Mitchell]

I have now tried with u-boot git master and uImage on the ext3
partition to no avail... i'll just have to keep trying!

[prpplague]

http://elinux.org/BeagleBoard/SPI

[Jack Mitchell]

Thanks for the reply prpplague but I have that page imprinted in
memory I've read it that many times! I have now succumbed and am
trying to get it going using pin muxing from within the kernel, while
bad practice at least it will make a proof of concept to keep moral
high!

[Jack Mitchell]

Ok, further testing and my pins are being set correctly, I scoped the
SOMI Pin and that is held high which means the pin muxing is working
correctly. There was no clock on CLK - which i assume is controlled by
the driver...?

[Jack Mitchell]

Right I fixed it. I used the config from the wiki for my kernel and it
started working. I don't know what was enabled that was different but
something had changed.

To conclude - there are some config options which need to be on in
addition to the SPI & SPIDEV configs - I can't work out which ones as
a diff between my old config and the given one are almost exactally
the same.

[Jack Mitchell]

Possible culprits:

CONFIG_SPI_BITBANG=m
CONFIG_SPI_GPIO=m

[Ben Gamari]

Just out of curiosity, what makes you say that pin muxing from within
the kernel is a bad practice? My understanding was that this was The Way
of the Future(TM).

Also, if I understand your issue correctly, you aren't seeing
/dev/spidev device nodes. This really should have nothing to do with pin
muxing. It sounds as though the spidev driver isn't being bound to your
SPI master.

Cheers,

- Ben

[Ben Gamari]

On Thu, 22 Sep 2011 05:38:55 -0700 (PDT), Jack Mitchell <jmdon...@gmail.com> wrote:
> Possible culprits:
>
> CONFIG_SPI_BITBANG=m
> CONFIG_SPI_GPIO=m
>
Hmmm, interesting. It would be nice if you could get positive
confirmation of this. If there is some configuration dependency it
really should be expressed in Kconfig so others aren't stuck in similar
situations as you.

Cheers,

- Ben

[Koen Kooi]

Op 22 sep. 2011, om 16:24 heeft Ben Gamari het volgende geschreven:

> On Thu, 22 Sep 2011 02:18:05 -0700 (PDT), Jack Mitchell <jmdon...@gmail.com> wrote:
>> Thanks for the reply prpplague but I have that page imprinted in
>> memory I've read it that many times! I have now succumbed and am
>> trying to get it going using pin muxing from within the kernel, while
>> bad practice at least it will make a proof of concept to keep moral
>> high!
>>
> Just out of curiosity, what makes you say that pin muxing from within
> the kernel is a bad practice? My understanding was that this was The Way
> of the Future(TM).

The way of the future alright, since the default mux in the kernel is broken for beagle. And it has been for years.

[Ben Gamari]

Hmmm, really? I've been using patched (for GPIO chip select support in
the McSPI driver) kernels with kernel pinmuxing since 2.6.35 (if I
recall correctly). What
exactly is the problem?

Cheers,

- Ben

[Jack Mitchell]

I believe muxing within the kernel is bad practice because rouge
software could alter your pins without you knowing leading to hard to
debug issues. If your pins get set at boot and they stay that way you
have a definitive knowledge of the pin state.

Yes the issue is in the kernel side but I was getting desperate and
wanted to make sure that my pin muxing was working which could have
lead to the driver not picking up the SPI interface.

I breifly read somewhere that a buffer must be enabled in the kernel
config to allow SPI but I forgot what it was and where I read it -
otherwise I would check to see if the wiki config had it enabled.

If i get time then I will investigate further as I would like to use
to u-boot muxing instead of the generic kernel pix muxing patch from
the wiki - at some point I may see if I can remove the muxing from the
patch and leave my u-boot muxing in to see if it still works.

On Sep 22, 3:24 pm, Ben Gamari <bgam...@gmail.com> wrote:

[Hunyue Yau]

Kernel pinmux has always been working with a few possible
exceptions in the 2.6.3x era when the new code went in. I have it
working with the McSPI and others with the 2.6.2x kernels and
with the 3.x kernels; I know of people having it working fine with
the 2.6.35 kernel. I have a quick write up for the older kernels
at (eventually, it will be updated for the 3.x kernels).
http://www.hy-research.com/omap3_pinumux.html

It is a bad idea to do the pinmux in u-boot for the simple reason
that it is yet another piece of code that depends on the kernel
config but do not have visiblity into the config. (OTH, the u-boot
is a quick and dirty way for testing.). For a given hardware,
there can be more then one pinmux config and it needs to match the
kernel config.
--
Hunyue Yau
http://www.hy-research.com/

[bhensley]

Hey Jack,

If you're tearing out your hair still I have a solution. After reading your post a month ago I decided to write a blog to walk through getting SPI working in Ubuntu 11.10 using Roberts scripts. I've gotten some good feedback from people saying its helped. Give it a try if you're still stuck. Otherwise if give me some feedback and I'll make it better.

http://www.brianhensley.net/2012/02/spi-working-on-beagleboard-xm-rev-c.html


Cheers,
Brian Hensley
www.brianhensley.net