BipBip1981

For information, fancontrol, deamon or service systemd crash but work just with run fancontrol from shell in root. Seen to be a privileges problem like systemd log... i look this soon and post here my workaround

Hi, Today i upgrade to Armbian Trixie my Helios64 with upgrade from bookworn to trixie, not clean install All seen to be Okok only with use of rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp file inside of original rk3399-kobol-helios64.dtb Only problems for moment are: - fancontrol not seen to work lm75 module... service crash... i will investigate soon if i have the time. - apt show warning with SHA1 checksum or anything i can't investigate for the moment

Hi, I continue to use file rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp on the last Helios64: v25.8.1 for Helios64 running Armbian Linux 6.12.42-current-rockchip64 Without this file, i have crash or problem with ciffer orperation (Luks and another program...) With this file, all it's Okok. Have a good day.

Hi, I agree with Snakekick, the voltage patch is for me the best thing for the helios64 run stable. Maybe it's not a perfect solution but: "It is better to have a good solution in time than a perfect one too late."

Hi, System work well with Kernel 6.12 and DTB patch, juste a problem with the service folow. Keep in touch. root@helios64:~# systemctl status helios64-heartbeat-led.service × helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64 Loaded: loaded (/etc/systemd/system/helios64-heartbeat-led.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Thu 2025-01-16 20:26:24 CET; 34min ago Process: 2899 ExecStart=bash -c echo heartbeat | tee /sys/class/leds/helios64\:\:status/trigger (code=exited, status=1/FAILURE) Main PID: 2899 (code=exited, status=1/FAILURE) CPU: 20ms Jan 16 20:26:24 helios64 systemd[1]: Starting helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64... Jan 16 20:26:24 helios64 bash[2906]: tee: '/sys/class/leds/helios64::status/trigger': No such file or directory Jan 16 20:26:24 helios64 bash[2906]: heartbeat Jan 16 20:26:24 helios64 systemd[1]: helios64-heartbeat-led.service: Main process exited, code=exited, status=1/FAILURE Jan 16 20:26:24 helios64 systemd[1]: helios64-heartbeat-led.service: Failed with result 'exit-code'. Jan 16 20:26:24 helios64 systemd[1]: Failed to start helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64.

Hi, i build and pass to last armbian from source with 6.12 kernel to test dtb file with it. Keep in touch.

Hello @prahal, i agree with @snakekick , you dtb changes is ready to go to official sources. I use it from the beginning, my helios now work good and stop to crash. My brother use it and same result. Your dtb changes commit to official sources for the first january 2025 will be a perfect.

Hi, For feedback, i disconnect from SATA connector by unrack/rack harddisk and i disconnect and reconnect plug on mainboard side. Have a good day.

Hi, few days ago, i disconnect and reconnect all connectors on ATA1 line, it's seem to become Okok 😉

Hi, I swap ata1 and ata5, problem stay on ata1, i look cable and socket on ata1 Keep in touch

Hi everybody, For information Prahal dtb patch file is not for me the problem because my problem is only on ata1 after cold boot, never after reboot command. I think hardware problem like harddisk, cables or mainboard... i continu to search. Have good day

