RK3288 device tree overlays

[TonyMac32]

Topic to discuss RK3288 overlays, primarily concerning ASUS Tinker Board, the MiQi is technically EOL and has very little GPIO anyway, and TV boxes are more or less sealed.

 

Kernel 4.19 will be the pilot for this, the discussion now that it seems to be working thanks to @martinayotte and @zador.blood.stained's feedback and examples is what to overlay.

 

For testing/debugging I started with some ASUS overlays for RTC and 1wire.

Easy ones:

 

• spidev out of the default tree but as default overlays.  instead of making 1 overlay and messing with parameters, just make 2 overlays
• DAC's:  I don't have a lot of hardware to play with, but @gkkpch has contributed to the existing ASUS overlays, if we ask super nicely maybe we'll get some help.  I2S on mainline is a question

 

Harder ones:

 

       RPI display:   I almost got this working on Mainline, I need to return to it, make it work, and make it an overlay.

       Cameras:      I honestly don't know if this is actually possible, I need to look at the drivers a bit more closely.

 

 

Original Content from Split:
 

Quote

@martinayotte I am trying to get overlays working on Rockchip, so far I have them compiling, and the boot script is loading them and such, I am having an issue with the fdt apply command, debugging tonight, something needs enabled in U-boot I assume.

 

 

[martinayotte]

1 hour ago, TonyMac32 said:

I am having an issue with the fdt apply command

Do you mean that you are trying to add fdt command in rockchip-fixup.scr for configurable parameters ?

I must admit that I didn't tested that since i2c overlay didn't required that ... Maybe you're right and u-boot config need to be added ...

 

EDIT : I did a quick look at both mainlined u-boot and u-boot-rockhip, both ".config" look similar in terms of FDT, but maybe I missed some ...

[TonyMac32]

Well, when the boot script says to apply it, u-boot spits out the "help text" for the command, reverts to original DTS, and boots without the adjustment.  I haven't played with any parameters requiring the fix-up script yet...  I will do some more tonight before accepting defeat.  ;-)

 

Ah, also, we only use mainline u-boot.

 

[Edit] I need to check libfdt and and fdt_overlay, given the issue I would guess they aren't enabled right now.

[martinayotte]

22 minutes ago, TonyMac32 said:

u-boot spits out the "help text" for the command, reverts to original DTS

Did you changed the rockchip-fixup.scr ? (The original I've commit doesn't do that on my rockpro64, and actually load the i2c8 overlay, since the source rockchip-fixup.scr-cmd is almost empty, only text comments)

[martinayotte]

23 minutes ago, TonyMac32 said:

Ah, also, we only use mainline u-boot.

Are you sure ? Last build I've done a week ago, we were using https://github.com/ayufan-rock64/linux-u-boot branch.

[TonyMac32]

I am talking about Rockchip for Tinker board, not rockchip64. Unless it was changed, it should be simple mainline.

Sent from my Pixel using Tapatalk

[martinayotte]

2 minutes ago, TonyMac32 said:

I am talking about Rockchip for Tinker board

Ah ! Ok ! Since I don't have this board, I've never prepared an image for it ...

 

[TonyMac32]

:-) that's why I am giving it a go, seeing your examples it didn't look awful, and I've wanted to get it worked out for some time.

Sent from my Pixel using Tapatalk

[martinayotte]

37 minutes ago, TonyMac32 said:

seeing your examples it didn't look awful,

It can become more awful when we will need to add parameters in fixup.scr, for SPI as an example ...

[TonyMac32]

Exactly, but for now I am learning to walk. ;-)

Sent from my Pixel using Tapatalk

[martinayotte]

1 hour ago, TonyMac32 said:

for now I am learning to walk. ;-)

On 2 or 4 feet ?

[zador.blood.stained]

3 hours ago, TonyMac32 said:

Well, when the boot script says to apply it, u-boot spits out the "help text" for the command, reverts to original DTS, and boots without the adjustment.

At least the vanilla mainline u-boot "fdt apply" requires OF_LIBFDT_OVERLAY (which there is set on the per board basis, but it's easier to "select" or "imply" it from ARCH_ROCKCHIP like here: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/enable-DT-overlays-support.patch

[martinayotte]

1 hour ago, zador.blood.stained said:

but it's easier to "select" or "imply" it from ARCH_ROCKCHIP

Right @zador.blood.stained !

It is what I did here two week ago : https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip64-dev/enable-DT-overlays-support.patch

But I didn't do any overlays things for others families, such as https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-rockchip/board_tinkerboard ,

I will leave @TonyMac32 pursing his walk learning ...

 

EDIT : Oupps ! I forgot that I didn't do the same for meson64, since I was testing overlays in runtime/userspace mode. Still, I've just check, overlays are loading, but, of course, if fixup.scr is needed, it is required.

So, I will add that patch a.s.a.p ...

[TonyMac32]

3 hours ago, zador.blood.stained said:

but it's easier to "select" or "imply" it from ARCH_ROCKCHIP like here: 

Right, I found that during my lunch break while talking back and forth on here, that's the only missing piece I know of (It didn't cross my mind, I'd aborted a build and the resulting restart didn't clean the source directory wiping out my patch, so I was redoing some stuff and forgot to look at u-boot before I needed to stop and sleep.)

