Jump to content

Helios64 Support


gprovost

Recommended Posts

Testing Helios64 as a file server and for backups (Time Machine) using netatalk is very promising: 

Htop reports a CPU load of 40-50% (half a core) while copying large files to discs over a 1Gb/s network connection with up to 110MB/s.

More than 2TB transferred without any instability (using Buster server 5.8.13). Perfect !

 

I am now very much looking forward to boot the system from emmc (/dev/mmcblk1) (which is not fully supported yet) since the performance of the microSD card is currently less than what I expected (see below - 16GB SanDisk Ultra used as /dev/mmcblk0, results are even worse with a 512GB Samsung Evo plus microSD):

 

root@helios64:~# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   2394 MB in  2.00 seconds = 1197.13 MB/sec
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads:  70 MB in  3.08 seconds =  22.70 MB/sec
root@helios64:~# hdparm -tT /dev/mmcblk1

/dev/mmcblk1:
 Timing cached reads:   2348 MB in  2.00 seconds = 1174.67 MB/sec
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing buffered disk reads: 520 MB in  3.01 seconds = 173.01 MB/sec

 

@gprovost I think "auto power on" should be the default system behaviour - without requiring to set any gpio pins, since Helios64 will not operate 24/7 in most of the use cases. The easiest way to achieve that is to interrupt the power after a normal shutdown (i.e. using a DECT switch) and to automatically boot the device once the power is back on.

Link to comment
Share on other sites

I'm getting a blank terminal window when running the command to connect to the console:

$ screen /dev/tty.usbserial-XXXXXXXX 1500000 -L

Of course I did input the correct usbserial number that shows up in the /dev/ directory.

 

The very first time the terminal window displayed a lot of noise with seemingly random characters. I killed the window and re-opened, and now whenever I re-open it, the terminal window is just empty. I've restarted the helios twice already while connected in the terminal, but still nothing. Not sure where the error could be.

 

EDIT: Forgot to say: I'm on Mac Catalina (OS 10.15), zsh-terminal. I do not own another machine currently, could set up a VM if the problem cannot be solved currently.

 

The initial bunch of symbols is as follows:

 

`�`���x�f������������`���������x�怘����怘�������f����怘��������怘����������怘���`������怘���f������怘����������怘���������~�� 怘����`�����~��怘����������怘����������怘����`�������怘����f������怘�������f����怘��������怘����������怘���`������怘���f������怘����������怘���������~��怘����`�����~��怘����������怘����������

 

Edited by Carlos Hartmann
Further info
Link to comment
Share on other sites

21 hours ago, erikced said:

Is it possible set the fan speed of the pwm fans somehow? For me the fan connected to P6 never ever starts, whereas the fan connected to P7 always runs at full speed (well, a little slower when on battery power).

 

That's strange that one of the fan never spin up, the same fancontrol configuration applies to both fans, so they should both spin at the same time and same speed.

Maybe something wrong with the fan.

 

You can manual set speed as follow :
 

echo 100 > /dev/fan-p6/pwm1
echo 100 > /dev/fan-p7/pwm1

 

PWM accepts value from 0 to 255.

You will have to stop fancontrol service otherwise it will constantly override you pwm values.

 

systemctl stop fancontrol.service

 

Link to comment
Share on other sites

On 10/10/2020 at 12:09 AM, flower said:

if someone wants to shutdown their unit on powerloss:

 

create file: /etc/udev/rules.d/15-gpio-charger.rules


SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/sbin/halt"

 

i'd love to know a way to start that unit when power is available again though.

 

on 4.4 the system crashes on halt. but as it does this after all services are stopped and the disks are synced this is not really a problem.

on 5.8 the system stops and "system halted" appears on serial console - BUT it is still on and fans are spinning.

 

19 hours ago, ebin-dev said:

@gprovost I think "auto power on" should be the default system behaviour - without requiring to set any gpio pins, since Helios64 will not operate 24/7 in most of the use cases. The easiest way to achieve that is to interrupt the power after a normal shutdown (i.e. using a DECT switch) and to automatically boot the device once the power is back on.

you could re-enable auto power on by removing /lib/systemd/system-shutdown/disable_auto_poweron . You can check the file to see how to control the gpio pin for the auto power on feature.

The auto power on is always enabled by bootloader.

 

 

16 hours ago, alchemist said:

Hi,

 

Do the SPI boot work? Can I install u-boot on SPI and then boot sda1 from SPI?

 

As @flower answered,  SPI boot is not yet working. Theoretically after boot from SPI  you could change boot target to first SATA drive

Link to comment
Share on other sites

On 10/8/2020 at 1:09 AM, antsu said:

Just tried building 0.8.5 on the Buster current image.  Unfortunately is still fails with the "__stack_chk_guard" errors.

