BipBip1981

Thank a lot !

Hello, I hope you don't have any problem. Maybe me and my brother have defective or more unstable helios64 than you. Only thing I can say that Prahal share here the specifics files rk3399-kobol-helios64.dtb-6.XX.xx-L2-hs400-opp in this forum since two years ago my helios64 and my brother's helios64 work stable only with it. I back to 6.12.58 Kernel with rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp file and freeze firmware/kernel with armbian-config.

For information: First reboot and crash same that before use rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp. 😞 Back to 6.12.58, rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and freeze to this setting Me and my brother have helios64 with 6.18.10 Kernel : RAID 10 / LVM / LUKS and crash always when "cryptsetup open..." start Crash when many I/O Crash when use Full CPUs With rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and Kernel 6.12.58 or 6.12.(XX below): Me, never crash but I reboot often and power off often for personal choice. My brother have uptime upper than 100 or 200 days with problem, freeze or crash Bye

Hi everybody, I running Helios64 with kernel 6.12.58 since a long time and the prahal dtb file rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and my helios64 work well. Today, Armbian upgrade to 6.18.10 kernel. Is this update use the same change or patch like in rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp ? Is rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp work with 6..18.10 kernel ? Is I must to downgrade to 6.12.58 kernel with rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and freeze at this kernel version ? Thanks for answer.

Hi, In 2025, Helios64 is now stable for me and for my brother, who also uses it. The only thing to do is, just after installation or after any upgrade, you must reinstall the special file rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp because I think the specific tuning in this file is not included in the official image. For me, I suggest keeping it, using it, and saving your money for other things. Bye.

Hi, my feedback with rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and agressif fancontrol setting like this: # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input MINTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=30 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=30 MAXTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=50 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=50 MINSTART=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINSTOP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINPWM=20 is: All it's Okok Without the tunning file DTB and Fancontrol, the nighmare restart. Today, update, original DTB file restore and CRASH when Luks begin to unciffer my DDs Il restore DTB file and my fancontrol setting and: Return to Okok situation. To conclude, i use my helios without problem when this files is installed. My helios64 always crash if i return to original setting after a update.

Hi, my feedback for fancontrol service here : for 2.5Gbits, i don't use. for rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp, same has i writed up: "It is better to have a good solution in time than a perfect one too late.", my helios64 going to the trash without this workaround.

Hi, To my side, below work in root but not with systemd service: # 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=50 /dev/fan-p7/pwm1=50 MINSTART=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MINSTOP=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MINPWM=20 To my side, below work in root and with systemd service: # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input MINTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=40 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=40 MAXTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=50 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=50 MINSTART=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINSTOP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20

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.