g2t

Hi @Vijay Gill, at the moment I start a gentoo rfs after the boot with armbian Kernel. Also I currently use a vendor Kernel build by my own with the armbian tool chain (took < 4min on the cm3588 system without Docker). So I can not say anything about the "idle-ness" of the mainline armbian Kernel and armbian rfs. At least for my system I think it would not go about 50-60°C when idle without the fan. This is my assumption because after the monitors (2 monitors possible with vendor Kernel) go to standby mode, the fan stops forever. But I have closed the case at the moment, so I can not simply disconnect the fan for an exact measurement. Do you have checked your system with "top" or another tool?

Hi, I have installed the latest image "Minimal/IOT images with Armbian Linux v6.12" with the mainline Kernel. Many thanks @ColorfulRhino , @amazingfate and many others for their hard work. I have a board with 32GB RAM and 4x NVMe and it is working with HDMI, USB and network. I have installed XFCE on top by my own. Some parts currently not working (what I have seen so far): * second HDMI * HDMI audio * sensor controlled fan speed This seems to be on the roadmap for 2025 for the upstream Kernel. For the fan control I currently use my own overlay and want to share it. /dts-v1/; /plugin/; / { /* our pwm-fan comes with 6 cooling levels (0-5) in relation to 255 <0 50 80 120 160 220> */ /* this overlay use the sensors of big core 0 to control cooling by the fan */ /* add new trips for active cooling */ fragment@0 { target-path = "/thermal-zones/bigcore0-thermal/trips"; __overlay__ { bigcore0-active1 { /* 55 degree with hysteresis of 5 deg */ temperature = <55000>; hysteresis = <5000>; type = "active"; // internal phandles use a small integer to be able to reference phandle = <0x00000001>; }; bigcore0-active2 { /* 60 degree with hysteresis of 2 deg */ temperature = <60000>; hysteresis = <2000>; type = "active"; // internal phandles use a small integer to be able to reference phandle = <0x00000002>; }; }; }; /* add cooling maps to use the new trips by the pwm-fan with level 0-5 */ fragment@1 { target-path = "/thermal-zones/bigcore0-thermal/cooling-maps"; __overlay__ { map1 { trip = <0x00000001>; cooling-device = <0xffffffff 0 1>; }; map2 { trip = <0x00000002>; cooling-device = <0xffffffff 2 5>; }; }; }; /* we need to poll, because in interrupt mode the fan will not stop */ /* alternatively we can use type="passive", a poll interval of 250 ms is already defined for passive */ fragment@2 { target-path = "/thermal-zones/bigcore0-thermal"; __overlay__ { /* for active cooling, in milliseconds */ polling-delay = <2000>; }; }; /* adjust the original fan levels <0 50 80 120 160 220> a bit */ /* the fan starts rotating at 40-45, 45 is sufficient to keep <50°C at normal operation */ fragment@3 { target = <0xffffffff>; __overlay__ { cooling-levels = <0 45 80 120 160 255>; }; }; __fixups__ { fan = "/fragment@1/__overlay__/map1:cooling-device:0", "/fragment@1/__overlay__/map2:cooling-device:0", "/fragment@3:target:0"; }; // to adjust finally the internal references __local_fixups__ { fragment@1 { __overlay__ { map1 { trip = <0x00000000>; }; map2 { trip = <0x00000000>; }; }; }; }; };

It is working, also for the USB-C port now. Many Thanks for the quick help!

Thanks, I will try this now: https://dl.armbian.com/nanopct6/Bookworm_vendor_minimal

Hello, I have installed the currently provided image "Armbian_24.11.1_Nanopct6_bookworm_current_6.12.0_minimal.img.xz" on my NanoPC-T6 (not LTS). Unfortuantely the only one USB3 port is not working. So no local access is possible and no external USB storage device can be used. I wonder if no one else has such problem reported yet since 3 weeks now (released 2024-11-21). The USB3 port is working with the FriendlyELEC image (rk3588-sd-debian-bookworm-core-6.1-arm64-20241112.img.gz), so maybe there is a small problem with a kernel module or the device tree. If someone can guide me to a starting point for investigation, I can do some debugging. I have little experience with device tree decompiling/compiling etc. Thanks Thomas

Good news - it is working now! As you can see here, the "gpio-36" is not available on 40-pin-header. The overlay needs to be manipulated. This can be done with the following steps: choose the gpio number from the link above (consider the "forbidden" yellow marked pins) the gpios are organized in lines of 32 gpios, so 0-31 is line 0, 32-63 is line 1 and so on (see also output of "cat /sys/kernel/debug/gpio") the GPIO-description GPIO<line>_<bank><number> helps us to change the overlay values if the choosen number will be "gpio-8", you can see it is header pin 7 and located on "GPIO0_B0" so the line needs to be changed from "gpio1" to "gpio0" in the overlay "__fixups__" section the pin-number "0x04" (coming from the gpio-36 = offset 32 for line 1 plus 0x04) needs to be changed to "0x08" (0x08 plus 0 as offset from line 0) after that changes the overlay can be compiled and activated like mentioned in the former post If someone can point me to the sources I can create a PR for fixup.

Hello, I have installed the "Armbian_community_25.2.0-trunk.124_Tinkerboard-2_bookworm_current_6.6.63_minimal.img.xz" image on my tinkerboard-2 to develop a library for one wire devices. There is a problem with the usage of armbian-config on activating overlays. The entry in armbianEnv.txt includes the prefix in the overlay name. This can be workarounded manually, e.g. for w1-gpio the correct entry needs to be: overlays=rk3399-w1-gpio2 If anyone can point me to the source code I maybe can provide a PR to fix it. Another problem is the content of the overlay of this w1-gpio. After activating the dmesg give an error (the first warning is normal and also exist on my working w1-gpio with tinkerboard1): sudo dmesg | grep one [ 8.630758] gpio-36 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 8.630883] OF: /onewire@0: could not get #gpio-cells for /vop@ff8f0000/port/endpoint@3 [ 8.630926] w1-gpio onewire@0: gpio_request_one (ext_pullup_enable_pin) failed [ 8.630934] w1-gpio: probe of onewire@0 failed with error -22 Reloading the module "w1_gpio" each time leads to the same output. Decompiling the overlay gives this content: /dts-v1/; / { compatible = "rockchip,rk3399"; fragment@0 { target-path = "/"; __overlay__ { onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = <0xffffffff 0x04 0x00 0xae>; status = "okay"; phandle = <0x01>; }; }; }; __symbols__ { w1 = "/fragment@0/__overlay__/onewire@0"; }; __fixups__ { gpio1 = "/fragment@0/__overlay__/onewire@0:gpios:0"; }; }; The difference to the tinkerboard1 overlay seems to be the structure of the "gpios" line. Normally there are 3 values only. Some searching in the latest Kernel documentation do not give me a hint that there is something changed in the past, but maybe I'm wrong here. My first try was to remove the last value, compiling the dtbo and test it. There is no error anymore in the dmesg output. Also the gpio-36 is now shown: sudo cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/ff720000.gpio, gpio0: gpio-3 ( |act-led ) out lo gpio-4 ( |pwr-led ) out hi gpio-10 ( |rsv-led ) out lo gpio-12 ( |ep ) out hi gpiochip1: GPIOs 32-63, parent: platform/ff730000.gpio, gpio1: gpio-35 ( |vbus-5vout ) out lo gpio-36 ( |onewire@0 ) out lo gpio-46 ( |vsel ) out lo gpio-49 ( |vsel ) out lo Nevertheless it is not working. On the tinkerboard1 the gpio output is a bit different (gpio-17 is "out hi"): sudo cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-23, parent: platform/ff750000.gpio, gpio0: gpio-3 ( |led-2 ) out hi gpio-5 ( |GPIO Key Power ) in hi IRQ ACTIVE LOW gpio-11 ( |dvs ) out hi gpio-12 ( |dvs ) out lo gpio-17 ( |onewire@0 ) out hi How can I proceed at this point with debugging and error catching? Thanks Thomas

Thanks! Unfortunatelly it is not working for me. But with the tag "tinkerboard-2" now I can found more information in the forum and stay up to date.

I have done some investigation and it looks a little bit different, but it seems there is the same behaviour for character device and sysfs. If all features are off (i2c1, uart etc.) the following header pins act fine as output: 3, 5, 7, 19, 21, 22, 23, 24, 26, 27, 28, 31 not working as output, current state in round brackets: 8 (1), 10 (1), 11 (0), 12 (1), 13 (1), 15 (1), 16 (0), 18 (0), 29 (0), 32 (1), 33 (1), 35 (0), 36 (1), 37 (1), 38 (1), 40 (0) Thats the reason why my initial test with pin 36 is not working and pin 26 has worked.

@usual user thanks for the fast reply, but therefore I have also tested sysfs and the "wait" option. Today I found my fault: It seems the used 1kOhm resistor together with the meter was not strong enough to override the internal resistors. The default internal resistor setup is possibly different between the Kernels. Using a LED show the correct behavior. Today I have also used another pin (header26, asus251, chip8-line3), so I will double check this.

Hello, is there an armbian available for Tinkerboard 2 (RK3399)? Mainly I need to setup a headless system with working i2c, pwm and gpio . Thanks!

Hi, I have installed "Armbian_22.08.7_Tinkerboard_bullseye_current_5.15.74_minimal.img.xz" on a Tinkerboard (no S, with RK3288). I have tried to set the output of some header pins without success. I used both "sysfs" and "gpiod" (which uses char-devices). Test procedure, e.g. for pin 36 (gpio223): # echo "223" > /sys/class/gpio/export # cat /sys/class/gpio/gpio223/direction in # cat /sys/class/gpio/gpio223/value 0 # echo "out" > /sys/class/gpio/gpio223/direction # cat /sys/class/gpio/gpio223/direction out # echo "1" > /sys/class/gpio/gpio223/value # cat /sys/class/gpio/gpio223/value 0 # echo "0" > /sys/class/gpio/gpio223/value # cat /sys/class/gpio/gpio223/value 0 The example is for the pin36 is grounded by an resistor with 1kOhm. If the resistor is switched to 3.3V all read values are go to "1". The read values match the measured voltage (~0V for "0", ~3.3.V for "1"). The same behaviour for "gpioset 7 7=0". After this, the "gpioinfo 7" lists the line as output, like expected. Only the voltage remain unchanged (gpioget will change the line to input). With TinkerOS the same test is working (with sysfs only, because old Kernel 4.4.). Afterwards I have also tested some (or all) different options, like "sudo gpioset -m wait -D push-pull -B pull-down gpiochip7 7=0". But no success. Have I something missed to set up in the device tree? I have enabled i2c1 & i2c4 and disabled all other features (uart, spi and w1-gpio etc.) by usage of armbian-config. Thanks for your help in advance