Hi, Same with 28.11-trunk build myself and 6.6.56 kernel Below grep SATA and grep ata: root@helios64:~# dmesg | grep SATA [ 3.137429] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode [ 3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) root@helios64:~# dmesg | grep ata [ 0.000000] Memory: 3787452K/4061184K available (16960K kernel code, 2318K rwdata, 5248K rodata, 4736K init, 604K bss, 142660K reserved, 131072K cma-reserved) [ 0.018184] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [ 0.719520] libata version 3.00 loaded. [ 3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 3.163337] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 82,32 bit host data width,256 deep fifo [ 8.508139] ata1: link is slow to respond, please be patient (ready=-19) [ 10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 10.610022] ata1.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133 [ 10.620898] ata1.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 10.624658] ata1.00: Features: NCQ-sndrcv NCQ-prio [ 10.639786] ata1.00: configured for UDMA/133 [ 11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.117876] ata2.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133 [ 11.128615] ata2.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 11.132356] ata2.00: Features: NCQ-sndrcv NCQ-prio [ 11.148021] ata2.00: configured for UDMA/133 [ 11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.630146] ata3.00: ATA-9: TS256GSSD370S, O1225G, max UDMA/133 [ 11.630849] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 32), AA [ 11.632376] ata3.00: Features: Dev-Sleep [ 11.635170] ata3.00: configured for UDMA/133 [ 12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.118227] ata4.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133 [ 12.128937] ata4.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 12.132823] ata4.00: Features: NCQ-sndrcv NCQ-prio [ 12.148357] ata4.00: configured for UDMA/133 [ 12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.626073] ata5.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133 [ 12.636772] ata5.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 12.640617] ata5.00: Features: NCQ-sndrcv NCQ-prio [ 12.656091] ata5.00: configured for UDMA/133 [ 52.828386] EXT4-fs (dm-1): mounted filesystem 58534626-3f89-40db-9b0e-9519a2805962 ro with writeback data mode. Quota mode: none. [ 56.637970] EXT4-fs (mmcblk0p1): mounted filesystem ba516afd-4114-4179-8bcf-3d0f63b058fe r/w with ordered data mode. Quota mode: none. [ 64.262140] EXT4-fs (dm-2): mounted filesystem cc702057-ff5f-4b6f-ad29-4f5d5d96216e r/w with ordered data mode. Quota mode: none. [ 64.341677] systemd[1]: Starting plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data... [ 64.358217] systemd[1]: Finished plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data. [ 66.316142] systemd-journald[1673]: Data hash table of /var/log/journal/21a29cba476e44048a808d9a655190f3/system.journal has a fill level at 88.2 (4015 of 4551 items, 2621440 file size, 652 bytes per hash table item), suggesting rotation.

Hi evevrybody, Since few days i note a problem with SATA on my Helios64. Only on a cold boot, SATA speed isn't to 6.0Gbps randomly on SATA disk, after reboot command, all it's good at 6.0Gbps root@helios64:~# dmesg | grep SATA [ 3.169958] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode [ 3.183007] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.183681] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.184378] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.185046] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.185710] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 10.440028] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 10.976033] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.480029] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.963976] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.472056] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) After reboot command: root@helios64:~# dmesg | grep SATA [ 3.151099] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode [ 3.164109] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.164781] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.165448] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.166114] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.166778] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 10.000101] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 10.524107] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.036103] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.520039] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.024104] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) I upgrade to 24.11 trunk build myself with framework and tune with Prahal dtb file and 6.6.56 kernel. Keep in touch. Bye

I hope all fixes and hacks will be include soon because the result is amazing to my side 😉 Welcome to Armbian-unofficial 24.5.3 Bookworm with Linux 6.6.32-current-rockchip64 System load: 16% Up time: 91 days 5:31

Hi, Today i upgrade to 24.5.3 when apt full-upgrade proposed me to upgrade and return of crash 😞 Tuned rk3399-kobol-helios64.dtb L2 hs400 file seen to be update... i copy paste file used with 6.6.32... I replace rk3399-kobol-helios64.dtb.org (with 24.5.3) with my rk3399-kobol-helios64.dtb post in this forum sha256sum: e90ebceb4b2f213818f320dfc61c90e556e0470702afa4117b0302bffc3d2cce rk3399-kobol-helios64.dtb sha256sum: 0eb03b645ab8125a4460d4509df32050188a8bdf2b5065f4321748b4eb6f6b4d rk3399-kobol-helios64.dtb.org It's seem to be not crash now... Keep in touch. UPDATE: i confirm, after update to 24.5.3, copy rk3399-kobol-helios64.dtb with L2 and hs400 in place of rk3399-kobol-helios64.dtb original is mandatory UPDATE 2: Same if you build with framwork last 24.8 version, you need to remplace: sha256sum: 0eb03b645ab8125a4460d4509df32050188a8bdf2b5065f4321748b4eb6f6b4d rk3399-kobol-helios64.dtb with sha256sum: e90ebceb4b2f213818f320dfc61c90e556e0470702afa4117b0302bffc3d2cce rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp rename to rk3399-kobol-helios64.dtb

Hi, I had this problem in past, you may try to unrack and rack hardisk or move it if you not use all rack. Problem to my side was bad contact in SATA connector. Bye

