Jump to content

[Solved - sort of] Cubietruck SPIdev - how to set it up please?


fri40

Recommended Posts

Armbianmonitor:

Hi there.

@Moderators: sorry for double-posting, started here: https://forum.armbian.com/topic/13916-cubietruck-allwinner-a20-spidev-no-such-device/?do=findComment&comment=101122

 

but might be the wrong section and been overlooked by "cubietruckers". Feel free to delete the one over there.

 

@Moderators: could you verify my account please so that I can edit my posts after posting on the same day? I'm human, I can tell traffic lights from trees, cars, and trucks ;-)

 

  • Cubietruck.
  • Stock image 20.02. apt-upgraded to 5.4.35-sunxi 
    EDIT: NOTE: just checked the armbianmonitor upload result, which says "5.4.20" at the top - but "uname -r" says "5.4.35", which armbianmonitor Shows further down, too.
  • No changes to device tree files / overlays; no user-overlays installed (tried a lot of things...)

 

Want to use SPI(0). Can't get it to "loop-back" anything. Been through "a lot" and a "lot of hours". I've read the enduser documentation on DT overlays, I've read the README for the sun7i overlays, I've read tons of threads....Is it that hard? Am I too stupid?

Q: Shouldn't it (these days) be as simple as putting these three lines into armbianEnv.txt, which I did?:

overlay_prefix=sun7i-a20
overlays=spi-spidev
param_spidev_spi_bus=0

Q: should there be an overlay "spi0" or "spi" along with spi-spidev above?

Q: If yes, then should there be a file /boot/dtb/overlay/sun7i-a20-spi(0).dtbo? I don't have that. For other platforms, there are spi0/1/...dtbo files in there. I only have these:

-rw-r--r-- 1 root root  267 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-analog-codec.dtbo
-rw-r--r-- 1 root root  386 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-can.dtbo
-rw-r--r-- 1 root root 5532 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-fixup.scr
-rw-r--r-- 1 root root  500 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c1.dtbo
-rw-r--r-- 1 root root  500 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c2.dtbo
-rw-r--r-- 1 root root  500 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c3.dtbo
-rw-r--r-- 1 root root  766 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c4.dtbo
-rw-r--r-- 1 root root  590 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-mmc2.dtbo
-rw-r--r-- 1 root root 2301 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-nand.dtbo
-rw-r--r-- 1 root root  778 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-pps-gpio.dtbo
-rw-r--r-- 1 root root  443 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-pwm.dtbo
-rw-r--r-- 1 root root 1040 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spdif-out.dtbo
-rw-r--r-- 1 root root  556 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spi-add-cs1.dtbo
-rw-r--r-- 1 root root 1093 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spi-jedec-nor.dtbo
-rw-r--r-- 1 root root 1069 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spi-spidev.dtbo
-rw-r--r-- 1 root root  808 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart2.dtbo
-rw-r--r-- 1 root root 1078 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart3.dtbo
-rw-r--r-- 1 root root  513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart4.dtbo
-rw-r--r-- 1 root root  513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart5.dtbo
-rw-r--r-- 1 root root  513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart6.dtbo
-rw-r--r-- 1 root root  513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart7.dtbo
-rw-r--r-- 1 root root  777 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-w1-gpio.dtbo

 

ttl console reports nothing "strange" I believe:

...
[22:44:20:553] 1069 bytes read in 6 ms (173.8 KiB/s)
[22:44:20:567] Applying kernel provided DT overlay sun7i-a20-spi-spidev.dtbo
[22:44:20:599] 5532 bytes read in 7 ms (771.5 KiB/s)
[22:44:20:621] Applying kernel provided DT fixup script (sun7i-a20-fixup.scr)
[22:44:20:633] ## Executing script at 44000000
[22:44:20:646] ## Loading init Ramdisk from Legacy Image at 43300000 ...
[22:44:20:662]    Image Name:   uInitrd
...
[22:44:28:422] [    6.431813] spidev spi0.0: probing from DT
...

Q: I have no other occurrences of "spi" in dmesg - should I?

lsmod lists "spidev".

I have NO /proc/device-tree/spi* entries (as other platforms or earlier kernels seem to have (had))

I DO have /proc/device-tree/soc/spi@1c05000

And I do have /dev/spidev0.0 (accessible to root only)

$ cat /proc/device-tree/soc/spi@1c05000/status 
okay
$ cat /proc/device-tree/soc/spi@1c05000/spidev@0/status 
okay

I'm positive I've got MISO and MOSI for SPI0 jumpered "short".

I have tried spidev_test.c, it transmits, but does not get anything back.

$ sudo ./a.out -v -D /dev/spidev0.0 
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  |......@.........................|
RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................................|

Q: Trying it with "--loop" gives "can't set spi mode: Invalid argument", "Aborted"... should that be working?

 

Found this: https://github.com/cpb-/spi-tools and compiled it and ran some tests - it does something.