This topic and this GitHub issue (by the same author) have more info about the possible cause for this.

 

In the meantime, I built a zfs 0.8.5 module that you can use on buster (but only the 5.8.13 kernel)

First install this package with dpkg -i kmod-zfs-5.8.13-rockchip64_0.8.5-1_arm64.deb and then install the zfs utils with apt install -t buster-backports zfsutils-linux

 

Edited by jbergler
Link to comment
Share on other sites

8 minutes ago, jbergler said:

 

In the meantime, I built a zfs 0.8.5 module for the 5.8.13 kernel using a focal container.

First install this package with dpkg -i kmod-zfs-5.8.13-rockchip64_0.8.5-1_arm64.deb and then install the zfs utils with apt install -t buster-backports zfsutils-linux

 

Legend! Thank you very much, I'll give this a try asap.

Link to comment
Share on other sites

On 10/11/2020 at 8:14 AM, flower said:

You can do that through /etc/fancontrol but the syntax is a litte strange.

...

 

8 hours ago, gprovost said:

 

That's strange that one of the fan never spin up, the same fancontrol configuration applies to both fans, so they should both spin at the same time and same speed.

Maybe something wrong with the fan.

 

You can manual set speed as follow :
 



echo 100 > /dev/fan-p6/pwm1
echo 100 > /dev/fan-p7/pwm1

 

PWM accepts value from 0 to 255.

You will have to stop fancontrol service otherwise it will constantly override you pwm values.

 



systemctl stop fancontrol.service

 

 

Thanks for the help both of you, unfortunately it doesn't seem to work. I've both attempted to configure fancontrol and setting the values manually., I can see that the values of /dev/fan-{p6,p7}/pwm1 change but that doesn't make the actual fans spin any faster or slower. I've also tried swapping the fans between P6 and P7 and confirmed that both work, and the fan connected to P7 always spins at a constant speed (a little slower on battery power than when the PSU is connected) whereas the fan connected to P6 usually spins for about a second then stops.

Edited by erikced
Link to comment
Share on other sites

i checked today and saw a new 20.08.9 in the updates.
Has anything new been implemented or fixed in the new 20.08.9 that might interest us as Helios64 owners?

 

root@helios64:~# apt list --upgradable
Listing... Done
armbian-config/buster,buster 20.08.9 all [upgradable from: 20.08.8]
armbian-firmware/buster,buster 20.08.9 all [upgradable from: 20.08.8]
linux-buster-root-current-helios64/buster 20.08.9 arm64 [upgradable from: 20.08.8]
root@helios64:~#

 

edit1:

I have found 2 commits from aprayoga, have they perhaps already been implemented in 20.08.9?
If so, the first one should be seen as fix for the eMMC problem, right?

 

https://github.com/armbian/build/commit/d909a4ea723f5e3e1d1b3e7bb07a2215793725b1 (Verified)

https://github.com/armbian/build/commit/bc66f9d835cb8303eb65ea55ac02da69920284f7 (???)

 

edit2:

Unfortunately there is nothing to find in the changelog about 20.08.9 yet.
Is it perhaps still so fresh?

https://docs.armbian.com/Release_Changelog/

Link to comment
Share on other sites

Has anyone had issues with SnapRaid? I'm getting a Kernel Oops while running 'snapraid sync'.

 

Steps were:

1. Flash Armbian_20.08.8_Helios64_buster_legacy_4.4.213.img to a microSD

2. Follow install via usb serial

3. apt update, apt upgrade

4. Install OMV via armbian-config

5. Install Snapraid via web ui

6. Config snapraid drives via webui

7. Run snapraid sync a terminal (left running)

 