Hi, i use on my own build from scratch with framework official Armbian 24.05 with kernel 6.6.30 and DTB file send by ebin-dev here with 408-1800mhz ondemand governor and for the first time since I have it, it is stable and usable with my case of uses and it pass my pattern stability test ! Many thanks to ebin-dev for the great work.

Hi, Thank for your files and informations. To my side i don't use 2.5G interface because i don't have router 2.5G (and i don't do this tune: https://blog.kobol.io/2020/11/13/helios64-2-5g-ethernet-issue/ ). For moment, no problem with armbian-hardware-monitor.service enable, i stay with this setting, if one day armbian version will be change to use your workaround upper, i use it. I keep my 6.6.29 build and i build 6.6.30 for futur Keep in touch

Hi, On post below i report i have a stable helios64 with ebin-dev's file dtb for 6.6.29 with ondemand 408-1800mhz Whereis a post explain how dtb file change for understand how that work? You speak about end of cpufreq, armbian-hardware-optimize.service, irq smp_affinity, xhci and ahci... anyone have enough knowlege to explain this change ? It's specific for helios64 support or that will be include on futur armbian for every boards/versions ?

Hi, uptime more 5 days with my pattern test and ebin-dev's file for voltage change, not crash. now i use helios64 on normal condition to see if better than before for information my pattern test never pass before today on my helios64 with ondemand gov and 408-1800 freqs since i have it Keep in touch root@helios64:~# uptime 10:06:08 up 5 days, 40 min, 2 users, load average: 1.94, 2.49, 2.65 root@helios64:~# uname -a Linux helios64 6.6.29-current-rockchip64 #1 SMP PREEMPT Sat Apr 27 15:11:44 UTC 2024 aarch64 GNU/Linux helios64@helios64:~$ cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu #INTERVAL=10 INTERVAL=30 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 #MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MAXTEMP=/dev/fan-p6/pwm1=50 /dev/fan-p7/pwm1=50 #MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTART=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 #MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINSTOP=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MINPWM=20 root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

Hi, we speak same problem to link below. Read last 2-3 pages . Keep in touch

Hi, Not crash for moment with my patern test after 2days in 400-1800 schedutil. I pass on fly to 400-1800 ondemand and restart cpufrequtils.service, no crash. I program 2 anothers pattern test after the end of this first that start 2 days ago with schedutil gov and finish with ondemand gov. Result for GOVERNOR=ondemand 408-1800 Monday Keep in touch

okok, i do one pass with my setting and if not crash, i try GOVERNOR=ondemand after, my pattern test during 36-40hours, keep in touch after this time if i not crash/freeze before

Hi, okok, i test with my pattern test My brother have Helios64 also, he use it with many Docker Container and freeze everyday with default settings, same stabilty problem, he pass to 1200 1200 performance this day and test this setting for moment... if work better to my side with your file, my brother test your file on his helios Your file is on my helios, 400-1800 schedutil echo check > /sys/block/md0/md/sync_action -> running btrfs check --check-data-csum --readonly --progress /dev/disk/by-uuid/XXXXXXXXXXXXX -> running Freeze Crash... Not Freeze Crash... Keep in touch

...and i reproduce twice same freeze with cryptosetup to unlock my raid... freeze network... access usb is ready... but terribely slow... i tape my login and password and i waiting... but no response... picocom v3.1 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 1500000 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no Type [C-a] [C-h] to see available commands Terminal ready helios64 login: root Password: I type CTRL-C and... ^C _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian-unofficial 24.2.1 Bookworm with Linux 6.6.29-current-rockchip64 No end-user support: built from trunk System load: 3% Up time: 11 min Local users: 2 Memory usage: 7% of 3.77G IP: 10.0.0.155 CPU temp: 41°C Usage of /: 46% of 14G RX today: 53.8 MiB [ General system configuration (beta): armbian-config ] Web console: https://helios64:9090/ You have no mail. I type CTRL-C ^C And no prompt.... full freeze or lost control I back to ENABLE=true MIN_SPEED=408000 MAX_SPEED=1200000 GOVERNOR=schedutil until you explain me where and how use your file