SPI Woes with different Kernel Versions

[Thomas Hoppe]

Hi,

I have a board attached via SPI0 to a BBB (also tested with Green).
I'm activating SPI0 via uEnv.txt entries which I read is the best practice.
Now I can use the board with its user space software (no kernel driver whatsoever involved).
The setup works with 3.8 and 4.1 kernels but not with 4.4 and 4.9.
Below I have the output of

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins | grep spi

and the actual device name for each version.
I cannot spot any relevant difference. So what has changed in the SPI code between those kernels
or has anyone an idea what could be the issue here?

BG, Thomas


3.8.13

/dev/spidev1.0

pin 84 (44e10950): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 85 (44e10954): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 86 (44e10958): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 87 (44e1095c): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins

4.1.x

/dev/spidev1.0

pin 84 (44e10950.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 85 (44e10954.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 86 (44e10958.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 87 (44e1095c.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins


4.4.x

/dev/spidev1.0

pin 84 (44e10950.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 85 (44e10954.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 86 (44e10958.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 87 (44e1095c.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins


4.9.x

/dev/spidev0.0

pin 84 (44e10950.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 85 (44e10954.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 86 (44e10958.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
pin 87 (44e1095c.0): 48030000.spi (GPIO UNCLAIMED) function pinmux_bb_spi0_pins group pinmux_bb_spi0_pins

[William Hermans]

root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2016-06-19

root@beaglebone:~# uname -r
4.4.43-bone-rt-r16

root@beaglebone:~# ls /lib/firmware/ |grep SPI
BB-SPI0-MCP3008-00A0.dtbo
BB-SPIDEV0-00A0.dtbo
BB-SPIDEV1-00A0.dtbo
BB-SPIDEV1A1-00A0.dtbo

root@beaglebone:~# ls /dev |grep spi

root@beaglebone:~# echo 'BB-SPIDEV0' > /sys/devices/platform/bone_capemgr/slots

root@beaglebone:~# ls /dev |grep spi
spidev1.0
spidev1.1

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e1a2e7ae-1e6e-406b-be64-7efb1cbfe8f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Additional information:

I seem to recall there was an issue with SPI loading at boot. This had something to do with having to enable the spi software module in main board overlay file. Of which there has been several posts over the last few months. So see those for the exact details. So basically . . .

root@beaglebone:~# dmesg |grep SPI
[   47.792110] bone_capemgr bone_capemgr: part_number 'BB-SPIDEV0', version 'N/A'
[   47.802326] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-SPIDEV0'
[   47.826377] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-SPIDEV0-00A0.dtbo' loaded; overlay id #0

There two modules must be loaded at boot, through the main board overlay file:
root@beaglebone:~# lsmod |grep spi
spidev                  7564  0
spi_omap2_mcspi        11588  0

Here is the include file:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am33xx-overlay-edma-fix.dtsi

Which you'll see is commented out by default in at least this one board overlay file. Which I'm fairly certain it's commented out in all the stock board files.
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts#L12-Lundefined

Additionally, if you simply upgraded your kernel from an older image( e.g. an image that started with kernel 3.8.x ). You'll need to git pull that whole git repo, rebuild the board files, then install the ones you need. But you did not mention how you've managed to update your kernels from one test to the next. The best way to test would actually be to use two different flasher or stand alone images to test properly. Wheezy(debian 7 ) for 3.8.x, and Jessie(debian 8 ) for 4.x kernels. As some important changes have been made which may conflict between different kernels. 3.8.x may actually work fine on Jessie images, but I did personally run into troubles trying to update to a 4.x kernel on Wheezy images. 

 

[Thomas Hoppe]

Maybe there was a misunderstanding, I do have the SPI devices with all the kernels I mention!
And that is because I have the lines on the bottom in uEnv.txt. So again the existence of the devices is not my problem,
it just does not work. Do you think the patch you mention can be the reason for that?

root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2016-12-09

root@beaglebone:~# uname -r
4.9.0-ti-r13

root@beaglebone:~# ls /lib/firmware/ |grep SPI

ADAFRUIT-SPI0-00A0.dtbo
ADAFRUIT-SPI1-00A0.dtbo
BB-SPI0-MCP3008-00A0.dtbo
BB-SPI1-01-00A0.dtbo

BB-SPIDEV0-00A0.dtbo
BB-SPIDEV1-00A0.dtbo
BB-SPIDEV1A1-00A0.dtbo

root@beaglebone:~# ls /dev |grep spi

spidev0.0
spidev0.1

excerpt from uEnv.txt:

dtb=am335x-boneblack-emmc-overlay.dtb
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0,BB-SPI1CLK

[Robert Nelson]

On Thu, Jan 19, 2017 at 3:43 PM, Thomas Hoppe <thomas...@n-fuse.co> wrote:
> Maybe there was a misunderstanding, I do have the SPI devices with all the
> kernels I mention!
> And that is because I have the lines on the bottom in uEnv.txt. So again the
> existence of the devices is not my problem,
> it just does not work. Do you think the patch you mention can be the reason
> for that?

SPI/SPIDEV has always been picky between kernel releases.

I'll take a look at it again..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

Thomas,

I don't rightly know. I've done plenty of bare metal SPI, or enough of it anyway. The only thing I've done with SPI on the beaglebone, is a lot of reading. No actual hands on, Honestly I'm not sure if the edma fix would work for your situation or not. I think the edma fix was more or less to make the SPI modules usable. Something about the kernel modules having to be loaded at boot, otherwise edma got in the way somehow I *THINK*

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYidraFhheOkwRHeLWsVM9wWXwNM8HZMKtMBo%3DWPwADLVw%40mail.gmail.com.

[William Hermans]

Now I can use the board with its user space software (no kernel driver whatsoever involved).
The setup works with 3.8 and 4.1 kernels but not with 4.4 and 4.9.
Below I have the output of

So maybe if you're a bit more verbose with what you mean by "it doesn't work". What you're trying to do, what you've done to get there, and how you know it's not working.

You should also be aware, that you are in fact using a kernel module if you're loading the stock device tree files. You just may not be aware of it. As all of the most recent Debian image will boot up, with the SPI kernel module loaded automatically. Which is actually annoying if you do not want, or need it running. Since it takes a "fakeinstall" to keep it from loading automatically.

[Thomas Hoppe]

I just try to start the software from the board's supplier. The software is known to work (tested myself) and on the mentioned kernels on the BBB.
So I think we can rule out the software part. When starting the software, it cannot find/ connect to the board -- that's the "does not work case".

[Thomas Hoppe]

Hi,

I did some more testing on a 4.4.41-ti-r83 and a 3.8.13-ti-rxx.
I tested with the spi-test tool (I copied some version not used the one shipped with the respective kernel) in loopback mode.
Interestingly this seems to work on both kernel versions while my board only works with the 3.8 as explained.
So there must be some differences. @RobertCNelson can you think of what might have changed?

BG

[Thomas Hoppe]

The Loopback test only involves MISO and MOSI lines that leaves CS and CLK as potential source of errors.
I have made some measurements with an oscilloscope and it shows two notable differences between 4.4 and 3.8:

- For 3.8 CS toggles between high and low. For 4.4 CS is always low after an short initial high period. Both scenarios should be correct for the SPI data transfer as I see it.
- For 3.8 you can see how data is transferred in the clock cycles but for 4.4 the MISO line always remains low.

What can cause this, how can I approach this issue further?