$ sudo spi-config -d /dev/spidev0.0 -q
/dev/spidev0.0: mode=0, lsb=0, bits=8, speed=1000000, spiready=0
$ sudo spi-config -d /dev/spidev0.0 -s 500000
$ sudo spi-config -d /dev/spidev0.0 -q
/dev/spidev0.0: mode=0, lsb=0, bits=8, speed=1000000, spiready=0
$ sudo spi-config -d /dev/spidev0.0 -s 500000 -w &
[1] 2041
$ PID=$!
$ sudo spi-config -d /dev/spidev0.0 -q
/dev/spidev0.0: mode=0, lsb=0, bits=8, speed=500000, spiready=0
$ sudo kill $PID

Note: That 4th test with "-w &" is because of "Note: on some platforms, the speed is reset to a default value when the file descriptor is closed. To avoid this, one can use the -w option that keep the file descriptor open." => Cubietruck is apparently one of those platforms.  That's why that speed setting change was only preserved on line $4, not on line $2

 

Tried looping back as root (sudo su) with spi-pipe (which comes with the spi tools above and the github page says one should be able to do like this) as follows:

 echo '000' | spi-pipe -d /dev/spidev0.0 | cat -

Getting nothing.

 

What am I doing wrong?

 

EDIT 2: found this bug, which suggests there should be some spi0 overlay (?) but that this was missing before 20.02:

https://github.com/armbian/build/pull/1663

However, marked as closed / merged as of 20.02 ---  so was it closed in 20.02 "current" or "next" which I am running? Shouldn't there be a ...-spi0.dtbo overlay then? Confused.

Edited by fri40
marked as solved; see next reply
Link to comment
Share on other sites

