Suitable replacement motherboard for helios64?

[yaleman]

I'm sick of having to play reset-it-until-it-boots-then-it-reboots-later game, anyone know a similar motherboard I can use in place of the helios64 with minimal extra messing around? I totally understand that the front and back panel will be a problem to set up, I just don't want to have to hack the main case part, and have support for the five SATA ports.

[Alexander Eiblinger]

Not sure if this is something you want to consider:
Using a Rasperry Pi 4 Compute Module ("CM4") it is possible to build a not too bad NAS
To use the CM4 you need a "IO Board" (e.g. https://www.berrybase.de/raspberry-pi/raspberry-pi-computer/compute-modules/raspberry-pi-compute-module-4-io-board).

The IO board has a PCIe port - and there you can plugin e.g. a 6bay SATA card. So in the end you get RP4 with as many SATA ports as you want / need. 
I have this running (but not in the enclosure of the Helios64) - performance is not that good as of the Helios64, but pretty close. It is running without any issues so far. 
The size of the system could fit into the Helios64 enclosure - some tinkering will be needed of course. 

[yaleman]

Yeah, I'll fall back to that kind of thing once I've exhausted the other options - I"m a little surprised that there aren't more Nano-ITX boards around

[ebin-dev]

Rock 5 B (Pico ITX - 8-core) is really powerful and power efficient (8nm lithography). I have preordered one.

[yaleman]

3 minutes ago, ebin-dev said:

Rock Pi 5 B (Pico ITX - 8-core) is really powerful and power efficient (8nm lithography). I have preordered one.

 

That doesn't look like it has any SATA ports...?

[Jin H. Jung]

1 hour ago, yaleman said:

 

That doesn't look like it has any SATA ports...?

You can use m.2 to sata. Or you may use rock pi 4 + penta sata hat

[mrjpaxton]

I'm really glad people are discussing this instead of blatantly tossing a perfectly good case with parts, leading to more e-waste.

 

I had almost forgot the case was Nano-ITX compatible.

 

The biggest challenges will be getting the fans, LEDs, the backup battery, and hardware buttons (power/reset) to work. The back with the I/O shield will also need to be replaced, or removed completely.

 

Otherwise, it sounds doable.

[yaleman]

18 minutes ago, mrjpaxton said:

I'm really glad people are discussing this instead of blatantly tossing a perfectly good case with parts, leading to more e-waste.

 

I had almost forgot the case was Nano-ITX compatible.

 

The biggest challenges will be getting the fans, LEDs, the backup battery, and hardware buttons (power/reset) to work. The back with the I/O shield will also need to be replaced, or removed completely.

 

Otherwise, it sounds doable.

 

Yeah, except the only options that seem to be available are some rando old intel aotec boards, so at this point I'm looking at a cheap matx AMD setup

[freed00m]

Ok, I will drop here one suitable yet ridiculously expensive replacement.

Overkill I know.

 

HoneyComb LX2 Workstation.

https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-servers-workstation/#honeycomb-workstation

 

My friend got one and very satisfied and he is also underwhelmed Helios64 user.

 

I would get that one too, but I am cheap not gonna lie.

 

I talked with him and he likes the board, the u-boot runs quite OK (maybe upstreamed even) + he tried to compile u-boot for helios64 to boot something else than amrbian kernel without much success.

 

It has 4x SATA 3.0 even some 8xPCI-e with standalone 4xPCI-e for M2-slot.

 

But I think no UPS support + it is probably more power hungry than helios64.

Also I've seen power supplies so small and mountable without case shielding (made in china), maybe it could fit inside also.

[freed00m]

Oh it's not nanoITX, nvm.. I just had a look and it wouldn't fit the case.

[prahal]

@yaleman if your helios64 is unstable you might want to try in /boot/armbianEnv.txt adding cpufreq.off=1 to extraargs:

extraargs=earlyprintk cpufreq.off=1

this option is available back to kernel 4.11.

Then reboot.

 

To test without reboot:

echo 1 | sudo tee /sys/module/cpufreq/parameters/off

might do.

 

I am still investigating and will try less severe ways soon (also there were reports of an instability issue with vdd_log so it might be required to set it to 0.95V in u-boot (like https://lists.denx.de/pipermail/u-boot/2019-January/353357.html ) and/or remove its definition in the board dts https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi?id=87eba0716011e528f7841026f2cc65683219d0ad in 2017 but it was reinserted in 2022 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi?id=e6bbf0d53ae1060ee6403bafcc4d1fd25d088e40).

This can be tested with:
 

regulator dev vdd_log
regulator value 950000

in /boot/boot.cmd then

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

and reboot.

 

But with this cpufreq disabled, I am at 27 days stable with the same loads that crashed in less than 16 days beforehand (it was crashing even with cpufreq set to performance and a fixed freq .

I am waiting for to see if I can be stable beyond my max of 42 days.

 

What seems to stress the board is borgbackup (which runs 23h per day since I have a repo with too many files in it and the board thus swap has it only has 4G RAM), urbackup, mdadm raid10 (when it resync which happens after a HW crash at boot - before the boot script to set cpufreq is even run - so setting to performance with a static freq has no effect on this crasher).

OMV seems to make the bug trigger more often, I think because if it sysctl tweaks from /etc/sysctl.d/99-openmediavault-nonrot.conf which I for now symlink to /dev/null.

 

I hope the issue is that helios64 dts has vdd_cpu_b: regulator@40 regulator-ramp-delay set to 40000 instead of the more common 1000 amond the rk3399 boards. I found a thread https://forum.odroid.com/viewtopic.php?t=30303 where hardkernel went from 1000 to 40000 on the odroid n1 but it might be that it is not stable on our rk3399 chips.

 

There is also the pwm-supply instead of vin-supply in dts for vdd_log per https://github.com/torvalds/linux/commit/dc570e8e1a7036eaaeede71b55e14739710ea0a4.

 

[yaleman]

Yeah I played that game for months and got sick of it, the machine's been decommissioned for some time. A complete waste of money and time.