It will get the Oops at anywhere between 2% and 60%

 

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42386.870707] Internal error: Oops: 96000004 [#1] SMP                                                                      

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.110416] Process snapraid (pid: 10333, stack limit = 0xffffffc0e50ac000)                                              

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.112203] Stack: (0xffffffc0e50afc20 to 0xffffffc0e50b0000)

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.113881] fc20: ffffffc0e50afca0 ffffff80081973c8 0000000000000000 ffffffc0e50afde0                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.115757] fc40: ffffffc0e50afe08 ffffffc02beb41c8 ffffffc0eb6bcf00 ffffffc02beb4030                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.117615] fc60: 0000000000000000 0000000000000000 ffffff8008bc2000 ffffffc0e8ab8000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.119481] fc80: 0000000000000000 0000000000001000 ffffffbdc2b3f140 0000000000000000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.121331] fca0: ffffffc0e50afcf0 ffffff800827d678 ffffffc02beb4030 0000000000040000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.123169] fcc0: ffffffc0e50afde0 0000000000000000 ffffffc0e50afe08 ffffffc0eb6bcf00                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.125021] fce0: ffffffc02beb40f0 0000000000000000 ffffffc0e50afda0 ffffff80081f9f6c                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.126848] fd00: ffffffc0eb6bcf00 ffffffc0e50afeb8 0000000000040000 00000056107ee300   

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.128690] fd20: 0000000000040000 0000000000000015 000000000000011d 0000000000000044                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.130539] fd40: ffffff8008bc2000 ffffffc0e8ab8000 0000000000000000 0000000000000081                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.132375] fd60: 0000000000000001 0000007feaf251c4 0000000000000001 0000007feaf251b8                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.134206] fd80: 0000007feaf25198 0000000000000062 ffffff8008bc2000 ffffffc0e8ab8000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.136036] fda0: ffffffc0e50afe30 ffffff80081fa820 ffffffc0eb6bcf00 0000000000040000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.137870] fdc0: 00000056107ee300 ffffffc0e50afeb8 00000056107ee300 0000000000040000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.139695] fde0: ffffffc0eb6bcf00 000004ebec540000 0000000000000000 ffffffc0e50afd54                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.141508] fe00: 0000000000000000 ffffff8000000001 0000000000031000 000000000000f000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.143342] fe20: ffffffc0e50afdd0 0000000000000001 ffffffc0e50afe70 ffffff80081fb3c0                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.145162] fe40: 000004ebec540000 ffffffc0eb6bcf01 ffffffc0eb6bcf00 00000056107ee300

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.146998] fe60: 0000000000040000 00000040eec83000 0000000000000000 ffffff8008082f30                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.148831] fe80: 0000000000000000 00000040eec83000 ffffffffffffffff 0000007f9acc5bcc                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.150653] fea0: 0000000080000000 0000000000000015 000000000000011d 000004ebec540000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.152478] fec0: 0000000000000004 00000056107ee300 0000000000040000 000004ebec540000                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.154299] fee0: 0000000000000000 0000007f9580c8e0 0000007f9580c0e0 0000000000000001                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.156123] ff00: 0000000000000044 00000056107ee300 0000000000000001 0000000000000080                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.157933] ff20: 0000007feaf2519c 0000000000000001 0000007feaf251c0 0000007feaf251a0                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.159732] ff40: 000000556c1501f0 0000007f9acc5b58 000000000000010f 0000000000000004                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.161538] ff60: 000004ebec540000 0000000000040000 00000056107ee300 0000007f9580c1e0                                    

Message from syslogd@localhost at Oct 14 08:57:16 ...                                                                               
 kernel:[42387.163333] ff80: 0000007f9acde000 0000007f9adc0f10 0000007f9580c2a0 0000007feaf24e80        

Message from syslogd@localhost at Oct 14 08:57:16 ...
 kernel:[42387.165142] ffa0: 0000007f9acde000 0000007f9580b910 0000007f9acc5bb0 0000007f9580b910

Message from syslogd@localhost at Oct 14 08:57:16 ...
 kernel:[42387.166959] ffc0: 0000007f9acc5bcc 0000000080000000 0000000000000004 0000000000000044

Message from syslogd@localhost at Oct 14 08:57:16 ...
 kernel:[42387.168791] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000

Message from syslogd@localhost at Oct 14 08:57:16 ...
 kernel:[42387.203922] Code: 12001c42 39003fe2 34fffa20 17ffffb3 (b9400005)

 

Any ideas? Kernel? SnapRaid?

Link to comment
Share on other sites

@KiSMI had the same kind of issue with the legacy image. It seems anything that puts a constant load on the system eventually causes a kernel crash, and sometimes a reboot.

The current image (kernel 5.8) however is rock solid. I've been using it now for 2 days and really stressing both the CPU and disks on my Helios64 without a single problem.

Link to comment
Share on other sites

[mention=16310]KiSM[/mention]I had the same kind of issue with the legacy image. It seems anything that puts a constant load on the system eventually causes a kernel crash, and sometimes a reboot.
The current image (kernel 5.8) however is rock solid. I've been using it now for 2 days and really stressing both the CPU and disks on my Helios64 without a single problem.
I downclocked the cpu to 1.6ghz and constrained unrar (which caused my crashes) to two cores. I am on 5.8

I am stable since.

Maybe its time for a new cpu and hdd stress test to see if it works now regardless of load.

Gesendet von meinem CLT-L29 mit Tapatalk

Link to comment
Share on other sites

2 hours ago, aprayoga said:

Armbian 20.08.10 has been released with eMMC boot fixed.
Please do a fresh install. If you want to boot from eMMC, you can transfer using armbian-config > System > Install > 2 Boot from eMMC - system on eMMC

 

Cool, very good news!
Is a fresh install from "20.08.8" also urgently necessary or can we also upgrade to "20.08.10" with an apt-get upgrade?

