anmaped

To maintain changes between different kernel versions, you can use overlays. I did this by following some dts changes from @ebin-dev. Add this line user_overlays=rockchip-rk3399-op1-opp rockchip-rk3399-l2-cache to /boot/armbianEnv.txt Copy the dtbo files to /boot/overlay-user (mkdir -p /boot/overlay-user if the folder does not exist). rockchip-rk3399-l2-cache.dtborockchip-rk3399-op1-opp.dtborockchip-rk3399-op1-opp.dtsrockchip-rk3399-l2-cache.dts

@ebin-dev not sure with your cpufreq settings as it should be 40000 otherwise the regulator cannot ramp-up the voltage so quickly. regulator@40 { compatible = "silergy,syr827"; reg = <0x40>; fcs,suspend-voltage-selector = <0x01>; pinctrl-names = "default"; pinctrl-0 = <0x83>; regulator-name = "vdd_cpu_b"; regulator-min-microvolt = <0xadf34>; regulator-max-microvolt = <0x16e360>; regulator-ramp-delay = <0x9c40>; regulator-always-on; regulator-boot-on; vin-supply = <0x82>; phandle = <0x0e>; regulator-state-mem { regulator-off-in-suspend; }; }; I have been using Helios64 for few years without any issues (four years ago, when I detected instability, I disabled the a72 cluster and continue only with updates, without any problems). Now that I have upgraded my network to 10 Gbits, I am experiencing problems with the 2.5 Gbits network card, which I did not use previously (link https://forum.armbian.com/topic/43858-helios-64-network-issues-with-armbian-2453-on-kernel-6639-frequent-disconnects/#findComment-225220 ). My theory is that the instability also affects USB 3.0 and RTL8156, causing crashes and triggering the watchdog. I also tried connecting an active switch to type C with an external RTL8156BG, and the watchdog was also triggered (some transmission errors, not many, but some). So I can confirm that with the a72 cluster and the 2.5 Gbit network card disabled, you have an extremely stable NAS (now with kernel 6.12.44). Does anyone have a damaged or non-functioning helios64 motherboard they can send?

@grendel Sure you're certain you need a new cable harness? A few years ago, I replaced the HDD power switches myself, they’re just small smd transistors. 1 and 2 (Channel A) power on simultaneously, followed by 3, 4, and 5 (Channel B). There’s a built-in delay between the two channels to help manage voltage spikes that occur during HDD initialization — Channel A starts first, then Channel B.

@ebin-dev@mtlmarko189 Not sure if this issue can be resolved. I've been running tests with different chip versions and discovered that the first batch of Helios64 devices includes an unreliable chip. Take a look at this: root@helios64:~# lsusb -v -d 0bda:8156 | grep bcdDevice bcdDevice 30.00 bcdDevice 31.04 According to cnx-software 30.00 corresponds to RTL8156 31.00 corresponds to RTL8156B 31.04 correspond to the third version, RTL8156BG So far, the RTL8156BG has been working better with Linux kernel 6.12.42. P.S. The workaround suggested by @ebin-dev helps reduce the symptoms, but the NIC is still sending corrupted packets.