[gkkpch]

OK, as this will give me the opportunity to see if 4.19 has the same i2s issues as explained to @TonyMac32 

Count me in for the dt overlay and es90x8q2m alsa driver I contributed to the Asus TinkerOS kernel for Volumio's primo box (see https://volumio.org/blog/)

However, I do not know in detail what else Asus initially changed to get PI compatible DACs to work with the Tinkerboard MCLK.

This will need some digging. 

 

This DT overlay work will also get very interesting for Volumio and the Rock64.

An upcoming board revision is going to to fix the RPi 40-pin gpio compatibily and then opens potential for a range of popular RPi compatible DACs.

 

[gkkpch]

small but important question: where do I find the sources?

[TonyMac32]

The build system pulls the sources for the board/kernel you select, you have to add a couple switches or modify the config file to enable making patches, see docs.armbian.com

[gkkpch]

got it, just forgot to add BRANCH=dev

[gkkpch]

 So, my build environment is now ready (don't use Armbian very often), played with compiling 4.19.y, saving and re-using patches (new to me), all fine, ready to go.

 

I have checked the DT overlays for our ES90x8Q2M DAC and the Allo Piano DAC against the dts for the tinkerboard on kernel 4.19.y.

They still seem to fit, so I will start with those as these DACs are still lying on my desk. The overlays compiled OK, next step is to add the drivers.

Also has a quick look at the boot.cmd to see how you handle the overlay loading, no issues there for a volumio test image (easier for me to use as a test environment instead of an Armbian build)

 

I did not have much time today, hope to do a little more this weekend, next week should be OK again .

 

 

[gkkpch]

Somewhere after 4.16 (or 4.15) the ALSA "snd_soc_code" structure was changed to something like "soc_snd_component" and "snd_soc_component_driver", which means the codec part of the ES driver does not compile anymore and needs to be adapted to fit the new requirements. This must have been done for all standard codecs, I willl need to find some commits to see what it needs. 

This is going to be a challenge, but as ES90x8Q2M has no priority for the armbian community, I will postpone it in favor of more popular devices. 

The Allo Piano driver has been ported, there are some question marks for the pcm512x codec (which it depends on), but it could be OK.

The kernel compiles OK with all the patches, I'll build  a Volumio image with it sometime this week and do the first test.

[gkkpch]

So far so good, after googling a little, fixing the Alsa compile issues in the ES90x8q2m codec module proved simpler than I thought.

The issues were mainly due to switching from obsolete structs to new ones and a renamed API call.

This was finalised in 4.16 by removing the obsolete code, luckily there were no functional changes.

With that the question mark for the pcm512x codec could also be eliminated, which completes my patch file for the first two DACs and corresponding DT overlays.

Due changed priorities I can't continue until the weekend (max 1 day, then a few days off).

 

 

[TonyMac32]

3 hours ago, gkkpch said:

So far so good, after googling a little, fixing the Alsa compile issues in the ES90x8q2m codec module proved simpler than I thought

Awesome!

 

3 hours ago, gkkpch said:

Due changed priorities I can't continue until the weekend

don't stress, any contribution is welcome, and in the time the contributor is willing to make it.

[TonyMac32]

I've broken these things down (perhaps too far, but I will give a case for it, and we can all discuss), here are the overlays:

 

- ds1307
- i2c1
- i2c4
- spi0
- spi2
- spidev0
- spidev2
- uart1
- uart2

- w1-gpio

 

The DS1307 was simply pulled from ASUS as a simple test overlay while I was working through implementing the scripts.  it can be jettisoned for all I care.

 

These are all written with only the Tinker Board in mind, of course they are all SoC-centric other than the 1wire and ds1307

 

"Pi" ports:

 

- i2c1 is the "Pi" I2C channel.  Make it configurable in case you just want the GPIO

- i2c4 is the "Pi" ID I2C channel.  Make it configurable in case you just want the GPIO

- spi2 is the "Pi" SPI channel. Makes it configurable in case you want just the GPIO

- spidev2 enables the user space spidev driver with 2 chip selects for spi2

- uart1 is the "Pi" UART position. 

 

Tinker ports:

 

- spi0 is the "extra" spi channel on Tinker, on pins 11/13/15/29/31.  Disabled by default, it occupies the same pins as UART4  *Not Pi Compliant in location*

- spidev0 enables the user space spidev driver with 2 chip selects for spi0

- uart2 is the debug port for Tinker.

 

There are some interesting extra features exposed on some of the pins (PWM/etc) that I would like to experiment with, we'll see. 

 

I have pulled the spi out as an overlay separate from the peripheral attached to it, my thought is, there may be 2 unrelated devices tied into the board on each chipselect that the user has their own overlay for.  (So up to 4 devices on hardware SPI)

[mtr46]

Hi,

 

I want to use 1-wire on TinkerBoard with the latest Linux Kernel.
I created dtb with rk3288-tinker-s.dts patched with reference to RaspberryPi w1-gpio.dts, but it didn't work.
When I run "cat /sys/kernel/debug/gpio", (w1) is not displayed.
Is there any good workaround?

 

Regards,

 

Additional:

I wrote a line 'fdtfile=rk3288-tinker-s.dtb' in /boot/armbianEnv.txt

 

Edited March 2, 2020 by mtr46
Additional Info

[martinayotte]

4 hours ago, mtr46 said:

I created dtb with rk3288-tinker-s.dts patched with reference to RaspberryPi w1-gpio.dts, but it didn't work.

How your patch looks like ?

Do you see in "lsmod" that the "w1_gpio" has been loaded ?

 

[mtr46]

Yes, I patched like this:

---

diff --git a/arch/arm/boot/dts/rk3288-tinker-s.dts b/arch/arm/boot/dts/rk3288-tinker-s.dts
index 970e13859..4fff9467d 100644
--- a/arch/arm/boot/dts/rk3288-tinker-s.dts
+++ b/arch/arm/boot/dts/rk3288-tinker-s.dts
@@ -10,6 +10,32 @@
 / {
     model = "Rockchip RK3288 Asus Tinker Board S";
     compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
+
+    fragment@0 {
+        target-path = "/";
+        __overlay__ {
+            w1: onewire@0 {
+                compatible = "w1-gpio";
+                pinctrl-names = "default";
+                pinctrl-0 = <&w1_pins>;
+                gpios = <&gpio0 17 0>;
+                status = "okay";
+            };
+        };
+    };
+
+    fragment@1 {
+        target = <&gpio0>;
+        __overlay__ {
+            w1_pins: w1_pins@0 {
+                rockchip,pins = <0 17 0 &pcfg_pull_up>;
+            };
+        };
+    };
+};
+
+&i2c1 {
+    status = "okay";
 };
 
 &emmc {
@@ -28,3 +54,4 @@
     pinctrl-names = "default";
     pinctrl-0 = <&hdmi_cec_c0>;
 };
+
---

 

and also w1-gpio is loaded on '/etc/modules'.

 

[martinayotte]

15 hours ago, mtr46 said:

also w1-gpio is loaded on '/etc/modules'.

You seems to use overlays syntax inside a main device tree...

Place the pin node inside "&pio" node, and pace the "onewire" node at root level.

[mtr46]

Thanks, I'll try later.

[mtr46]

I tried to apply a new patch like this:

---

diff --git a/arch/arm/boot/dts/rk3288-miqi.dts b/arch/arm/boot/dts/rk3288-miqi.dts
index c41d012c8..70c0b6365 100644
--- a/arch/arm/boot/dts/rk3288-miqi.dts
+++ b/arch/arm/boot/dts/rk3288-miqi.dts
@@ -37,6 +44,14 @@
         };
     };
 
+    onewire {
+        compatible = "w1-gpio";
+        pinctrl-names = "default";
+        pinctrl-0 = <&w1_pins>;
+        gpios = <&gpio0 17 0>;
+        status = "okay";
+    };
+
     vcc_flash: flash-regulator {
         compatible = "regulator-fixed";
         regulator-name = "vcc_flash";
@@ -294,6 +314,10 @@
         drive-strength = <12>;
     };
 
+    w1_pins: w1_pins@0 {
+        rockchip,pins = <0 17 0 &pcfg_pull_up>;
+    };
+
     act8846 {
         pmic_int: pmic-int {
             rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
---

 

But, no devices found on /sys/bus/w1/devices.

What should I do anything?

 

EDIT:

I want to use linux-mainline(5.4.y) kernel.

[Myy]

Is the w1-gpio module loaded ?