ebin-dev

So the HDD LEDs are really dimmed as shown in the video linked above by @djurny. Does that mean that there is in fact a way to dim the LEDs contrary to what is stated in the other thread ?

Some of you may be interested to not only store your data on Helios64 but to also run other services on it - such as home automation. One of the popular platforms for home automation in Europe - and in Germany in particular - is "Homematic". They opened up their ecosystem some time ago and allow others to implement their own components (some excellent examples from Jérôme are here). As of yesterday - with the latest commit - it is possible to run a virtualised "ccu3" base station for that platform, called pivccu, with support for a detached antenna module (RPI-RF-MOD) coupled to Helios64 (and Armbian 20.11 kernel 5.9.10) through a tcp/ip network using a dedicated circuit board developed by Alex Reinert (HB-RF-ETH). All of these projects are in the open domain. Actually not only Helios64 but also most of the SBCs running Armbian and a recent mainline kernel should now also be supported. There is a logic layer built into the pivccu system, but actions can also easily be automated using i.e. Node-Red or OpenHab2. Just to let you know: If you don't want to build stuff yourself, components could be purchased in Germany from i.e. elv and smartkram.

I send my disks to sleep with the following hdparm.service script: # cat /etc/systemd/system/hdparm.service [Unit] Description=hdparm sleep [Service] Type=oneshot ExecStart=/usr/sbin/hdparm -q -S 60 -y /dev/sda ExecStart=/usr/sbin/hdparm -q -S 60 -y /dev/sdb ExecStart=/usr/sbin/hdparm -q -S 60 -y /dev/sdc ExecStart=/usr/sbin/hdparm -q -S 60 -y /dev/sdd ExecStart=/usr/sbin/hdparm -q -S 60 -y /dev/sde [Install] WantedBy=multi-user.target

Actually I just picked up a suggestion to completely power off rails A and/or B by @gprovost three months ago ( see here ). It would be really appeciated if you implemented this feature. Once it is implemented I would try to seek a way to configure u-boot from linux such that the power to rails A and/or B is enabled/disabled upon the next reboot.

You can see the current root medium by typing 'df -h'. I think this was already addressed in this thread. If there is a system installed on emmc and on SD (SD inserted), then Helios64 will always boot from SD with the current bootloader (factory default settings). If the SD is not inserted, then the system will boot from emmc.

@aprayoga I am still interested in controlling the power of rail A and B. You mentioned that the power is controlled by the bootloader, but that the delay would be user configurable sometime. I would like to almost always power off rail A: In my use case rail A contains two hard disks supposed to alternatively back up the content of the SSDs in rail B - i.e once a day or even only once a week. The remaining time it would be beneficial to power off the hard drives in order to eliminate start/stop cycles and to make those drives inaccessible (protection against malware). Would there be a solution to make this user configurable - i.e by setting the delay to a very large number ?

Update to Armbian 20.08.21 Buster with Linux 5.8.17-rockchip64 was without any issues. The only little glitch I could find in syslog relates to Armbian hardware optimization: Oct 31 19:53:46 helios64 armbian-hardware-optimization[701]: /usr/lib/armbian/armbian-hardware-optimization: line 214: /proc/irq/$(awk -F":" "/eth0/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity: No such file or directory

You could try to boot from SD: although the boot order officially is SPI, EMMC, SD - Helios64 seems to boot from an inserted SD card although there is a bootable system installed on emmc. btw: I have downgraded to kernel 5.8.14.

The image "flash-image-DDR3-2g_2cs_7-600_600.bin" is not from the EspressoBin download page. Please try the current ones - they are from Sept. 2020 - branch 18.12-fixed. The ones you have tied were probably produced by the Armbian build system on the fly and are not tested.

@aprayoga Thanks for your reply. Your guess was just right - I have temporarily disconnected the UPS battery before I was experimenting with various system configurations so that I would be able to recover from a hanging system by disconnecting the main power. If you are improving the wiki pages - there are actually at least three topics of interest: 1.) how to enable "auto power on" 2.) how to use the RTC to automatically start the system at predefined times 3.) how to control powering hdd rails A and B

If the file /lib/systemd/system-shutdown/disable_auto_poweron is deleted "auto power on" does not happen - it sits just there and waits for the power button to be pressed. Would you please explain any further actions necessary to "enable auto power on" ? The information about the power staggering approach of HDD Rails A and B is very interesting. HDD rail A seem to refer to disks 3,4, and 5. They are powered up first. After about 10s disks 1 and 2 follow. Could you briefly explain how to enable/disable powering HDD rails A and B ?

@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.

see the previous posting

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.

