SPI Woes with different Kernel Versions

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

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

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.

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

SPI/SPIDEV has always been picky between kernel releases.

I'll take a look at it again..

Regards,

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

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.

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”.

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

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?