[Helios64 - Armbian 23.08 Bookworm issues (solved)]

 Thank you @prahal!! - for getting us back into supported status.

[Helios64 - Armbian 23.08 Bookworm issues (solved)]

@ebin-dev - one quick question.
Applying this script at boot should change the sampling rate to the desired values?
 

for cpufreqpolicy in 0 4 ; do
    echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy
    echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold
    echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor
    echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate
done

 

[Helios64 - Armbian 23.08 Bookworm issues (solved)]

Thank you @ebin-dev for the dtb file & @prahal for figuring out what changes to make.
I just reinstalled my NAS with the 6.6.30 kernel and the bookwork image. The dtb file is the only change I've made to configuration.
Haven't had any issues yet - so far recompiling ZFS KMOD 2.2.4 to run with new kernel hasn't crashed - MAX CPU freq. for the BIG cores is 1.8GHz

NFS and SMB are working fine. sbc-bench is stable as well.

[Upgrading to Bullseye (troubleshooting Armbian 21.08.1)]

Thanks @lanefu.

Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs.

 

Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.

[Upgrading to Bullseye (troubleshooting Armbian 21.08.1)]

@Igor, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)?

That way we can participate on the QA process and help raise flags when pre-released changes break the stable builds.

I understand that you do not have an Helios64 to test, and so as part of the community we should be able to help in that regard.

[Kobol Team is pulling the plug ;(]

18 hours ago, aprayoga said:

Hi everyone, thank you for all of your support.

I'll be still around but not in full time as before.

 

I saw Helios64 has several issues in this new release. I will start looking into it.

Thank you @aprayoga

[[Temp FIX] for armbian-bsp-cli-helios64 21.05.8 fancontrol service fail.]

@halfa

I get this as output:

Package: armbian-bsp-cli-helios64
Version: 21.05.8
Priority: optional
Section: kernel
Maintainer: Igor Pecovnik <igor.pecovnik@****l.com>
Installed-Size: 1,024 B
Provides: linux-focal-root-legacy-helios64, linux-focal-root-current-helios64, linux-focal-root-edge-helios64
Depends: bash, linux-base, u-boot-tools, initramfs-tools, lsb-release, fping
Recommends: bsdutils, parted, util-linux, toilet
Suggests: armbian-config
Breaks: linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~)
Replaces: zram-config, base-files, armbian-tools-focal, linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~)
Download-Size: 417 kB
APT-Manual-Installed: yes
APT-Sources: http://apt.armbian.com focal/focal-utils arm64 Packages
Description: Tweaks for Armbian focal on helios64

 

I see a few packages listed under 'Breaks'

[[Temp FIX] for armbian-bsp-cli-helios64 21.05.8 fancontrol service fail.]

@ebin-dev @m11k - how often do you update the packages on your NAS?

Or do you do installation once and then cherry pick which updates you want?

[[Temp FIX] for armbian-bsp-cli-helios64 21.05.8 fancontrol service fail.]

@Heisath

@Igor

I don't have environment to build the image at the moment, but if there is a repository where the beta images are available I can test them out.

[[Temp FIX] for armbian-bsp-cli-helios64 21.05.8 fancontrol service fail.]

@Heisath

Right now the file present on the installation is: '90-helios64-hwmon-legacy.rules'

I'll update the title of this post to mark a temporary fix, I agree with both of you that the fans should be tied to the CPU temperatures and not the board. But since the release broke monitoring having the fan control tied to something is better than nothing - otherwise the fan don't even spin up.

[[Temp FIX] for armbian-bsp-cli-helios64 21.05.8 fancontrol service fail.]

A few Armbian packages were updated (armbian-bsp-cli-helios64, armbian-config, armbian-firmware &armbian-zsh) to version 21.05.08.

At some point I noticed that the fancontrol service had failed to start up after the reboot - it was complaining about a file missing(/dev/thermal-cpu). If you run into this after the update, just update your /etc/fancontrol to the content below and your fancontrol should go back to normal.

 

 

