fri40

Validating
  • Content Count

    7
  • Joined

  • Last visited

  1. 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.
  2. 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...
  3. doing a PR ... is way beyond my skills, sorry. Not ever done anything alike. Spent probably 100 hours now on messing around with spi on cubietruck. Me := too stupid for this stuff. Eventually got what I needed falling back to a 4.x image and switching over to spi2. Something weird with spi0 on this thing. tl;dr. Got to call it a day on this.
  4. Hi all. Not sure if it is me not understanding (may well be! built my last kernels in 1997 I think...) or a flaw in this patch: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/general-sunxi-overlays.patch which is supposed to fix this bug if I understand correctly: https://github.com/armbian/build/pull/1663 Looking at the patch file in my built tree: build/patch/kernel/sunxi-dev/general-sunxi-overlays.patch To my understanding it contains the (re)addition of dts files for sun7i-a20-spi{0..2}, i.e. as of line 3456 it addes the spi0.dts source. However, building the dev kernel (latest, git updated two days ago), there is no corresponding dtbo file in /boot/dtb/overlays/ afterwards, I checked the resulting .deb. However, checking the sources deb file that is created, I can find the spi0.dts source file in arch/arm/boot/dts/overlay/sun7i-a20-spi0.dts SO, my understanding: The patch is applied, it causes the .dts source file to be created, but it never gets compiled. Looking again at the patch, after line 53 where the makefile is to be updated, it does not enlist the sun7ia-a20-spi{0..2}.dtbo files (as it does for sun5i-a13 after line 37). I've added three lines in that sun7i makefile block and started another built, which results in those spi{0..2}.dtbo files in the dtb-dev deb file. Not installed onto my cubietruck yet, so can't say if the patch actually helps with my original problem. Is the patch broken? Or did I miss the point?
  5. 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.
  6. Some progress... after many hours of strolling through various threads on SPI issues from about 200 before Christ up to about 2018.... Found some tweaks to the device tree files and the spi-spidev overlay which got me a /dev/spidev0.0. Then tried a loopback test with spidev_test.c from the kernel sources. That gave lots of ouput TX, but only zeros on RX. Reverted changes, tried this and that. Eventually ran apt update + apt upgrade to get the kernel from 5.4.20-sunxi to 5.4.35-sunxi. After a reboot, this makes spidev0.0 appear without any of my earlier tweaks to the device tree / overlay files. But I still can't get spidev_test.c get anything back to itself but zeros (i.e. "nothing") I'm sure I have the right pins looped - unless every documentation I find on the cubieboard3 / cubietruck layout is wrong (guess not). Also the wire (10cm) connects the pins - checked; they are at least "shortend" to each other by it. Anyone out there who recently got spidev working on an allwinner a20? All those I found who did it did so years back doing more or less the same I did. They got their /dev/spidev0.0 appearing, fired up the loop test and were happy (as it seems). H E L P :-) !
  7. Hi there. Trying to get SPIDEV working on my good old cubietruck aka cubieboard3 with an allwinner A20. Found some posts here and there dealing with A20 boards. But nothing of that did anything for me so far. Enabled it in armbian-config hardware settings and rebooted. No /dev/spi* at all. No mentioning of "spi" in dmesg. Step 1 gave a line "overlays=spi-spidev" in /boot/armbianEnv.txt. Read somewhere else that there should be another line "param_spidev_spi_bus=0", but that was not created by armbian-config. Added that ...bus=0 line myself and rebooted. Still no spi device and nothing in dmesg /proc/device-tree-model says "cubietech cubietruck" which is correct. Running 5.4.20-sunxi, fresh install a few days ago. Nothing special done to it yet. Anyone still playing with these old toys and done this? Thanks!