Hi guys, I got a SPIdev overlay to work on the rock S0, figured I'd just share it here for the record, since I could have used this info myself (I spent days trying to figure it out since I had no experience with device trees or whatnot).

 

Basically, download the attached .dts file, then run

sudo armbian-add-overlay rk3308-spi2-spidev.dts

I also edited /boot/armbianEnv.txt and added this line, but I'm unsure if that's actually necessary?

param_spidev_spi_bus=2

 

This worked on Armbian 24.5.1 Noble, creating /dev/spidev2.0. You can verify that it works using this tool: https://github.com/rm-hull/spidev-test

The dts file is based on this one from radxa, however changed to "fragment@" syntax like other armbian overlays: https://github.com/radxa-pkg/radxa-overlays/blob/main/arch/arm64/boot/dts/rockchip/overlays/rk3308-spi2-spidev.dts

Maybe this will also work on Rock Pi S, but haven't tested.

 

 

rk3308-spi2-spidev.dts

Edited August 3, 20242 yr by grixm

And here is one for SPI1: rk3308-spi1-spidev.dts

Interesting that you were able to get the overlay to work on Noble. Cannot get any overlay to work on bookworm 24.11.1...

Do you happen to know if the S0 has an ADC input?

 

(Got the overlays working finally)

Edited January 6, 20251 yr by Meestor_X

No I don't think it has ADC. But you can use the numerous SPI or i2c ports to connect an external adc.

Edited January 7, 20251 yr by grixm

The SoC has an ADC AFAIR, but it is used for 'Recovery Key' AFAIR. Look in Radxa PCB schematics to be sure.

Ty.

I picked up a cheap sda1115 ADC which uses I2C.

Will i2c on the Rock-S0 need an overlay or is it already enabled by default in armbian. Haven't figured out how to test for that yet.

 

NM - it "just works", I didn't have to change anything or add an overlay! 🙂

Edited January 19, 20251 yr by Meestor_X

On 1/6/2025 at 8:06 PM, Meestor_X said:

 

(Got the overlays working finally)

What did you do? I am also experiencing all my overlays breaking after updating the armbian version.

On 3/8/2025 at 8:54 AM, grixm said:

What did you do? I am also experiencing all my overlays breaking after updating the armbian version.

It's been a while, but I believe it was the prefix issue. Perhaps it's been fixed now?
https://github.com/armbian/configng/issues/360#issuecomment-2573855215

A big part of getting to the bottom of overlay issues is to use a TTL->USB adapter to watch the boot process.

Edited March 25, 20251 yr by Meestor_X

@Meestor_X

I see, unfortunately it doesn't seem to work for me. I don't use official overlays, just user overlays. Tried every combination of with or without prefix in the filename and in armbianEnv.txt and none of them work. I tried to monitor the boot process but I found that my TTL->USB adapter seems to be about 10x too slow for the baudrate used. 

 

In addition, I don't know if this is something you saw too, but armbian-config crashed when I try to enter the overlay config menu, with the message "Invalid overlay_prefix rk3308".

 

Guess I'm stuck on 24.11 for the time being. Or I can try installing 25.2 from scratch rather than update, maybe it will be different.

Edited March 25, 20251 yr by grixm

Understood. I'm still on 24.x.x so I don't know if the later ones are better.

 

I tried for a while without, but honestly, you gotta get yourself a TTL -> USB that works so you can follow the log. Once you do that, you'll see the errors clear as day as to why the overlays aren't being loaded.

Not sure what country you're in, but in NA they're quite inexpensive. This is the one I got:

https://www.amazon.com/Serial-Adapter-Signal-Prolific-Windows/dp/B08BLKBK1K

 

Turns out it wasn't the overlays failing to be recognized after all, one of the overlays were simply wrong, because the base device tree had changed. And if even just one of the user overlays was invalid, they all failed to load.

If anyone reads this with the same problem after using my overlay: In rk3308-spi1-spidev.dts, you need to change the word "acodec" (in fragment@2 near the bottom) to just "codec".

Tried to get it running on the Rock PI S, which has the same chip, but it somehow doesn't seem to work... I think it has different conflicts maybe? It's kinda hard to debug. Originally I used the following (on 24.*):

/dts-v1/;
/plugin/;

/ {
	compatible = "rockchip,rk3308";

	fragment@0 {
		target = <&spi1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			spidev@0 {
				compatible = "rockchip,spidev";
				status = "okay";
				reg = <0>;
				spi-max-frequency = <10000000>;
			};
		};
	};
};

But it stopped working on upgrade to 25.11. I was able to get it to load again until I adjusted the compatible field to "armbian,spi-dev". But the the connected chip just wouldn't answer. I now tried rk3308-spi1-spidev.dts from this thread, with the codec modification and then even tried to fix the correct conflicts for the Rock PI S' different pinout:

/dts-v1/;
/plugin/;

/{
	metadata {
		title = "Enable spidev on SPI1";
		compatible = "radxa,rockpis", "radxa,rock-s0";
		category = "misc";
		exclusive = "GPIO2_B1", "GPIO2_A4", "GPIO2_A5", "GPIO2_A7";
		description = "Enable spidev on SPI1.";
	};

	fragment@0 {
		target = <&spi1>;

		__overlay__ {
			status = "okay";
			pinctrl-names = "default";
			pinctrl-0 = <&spi1_clk &spi1_csn0 &spi1_miso &spi1_mosi>;
			#address-cells = <1>;
			#size-cells = <0>;

			spidev@0 {
				compatible = "rockchip,spidev", "armbian,spi-dev";
				reg = <0>;
				spi-max-frequency = <10000000>;
			};
		};
	};

	fragment@1 {
		target = <&i2c3>;

		__overlay__ {
			status = "disabled";
		};
	};

	fragment@2 {
		target = <&uart3>;

		__overlay__ {
			status = "disabled";
		};
	};
};

But it still doesn't communicate. It's there, but not receiving any data from my chip like it did in the past. I can't find anything in dmesg, so I'm not sure how one can find out what's wrong with it.