Dennboy

Because I have updated to Armbian 22.02 with the linux 5.15.25 kernel and I am using the rk3328-nanopi-r2-rev00 device tree, I thought I should share what I have discovered.
 
1/
I had trouble setting up a one-wire device (ds18b20 temperature sensor).
I think the w1-gpio pin assigned in the supplied overlay is messing up access of the SD card.
 
I found some helpful information from this post:
https://forum.pine64.org/showthread.php ... #pid100639
 
I copied the overlay code, modified it to use GPIO2_A2 (pin 7 on the 26pin header), compiled it and copied the new dtbo file to "/boot/overlay-user/" . Added the "user_overlays=rockchip-w1-gpio" line to "/boot/armbianEnv.txt" and rebooted.
Success. I was able to read the ds18b20.
(I have since discovered the utility "armbian-add-overlay" would have done the compile, copy and edit steps all at once.)
 
The steps I took:
Overlay filename: rockchip-w1-gpio.dts
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/"; __overlay__ { w1: onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = <&gpio2 2 0>; status = "okay"; }; }; }; };  
You will probably need to install the device-tree-compiler.
 
sudo apt install device-tree-compiler  
Compile the overlay:
dtc -I dts -O dtb -o rockchip-w1-gpio.dtbo rockchip-w1-gpio.dts  
Copy the compiled overlay:
sudo cp rockchip-w1-gpio.dtbo /boot/overlay-user/  
Add the "user_overlays=rockchip-w1-gpio" line (without quotes) to "/boot/armbianEnv.txt" and reboot.
 
