hajs Posted March 11, 2017 Share Posted March 11, 2017 hello, can you help me to enable SPI please. I have MCP004 with SPI on orange pi zero with armbian , and I dont know how enable SPI comunication. Before I used raspberry pi and there MCP3004 worked fine. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted March 11, 2017 Share Posted March 11, 2017 You are probably using Legacy kernel, so, in such case, take a look at Fex Guide under SPI section : http://linux-sunxi.org/Fex_Guide 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 How about for the mainline kernel? I've tried: Editing /boot/armbinaEnv.txt and adding "overlays=sun8i-h3-spi0-spidev" and rebooting. modprobing spi-dev I don't see anything in /dev/spi* Clearly I've missed something. Can you advise, please? 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 2 minutes ago, willmore said: Clearly I've missed something. Probably you missed the documentation: https://docs.armbian.com/Hardware_Allwinner_overlays/ Overlay names and availability changed several times, and in recent enough versions documentation above and SoC specific READMEs should be used as a reference. 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 I've read the documentation you linked to. I think the problem start around Overlay Parameters. They mention a set of README.* files that should be in /boot/dtb/overlay or in /boot/dtb/allwinner/overlay, but no such files exist. Following the general--and maybe outdated--advice from the documentation, I added "param_spidev_spi_bus=0" and rebooted. Nothing changed. I guess the next step is to hook a serial line up to it and see what's happening. 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 6 minutes ago, willmore said: I've read the documentation you linked to. I think the problem start around Overlay Parameters. They mention a set of README.* files that should be in /boot/dtb/overlay or in /boot/dtb/allwinner/overlay, but no such files exist. Following the general--and maybe outdated--advice from the documentation, I added "param_spidev_spi_bus=0" and rebooted. Nothing changed. This depends on your boot script version and kernel/DT packages build date. I would recommend using both as new as possible (may require using a new image or manually upgrading the boot script). Serial console can be useful to spot any issues, but SPIdev overlays should work out of the box if they are loaded properly. 1 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 Searching elsewhere on the forum, I found How to enable hardware SPI which covers the 'dynamic dtb overlay' support. The summary is to: mkdir /sys/kernel/config/device-tree/overlays/spi cat spidev-enable.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo Where 'spidev-enable.dtbo' could be any file from /boot/dtb/overlay. I got a big kernel bug from that. I'll try it again from a clean boot without modprobing the spidev module. That gives the same error. Oh, you responded... 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 Okay, I'll try it with overlays from the testing repo that you mentined in your call for testers. Thanks for the help! 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 (edited) 2 hours ago, willmore said: I got a big kernel bug from that. I'll try it again from a clean boot without modprobing the spidev module. Hm. It shouldn't produce any bugs (except for "spidev listed directly in DT" which is not a bug but a warning which is removed in newer Armbian kernels), but also please note that newer provided overlays may not work with configfs - i.e. for SPIdev overlays have everything in "disabled" state and require additional parameter to specify the bus number to enable. Edited March 19, 2017 by zador.blood.stained may **not** work 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 2 hours ago, willmore said: Okay, I'll try it with overlays from the testing repo that you mentined in your call for testers. Thanks for the help! These ones should be already included in the latest nightly images or beta repository packages. If you just want to test SPI you can just try a fresh nightly image (if it exists for your board) 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 I've never intentionally used the beta repository. I do notice that my Zero's, PC's, and PC2's all get regular kenel update, but my One doesn't. I guess that's probably the difference. I'll go look at the other boards repo setup and see what's different--and bring the One over to the beta feed. Thanks for all of the help, Zador! 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 Okay, got an Opi One on the beta repository booting a new kernel. I tried both the armbianEnv.txt method and the "cat /boot/dtb/overlay/sun8i-h3-spi-spidev.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo" methods and had no luck. No response from dmesg nor any /dev/spi* files. I seem to be getting further away from a working system. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted March 19, 2017 Share Posted March 19, 2017 @willmore, have you done "mkdir /sys/kernel/config/device-tree/overlays/spi" before doing the "cat" ? Do you have a pseudo file /sys/kernel/config/device-tree/overlays/spi/status ? Can you "cat" to see if it contains "applied" or "unapplied" 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 @martinayotte Yes, sir, I did. I'm following the advice of the thread How to enable hardware SPI. I've cloned the current dtb code mentioned in that thread as well and I'm making my own .dtbo. I've also tried the one in /boot/dtb/overlay/ Neither shows any reaction by the kernel. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted March 19, 2017 Share Posted March 19, 2017 Can you try with the one I've placed in attachment ? sun8i-h3-spi0-spidev.dtbo 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 3 minutes ago, willmore said: Neither shows any reaction by the kernel. Sorry, I meant may not work 2 hours ago, zador.blood.stained said: also please note that newer provided overlays may not work with configfs - i.e. for SPIdev overlays have everything in "disabled" state and require additional parameter to specify the bus number to enable. If yu updated the kernel and packages, then please also update the boot script (as root) wget https://raw.githubusercontent.com/igorpecovnik/lib/master/config/bootscripts/boot-sunxi.cmd -O /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and try using overlays=spi-spidev param_spidev_spi_bus=0 in /boot/armbianEnv.txt 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 @martinayotteThat seems to have produced a /dev/sdidev0.0! I'll see if I can get it to speak, too. @zador.blood.stained Not "overlays=sun8i-h3-spi-spidev"? 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 4 minutes ago, willmore said: @zador.blood.stained Not "overlays=sun8i-h3-spi-spidev"? No. But I also forgot that you need to add overlay_prefix=sun8i-h3 to /boot/armbianEnv.txt if you don't have that line. 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 Okay, @zador.blood.stained, that made the device persistant. the spidev-test program doesn't do anything that I can see, so I'll have to poke around in user land as it seems things are good in kernel land now. I'm monitoring pins 19, 21, 23, 24 and not seeing anything with: ./spidev_test -D /dev/spidev0.0 -s 10000 -b 8 I was expecting to see some activity on CS or CLK, but nothing at this time. Probably just pilot error on my part. I'll keep at it and see if I can get movement on something. Thank you again for all of your help. Same to you, @martinayotte. 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 19, 2017 Share Posted March 19, 2017 18 minutes ago, willmore said: I'm monitoring pins 19, 21, 23, 24 and not seeing anything with: ./spidev_test -D /dev/spidev0.0 -s 10000 -b 8 I was expecting to see some activity on CS or CLK, but nothing at this time. Probably just pilot error on my part. I'll keep at it and see if I can get movement on something. For me ./spidev-test -D /dev/spidev0.0 is enough to see some activity on CLK and MOSI. If you connect MOSI and MISO togehter you should see that your data is received back if everything is wired and configured correctly, i.e. root@orangepiplus2e:~# ./spidev-test -D /dev/spidev0.0 -s 10000 -p 123456789 spi mode: 0x0 bits per word: 8 max speed: 10000 Hz (10 KHz) RX | 31 32 33 34 35 36 37 38 39 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | 123456789 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 I jumpered 19 to 21 and ran the test and I don't see anything. looks like something still isn't right. To summarize: 1> installed the new boot.cmd (@zador) 2> did the mkimage 3> edited /boot/armbianEnv.txt to add: overlay_prefix=sun8i-h3 overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_max_freq=100000000 4>rebooted and found /dev/spidev0.0 crw------- 1 root root 153, 0 Mar 19 20:42 /dev/spidev0.0 5>I see the spidev kernel module installed. 6>Compiled the spidev_test.c program from the mainline kernel 7>Hooked a scope to Orange Pi One pins 19, 21, 23, 24 8>ran the spidev_test program with several sets of options 9>observed no changed on the scope. Well, I did see the line that should be CS go and stay high--I think that happened during the first 'cat' into /sys when followerd @martinayotte's procedure. It's stayed that way through several reboots. I think I'll power cycle and see when it goes high. 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 19, 2017 Share Posted March 19, 2017 Note to self, don't be stupid. On the plus side, both of my Orange Pi One boards now have working SPI0. Want to guess why? Let's use my previous post to show how to do it right as that worked perfectly. One might just make a note to remember to perform all of those actions *on the same board*. I'm going to go enjoy my working SPI and my stupidity. Thanks for all of the help, @zador.blood.stainedand @martinayotte. Also, sorry for the grief. 1 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted March 20, 2017 Share Posted March 20, 2017 Enjoy your new SPI ! Now you can build small SPI-NOR adaptor, upload U-Boot SPL to this Flash using flashcp, and enjoy booting from USB-Drive without any SDCard ... 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 20, 2017 Share Posted March 20, 2017 Cool, works from 12.5KHz to 100MHz. The top end is a bit crampt, but signals look as good as my poor 100MHz BW scope can see. The granularity of the clock is poor. It's just 100MHz/N where N is a natural number. @martinayotte, is the clock for SPI that simple or is there a more complex clock chain that can feed the SPI unit? It looks like the largest transfers I can do are 4K. Does that sound correct? Does something else need to be done to do larger transfers? 4K is, I'm guessing, page size? 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 20, 2017 Share Posted March 20, 2017 @martinayotte, thanks! That's the eventual use. I have two Zero's. One with the stock 16Mb chip and the other with a custom 128Mb chip for just that kind of testing. Before that, I want to test out the DMA SPI code and help tune where the buffer thresholds need to be. I also want to see about getting DIO working in the kernel. Then it'll be time to move on to learning uboot and the SPI boot code. 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 20, 2017 Share Posted March 20, 2017 I did a loopback test with a 200mm+ jumper wire from MISO to MOSI and transfered a 4KB block of random data error free. That makes me think that a short well laid out PCB trace should do better. Maybe we can get 100MHz at DIO for a whopping 25MB/s! Feel the power! 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 20, 2017 Share Posted March 20, 2017 @zador.blood.stained, Am I correct in believing that the current beta channel kernels for the Orange Pi One have the DMA patch in them and the FIFO set to 'fifo_size - 1'? MoeIcenowy was saying that on the IRC. I put a command to do 4K transfers in a loop which should exit if there is an error. I'm letting it run overnight. Okay, looking closer at the scope, I can see it. It's pretty interesting. I need to get the protocol analysis tools running on the scope to see how many bytes are transfered between the gaps. Looks like I can do 48 4K transfers/sec using the spidev_test program. So, that's got a ton of overhead. I need to write a program that cuts that out. 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 20, 2017 Share Posted March 20, 2017 5 hours ago, willmore said: Am I correct in believing that the current beta channel kernels for the Orange Pi One have the DMA patch in them and the FIFO set to 'fifo_size - 1'? First, I'm pretty sure that we don't have DMA transfers in both sunxi SPI drivers. Second, previously we had large transfers patch from @martinayotte that reported large enough max transfer size, but several days ago it was replaced with Icenowy's version which didn't touch max transfer size reporting (so fifo_depth-1 was returned). I fixed it yesterday so next kernel should be ready for large enough transfers. 0 Quote Link to comment Share on other sites More sharing options...
willmore Posted March 20, 2017 Share Posted March 20, 2017 Quote First, I'm pretty sure that we don't have DMA transfers in both sunxi SPI drivers. Second, previously we had large transfers patch from @martinayotte that reported large enough max transfer size, but several days ago it was replaced with Icenowy's version which didn't touch max transfer size reporting (so fifo_depth-1 was returned). I fixed it yesterday so next kernel should be ready for large enough transfers. Hmm, okay, I'm seeing 4K transfers accepted by the test program, but not 8K. That's well past the size of the FIFO. It may not use DMA, but something is feeding the FIFO. I think it's time to me to make my own test program so that I know exactly what it does and what the error messages are. 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 20, 2017 Share Posted March 20, 2017 11 minutes ago, willmore said: Hmm, okay, I'm seeing 4K transfers accepted by the test program, but not 8K. SPIdev driver limitation? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/spi/spidev.c#n93 static unsigned bufsiz = 4096; module_param(bufsiz, uint, S_IRUGO); MODULE_PARM_DESC(bufsiz, "data bytes in biggest supported SPI message"); 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.