I can confirm the issue with the USB-C cable. It does not fit into the USB-C port (the reason may just be the additional layer introduced by the label around the ports). The issue can be resolved by cutting away about 0.5 mm of the plastic around the plug at the end of the USB cable. It will then easily fit into the port. Otherwise I am very impressed by Helios64 - it is very well engineered - my congratulations to Kobol ! I am using the latest Armbian Buster image (Linux helios64 5.8.13-rockchip64 #20.08.8 SMP PREEMPT Mon Oct 5 15:59:02 CEST 2020 aarch64 GNU/Linux) - no issues so far in my use cases.

Or we are just missing a patch - the real CPU frequency as measured by 7zip seems to correspond to the selected DDR frequency. But would that help ? You still require a stable system.

Here are some additional tests with all current Armbian bootloader versions. The current Armbian buster image boots with all of them - none of the bootloader versions leads to crashes or requires a cumbersome recovery (at least on a V5_0_1 EspressoBin 1G - see below). It seems that everything works as expected with CPU_DDR frequencies 600_600 and 800_800. However, CPU frequency remains at 800 MHz if 1000_800 is loaded and is even reduced to 750MHz if DDR_Topology 1200_750 is loaded (according to 7zip, but cpufreq-info reports the correct maximum CPU frequency). So - stable operation is established with each of the four DDR_Topologies loaded, but a system with the current bootloader (compiled from Marvells sources) and a current kernel 5.8.6 simply throttle CPU speeds above 800MHz in order to maintain a usable system. I have the impression that this is a feature rather than a bug. It would be highly desirable that GlobalScaleTechnologies comments on these observations or stops advertising Armada 3720 based products as using "Marvell 64bit Dual Core ARM A53 Armada 3700 SOC clocked up to 1.2Ghz". Anyway - I have replaced my EspressoBin some time ago by a more suitable SBC ... DDR_Topology 600_600 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 338 595 595 595 595 595 595 595 DDR_Topology 800_800 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 421 794 789 794 794 793 793 793 DDR_Topology 1000_800 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 789 794 794 794 794 794 793 794 DDR_Topology 1200_750 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 747 748 743 748 748 746 747 747 root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:92.16%, 300 MHz:0.75%, 600 MHz:0.18%, 1.20 GHz:6.91% (179) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:92.16%, 300 MHz:0.75%, 600 MHz:0.18%, 1.20 GHz:6.91% (179)

The current Armbian buster image with kernel 5.8.6 (thanks to @Igor) works nicely in combination with the current Armbian bootloader - at least with CPU_DDR=800_800 on a V5_0_1 EspressoBin 1GB. 7Zip correctly reports a CPU frequency of 800 MHz: root@espressobin:~# cat /proc/version Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 794 794 794 794 794 794 794 794 I also tried the bootloader with CPU_DDR=1000_800. Armbian launches without issues, cpufreq-info correctly reports the maximum CPU frequency of 1000MHz, but 7zip still reports a CPU frequency of about 800 MHz: root@espressobin:~# cat /proc/version Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020 root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89% (309) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89% (309) root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 612 794 794 794 794 794 794 794

@umiddelb You can try my latest u-boot flash images (see below) - they were compiled on March 7th 2020. I have just used newer versions of the Linaro tools. @lsartory Historical remarks: There are two issues to be solved in the build system: a) A3700-Utils 18.12 in Marvell Repository does not provide a DDR_Topology for the DDR3 2GB EspressoBin and b) there is an error in DDR_Topology_6.txt related to the V7 2G Espressobin: it shoud specify ddr_mem_size_index=4 (1024MB) for the single chip size instead of 5. The second issue is corrected by using an amended DDR_Topology_6.txt in the Armbian Build system which is copied into place before building the flash files. The first issue was solved in a similar way using two different versions of DDR_Topology_2 - one for the DDR3 1G EspressoBin (DDR_Topology_2-1g) and the other one for the DDR3 2G EspressoBin (DDR_Topology_2-2g) copied into place as DDR_Topology_2 just before compiling the corresponding flash images. The A3700-utils-marvell/script/buildtim.sh did not need any adaptation. Edit: The u-boot flash images should be available by now on the EspressoBin download page.

Unfortunately there are no details about your board. Do you own a V5_0_1 EspressoBin with 2GB RAM (2 x 8Gbit DDR3, one on each side of the board) ?

@msmol I have corrected the error in DDR_Topology_6 as identified by @Rainbaby and recompiled flash, sata and uart images for the V7-2G EspressoBin (uboot version is still the same). Please let me know if the flash images now also work with the 2GB version of the V7 EspressoBin (download link). EDIT: download link changed to dl.armbian.com

@Igor In armbian-config on EspressoBin (Buster - fully updated und upgraded) there are currently not options for alternative kernels under System -> Other. I am currently on the nightly branch (Linux version 4.19.66-mvebu64). Edit: Switching back to stable kernels in armbian-config now leads to the installation of Linux version 4.19.85-mvebu64. Everything went fine without any issues. armbian-config now presents alternative kernels under System -> Other: either "legacy" kernel 4.14.135-mvebu64 or "next" kernel 4.19.56-mvebu64.

deleted

@sfx2000 What about the cooling system ? There would not appear to be any fan inside the housing. Passive cooling inside an essentially closed box ? I don't think this is going to work.

That is true - but EspressoBin is an exception - systemd-networkd is used instead: root@ebin:~# nmtui NetworkManager is not running. root@ebin:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether degraded configured 3 wan dsa degraded configured 4 lan0 dsa no-carrier configuring 5 lan1 dsa no-carrier configuring 6 br0 bridge routable configured 6 links listed. @StarSurfer The default configuration is DHCP=ipv4. So your router determines the ip address: root@ebin:/etc/systemd/network# cat 10-br0.network [Match] Name=br0 [Network] DHCP=ipv4 You may specify a static IP in 10-br0.network. According to this explanation the following should work (change the address according to your needs): root@ebin:/etc/systemd/network# cat 10-br0.network [Match] Name=br0 [Network] Address=10.1.10.9/24 Gateway=10.1.10.1 DNS=10.1.10.1 #DNS=8.8.8.8