I have learnt a bit more about "Device Trees" and "dt overlays" (I still don't understand how it all works), it turns out overlays can be used to change (somewhat) what has been configured in the Device Tree being used.
So here are some more overlays that I have come up with after grabbing snippets from here and there.
 
2/
I have read of people editing and recompiling the device tree dtb file to enable the USB-OTG to be used as a "normal" USB port.
I have created an overlay that changes the dr_mode of the USB-OTG from "otg" to "host".
 
Overlay filename: rockchip-usb-otg.dts
 
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328-usb\0rockchip,rk3066-usb\0snps,dwc2"; fragment@0 { target-path = "/usb@ff580000"; __overlay__ { dr_mode = "host"; }; }; };  
Compile:
dtc -@ -I dts -O dtb -o rockchip-usb-otg.dtbo rockchip-usb-otg.dts
Copy the compiled overlay to /boot/overlay-user/ and add "rockchip-usb-otg" (without quotes) to /boot/armbianEnv.txt on the "user_overlays=" line.
After a reboot, check by plugging a "9-hole To Dual USB2.0 Female Header Adapter Cable" (or similar) onto the USB header and plug a couple of flash drives in to the USB sockets.
Type lsblk and the resulting output should show /dev/sda and /dev/sdb.
 
3/
The rk3328-nanopi-r2.dtb doesn't enable "pwm".
PWM is handy for controlling the speed of a cooling fan. There is a header on the board for just a thing. (2Pin JST ZH 1.5mm Connector for 5V Fan)

Overlay filename: rockchip-pwm-gpio.dts
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/pwm@ff1b0020"; __overlay__ { status = "okay"; }; }; };  
Compile, copy and edit as above and reboot.
 
ls /sys/class/pwm/
 
This should show "pwmchip0" is available.
To be able to control "PWM" from userspace, a couple of other things need to be in place.
The user needs to be a member of the "gpio" group and some udev rules need to be in place.
 
filename: 50-pwm.rules
 
SUBSYSTEM=="pwm*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/pwm && chmod -R 770 /sys/class/pwm;\ chown -R root:gpio /sys/devices/platform/*.pwm/pwm/pwmchip* && chmod -R 770 /sys/devices/platform/*.pwm/pwm/pwmchip*\ '"
 
Copy the 50-pwm.rules file to:- "/etc/udev/rules.d/" (without the quotes)
 
Reload the udev rules.
 
udevadm control --reload-rules ; udevadm trigger  
Here is a shell script to setup the PWM. Values for period and duty-cycle width may be changed as required.

filename: setpwm.sh
 
#! /usr/bin/bash # activate the PWM. echo 0 > /sys/class/pwm/pwmchip0/export #Wait for export to settle sleep 2 # set period to 10ms echo 10000000 > /sys/class/pwm/pwmchip0/pwm0/period # set normal polarity. needs to be reset explicitly. Bug? echo "inversed" > /sys/class/pwm/pwmchip0/pwm0/polarity echo "normal" > /sys/class/pwm/pwmchip0/pwm0/polarity # enable the PWM echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable # set duty cycle to 1ms echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle  
 
4/
The NanoPi NEO3 has a push button. From documentation I have found, indicates that it is supposedly a reset button, but it seems to have no effect.
 
This overlay renames the button and sets the function to "Power Off" (or "Reset"). I wanted it to shutdown the NEO3, so I have configured it as "KEY_POWER" (0x74). Change line 15 to "linux,code = <0x198>;" for a Reset button.
 
Overlay filename: rockchip-power-button.dts
 
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/"; __overlay__ { gpio-keys { button@0 { label = "k1_button"; linux,code = <0x74>; //0x198 = KEY_RESTART, 0x74 = KEY_POWER }; }; }; }; };
Compile, copy and edit as above and reboot.
 
Press the button and the NEO3 should shutdown (or restart).
 
5/
Apparently the NanoPi R2 has two additional LEDS, ("lan-led" and "wan-led") that the NEO3 does not. The rk3328-nanopi-r2.dtb assigns these LEDS to GPIO pins that are on the 26pin header that would be used as normal GPIO or used by I2S and SPI on the NEO3.
To make these pins available for use, I have made an overlay that re-assigns the "lan-led" and "wan-led" to gpios that (according to the NEO3 schematic) are not used on the NEO3.

Overlay filename: rockchip-leds.dts
 
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/"; __overlay__ { gpio-leds { led@2 { gpios = <&gpio0 5 0>; }; led@3 { gpios = <&gpio0 6 0>; }; }; }; }; };  
Compile, copy and edit as above and reboot.
Check by using "gpioinfo"
 
gpioinfo gpiochip0  
The output will show that the "lan-led" and "wan-led" are now assigned to gpiochip0, lines 5 and 6 respectively.
 
 
I believe that using these simple Device Tree Overlays, has made my NanoPi NEO3 perform as it was intended.
 
 
I have found one flaw. After upgrading to the latest armbian kernel, 20.02, two GPIO pins will not change state.
They are GPIO2_B7/I2S1_MCLK (gpiochip2, 15) and GPIO3_B0/SPI_CSN0 (gpiochip3, 8).
Something is loaded during boot that sets them both High (I have LEDs connected and can see when they go High).
Using the commands "gpioset gpiochip2 15=0" and "gpioset gpiochip3 8=0" does not turn the LEDs off.
There are no errors or warnings when using the commands and "gpioinfo" shows that the pins are "input active-high".
This effect did not happen using the previous kernel and happens late in the boot process.
I am ruling out any Device Tree problems as the Green Status LED is flashing happily well before either pin goes high.

Regards,
John
 

Thanks Igor, I've created a pull request (https://github.com/armbian/build/pull/3967) after some tweaks & tests with non-rsync ramlog.

After some experimenting I found a way to flush the journal and maintain logs in tmpfs using /run/log/journal, and only have a softlink from /var/log/journal to /var/log.hdd/journal. Additionally the cached journals are to be cleaned up when /var/log becomes too full.
 
 I created the attached patches for armbian-truncate-logs and armbian-ramlog: armbian-truncate-logs.patcharmbian-ramlog.patch 
 
Some logic was needed in cases where the user decides to do Storage=volatile journal logging in /etc/systemd/journald.conf, or when the user or journald with Storage=persistent creates a /var/log/journal folder which will be moved to /var/log.hdd/journal and replaced by the softlink.
 
I tested stop, start, write for armbian-ramlog, and truncate-logs. They seem to work fine.

Interesting. Doing some more digging into the debian postinst scripts. May be useful for you in the future if this becomes a continuing issue.
 
The resolvconf package touches this file after installation (/var/lib/dpkg/info/resolvconf.postinst), but only once (tracked via a file you can pre-place, and disable any action on its part).
 
# Linkify /etc/resolv.conf if appropriate if [ ! -e /var/lib/resolvconf/linkified ] ; then ... <snip> ... ln -nsf ../run/resolvconf/resolv.conf /etc/resolv.conf # Make a record that we have created it :> /var/lib/resolvconf/linkified fi  
Looks like network-manager does too (/var/lib/dpkg/info/network-manager.postinst), but only if it's already a link.
 
SystemD appears to poke this file on a fresh installation (/var/lib/dpkg/info/systemd.postinst), but not on upgrade.
 
Might be useful to find out what /etc/resolv.conf is pointing to, and look for that pattern in /var/lib/dpkg/info? Might tell you which package is tripped you up, and how to prevent it from doing that in the future?

Dear all,
 
I occasionally have a full /var/log at startup on various boards, probably because the logs are not rotated /vaccuumd at boot (we had a thread about this in the old opi1 forum). The rotating /vaccuum is currently done every 15 minutes, so I figured why not do it directly at boot as well?
 
For this purpose I updated /etc/cron.d/armbian-truncate-logs with an extra @reboot line:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin */15 * * * * root /usr/lib/armbian/armbian-truncate-logs @reboot root /usr/lib/armbian/armbian-truncate-logs I rebooted several times, and didn't get a full /var/log anymore.
All subsequent problems like failing networking when filesystem full also vanished;-)
 
Kind regards,
Dennis

Hi Igor,
 
Thanks very much for fixing this, building out-of-tree modules now works great in Armbian 20.02.1, on 5.10.12-sunxi (opi0) and 5.10.12-rockchip64 (neo3)!

Kind regards,
Dennis