GoGerriko

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.

Regarding SPI, I see the SPI0 is as intended, as per the README.rockchip-overlays file. However, I discovered that the SPI2 and SPI3 pins listed are reversed. As in pins for SPI2 are in fact for SPI3 and vice versa.

I was merely searching on the forum for info on how to find overlays and came across your post, as I too have an unrelated issue with Rock4b (or SE) overlays. As a complete noob on overlays I had a quick look through that overlay file and simply wondered if you are using the right overlay file for the pin header you're using. Looking at the Rock4 SE schematic, that said overlay points to I2C1 which is attached to I2C_SDA_AUDIO/I2C_SCL_AUDIO which then feeds into an audio codec device (ES8316) and then into J8204 15PH. If you are using J8203 15PH then it uses I2C4, which must be a different overlay. Of course I could be talking nonsense here 😬

I have a Rock4 SE Board (or Rock Pi 4 SE) and I'm using the Armbian_23.02.2_Rockpi-4b_bullseye_current_5.15.93 Debian version. (Linux rockpi-4b 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 GNU/Linux) I am trying to set up the correct Device Tree Overlay configuration for my intended application. If I use Armbian-config as a tool to demonstrate the issue here. It starts by listing I2C7 and then I2C8. If I go to the Rock4 SE schematic and search for I2C8, it is not even setup as I2C: Then where is I2C6, for example. It's supposed to be there. If I then look further through the list, it is using RK3318 files (according to Internet search, they are from same 3300 family of chips but the 3318 has 4 x ARM Cortex-A53 @ 1.5 GHz cores). So are these correct. I'm rather confused by these. Could anyone explain. Thanks Colin PS. If I enable spi-spidev and then set the spi parameter to 0 it references SPI0, which is linked to the Ethernet port. I don't believe this is correct behaviour. The reason for this is that when setting it to 0, I cannot SSH into my board. When I set it to 1, I can. However when setting to 1, it shows the following (/dev/spidev1.0) when running ls /dev/spidev*

I am using the Rockpi 4c plus for the first time. I am also trying out Armbian (for the first time) and downloaded the latest stable version for my board (Linux rockpi-4cplus 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux) Using armbian-config I selected in hardware configuration "spi-spidev". when my board rebooted, I checked the following: dmesg | grep uart This returns: [ 6.120938] dw-apb-uart ff1a0000.serial: forbid DMA for kernel console I then tried dmesg | grep i2c and this returns [ 1.511705] i2c_dev: i2c /dev entries driver [ 1.564824] input: rk805 pwrkey as /devices/platform/ff3c0000.i2c/i2c-0/0-0020/rk805-pwrkey/input/input0 And finally, I tried dmesg | grep spi And this returns blank. So I was a little confused. (PS. I forgot to mention that lsmod | grep uart or i2c or spi provides some more useful info too). Doing some reading in the Armbian website documentation section I found a section on Device Tree Overlays, but this is just a generic help guide: https://docs.armbian.com/User-Guide_Allwinner_overlays/ This document does help, to a point. Step 1 notes a readme. I found this in the "boot/dtb/rockchip/overlay" folder. However, this readme text was still not very clear to me (see points below): ### spi-spidev Activates SPIdev device node (/dev/spidevX.Y) for userspace SPI access, where X is the bus number and Y is the CS number SPI 0 pins (MOSI, MISO, SCK, CS): GPIO3_A5, GPIO3_A4, GPIO3_A6, GPIO3_A7 SPI 1 pins (MOSI, MISO, SCK, CS): GPIO1_A7, GPIO1_B0, GPIO1_B1, GPIO1_B2 SPI 2 pins (MOSI, MISO, SCK, CS): GPIO1_C0, GPIO1_B7, GPIO1_C1, GPIO1_C2 SPI 3 pins (MOSI, MISO, SCK, CS): GPIO2_B2, GPIO2_B1, GPIO2_B3, GPIO2_B4 Parameters: param_spidev_spi_bus (int) SPI bus to activate SPIdev support on Required Supported values: 0, 1 param_spidev_spi_cs (int) SPI chip select number Optional Default: 0 Supported values: 0, 1 Using chip select 1 requires using "spi-add-cs1" overlay param_spidev_max_freq (int) Maximum SPIdev frequency Optional Default: 1000000 Range: 3000 - 100000000 The overlays guide then instructs "2. Add names of overlays you want to activate to overlays= line in /boot/armbianEnv.txt, separated with spaces". Checking this file, confirmed that the "armbian-config" tool worked as it had added the spi-spidev parameter: But the above pin description was confusing as it not match the pinout diagram I had found as a reference: https://wiki.radxa.com/Rockpi4/hardware/gpio Basically for SPI I wanted to use Pin#: 19, 21, 23 & 24 which from the above gpio pinout at least matches the readme (e.g. GPIO1_A7, GPIO1_B0, GPIO1_B1, GPIO1_B2). But what confused me is that the GPIO pinmap has 1 spi bus marked as default and yet nothing is set in Armbian. Reading online and the forums, I see most use the following: param_spidev_spi_bus=0. But I am guessing if this is the spi bus then should I be using "1" instead. Then what is not shown is what to do if you want to have two SPI buses. What is the format. Then a somewhat related aside question. I wanted to use UART2 Pin#: 8 & 10. I read that in the Radxa debian release they have this on as default (for debugging purposes). It was not clear to me if this is the same here - from what I see it could be inferred but thought to ask. Using "grep uart" indicates that something is available for UART. It was also not clear to me, from the gpio pin mapping what UART4 is as not shown. Any help gladly appreciated