# Helios64 PWM Fan Control Configuration
# Temp source : /dev/thermal-cpu
# After 21.05.08 [2021.08.10]
# Temp source : /dev/thermal-board
INTERVAL=10
# FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input
# After 21.05.08 [2021.08.10]
FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-board/temp1_input /dev/fan-p7/pwm1=/dev/thermal-board/temp1_input
MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40
MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110
MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60
MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40
MINPWM=20

 

[Installing Armbian on Helios64]

@jsfrederick

You can just write the image to the SD card and boot.

For SSH, as long as you know what IP address the Helios64 gets than you can just use that to connect.

The serial terminal is just to check if things booted correctly or in case of an error that needs to be diagnosed.

You should be fine with your usual process.

[Does anybody know what is new in the linux-u-boot-helios64-current 21.08.1 package?]

Thank you @Werner

[Does anybody know what is new in the linux-u-boot-helios64-current 21.08.1 package?]

I checked for any available updates yesterday, and this (linux-u-boot-helios64-current 21.08.1) was applied.

Can't find what was new or if it was only a version bump.

By the way, nothing broke after the update.

[ZFS: Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended.]

I'm curious about this issue.

Let us know if changing the CPU Voltage has an effect on system stability.

[We want YOU for armbian]

Hello @Igor, @Werner,

I'm open to collaborating to the armbian project, my background is on software development and system administration and I have a small Helios64 to test things with.

[Kobol Team is taking a short Break !]

Enjoy your time off - looking forward to new products from you guys.

[Feature / Changes requests for future Helios64 board or enclosure revisions]

My comment might be late to the party - if there was a possibility to add an optional display and a few user-configurable buttons to the Front Panel, that would be great.

I know it would mess a bit with the airflow, but it could be used for system monitoring and few other specific use cases.

[SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED]

Thanks @aprayoga.

What's new or has changed in the latest SATA firmware image?

[UPS service and timer]

@wurmfood

The script looks goods.

I like the check for main power before the battery level verification, it solves the use case @clostro mentioned.

 

@aprayoga

Looking forward to the new release

[UPS service and timer]

@wurmfood

On my system the helios64-ups.timer is disabled by default.

Is this a timer that has to be manually enabled ?? I thought that the Helios would check if it had the battery and activate this automagically.

It might be better to have a daemon in the background that checked the battery value every 20 seconds and only printed out output when there was a change.

[Does anyone actually have a stable system?]

Thanks for the information @gprovost.

From the looks of it - Armbian 21.02.03 seems to install the Rockchip Blob.

Where does the U-boot TPL/SPL come from ?? the new beta builds?

 

Regards.

[Does anyone actually have a stable system?]

My case is similar to @wurmfood's - latest OS, ZFS and no OMV.

@gprovost, how can we check and determine "if you are using rockchip blob or u-boot TPL/SPL"?

[Crazy instability :(]

Thanks for the tip @ShadowDance, in my case I haven't had any crashes while using ZFS.

But I've updated my systemd scripts to take the ZFS scheduler into account.

What I did notice was that my data-sets on raid-z1 pool seems to be a bit more snappy (it might be a perception issue on my part).

 

[Unit]
Description=HDD-Idle service
After=basic.target multi-user.target

[Service]
Type=oneshot
## Set Power Management parameters to all HDD
ExecStart=/bin/sh -c '/usr/sbin/hdparm -qB255S120 /dev/sd[a-e]'
## Allows ZFS to use it's own scheduler for rotating disks.
ExecStart=/bin/sh -c 'echo none | tee /sys/block/sd[a-e]/queue/scheduler'

[Install]
WantedBy=multi-user.target

 

[Easy way to up boot precedence for microSD]

21 hours ago, oneo said:

Hey there, so I was curious is there an easier way to make microSD take precedence in the boot order then having to futz with jumpers?

 

Wanting to try out a new distro on microSD before deciding to make the switch and flash it to eMMC.

If I do futz with jumpers I'll still be able to mount and write to the eMMC correct?

@oneo - what distro are you trying out?