Link to comment
Share on other sites

Controlling the LEDs.

 

Hello, I am looking for the proper way to control the LEDs. (box facing front next to the TV etc.)

Operating System: Armbian 20.08.9 Buster
Kernel: Linux 5.8.13-rockchip64

 

What I get is :

 

root@helios64:/# echo "0" > /sys/devices/platform/io-gpio-leds/leds/helios64:blue:hdd-status/max_brightness
-bash: /sys/devices/platform/io-gpio-leds/leds/helios64:blue:hdd-status/max_brightness: Permission denied

 

 

:unsure:

 

Link to comment
Share on other sites

39 minutes ago, Werner said:

 

 

thanks for the feedback.
Will be available again after about 24h via apt-get.
Currently the 20.08.9 is still offered...

 

root@helios64:~# apt list --upgradable
Listing... Done
armbian-config/buster,buster 20.08.9 all [upgradable from: 20.08.8]
armbian-firmware/buster,buster 20.08.9 all [upgradable from: 20.08.8]
linux-buster-root-current-helios64/buster 20.08.9 arm64 [upgradable from: 20.08.8]
root@helios64:~#

 

 

edit:

the new wikis are even already online :thumbup:...

https://wiki.kobol.io/helios64/install/emmc/

Link to comment
Share on other sites

I've installed latest armbian buster 20.08.10.

 

I want to install kernel headers, but the package is not available for helios kernel?

 

╭─root@helios64 /lib/modules/5.8.14-rockchip64
╰─➤  apt install linux-headers-$(uname -r)
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-headers-5.8.14-rockchip64
E: Couldn't find any package by glob 'linux-headers-5.8.14-rockchip64'
E: Couldn't find any package by regex 'linux-headers-5.8.14-rockchip64'

 

Is there a way to build this package? Why is it not available in the repo?

Link to comment
Share on other sites

9 hours ago, aprayoga said:

Armbian 20.08.10 has been released with eMMC boot fixed.
Please do a fresh install. If you want to boot from eMMC, you can transfer using armbian-config > System > Install > 2 Boot from eMMC - system on eMMC

only through a fresh install?

i would have preferred f2fs. for flash memory it has a way better durability.

anyway... thank you. i wont write much there anyway - all data is in docker volumes on hdd

Link to comment
Share on other sites

1 hour ago, raoulh said:

Why is it not available in the repo?


Because packages needs up to 24h before they are transmitted around the mirrors. Then package list is updated. And then this will work for you.

 

Patience and perhaps some support? This service is almost entirely paid from our own pockets so complaining is not an option :P

Link to comment
Share on other sites

Idk if these questions are within the scope of this thread, but I'm curious about a few things regarding thermals on the Helios64, if someone from Kobol could clarify:

- What is the expected temperature range for this SoC?
- How does the heatsink interface with the SoC? Pads, paste?

- Does the heatsink also make contact with any other chips around the CPU?

- Would it benefit in any way from a "re-paste" with high performance thermal paste?

 

I could, of course, just disassemble mine and find out for myself, but I figured I would ask first.

Link to comment
Share on other sites

14 hours ago, aprayoga said:

Armbian 20.08.10 has been released with eMMC boot fixed.
Please do a fresh install. If you want to boot from eMMC, you can transfer using armbian-config > System > Install > 2 Boot from eMMC - system on eMMC

 

@aprayogaThe installation of a fresh 20.08.10 image to emmc using armbian-config and to boot from emmc works perfectly. Thank you.

 

root@helios64:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.8G     0  1.8G   0% /dev
tmpfs           381M  5.3M  375M   2% /run
/dev/mmcblk1p1   15G  1.6G   12G  12% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           1.9G  4.0K  1.9G   1% /tmp
/dev/zram0       49M  160K   45M   1% /var/log
tmpfs           381M     0  381M   0% /run/user/0

 

P.S.: The way to install Armian to emmc with a u-boot only image as described here https://wiki.kobol.io/helios64/install/emmc/ did not work for me. I tried it using macOS, Ubuntu 20.04 and Windows. The issue is that Helios64 does not show up as an USB Drive.

Link to comment
Share on other sites

On 10/12/2020 at 7:58 PM, erikced said:

Thanks for the help both of you, unfortunately it doesn't seem to work. I've both attempted to configure fancontrol and setting the values manually., I can see that the values of /dev/fan-{p6,p7}/pwm1 change but that doesn't make the actual fans spin any faster or slower. I've also tried swapping the fans between P6 and P7 and confirmed that both work, and the fan connected to P7 always spins at a constant speed (a little slower on battery power than when the PSU is connected) whereas the fan connected to P6 usually spins for about a second then stops.

 

Could you contact us to support@kobol.io and see how we can help you from there in case there is a need to return the board.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines