Don't understand instruction to enable 2 SPI buses and spi pin mappings for Rockpi 4c plus

GoGerriko · March 8, 2023

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

Edited March 10, 2023 by GoGerriko

Igor · March 9, 2023

15 hours ago, GoGerriko said:

Radxa debian release

https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one
This is clear, right? Armbian is using mainline kernel, where not all features are developed or worked the same. GPIO's https://www.acmesystems.it/gpiod

UART is where it is. If its enabled by default and usually is, then is on the same UART as legacy kernel. Just in some cases its not (for no apparent reason).