SymbiosisSystems

Hi @ebin-dev, @SymbiosisSystems, and everyone in this thread,
Following the recurring instability reports here and in the older topic
30074, I've packaged your opp-microvolt workaround as an opt-in DT
overlay in the Armbian build framework.
PR:
**armbian/build#9822** — adds the overlay to both Armbian kernel
trees: `rockchip64-current` (6.18) and `rockchip64-edge` (7.0).
What you get once this lands:
  - `rockchip-rk3399-helios64-cpu-stability.dtbo` ships inside the
    regular `linux-dtb-{current,edge}-rockchip64` package. No
    hand-patching of DTBs, no separate downloads; `apt upgrade` keeps
    the overlay in sync with whatever DTB your kernel ships.
  - **Not enabled by default** — for the people whose Helios64 "just
    works", the mainline OPPs stay untouched. I don't want to push a
    tree-wide voltage bump onto every user when only some units exhibit
    the instability.
  - Activation is the standard Armbian way, either:
      armbian-config → System → Kernel →
      Manage device tree overlays → [*] rk3399-helios64-cpu-stability
      → save → reboot
    or manually, by adding the overlay name to the `overlays=` line in
    `/boot/armbianEnv.txt` (the `rockchip-` prefix is implicit, because
    `overlay_prefix=rockchip` is already set on this board):
      overlays=rk3399-helios64-cpu-stability
    Then reboot.
Voltages are exactly the ones from post #237456 (opp00..opp06 raised to
900 / 900 / 900 / 950 / 1025 / 1100 / 1175 mV; opp07 left at the
mainline 1.20 V; `max` everywhere kept at 1.25 V). Frequencies are not
touched.
End-to-end verified on my Helios64 with both kernels:
  - current / 6.18.30, Trixie SD-card image
  - edge    / 7.0.7,   Trixie SD-card image (locally built)
After enabling the overlay and a reboot:
  for n in 0 1 2 3 4 5 6 7; do
    od -An -tx4 --endian=big \
       /sys/firmware/devicetree/base/opp-table-1/opp0$n/opp-microvolt
  done
  opp00  000dbba0 000dbba0 001312d0
  opp01  000dbba0 000dbba0 001312d0
  opp02  000dbba0 000dbba0 001312d0
  opp03  000e7ef0 000e7ef0 001312d0
  opp04  000fa3e8 000fa3e8 001312d0
  opp05  0010c8e0 0010c8e0 001312d0
  opp06  0011edd8 0011edd8 001312d0
  opp07  00124f80 00124f80 001312d0
...which matches your table 1:1. U-boot log line on boot:
  Applying kernel provided DT overlay
  rockchip-rk3399-helios64-cpu-stability.dtbo
confirms that u-boot picks up the `.dtbo` from
`/boot/dtb/.../rockchip/overlay/` and applies it via `fdt apply` before
the kernel starts.
Ready-to-flash **current/6.18** images, built from the PR branch by the
official Armbian builder workflow:
  https://fi.mirror.armbian.de/incoming/iav/helios64/archive/
  - Armbian_26.5.0_Helios64_resolute_current_6.18.30_minimal.img.xz
  - Armbian_26.5.0_Helios64_resolute_current_6.18.30_xfce_desktop.img.xz
  - Armbian_26.5.0_Helios64_trixie_current_6.18.30_minimal.img.xz
If any of you can grab one of those (or wait for a nightly after the PR
is merged) and confirm the workaround applies cleanly through the
overlay path on your board, that would help the PR land. Bug reports
are welcome too.
Attribution lives in
`patch/kernel/archive/rockchip64-{6.18,7.0}/overlay/README.rockchip-overlays`
under `### rk3399-helios64-cpu-stability`, pointing back to topics 30074
and 58597, prahal and ebin-dev.
Thanks!

