How to enable hardware SPI

[willmore]

Thanks for that!  Okay, then the DMA patches from MoeIcenowy are a bit overkill when they limit their transfer length to 2^24-1.

sun6i-dma-patch

 

"#define SUN6I_MAX_XFER_SIZE 0xffffff"

 

Seeing that, I was assuming that the rest of the SPIDEV infrastructure supported larger transfers.  Maybe that's there for kernel drivers which may do larger than page sized transfers.  That would make sense as it would be hard to get DMA memory allocated from a user space transfer, while a kernel module wouldn't have the same issue.

[zador.blood.stained]

1 minute ago, willmore said:

Okay, then the DMA patches from MoeIcenowy are a bit overkill when they limit their transfer length to 2^24-1.

Why? SPIdev is not the only thing that SPI can be used for. SPI NOR MTD layer, fbtft and other kernel drivers may want to use large enough transfers, and this limit is the same as in sun4i SPI driver.

 

3 minutes ago, willmore said:

I was assuming that the rest of the SPIDEV infrastructure supported larger transfers.

SPIdev is just one of SPI "clients" that exposes a device node for the userspace. It's separate from other SPI drivers and is not required by them.

[willmore]

Quote

Why? SPIdev is not the only thing that SPI can be used for. SPI NOR MTD layer, fbtft and other kernel drivers may want to use large enough transfers, and this limit is the same as in sun4i SPI driver.

Thank goodness I answered that in the very message you quote.

Quote

Maybe that's there for kernel drivers which may do larger than page sized transfers.  That would make sense as it would be hard to get DMA memory allocated from a user space transfer, while a kernel module wouldn't have the same issue.

 

[zador.blood.stained]

7 minutes ago, willmore said:

Thank goodness I answered that in the very message you quote.

I just wanted to clarify that there is no "SPIdev infrastructure" and SPIdev limitations don't affect other device drivers.

[willmore]

Quote

I just wanted to clarify that there is no "SPIdev infrastructure" and SPIdev limitations don't affect other device drivers.

 

Fair enough.  On the plus side, it looks like 4K transfers are sufficient to drain the buffer with the existing driver.  I need to annotate the captures I've done so far.  I'll also need to do them again at slower speeds--100MHz is, by definition, an extreme test.

[martinayotte]

Folks, I apologize not having reviewed Icenowy's version properly about sun6i_spi_max_transfer_size().

I think I will ping her about this issue ...

[willmore]

@martinayotteI don't think there is a problem.  As @zador.blood.stainedpoints out, there are other consumers of the SPI drivers in the kernel which don't share the 4K limitation that the user space facing spidev codes does.

 

When I looked over her code, I didn't assume the 4K limitation.  My only concern is that I didn't see any of the normal 'is this page proper for DMA on this architecture' kind of checks.  But, I'm well out of practice for reviewing kernel patches.  It's been a very long time.

[martinayotte]

Well, as you discovered, Zador's discovery against previous version was important, not for the 4K limitation but for the FIFO size.

Yesterday, I've done only quick tests, so, I'm still apologized for having missed that one.

 

[zador.blood.stained]

Some drivers (like SPIdev) simply ignore max_transfer_size check for the SPI master, but others do use this value (out of in-kernel drivers only SPI NOR does this according to quick kernel sources checking)

 

Edit: There is also max_message_size that is not enforced for sunxi SPI master drivers, so it defaults to SIZE_MAX (no limitation)

[jbird1]

So learned a lot of interesting things.  3.4.113-sun8i

1.  rebuilt using armbian build system on my linux virtual box latest 

2. spent several hours digging in to SPI mess.  Turns out armbian-config is broken, none of the overlays work.

3. I found the /boot/dtb-4.13.5-sunxi/overlay/README.sun8i-h3-overlays file that explains the correct configuration information

4. Then watching boot on serial console, noticed that /boot/dtb/overlay/sun8i-h3 was not being found.

5.  Dug through /boot/dtb-4.1.3.5-sunxi/overlay and found /boot/dtb-4.13.5-sunxi/sun8i-h3-orangepi-plus.dtb

6.  I mkdir -p /boot/dtb/overlay/ and copied /boot/dtb-4.13.5-sunxi/sun8i-h3-orangepi-plus.dtb to /boot/dtb/overlay/sun8i-h3

7. That failed so went back to arbianEnv.txt and tried alternative kernel.

8.  Now the hand edited armbianEnv.txt file below works on reboot

This suggests that last nights build has broken or miss matched overlay names (see above) which results in sun8i-h3 not being found.  And possibly armbian-config has dev vs default kernal backwards as well as the armbian-config tool is crashing when you attempt to use to configure the system.  So we are successful but recommend the nightly build be inspected and an update be made available.  Thanks however to all that helped me learn how to look in the right places. Greatly appreciate your assistance and support.  

 

