How to enable spidev interface on SoC Allwinner?

    Yes, it's still happening to me. I tried again today. But the official nightly LE10 can be installed and will run without any problems. So the cause is probably on my side, but I have no idea where. Maybe I'll try it on another computer from scratch.

    It took me several tens of hours, but I finally have some results...

    On the Orange Pi PC board, I got the OLEDproc add-on with the SPI interface up and running very quickly, without any problems. I then moved on to the Orange Pi Lite 2 board. Unfortunately there were problems there. Although the interface /dev/spidev0.0 existed, the display showed nothing. I was looking for why. I suspected the spidev add-on at first, but a test using loopback showed that spidev is fine. So I had to focus on CS, DC and RST signals. I even made a (very improvised) logic analyzer and found that the problem was in the CS signal (it was permanently connected to the logic one level). I tried to (on display) connect the CS signal permanently to GND and the display started showing! Although somewhat distorted, but still. So it was confirmed that the problem is in the non-functioning CS signal. I have now begun to investigate why this is so. I thought I'd try how it works with Armbian. I was surprised that it behaved exactly the same. I seem to have run into some bug in DT that is common to multiple OSes...

    I compared the fdt and dts files of the H3 and H6 boards and it occurred to me that the problem is that (for the H6 boards) the reference to the CS pin is missing in the fdt file.

    Here is a snippet from the decompiled fdt file:

    I believe it should look something like this correctly:

    Unfortunately, I haven't figured out a way to fix it. That's why I did it in a different way - I tried (using a patch) to modify the dts/dtb file in the same way as it is done with the H3 boards (that is, the CS pin does not have a separate node, but it is in a common node with the other signals) and it showed hope it helps!

    At first I just made a patch, modifying the "sun50i-h6.dtsi" file. However, the compilation ended with an error (in the file "sun50i-h6-pine-h64.dts" there was a reference to a missing node with a CS pin). So I had to make another patch that addressed this. Unfortunately, I don't own a pine-h64 board and I don't know if this will have any consequences for it.

    The next step was a test with the Orange Pi 3 board. It turned out that it behaves exactly the same as the Lite 2 board. This is logical, because the file "sun50i-h6.dtsi" is common to several boards. The corrected dtb file (with the help of a patch) also helped here.

    @jernej: Can you apply these patches in the official (currently nightly) release? Or to solve the problem in a different way - more professionally (that is, make sure that the reference to the CS pin is not missing in the fdt file). The non-functioning CS pin on the H6 family makes it impossible to use displays with an SPI interface.

    patches.zip

    No, there is no DT bug. It's customary to have two pin groups, one for communication pins (MISO, MOSI, SCK) and another for CS pin. CS pin can be basically any GPIO pin, not only that from SPI controller. You should actually use PineH64 DT as an example - along with SPI pin group you should also specify additional pin group for CS pin in your overlay.

    Note, we don't accept Linux patches unless they are either reviewed on some Linux ML and are on it's way to be merged or, in rare cases, work in progress patches maintained by LE developers themselves (even such patches get merged in Linux eventually).

    Other people also have trouble with the CS pin (which is high instead of low) on Orange Pi Lite 2.

    This guy has a proper configuration, but still an error:

    problems with spidev on orange pi lite 2
    I bought an orange pi lite 2 and I would like to use it with the ADC MCP3008 but when executing the code in python using the spidev library, it always returns…
    forum.armbian.com

    PS: The guy has those params:

    Code
    param_spidev_spi_bus=0
param_spidev_spi_cs=0

    Do you also have them somewhere?

    Background: Maybe some devices have SPI 0 pre-selected, but other devices need params to activate SPI 0's CS pin.

    Those parameters are not relevant for LE. Armbian has some custom extensions ported over from RPi kernel. One of these allows to have parameters for overlays.

    Quote from jernej

    No, there is no DT bug.

    OK - you're right, my reasoning was wrong.

    Quote from jernej

    It's customary to have two pin groups, one for communication pins (MISO, MOSI, SCK) and another for CS pin.

    I agree, it probably has its reasons. But I wonder why Allwinner H3 (certainly e.g. Orange Pi PC) has it differently (all pins including CS are in one group).

    Quote from jernej

    CS pin can be basically any GPIO pin, not only that from SPI controller.

    I don't think that's entirely accurate. For Allwinner H6, there is always only one HW pin (for SPI0 it is PC5, for SPI1 it is PH3). See datasheet. Yes, additional CS pins can be added using the overlay, but they are no longer HW, but SW pins. I don't need to add more pins, one SPI device is enough for me.

    Quote from LuRu

    ... Or to solve the problem in a different way - more professionally (that is, make sure that the reference to the CS pin is not missing in the fdt file).

    I knew that my solution was actually a workaround. However, now I've learned a lot about overlays and I've finally done it!

    This is what the fdt file snippet looks like after applying my new overlay and it actually works with the original dtb (without any patches).

    So the only problem was that I couldn't find a working overlay anywhere and I had to create it myself.

    Here is the (source) overlay, tested on an OPi Lite2 board: sun50i-h6-spi-spidev0.dts.zip