Kalobok

And here's the input from Radxa: https://forum.radxa.com/t/hi-has-anyone-run-into-rtc-trouble-with-rock-3a/8522/42 So RTC part of rk809 can be disabled completely in the device tree.

I would gladly do, but my knowledge of git is close to zero. Do you mind if I ask for some guidance directly?

After restoring from backup got this message: Learn more leads here: https://www.home-assistant.io/more-info/unsupported/cgroup_version I used Ignore and it disappeared. Also upgraded the HA Core: After the upgrade installed "File editor" add-on successfully.

It works. Lots of thanks for the design! ___ _ _ _ __ ___ _ _ _ / _ \ __| |_ __ ___ (_) __| | \ \/ / | | | || | | | | |/ _` | '__/ _ \| |/ _` | \ /| | | | || |_ | |_| | (_| | | | (_) | | (_| | / \| |_| |__ _| \___/ \__,_|_| \___/|_|\__,_| /_/\_\\___/ |_| Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.1.80-current-odroidxu4 No end-user support: built from trunk System load: 68% Up time: 7 min Memory usage: 12% of 1.94G IP: 172.17.0.1 172.30.32.1 CPU temp: 50°C Usage of /: 20% of 15G RX today: 206.4 MiB

Looks like somebody fixed it in the latest release: ____ _ _____ _ | _ \ ___ ___| | __ |___ / / \ | |_) / _ \ / __| |/ / |_ \ / _ \ | _ < (_) | (__| < ___) / ___ \ |_| \_\___/ \___|_|\_\ |____/_/ \_\ Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.6.21-current-rockchip64 No end-user support: built from trunk System load: 2% Up time: 1:25 Memory usage: 10% of 1.87G IP: CPU temp: 52°C Usage of /: 2% of 233G RX today: 1.0 MiB root@Rock3A:~# dmesg | grep rtc [ 1.013050] rtc-hym8563 5-0051: registered as rtc0 [ 1.014152] rtc-hym8563 5-0051: setting system clock to 2024-03-08T14:02:28 UTC (1709906548) [ 2.552805] rk808-rtc rk808-rtc.4.auto: registered as rtc1

Yes, will try. Do I understand correctly that I need to download Docker and HA extensions to userpatches/extensions directory and then build an image for XU4?

Great idea! Any chance Odroid XU4 will be added to the list?

Started with this. Somehow timedatectl and hwclock ignore /dev/rtc symlink and use rtc0. For hwclock I can use command-line argument --rtc=/dev/rtc1, but didn't find how to change default settings for timedatectl.

Hi all! There's a dedicated RTC chip in Rock3A (HYM8563TS), but unfortunately it doesn't work right with the standard Armbian image. The chip is correctly identified, but the problem is with the RK809 PMIC, which also contains an RTC. During boot RK809 is labeled as rtc0, and HYM8563TS as rtc1, and by default kernel uses rtc0 for hwclock manipulations. Since RTC battery is connected to HYM8563TS, after power cycle RK809 is reset to 2017-08-05 09:00:00. | _ \ ___ ___| | __ |___ / / \ | |_) / _ \ / __| |/ / |_ \ / _ \ | _ < (_) | (__| < ___) / ___ \ |_| \_\___/ \___|_|\_\ |____/_/ \_\ Welcome to Armbian 23.11.1 Bookworm with Linux 6.1.63-current-rockchip64 System load: 12% Up time: 0 min Memory usage: 6% of 1.93G IP: CPU temp: 41°C Usage of /: 13% of 15G Last login: Thu Nov 30 01:59:45 CET 2023 on ttyS2 root@rock-3a:~# timedatectl Local time: Thu 2023-11-30 02:02:23 CET Universal time: Thu 2023-11-30 01:02:23 UTC RTC time: Sat 2017-08-05 09:00:58 Time zone: Europe/Brussels (CET, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no root@rock-3a:~# hwclock -r --rtc=/dev/rtc0 2017-08-05 11:01:08.022461+02:00 root@rock-3a:~# hwclock -r --rtc=/dev/rtc1 2023-12-17 18:25:06.420734+01:00 root@rock-3a:~# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Nov 30 02:01 /dev/rtc -> rtc0 crw------- 1 root root 252, 0 Nov 30 02:01 /dev/rtc0 crw------- 1 root root 252, 1 Nov 30 02:01 /dev/rtc1 root@rock-3a:~# dmesg | grep rtc [ 2.602457] rk808-rtc rk808-rtc: registered as rtc0 [ 2.605220] rk808-rtc rk808-rtc: setting system clock to 2017-08-05T09:00:08 UTC (1501923608) [ 2.617968] rtc-hym8563 5-0051: registered as rtc1 There is a parameter in kernel configuration file which specifies RTC to use: CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC=y CONFIG_RTC_SYSTOHC_DEVICE="rtc0" Straightforward solution would be to compile kernel with above parameters set to rtc1. It worked: ____ _ _____ _ | _ \ ___ ___| | __ |___ / / \ | |_) / _ \ / __| |/ / |_ \ / _ \ | _ < (_) | (__| < ___) / ___ \ |_| \_\___/ \___|_|\_\ |____/_/ \_\ Welcome to Armbian 23.11.1 Bookworm with Linux 6.1.66-current-rockchip64 System load: 28% Up time: 0 min Memory usage: 6% of 1.93G IP: CPU temp: 45°C Usage of /: 16% of 15G Last login: Thu Aug 31 19:25:12 CEST 2023 on ttyS2 root@rock-3a:~# timedatectl Local time: Sun 2023-12-17 18:27:43 CET Universal time: Sun 2023-12-17 17:27:43 UTC RTC time: Sun 2023-12-17 17:27:42 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no root@rock-3a:~# hwclock -r --rtc=/dev/rtc0 2017-08-05 11:01:01.778545+02:00 root@rock-3a:~# hwclock -r --rtc=/dev/rtc1 2023-12-17 18:28:07.062160+01:00 root@rock-3a:~# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Dec 17 18:27 /dev/rtc -> rtc1 crw------- 1 root root 252, 0 Dec 17 18:27 /dev/rtc0 crw------- 1 root root 252, 1 Dec 17 18:27 /dev/rtc1 root@rock-3a:~# dmesg | grep rtc [ 2.609825] rk808-rtc rk808-rtc: registered as rtc0 [ 2.622573] rtc-hym8563 5-0051: registered as rtc1 [ 2.623661] rtc-hym8563 5-0051: setting system clock to 2023-12-17T17:27:04 UTC (1702834024) But maintaining custom kernel is not the ideal solution. Could anybody suggest how to force the system to detect HYM8563TS as rtc0?