/boot/armbianEnv.txt

 

verbosity=7    # I set to maximum to see individual sets in the boot on the serial console thats how we found the file issue.
logo=enabled
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=spi-spidev spi-add-cs1 i2c0 i2c1 i2c2 pps-gpio pwm w1-gpio uart1 uart2 uart3 usbhost0 usbhost1 usbhost2 usbhost3 analog-codec cir
param_spidev_spi_bus=0
param_spidev_spi_cs=0
param_spidev_max_freq=1000000

rootdev=UUID=36c931bc-bed2-4783-9738-42e41805b426
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

Here is how we tested spidev0.0 on a Orange PI 2+ with hand wired MCP3008 on port 0.  (confusing about spi-add-cs1 but understand why not to use spi-nor bits as they are in conflict with spidev0.0.

root@opi:/home/j/mcp3008# ls /dev/s*
/dev/sda        /dev/stderr  /dev/stdout     /dev/sunxi_soc_info
/dev/spidev0.0  /dev/stdin   /dev/sunxi-reg

/dev/shm:

/dev/snd:
by-path    controlC1  pcmC0D0p  pcmC1D0p  timer
controlC0  pcmC0D0c   pcmC1D0c  seq
 

spidev0.0 is visible and active, and testspi now works

 

root@opi:/home/j/mcp3008# tree /dev/spidev0.0
bash: tree: command not found
root@opi:/home/j/mcp3008# ./testspi
writing command 1 1 0
reading data 0 0 119 
count = 119 voltage 2.0105
writing command 1 1 0
reading data 0 0 84 
count = 84 voltage 1.4192
writing command 1 1 0
reading data 0 0 22 
count = 22 voltage 0.3717
 

Attached are the mcp3008 files used to build the testspi, comments document all the pins and bits.

 

Please share and I hope it helps others,  J 

 

 

buildit.sh

mcp3008.cpp

mcp3008Spi.h

mcp3008test.cpp

[martinayotte]

Quote

3.4.113-sun8i

Overlays only work under Mainline !

For Legacy, you still need to use FEX ...

Quote

spidev0.0 is visible and active, and testspi now works

Good ! There is also the spidev_test.c from kernel tree that allow to test SPIs with a loopback wire between MISO/MOSI.

 

[ag123]

hi i'm bouncing this thread as i'm messing around with the device tree on Debian Stretch distribution on Orange Pi one. so i picked spi as the starting point as it seem to have plenty of 'old' threads about it

i ran into the same problems that even though i found the dtb (device-tree-blobs) in /boot/dtb/sun8i-h3-* (for the boards) and /boot/dtb/overlay/sun8i-h3-spi-spidev.dtbo, i simply don't find any spi devices in  /dev/spi*. neither do i find spidev loaded with lsmod. doing a modprobe doesn't solve it either.

 

hence i tried @martinayotte's sun8i-h3-spi0-spidev.dtbo file and it works. thanks !

 

out of curiosity i checked out /boot/dtb/overlay/sun8i-h3-spi-spidev.dtbo

Spoiler

$ dtc -I dtb -O dts sun8i-h3-spi-spidev.dtbo

/dts-v1/;
/ {
        compatible = "allwinner,sun8i-h3";
        fragment@0 {
                target-path = "/aliases";

                __overlay__ {
                        spi0 = "/soc/spi@01c68000";
                        spi1 = "/soc/spi@01c69000";
                };
        };
        fragment@1 {
                target = <0xffffffff>;

                __overlay__ {
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;

                        spidev {
                                compatible = "spidev";
                                status = "disabled";
                                reg = <0x0>;
                                spi-max-frequency = <0xf4240>;
                        };
                };
        };
...

hence as it turns out the delivered dtc overlays in the distribution has the devices *disabled*

after doing google searching around, i stumbled into this

http://linux-sunxi.org/SPIdev#Configuring_your_device-tree_.28mainline.29

Quote

For the most boards SPI is disabled by default. To enable it you have to modify device-tree of your board.

 

hence, that would mean one needs to use a custom device tree file in place of those dtc overlays provided in /boot/dtb or /boot/dtb/overlay if they are delivered disabled in default

 

 

[martinayotte]

2 hours ago, ag123 said:

if they are delivered disabled in default

Did you provided such parameters in /boot/armbianEnv.txt as explained in /boot/dtb/overlay/README.sun8i-h3-overlays ?

param_spidev_spi_bus=0
param_spidev_spi_cs=0

 

[ag123]

1 hour ago, martinayotte said:

Did you provided such parameters in /boot/armbianEnv.txt as explained in /boot/dtb/overlay/README.sun8i-h3-overlays ?

 

yup i've tried those, but none of those parameters succeeded in 'enabling' the spi devices

in fact i checked in /proc/device-tree/soc/spi@01c68000 and /proc/device-tree/soc/spi@01c69000

each time cat status returns 'disabled'

only using a different dtbo file resolve the issue and /dev/spi* appears

 

i tried something following your hints here

that actually works, the DTC compiler by Pantelis Antoniou is apparently much better than the DTC compiler distributed in stock debian.  Pantelis Antoniou's DTC compiler resolves symbols in the dts file rather than needing static references. in fact i use the following DTS file which is adapted by decompiling the distributed DTBO, and following some hints from your prior posts and the /dev/spi* devices appears after reboot

 

Spoiler

compile the following code using Pantelis Antoniou's DTC compiler (https://github.com/pantoniou/dtc)
$ dtc -@ -I dts -O dtb sun8i-h3-spi-spidev.dts > sun8i-h3-spi-spidev.dtbo

----- sun8i-h3-spi-spidev.dts -----
// Enable the spidev interface
/dts-v1/;
/plugin/;
/ {
    compatible = "allwinner,sun8i-h3";
    fragment@0 {
    target-path = "/aliases";
    __overlay__ {
            /* Path to the SPI controller nodes */
            spi0 = "/soc/spi@01c68000";
            spi1 = "/soc/spi@01c69000";
        };
    };
    fragment@1 {
        target = <&spi0>;
        __overlay__ {
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            spidev@0 {
                compatible = "spidev";
                reg = <0x0>;
                spi-max-frequency = <1000000>;
            };
        };
    };
    fragment@2 {
        target = <&spi1>;
        __overlay__ {
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            spidev@0 {
                compatible = "spidev";
                reg = <0x0>;
                spi-max-frequency = <1000000>;
            };
        };
    };
};

(take note that this may cause a pin conflict on SPI1 with the led on orangepi one. see comments below

[martinayotte]

I've just checked on some of my board with Mainline 4.18.5, and the /dev/spidev0.0 are appearing ...

Which kernel are you using on your OPiOne ?

 

[ag123]

currently i'm seeing 4.14.18-sunxi when i run uname -a, perhaps i need to update my kernels

[martinayotte]

Maybe ... Keep this 4.14.8 on current SDCard, and use another one for trying building a Mainline image.

BTW, Did you see any error in u-boot booting phase on debug serial ?

 

[ag123]

i've not actually tried a serial debug, what i did is  to update /boot/armbianEnv.txt so that it loads the spi device tree overlay blob. hence i tried the parameters as well. after that i check /proc/device-tree/soc/spi@* to see if it is successfully instantiated as well as /dev/spi* to see that it is there

---- /boot/armbianEnv.txt ----
overlay_prefix=sun8i-h3
overlays=spi-spidev

some messages in dmesg

Quote

[    3.840120] sun8i-h3-pinctrl 1c20800.pinctrl: pin PA15 already requested by 1c69000.spi; cannot claim for leds
[    3.840128] sun8i-h3-pinctrl 1c20800.pinctrl: pin-15 (leds) status -22
[    3.840136] sun8i-h3-pinctrl 1c20800.pinctrl: could not request pin 15 (PA15) from group PA15  on device 1c20800.pinctrl

[    8.865939] spidev spi0.0: probing from DT
[    8.872538] spidev spi1.0: probing from DT

 

 

i'd probably disble spi1 in the dts file due to the pin conflict with led

[martinayotte]

19 minutes ago, ag123 said:

pin PA15 already requested by 1c69000.spi

That's explain every thing ... The overlay trying to hook up both SPI0 and SPI1, and on some OPi, the STATUS-LED is moved on PA17 instead of PA15 to free up the SPI1-MOSI.

So, best thing to do is either use my old overlay only for SP10, since you don't use SPI1, or you can edit the spi-spidev to remove SPI1 section, or use another overlay to unbind the STATUS-LED :

 

// Unbind LED
/dts-v1/;
/plugin/;

/ {
    compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";

    fragment@0 {
	target-path = "/aliases";
	__overlay__ {
            led = "/soc/pinctrl@01c20800/led_pins@0";
        };
    };
    fragment@1 {
        target = <&leds_opc>;
        __overlay__ {
            label = "orangepi:red:status";
            gpios = <&pio 0 15 0>;
            linux,default-trigger = "none";
            default-state = "off";
        };
    };
};

 

 

 

[ag123]

@martinayotte thanks much for all the responses, i'd explore other things including to make an attempt to verify that spi is after all working

i'd update to a more recent mainline kernel as things seem to be evolving and what i'm seeing may change in a more recent kernel update

 

figuring out DTS is a good thing, i'm looking out for the means to access those same things that is done in FEX in the 'legacy' kernels.

 

[martinayotte]

45 minutes ago, ag123 said:

PA15 already requested by 1c69000.spi

I've check again my previous affirmation directly on my un-dusted OPiOne, and I was wrong : since spi-spidev overlay keep both SPI "disabled" , only the one specified in param_spidev_spi_bus=0 will turn as "okay" and I didn't get any conflict with STATUS-LED. So, if you had this conflict, it is because you used param_spidev_spi_bus=1 instead ...

So, it should have work on your previous attempt !

 

EDIT : I've even added a loopback wire between MOSI and MISO, and it is working fine ...

[Jay The Legend]

So I've been following this thread with little success. One big difference I noticed is this is for the Orange Pi(All winner H3 ) and I am using the Pine A64 (All winner A64). Are there much difference in how you enable SPI on the A64?

[martinayotte]

8 hours ago, Jay The Legend said:

re there much difference in how you enable SPI on the A64?

No, there are no differences ...

What did you tried and did not get success ?

[Jay The Legend]

I'm running Armbian 5.65 and only interested in SPI0.
Following willmore:

1. Installed the new boot.cmd and ran mkimage (Same result, broke my kernel)

2. Tried sun8i-h3-spi-spidev.dtbo file from martinayotte (Files on my board was: sun50i... which seemed strange)

3. edited /boot/armbianEnv.txt to add:

overlay_prefix=sun8i-h3
overlays=spi-spidev
param_spidev_spi_bus=0

param_spidev_spi_cs=0
param_spidev_max_freq=100000000
(I also remembered changing SPI0 from disabled to okay, but going back in the files I do not see it anymore. Think it was part of a longsleep ubuntu I tried before.)

4. add overlay_prefix=sun8i-h3

5. Tried hard not to be stupid(failing miserably)....

Rebooted in between a couple of times, however nothing in /dev. After looking at jbird1 I'm seriously confused. No solution seems to work out of the box.

This thread jumps around a lot, is there a step by step I can try and follow?

[martinayotte]

34 minutes ago, Jay The Legend said:

(Files on my board was: sun50i... which seemed strange)

Of course, since your board is a PineA64, you should leave the overlay_prefix=sun50i-a64, don't change it to sun8i-h3 ...

 

[Jay The Legend]

@martinayotte Thank you for the suggestion. I changed to same, rebooted with no luck. Anything else I'm missing like do another make or something? For reference herewith my armbianEnv.txt:

 

verbosity=1
console=both
disp_mode=720p60
camera_type=none
pine64_lcd=off
rootdev=UUID=2a9ed406-bd1a-46ce-b16b-908ee24b8eeb
rootfstype=ext4
overlay_prefix=sun50i-a64
overlays=spi-spidev
param_spidev_spi_bus=0
param_spidev_spi_cs=0
param_spidev_max_freq=100000000
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

And the contents of my dtb:

dtb-3.10.107-pine64         sun50iw1p1-nanopim64.dtb      sun50iw1p1-pine64.dtb           sun50iw1p1-pine64so.dtb
sun50iw1p1-bananapim64.dtb  sun50iw1p1-olinuxino-a64.dtb  sun50iw1p1-pine64-pinebook.dtb  sun50iw1p1-soc.dtb
sun50iw1p1-fpga.dtb         sun50iw1p1-orangepiwin.dtb    sun50iw1p1-pine64-plus.dtb      sun50iw1p1-teres.dtb

 

Lastly The test I do to see if it is available is to check /dev for some flavour of SPI?

[martinayotte]

27 minutes ago, Jay The Legend said:

dtb-3.10.107-pine64

What is that ?

Which kernel are you using ?

Overlays are only supported in Mainline 4.x or 5.x ...

[Jay The Legend]

10 hours ago, martinayotte said:

What is that ?

Which kernel are you using ?

Overlays are only supported in Mainline 4.x or 5.x ...

Not sure what the file is, but the 3.10.107 is the kernel version. Thanks for the heads up. I remember reading the version issue on this post, but thought it would not be an issue as the armbian I'm using is only a couple of months old. Anyway, I'll try it out and revert back. @martinayotteThank you for your valuable input.

[Jay The Legend]

@martinayotte The Kenrel version was indeed the problem. Updated edited armbianEnv.txt, rebooted and now I can see spidev0.0! Thanks for the assist!

[martinayotte]

1 hour ago, Jay The Legend said:

Thanks for the assist!

You're welcome !