Jump to content

How to enable hardware SPI


hajs

Recommended Posts

Armbian & Khadas are rewarding contributors

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by zador.blood.stained
may **not** work
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines