I am using a Linux rockpi-4cplus with 5.15.93-rockchip64 (bullseye).
I plan to use SPI1 (GPIO1_A7, GPIO1_B0, GPIO1_B1, GPIO1_B2), and then add in a 2nd device on this SPI bus via a custom CS GPIO pin (GPIO4_D5).
I could not find the corresponding script file (.DTS) online (on Github) associated with the object file (rockchip-spi-spidev.dtbo). Please could someone point me to it - I can only find files for "sunxi-DT-overlays".
So I decided to create my own DTS file, as follows:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target = <&spi1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
cs-gpio = <0>, <&gpio4 29 0>;
status = "okay";
spidev@0 {
reg = <0>;
compatible = "spidev";
status = "okay";
spi-max-frequency = <5000000>;
};
spidev@1 {
reg = <1>;
compatible = "spidev";
status = "okay";
spi-max-frequency = <50000000>;
};
};
};
};
This compiles and I then added in my own DTBO reference inside armbianEnv.txt (under #overlays=). I also included param_spidev_spi_bus=1, as I discovered this is still needed (where is this check made, btw).
When I reboot the following shows up for SPI in the device tree:
/proc/device-tree/spi@ff1c0000/status: disabled
/proc/device-tree/spi@ff1d0000/spidev@0/status: okay
/proc/device-tree/spi@ff1d0000/status: okay
/proc/device-tree/spi@ff1d0000/spidev@1/status: okay
/proc/device-tree/spi@ff1e0000/status: disabled
/proc/device-tree/spi@ff1f0000/status: disabled
/proc/device-tree/spi@ff200000/status: disabled
So far so good.
Interestingly you have to use spidev@0 or spidev@1 in an overlay otherwise it won't compile. So already I am at odds with the current Armbian configuration setup logic (as per overlays readme text for using a different CS and armbian just relies on spidev and not spidev@...).
I learnt from another Linux board that I can "bind" the spidev to the correct spi drivers and add in a script (e.g. within rc.local to automate). But first I needed to check what has been setup for the spi drivers. This is where I got a surprise.
root@rockpi-4cplus:/boot$ ls -l /sys/bus/spi/devices
total 0
lrwxrwxrwx 1 root root 0 Aug 5 2017 spi0.0 -> ../../../devices/platform/ff1d0000.spi/spi_master/spi0/spi0.0
lrwxrwxrwx 1 root root 0 Aug 5 2017 spi0.1 -> ../../../devices/platform/ff1d0000.spi/spi_master/spi0/spi0.1
My SPI1 reference in my device tree overlay (i.e. <&spi1>) was showing up here as spi0.
How/ why so??
(In my opinion this messes other things up... as shown below when using Python).
I assume you have done something similar as per sunxi-DT-overlays where you are using aliases (this really is unnecessary, IMHO)
fragment@0 {
target-path = "/aliases";
__overlay__ {
spi0 = "/soc/spi@01c68000";
spi1 = "/soc/spi@01c69000";
};
};
I then bound these by using the following commands:
echo spidev > /sys/bus/spi/devices/spi0.0/driver_override
echo spi0.0 > /sys/bus/spi/drivers/spidev/bind
echo spidev > /sys/bus/spi/devices/spi0.1/driver_override
echo spi0.1 > /sys/bus/spi/drivers/spidev/bind
Now after a reboot I get:
root@rockpi-4cplus:~$ ls -l /dev/spi*
crw------- 1 root root 153, 0 Apr 15 11:17 /dev/spidev0.0
crw------- 1 root root 153, 1 Apr 15 11:17 /dev/spidev0.1
I thought this was good enough.
However, when I use Python3 together when SPI pin references it does not like it.
It throws an error "OSError: /dev/spidev1.0 does not exist".
Any suggestions.