Hi @ebin-dev, @SymbiosisSystems, and everyone in this thread,
Following the recurring instability reports here and in the older topic
( https://forum.armbian.com/topic/30074-helios64-armbian-2308-bookworm-issues-solved/ ),
I've packaged your opp-microvolt workaround as an opt-in DT overlay in
the Armbian build framework. PR:
  https://github.com/armbian/build/pull/9822
— adds the overlay to both Armbian kernel trees: `rockchip64-current`
(6.18) and `rockchip64-edge` (7.0).
What you get once this lands:
  - `rockchip-rk3399-helios64-cpu-stability.dtbo` ships inside the
    regular `linux-dtb-{current,edge}-rockchip64` package. No
    hand-patching of DTBs, no separate downloads; `apt upgrade` keeps
    the overlay in sync with whatever DTB your kernel ships.
  - **Not enabled by default** — for the people whose Helios64 "just
    works", the mainline OPPs stay untouched. I don't want to push a
    tree-wide voltage bump onto every user when only some units exhibit
    the instability.
  - Activation is the standard Armbian way, either:
      armbian-config → System → Kernel →
      Manage device tree overlays → [*] rk3399-helios64-cpu-stability
      → save → reboot
    or manually, by adding the overlay name to the `overlays=` line in
    `/boot/armbianEnv.txt` (the `rockchip-` prefix is implicit, because
    `overlay_prefix=rockchip` is already set on this board):
      overlays=rk3399-helios64-cpu-stability
    Then reboot.
Voltages are exactly the ones from your post in this thread —
https://forum.armbian.com/topic/58597-helios64-armbian-trixie-with-linux-618-incl-opp-microvolt-patch/?do=findComment&comment=237456
(opp00..opp06 raised to
900 / 900 / 900 / 950 / 1025 / 1100 / 1175 mV; opp07 left at the
mainline 1.20 V; `max` everywhere kept at 1.25 V). Frequencies are not
touched.
End-to-end verified on my Helios64 with both kernels:
  - current / 6.18.30, Trixie SD-card image
  - edge    / 7.0.7,   Trixie SD-card image (locally built)
After enabling the overlay and a reboot:
  for n in 0 1 2 3 4 5 6 7; do
    od -An -tx4 --endian=big \
       /sys/firmware/devicetree/base/opp-table-1/opp0$n/opp-microvolt
  done
  opp00  000dbba0 000dbba0 001312d0
  opp01  000dbba0 000dbba0 001312d0
  opp02  000dbba0 000dbba0 001312d0
  opp03  000e7ef0 000e7ef0 001312d0
  opp04  000fa3e8 000fa3e8 001312d0
  opp05  0010c8e0 0010c8e0 001312d0
  opp06  0011edd8 0011edd8 001312d0
  opp07  00124f80 00124f80 001312d0
...which matches your table 1:1. U-boot log line on boot:
  Applying kernel provided DT overlay
  rockchip-rk3399-helios64-cpu-stability.dtbo
confirms that u-boot picks up the `.dtbo` from
`/boot/dtb/.../rockchip/overlay/` and applies it via `fdt apply` before
the kernel starts.
Ready-to-flash **current/6.18** images, built from the PR branch by the
official Armbian builder workflow:
  https://fi.mirror.armbian.de/incoming/iav/helios64/archive/
  - Armbian_26.5.0_Helios64_resolute_current_6.18.30_minimal.img.xz
  - Armbian_26.5.0_Helios64_resolute_current_6.18.30_xfce_desktop.img.xz
  - Armbian_26.5.0_Helios64_trixie_current_6.18.30_minimal.img.xz
If any of you can grab one of those (or wait for a nightly after the PR
is merged) and confirm the workaround applies cleanly through the
overlay path on your board, that would help the PR land. Bug reports
are welcome too.
Attribution lives in the overlay README block (look for the heading
`### rk3399-helios64-cpu-stability`), pointing back to forum topics
30074 and 58597, prahal and ebin-dev:
  https://github.com/armbian/build/blob/feat/helios64-cpu-stability-overlay/patch/kernel/archive/rockchip64-6.18/overlay/README.rockchip-overlays
  https://github.com/armbian/build/blob/feat/helios64-cpu-stability-overlay/patch/kernel/archive/rockchip64-7.0/overlay/README.rockchip-overlays
Thanks!

I have attached both the dtbs for linux 6.6 and 6.12 to this message in the forum.

@SymbiosisSystems To get those changes into the mainline build is currently not the solution preferred by the maintainer of this board, because it is some kind of a hot fix.
 
To boot your helios64 to the command line you could try an image from the archive and boot from sd. A system on emmc could then be manipulated using chroot.

The most current download images for Helios64 are now all provided with linux 6.18.xx.
 
I downloaded a minimal image and checked the dtb: it would not appear to contain the opp-microvolt patch that made Helios64 finally stable.
 
So for the ones who have stability issues again on Helios64, I attached the patched dtb compiled for linux 6.18.xx using the exact same opp-microvolt values as in the previous dtb versions I compiled for linux 6.6 and 6.12. The current linux deb files can be downloaded from beta.armbian.com, the linux 6.18.18 deb files I used can be downloaded from here (to be installed with 'dpkg -i linux*').
 
In order to install the dtb, simply unzip it, copy it into the proper location, update initramfs and reboot:
 
# install the dtb with the opp-microvolt patch: unzip rk3399-kobol-helios64.dtb-6.18.18-opp.zip cp rk3399-kobol-helios64.dtb-6.18.18-opp /boot/dtb/rockchip/rk3399-kobol-helios64.dtb update-initramfs -u reboot rk3399-kobol-helios64.dtb-6.18.18-opp.zip

@jbergler I recently noticed the armbian-hardware-optimization script for Helios64 changes the IO scheduler to `bfq` for spinning disks, however, for ZFS we should be using `none` because it has it's own scheduler. Normally ZFS would change the scheduler itself, but that would only happen if you're using raw disks (not partitions) and if you import the zpool _after_ the hardware optimization script has run.
 
You can try changing it (e.g. `echo none >/sys/block/sda/queue/scheduler`) for each ZFS disk and see if anything changes. I still haven't figured out if this is a cause for any problems, but it's worth a shot.

Hi,
On an up-to-date Helios64, around 50% of boots are stuck at "Starting kernel ...".
As device is having kernel panics every day, it reboots and then sometimes can't start, stuck on this.
When will we have a stable device ? I can't understand selling devices which just can't run !

If you want the fans of your Helios64 to start spinning earlier, look no further. This will allow the fans to spin at a constant speed from the earliest stage of initrd until fancontrol is started by the system. My use-case is for full disk encryption and recovery in initramfs, sometimes I can have the machine powered on for quite a while before fancontrol starts. Or, if the boot process encounters an error the fans may never start, this prevents that.
 
Step 1: Tell initramfs to include the pwm-fan module
echo pwm-fan | sudo tee -a /etc/initramfs-tools/modules  
Step 2: Create a new file at /etc/initramfs-tools/scripts/init-top/fan with the following contents:
#!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in prereqs) prereqs exit 0 ;; esac . /scripts/functions modprobe pwm-fan for pwm in /sys/devices/platform/p*-fan/hwmon/hwmon*/pwm1; do echo 150 >$pwm done exit 0 Feel free to change the value 150 anywhere between 1-255, it decides how fast the fans will spin.
 
Step 3: Enable the fan script for inclusion in initramfs and update the initramfs image:
sudo chmod +x /etc/initramfs-tools/scripts/init-top/fan sudo update-initramfs -u -k all  
Step 4: Reboot and ejoy the cool breeze.