How to enable hardware SPI

[hajs]

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. 

[martinayotte]

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

 

[willmore]

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?

[zador.blood.stained]

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.

[willmore]

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.

[zador.blood.stained]

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.

[willmore]

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

[willmore]

Okay, I'll try it with overlays from the testing repo that you mentined in your call for testers.  Thanks for the help!

[zador.blood.stained]

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

[zador.blood.stained]

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)

[willmore]

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!

[willmore]

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.

[martinayotte]

@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"

 

[willmore]

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

[martinayotte]

Can you try with the one I've placed in attachment ?

sun8i-h3-spi0-spidev.dtbo

[zador.blood.stained]

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

[willmore]

@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"?

[zador.blood.stained]

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.

[willmore]

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.

[zador.blood.stained]

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

 

[willmore]

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.

[willmore]

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.

[martinayotte]

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

 

[willmore]

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?

[willmore]

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

[willmore]

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!

[willmore]

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

[zador.blood.stained]

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.

[willmore]

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.

[zador.blood.stained]

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");