rjgould

mind the voltage changes I am uneasy to push to main until I either get no more crashes for a long long time or the issue is nailed down to its cause.
I might revisit this choice.
I plan to have the emmc hs400 fix in Armbian and vanilla linux. Probably not for the august Armbian release but I expect for the next one.

So I don't know about everyone else, but for myself I've had my helios64 running on Armbian 22.02 with the 5.15.93-rockchip64 kernel for some time.
 
Mine is an on-lan ZFS replication target for my main NAS, i.e. overnight low power local part of my backup strategy.  I always knew it was not performing to it's full potential but it doesn't fall over.
 
The biggest challenge I had was getting OpenMediaVault 6 on it with the ZFS plugins from the extras repository.  The upgrades around those broke so often I ended up learning Ansible so I could script the steps I was doing by hand.
 
Also, because of the quirks and the "if it breaks, it's going to be painful" situation of it all, I stuck to running from the SD card, which I have an image of at a stable point on my main NAS.
 
Every once in a while I would try to move it all forwards to newer versions, when it doesn't go so well I flash the SD card from the image and start reading the forums, which is what brought me back here 😅

I don't even own one of these, but I am fascinated by how you guys finally got it stable it sounds like?  After all these years.  And the fact that Kobol (our once partner) went out of business years ago (I just looked and we are about a month shy of 3 years now).
 
Such triumph of the human will (and this project!), it could almost warm an old cynics heart. 
 
EDIT:
 
I updated (removed) the "instability" comments about Helios64 in my NAS article: So, you want to run a file server (aka NAS)?
 

Started work on syncing the helios64 dts to upstream for 6.9: https://github.com/prahal/build/tree/helios64-6.9 .
 
I removed the overclock disabling patch as the overclock as it disables an overclock that is at least nowadays not in the included rk3399-opp.dtsi (ie cluster0 has no opp6 and cluster no opp8). It was not a high priority beforehand but as the helios64 dts starts to change, thus carries unnecessary work.
 
The pachtset applies. The helios64 dts compile fine to dtb.
Kernel built and booted. (see below for network connection, ie ethernet MAC fixup)
 
There are not many functional changes on my side (there are in upstream dts). There are a few differences with upstream dts I did not bring as I don't know if they are leftover from the initial patch set or new fixups. But this could already have been an issue before 3.9 for most of these changes (there is at least a new upstream change 93b36e1d3748c352a70c69aa378715e6572e51d1  "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64") I brought forward.
I also brought in vcc3v0_sd node "enable-active-high;"  and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;".
 
 
Beware.
ethernet MAC change (now working as designed). The fact I kept the aliases from upstream fixes the ability for the eth0 (then renamed to end0 by armbian-hardware-optimization) ethernet mac - grabbed from OTP via SPI in u-boot to be applied. Thus if you bound the MAC address that was generated by the kernel instead of from the hardware to a host and IP, you will have to find the new IP assigned by the DHCP server to connect to the helios64.
I believe this is fine for edge even if not for current (so should be good for 6.9?).