after spending a hundred or so (no kiddin') hours on this...

went back to the last 4.x image available, did a fresh install onto another SD card.

Played around with spi0 and spidev - never got anything back from spidev_test.

Then switched to spi2 - et voilá... here we go.

 

/boot/armbianEnv.txt:

 

verbosity=7
logo=disabled
console=both
disp_mode=1920x1080p60
rootdev=UUID=3595ccbf-f621-4737-ab70-f6bd9ccd8f49
rootfstype=ext4
overlay_prefix=sun7i-a20
overlays=spi2 spi-spidev
param_spi2_bus_pins=a
param_spidev_spi_bus=2
param_spidev_max_freq=12000000
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

Note that this uses

SPI 2 pins group "a" (MOSI, MISO, SCK, CS0): PC21, PC22, PC20, PC19

These are on CN8, next to the ethernet port. When the eth port is facing away from you, CN8 is at the left edge of the board.

PC21 + 22 in the left row, 3rd+4th from botom

PC19+20 in the right row, 3rd+4th from bottom

GND + 3.3V are next to each other at the bottom

see here: http://docs.cubieboard.org/tutorials/cubietruck/start

Don't be confused, on that page you see the SPI2 pins in the table below the picture. Klicking on the picture, you get the same table in it, but only "PCxx" names for these same pins.

 

You can check whether the pins are allocated to SPI2 using this:

sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins

which should give:

pin 83 (PC19): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PC19
pin 84 (PC20): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PC20
pin 85 (PC21): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PC21
pin 86 (PC22): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PC22

you can have a look at the status of the SPI2 / SPIDEV:

cat /proc/device-tree/soc@01c00000/spi@01c17000/status
cat /proc/device-tree/soc@01c00000/spi@01c17000/status 
dmesg | grep -i spi
lsmod | grep -i spi
ls -l /dev/spi*

which should give "okay" for the first two, and one line for the third, fourth and fifth each

 

now, get spidev_test.c and compile it:

https://raw.githubusercontent.com/torvalds/linux/master/tools/spi/spidev_test.c
gcc spidev_test.c
 

Then, finally, if you jumper PC21<>PC22 (MOSI<>MISO), you should get a successful loop-back like this from spidev_test.c (compiled into a.out)

$ sudo ./a.out -D /dev/spidev2.0 -v
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  |......@.........................|
RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  |......@.........................|

 

IF RX is all zero... don't ask me. WTF...

Link to comment
Share on other sites

9 minutes ago, fri40 said:

after spending a hundred or so (no kiddin') hours on this...


Welcome to the time wasting club :rolleyes:

 

Most of the bugs we have to ignore, since a few people can't support 1000 people work. We can only do "best effort" way. I will book this one for inspection when time permits. This is the best I can do ATM - it can easily take months.

 

 

Link to comment
Share on other sites

Hi Igor, no offence, no expectations for support! If I get some, great, if not, well... that's why I'm in said "club" for decades already anyhow.

 

Maybe it is straight forward, not really a "bug" but lack-of-knowledge and understanding on my side. But I couldn't find a straight, recent "howto" anywhere.

 

If by more testing I can help to get spi0..2 reliable on cubietrucks, count me in. Coding is not my domain though.

 

I can add more information on what I found playing with the dev branch (built Linux version 5.6.12-sunxi) - there at some point it appeared that brcm (wifi?) and spi0 got mixed up.

I had patched the "genreal sunxi" DTB patch to include building spi0..2 (see here).

I had spi0 and spidev in armbianEnv.txt.

 

ttl console reported no problem applying both overlays at first glimpse:

[21:45:17:145] 601 bytes read in 4 ms (146.5 KiB/s)
[21:45:17:157] Applying kernel provided DT overlay sun7i-a20-spi0.dtbo
[21:45:17:187] 1069 bytes read in 5 ms (208 KiB/s)
[21:45:17:204] Applying kernel provided DT overlay sun7i-a20-spi-spidev.dtbo
[21:45:17:231] 5532 bytes read in 5 ms (1.1 MiB/s)
[21:45:17:243] Applying kernel provided DT fixup script (sun7i-a20-fixup.scr)
[21:45:17:258] ## Executing script at 44000000

But further on in that ttl console output, I had this, looking not good:

[21:45:22:763] [    4.111870] ahci-sunxi 1c18000.sata: 1c18000.sata supply ahci not found, using dummy regulator
[21:45:22:775] [    4.120655] ahci-sunxi 1c18000.sata: 1c18000.sata supply phy not found, using dummy regulator
[21:45:22:787] [    4.130252] sun4i-pinctrl 1c20800.pinctrl: pin PI12 already requested by 1c20800.pinctrl; cannot claim for 1c05000.spi
[21:45:22:800] [    4.141034] sun4i-pinctrl 1c20800.pinctrl: pin-268 (1c05000.spi) status -22
[21:45:22:800] [    4.148030] sun4i-pinctrl 1c20800.pinctrl: could not request pin 268 (PI12) from group PI12  on device 1c20800.pinctrl
[21:45:22:813] [    4.158748] sun4i-spi 1c05000.spi: Error applying setting, reverse things back
[21:45:22:824] [    4.166010] sun4i-spi: probe of 1c05000.spi failed with error -22
[21:45:22:837] [    4.173420] libphy: Fixed MDIO Bus: probed
[21:45:22:837] [    4.178208] sun4i-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pa not found, using dummy regulator

And checking

$ sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins

gave this:

pin 266 (PI10): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 267 (PI11): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 268 (PI12): 1c20800.pinctrl (GPIO UNCLAIMED) (HOG) function clk_out_a group PI12
pin 269 (PI13): (MUX UNCLAIMED) (GPIO UNCLAIMED)

What does clk_out_a have to do on PI12 then?

Last test with 5.6: removed “spi0” from armbianEnv.txt; Reboot; no change except for the errors are gone from dmesg; clk_out_a is still on PI12. Not wanting to dig down that tunnel, I stopped with 5.6 experiments.

 

I then made a fresh SD card using "Armbian_5.59_Cubietruck_Ubuntu_bionic_next_4.14.65".

On that, first tried with only "spidev" in armbianEnv.txt. That gave spidev0.0, but PI10..P13 remained "unclaimed" in the pinmux output.

 

Okay, so one has to also add spi0 to armbianEnv.txt. Done that, rebooted.

=> $ sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins

pin 266 (PI10): 1c05000.spi (GPIO UNCLAIMED) function spi0 group PI10
pin 267 (PI11): 1c05000.spi (GPIO UNCLAIMED) function spi0 group PI11
pin 268 (PI12): 1c05000.spi (GPIO UNCLAIMED) function spi0 group PI12
pin 269 (PI13): 1c05000.spi (GPIO UNCLAIMED) function spi0 group PI13

Okay, now spi0 claims PI12 (as it should, right?).

 

When I then fired spidev_test (alias a.out in output below) onto the pins, the cubietruck lost network connections and did also not accept local keyboard inputs any more except for CTRL+ALT+DEL (=SIGINT below) to make it reboot. relevant journalctl output below (the brcmf_... messages would repeat endlessly until I give it the SIGINT "shot")

May 14 06:56:06 cubie2 sudo[1243]:    cubie : TTY=pts/0 ; PWD=/home/cubie/SPIdev/spidev_test ; USER=root ; COMMAND=./a.out -v
May 14 06:56:06 cubie2 sudo[1243]: pam_unix(sudo:session): session opened for user root by cubie(uid=0)
May 14 06:56:06 cubie2 sudo[1243]: pam_unix(sudo:session): session closed for user root
May 14 06:56:11 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:11 cubie2 kernel: brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110)
May 14 06:56:14 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:17 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:17 cubie2 kernel: brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
May 14 06:56:19 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:22 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:22 cubie2 kernel: brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
May 14 06:56:24 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:27 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:27 cubie2 kernel: brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
May 14 06:56:30 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:32 cubie2 kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
May 14 06:56:32 cubie2 kernel: brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
May 14 06:56:33 cubie2 systemd[1]: Received SIGINT.

Repeated that twice, then decided to give up on it with spi0.... and give spi2 a shot. As reported above, that worked "immediately" with 4.14.65.

 

Have not yet been brave enough (wife rolling eyes ;-) ) to check 5.6 dev with spi2 yet.

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines