Jump to content

How to enable hardware SPI


hajs

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

 

 
Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

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