Hi @yang and @TRS-80, If it's not too late, I'd like to pick up OrangePi Zero Plus2 H3 as a maintainer. I have two Plus2 boards with expansion boards, and can to test for releases and troubleshooting. Don't have much experience in SW development, but have some as Linux basic admin. As an experiment built an image for "BRANCH=current KERNEL_ONLY=no BUILD_DESKTOP=yes RELEASE=bullseye", all seems to work: http://ix.io/3Qdm. I like the board and would like to keep it in the game.

Well, if it's possible, why not to include it? Especially that it's almost 30% increase in frequency. Since the board doesn't tend to overheat, there should be no thermal issues. Also (and it's quite subjective, I admit), I have an impression that the board is somewhat slow when it has to generate web content for rpimonitor. PS Tried usb with custom-built kernel - the same result (USB hubs are present but devices are not recognized).

@ashthespy, thanks for the hint. USB hubs are now available: But USB devices are not recognized. Also, max frequency is limited to 1008000

Well, I'm not that familiar with kernel and device tree patching. Could you provide some explanations on how I can test it?

There were several 5.8.16 lines, I've selected the topmost (assuming it's the latest), and the LEDs are back! Thanks a lot!

After recent upgrade of Debian Buster stable on Orange Pi Zero Plus 2 leds entries disappeared from class directory: Could anybody provide some guidance on how to get them back?

Yes, I'd like to test, please provide me instructions.

USB works in buster 4.4.243. Didn't check with 5.x kernels.

If you provide some guidance, I could try to check.

Just checked Armbian_21.02.0-trunk.4_Rockpi-s_buster_current_5.9.11_minimal image. Wifi works, USB doesn't (lsusb gives no output). Also, available frequencies are limited to 1008000, while with the legacy kernel max freq is 1296000. Here's the report: +BOOT=yes +VERSION=21.02.0-trunk.4 +KERNEL=5.9.11-rockchip64 +NETWORK=NT +WIRELESS=yes +HDMI=NA +USB=no +DVFS=NT +ARMBIANMONITOR=http://ix.io/2G2R

OK, tried on mainline kernel. /etc/default/crda: REGDOMAIN=NL iw reg get shows NL after reboot, but the board still doesn't see SSIDs on Control Channel 13.

WiFi behaviour may depend on what kernel you are using. Does the board see any SSIDs at all (nmcli device wifi)? I faced a situation with mainline kernel when SSIDs with Control Channel set to 13 are not seen by the board.

Checked with legacy kernel (5.35 user-built Ubuntu 16.04.3 LTS 3.4.113-sun8i). Country is also set to 00: DFS-UNSET, but iw reg set NL has no effect, country remains set to 00. The board, however, sees my AP on Control Channel 13 and successfully connects. So it's driver, not AP6212 chip. After upgrading legacy to 5.36 reg set and reg get work. @guidol, for upgraded legacy kernel setting region in /etc/default/crda works. Will check with mainline kernel later.

@tkaiser thanks for the hint. Initially country is set to 00, and is changed with iw reg set: anton@BPI-M2p:~$ sudo iw reg get global country 00: DFS-UNSET (2402 - 2472 @ 40), (N/A, 20), (N/A) (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR (57240 - 63720 @ 2160), (N/A, 0), (N/A) anton@BPI-M2p:~$ sudo iw reg set NL anton@BPI-M2p:~$ sudo iw reg get global country NL: DFS-ETSI (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5330 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS (5725 - 5875 @ 80), (N/A, 13), (N/A) (57000 - 66000 @ 2160), (N/A, 40), (N/A) iw list shows band 13 as available: Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (disabled) However, if I switch my AP to Control Channel 13, the board cannot see my AP. It seems that HW stays tuned to some other region. Unfortunately, I don't have enough knowledge to dig deeper. Ah, and after reboot the region is back to 00.

Hi all! I'm new to Armbian so share my experience in this section. After several failures I managed to find an image that boots on my Banana Pi M2+ (Armbian_5.34.171121_Bananapim2plus_Debian_stretch_next_4.13.14_desktop). Everything worked nicely from the box, thanks all developers for a great job (but indeed, huge penguin looks a bit frightening on 55" TV). While setting up WiFi I found that the board doesn't "see" my AP (while all neighbours' were there). After playing with AP's settings i figured out that it's not visible if Control Channel is set to 13. When I disabled autoselection of channel 13 on the AP, the board was able to connect. My AP is ASUS RT-AC68U with Merlin, all settings for 2.4 GHz are set to Auto (except control channel selection now). Current Armbian is 5.37.180112 nightly Debian GNU/Linux 9 (stretch) 4.14.13-sunxi. So the question is could visibility of Channel 13 be fixed by configuration, or it's hardcoded in the AP6212 WiFi module?