ebin-dev Posted October 11, 2020 Posted October 11, 2020 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.
alchemist Posted October 11, 2020 Posted October 11, 2020 Hi, Do the SPI boot work? Can I install u-boot on SPI and then boot sda1 from SPI?
flower Posted October 11, 2020 Posted October 11, 2020 2 minutes ago, alchemist said: Hi, Do the SPI boot work? Can I install u-boot on SPI and then boot sda1 from SPI? Not yet. They are working on it
Carlos Hartmann Posted October 11, 2020 Posted October 11, 2020 (edited) 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 October 11, 2020 by Carlos Hartmann Further info
TDCroPower Posted October 11, 2020 Posted October 11, 2020 I had the same problem on my Mac. But with Windows and PuTTY it works perfectly.
gprovost Posted October 12, 2020 Author Posted October 12, 2020 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
aprayoga Posted October 12, 2020 Posted October 12, 2020 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 1
jbergler Posted October 12, 2020 Posted October 12, 2020 (edited) 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 October 12, 2020 by jbergler
antsu Posted October 12, 2020 Posted October 12, 2020 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.
erikced Posted October 12, 2020 Posted October 12, 2020 (edited) 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 October 12, 2020 by erikced
TDCroPower Posted October 12, 2020 Posted October 12, 2020 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/
KiSM Posted October 14, 2020 Posted October 14, 2020 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?
aprayoga Posted October 14, 2020 Posted October 14, 2020 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 2
Igor Posted October 14, 2020 Posted October 14, 2020 Images were updated few hours ago and are containing latest fixes. Update via apt will follow once mirrors are updated.
antsu Posted October 14, 2020 Posted October 14, 2020 @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. 1
flower Posted October 14, 2020 Posted October 14, 2020 [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.8I 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
TDCroPower Posted October 14, 2020 Posted October 14, 2020 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?
registr123 Posted October 14, 2020 Posted October 14, 2020 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
Werner Posted October 14, 2020 Posted October 14, 2020 56 minutes ago, TDCroPower said: 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?
TDCroPower Posted October 14, 2020 Posted October 14, 2020 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 ... https://wiki.kobol.io/helios64/install/emmc/
raoulh Posted October 14, 2020 Posted October 14, 2020 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?
antsu Posted October 14, 2020 Posted October 14, 2020 @raoulh The correct package name is linux-headers-current-rockchip64.
flower Posted October 14, 2020 Posted October 14, 2020 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
Igor Posted October 14, 2020 Posted October 14, 2020 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
flower Posted October 14, 2020 Posted October 14, 2020 16 minutes ago, Igor said: Patience and perhaps some support? This service is almost entirely paid from our own pockets so complaining is not an option just donated a little. thank you for this project! 1
antsu Posted October 14, 2020 Posted October 14, 2020 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.
barnumbirr Posted October 14, 2020 Posted October 14, 2020 14 minutes ago, antsu said: - What is the expected temperature range for this SoC? Operating temperature for the Rockchip RK3399K SoC is -20°C~85°C. Don't know about the rest of your questions as I haven't taken my Helios apart (yet ;) ). 1
ebin-dev Posted October 14, 2020 Posted October 14, 2020 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.
gprovost Posted October 15, 2020 Author Posted October 15, 2020 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.
Recommended Posts