• Before reporting problems with your board running Armbian, check the following:

    • 1. Check power supply, check SD card and check other people experiences   06/23/17

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information   06/24/17

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

How to enable hardware SPI
1 1

39 posts in this topic

Recommended Posts

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. 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
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.

Share this post


Link to post
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.

willmore likes this

Share this post


Link to post
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...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
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)

Share this post


Link to post
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!

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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! ;)

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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");

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

1 1

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.