Hello,

 

I am the author of a home automation platform (RaspberryMatic) which is targeted for embedded platforms like RaspberryPi or Tinkerboard. I am regularly following Armbian kernel and u-boot updates for the Tinkerboard and integrate them into my buildroot-based environment so that recent kernel and u-boot versions can be used. I have already updated my environment to kernel 4.14.x and U-boot 2018.05 using the great armbian patchset from GitHub (Thanks for the hard work to get all the Tinkerboard S related issues sorted out recently).

 

What I am currently trying to achieve is to get the Tinkerboard to use a different set of standard gpio settings for certain GPIOs because my application requires this for some additional HAT hardware. On the RaspberryPi I was able to perform this by using a device tree overlay and using the following device tree definitions:

 

[...]
                brcm,pins = <18 12 16 20 21>; // 18=reset, 12=button, 16=red, 20=green, 21=blue
                brcm,pull = <0 2 0 0 0>; // 18=no-pullup, 12=pullup, 16,20,21=no-pullup
                brcm,function = <1 0 1 1 1>; // 18=output, 12=input, 16,20,21=output
[...]

 

For the tinkerboard I tried to applied similar setting (but using rockchip-like device tree definition) as a patch against linux/arch/arm/boot/dts/rk3288-tinker.dts in the kernel tree. The corresponding patchset which I developed can be found here:

 

https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/board/tinkerboard/kernel-patches/0002-rk3288-tinker.patch

 

It is essentially trying to achieve the same like the above RaspberryPi-based device tree overlay by using:

 

[...]
rockchip,pins = <7 RK_PA7 RK_FUNC_GPIO &pcfg_output_high>,
                <6 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>,
                <6 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
[...]

However, this does not seem to work somehow because after booting the GPIOs in question are still partly assigned as input direction gpios rather than output direction gpio like I need them.

 

Does anyone have any idea how to solve this issue or point me at the bug in my device tree patch which might explain why I cannot change the default GPIO setup for the Tinkerboard?

 

BTW: Using WiringPi during bootup of course works (and I am using this as a workaround). But I would like to perform this without using WiringPi directly in the device tree.

 

8 hours ago, jmaus said:

Does anyone have any idea how to solve this issue or point me at the bug in my device tree patch which might explain why I cannot change the default GPIO setup for the Tinkerboard?

Do you want to patch the DT or solve it via overlay? In case it's the second, is your u-boot prepared to load overlays (dtbo) during boot? Is your kernel/buildscript prepared to compile them during image generation. You may find some hints in dmesg? 

16 hours ago, chwe said:

Do you want to patch the DT or solve it via overlay? In case it's the second, is your u-boot prepared to load overlays (dtbo) during boot? Is your kernel/buildscript prepared to compile them during image generation. You may find some hints in dmesg? 

 

I would of course prefer to use a dt overlay. However, I have learned so far that this is not really supported by the Tinkerboard. But I might of course be wrong. As said, I am using Boot 2018.05 with the armbian patches, thus U-Boot should be as prepared for dtbo like armbian is. However, there AFAIK also no dtoverlays are using, isn't it? No matter how, what I need to know is how I can tuned the device tree so that the default GPIO pin settings are changed (to OUT direction) for the pins specified in my first posting. Regarding my build environment. It is indeed already prepared to create a dtoverlay if it might be necessary. But I would of course also be fine with directly patching rk3288-tinker.dts in the linux kernel tree like I currently do.

This is the way I set the GPIO at boot time in u-boot

 

&pinctrl {
	
	u-boot,dm-pre-reloc;
	
	pinctrl-names = "default";
	pinctrl-0 = <&power_led>, <&pwr_hold>, <&host_vbus_drv_en>, <&otg_vbus_drv_en>;
	
	.
    .
    .      
    
    leds {
		power_led: power-led {
			rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_up>;
		};
	};
      
	.
    .
    .
      
}

 

As you can see, with the pinctrl-names you can define various pin configurations (here just one, named default).

pinctrl-0 is bound to the default and is applied when the driver wants to put the pins in that configuration; in this particular case it applies the configuration to 4 GPIO pins: power_led, pwr_hold, host_vbus_drv_en and otg_vbys_drv_en.

power_led, as described above, will turn the GPIO pin 2 of bank 7 to pull-up. You may decide to put it always high, low, pull-down, or none to leave it floating. You can also group more pins together.

 

PS:

I'm sorry if the jargon is not proper, but you may consult the kernel documentation about the pin controller device tree bindings to be more compliant, but I hope I gave you the gist.

The reference patch I extracted those bits is here

20 hours ago, jock said:

This is the way I set the GPIO at boot time in u-boot

[...]

As you can see, with the pinctrl-names you can define various pin configurations (here just one, named default).

pinctrl-0 is bound to the default and is applied when the driver wants to put the pins in that configuration; in this particular case it applies the configuration to 4 GPIO pins: power_led, pwr_hold, host_vbus_drv_en and otg_vbys_drv_en.

power_led, as described above, will turn the GPIO pin 2 of bank 7 to pull-up. You may decide to put it always high, low, pull-down, or none to leave it floating. You can also group more pins together.

 

PS:

I'm sorry if the jargon is not proper, but you may consult the kernel documentation about the pin controller device tree bindings to be more compliant, but I hope I gave you the gist.

The reference patch I extracted those bits is here

 

Thanks for linking me to this information and thanks for your example dts. With the reference patch and your short example I was able to tune my dts patch to actually work. The result can be viewed here:

 

https://github.com/jens-maus/RaspberryMatic/blob/e9d3293109933c78acb834673e4f6b5735044e90/buildroot-external/board/tinkerboard/kernel-patches/0002-rk3288-tinker.patch

 

The actual bit that made the GPIO setup (in/out) finally work was the additional "pinctrl-names" and "pinctrl-0" setting within the "&pinctrl {...}" part of the dts. Previously I just had them in the "gpio-leds {...}" part, but this doesn't seem to have been enough to actually trigger a correct setup. So thanks again for your pointer and help.

 

Apart from that I am of course still curious if and how the support dt overlays with a Tinkerboard is actually? It would be great if I would not have to patch the "rk3288-tinker.dts" file directly in the linux kernel tree but use a dtoverlay file similar to how this is done with a RaspberryPi. Any more detailed/updated information on that?

3 hours ago, jmaus said:

Any more detailed/updated information on that?

Armbians GitHub repo...  You may have a look into the DT-overlay stuff which was done for the Sunxi SoCs. Then compare what's here and whats not for the RK3288 (e.g. u-boot loads the DTBO, the overlays get compiled during kernel build etc.). Commit history & https://docs.armbian.com/User-Guide_Allwinner_overlays/ may be worth a look.