ebin-dev

I can confirm that the following procedure updates u-boot on emmc without any issues:
 
# cd /usr/lib/linux-u-boot-current-helios64_21.02.3_arm64 # ls -la total 8404 drwxrwxr-x 2 root root 4096 Mar 9 11:01 . drwxr-xr-x 80 root root 4096 Mar 9 11:01 .. -rw-rw-r-- 1 root root 206844 Mar 8 15:55 idbloader.bin -rw-rw-r-- 1 root root 4194304 Mar 8 15:55 trust.bin -rw-rw-r-- 1 root root 4194304 Mar 8 15:55 uboot.img # dd if=idbloader.bin of=/dev/mmcblk2 seek=64 conv=notrunc # dd if=uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc # dd if=trust.bin of=/dev/mmcblk2 seek=24576 conv=notrunc # reboot now  

I am using the following modified version of an Armbian Script to rsync emmc to sd (replace UUIDs to match yours):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk0p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  

The next thing I would buy is a drop in replacement board for the helios64 with:
rk3588 ECC RAM  nvme PCI-e port 10GBase-T port

The next thing I would buy is a drop in replacement board for the helios64 with:
rk3588 ECC RAM  nvme PCI-e port 10GBase-T port

@NickSYou just need to change a single digit from 0 to 1 - see here.
 
Unfortunately you need to repeat that if /lib/systemd/system-shutdown/disable_auto_poweron is updated by Armbian.

I am using the following modified version of an Armbian Script to rsync emmc to sd (replace UUIDs to match yours):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk0p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  

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.
 

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

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  

No issues so far with Buster on EspressoBin.
Nextcloud is faster with PHP 7.3.4 -- I am thrilled.
 
_____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64 System load: 0.06 0.12 0.15 Up time: 8:04 hours Memory usage: 42 % of 990MB IP: 12.34.56.78 Usage of /: 18% of 908G  

@Jens Bauer @ManoftheSea @anubisg1
The MAC address of the bridge can be specified in 10-br0.netdev. This works without any issues in Stretch and in Buster (at least on a V5_0_1 EspressoBin). If you have problems with Ubuntu Bionic, then their implementation of systemd-networkd may be the reason.
 
# cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge MACAddress=XX:XX:XX:XX:XX:XX # 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 _____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64 System load: 0.15 0.13 0.11 Up time: 17:54 hours Memory usage: 37 % of 990MB Zram usage: 36 % of 495Mb Usage of /: 18% of 908G  

@Fan KunPeng Are you using the latest boot loader ?

@FlashBurn @spqr
 
Please find the updated bootloader here (u-boot is unchanged; WTMI is updated to 18.12.1) - it should solve the stability issues and  it works fine on my V5_0_1 EspressoBin (https://pastebin.com/xJCtLXsH). The recovery images are also updated: sata-images and uart-images.
 
Could you please test if your EspressoBin ist stable now and if you can apply the pending cpufreq and xtal kernel patch without creating any further issues ?
 
Edit: links updated ; images are now available through Armbian servers

I have updated the 18.12 branch with patches from current development stream. Please check if it improves the stability.
https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/commits/A3700_utils-armada-18.12

Since the patch is not working for all EspressoBins I would suggest to consider it a WIP or to delete it. Marvell already allocated resources in order to solve the issue. 
 
Edit: I have tested patched kernel 4.19.20 on three V5 EspressoBins - one used and two new ones. All of them produce the same issues (i.e. a kernel panic "Internal error: synchronous parity or ECC error" with bootloader 1000_800). With this patch applied we risk to lose the installed base of V3-V5 EspressoBins. It is simply not enough to just change parts of the cpufreq code - the problem has a wider scope and the bootloader probably needs some adjustments too.

With kernel 4.12.1 and stock firmware 17.02 openssl performance was fine - with kernel 4.14.27 and firmware 17.10 (both versions compiled 15 March 2018 and 4 October 2017) openssl performance was degraded (see here).

We have produced a few minimalistic housings for the EspressoBin (120x42x81mm) with space for a 2.5" drive using a CNC molding cutter.
Passive cooling of the processor and topaz switch by thermal coupling to the housing works well (housing temperature 31 degrees, ambient temperature 20 degrees).




 
 

Your u-boot was not provided by Armbian - you can convince yourself by comparing it to the ones in the Archive (yours was compiled on June 1st, in timezone GMT +8 ...).
 
Your EspressoBin is equipped with a Macronix SPI - if you need to rescue it start from here or here.

So, I just checked that I could use the images in this folder to flash the current ones in its grand-parent one, and that I still was able to boot from the Armbian already installed in my SD card with a Macronix chip. Thanks a lot for these fixed images! 
 
Steps:
Had to use miniterm: miniterm --eol CR /dev/ttyUSB0 115200 rather than minicom. Minicom would interfere with the transfer from WtpDownload by trying to reopen the serial port once it had lost it; and then WtpDownload_linux would get interrupted. Set the jumpers for UART recovery and powered the board. In miniterm I hit enter until I got the E prompt, then entered "wtp". Then I ran the upload:  <path>/<to>/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E  
As my bootable SD card was in, the just-downloaded bootloader in RAM would quickly go and start Linux from the SD card. If your EspressoBIN is borked, you probably should just remove any boot device. In my case I didn't bother; I just restarted miniterm quickly after WtpDownload had finished and pressed enter a number of times to interrupt the boot sequence.
I plugged in a USB stick with flash-image-2g-2cs-1000_800.bin in it.
I flashed it to SPI:
Marvell>> bubt flash-image-2g-2cs-1000_800.bin spi usb Burning U-BOOT image "flash-image-2g-2cs-1000_800.bin" from "usb" to "spi" USB0:   Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1:   USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found reading flash-image-2g-2cs-1000_800.bin Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB     Updating, 8% 126859 B/s    Updating, 16% 127704 B/s    Updating, 31% 167458 B/s    Updating, 39% 155994 B/s 262144 bytes written, 593344 bytes skipped in 2.249s, speed 389342 B/s Done! I then powered the board off, switched the boot jumpers back to their default position, and powered it on again. The board booted Armbian from SD card as usual.
 

The problem with the Molex male power connector was solved with a soldering iron :-)) - the male power connector at the end of a sata power cable was replaced by a female one - a not so difficult task, since the pins can be removed from the female connector.
 
If there is some interest in these enclosures, I will try to find a company to produce and sell them (with an obligation to donate 1 USD/ 1 EUR to Armbian per housing sold). 

@Igor is working on it ... (my installation responds as expected):
# apt-get install armbian-config Reading package lists... Done Building dependency tree Reading state information... Done armbian-config is already the newest version (5.45). Edit: did you see this ?  You can install it from there:
https://github.com/armbian/config  

Debian server - mainline kernel - make sure you are on the stable branch and update your system with 'apt-get update && apt-get upgrade'.

The new Armbian flash-images are online now  (1g (1cs and 2cs), 2g and 512m versions were tested). All available CPU_DDR frequency combinations are there for all boards.
 
Most EspressoBins out there have 2 DDR memory chips (one on each side of the board). Select the 2cs firmware version for your board in this case. If you are an owner of a brand new 1G EspressoBin you may just have 1 DDR memory chip on board (see here). In that case you have to select the 1cs firmware version for your board.
 
The flash images were rebuilt with the following refreshed parts:
A3700-utils-marvell Armada-17.10.3
atfv1.3 armada-17.10.7
uboot armada-17.10.2
 
Stability issues are solved with these updated versions by a refined DDR RAM training algorithm (provided by Marvell).
 
With the new firmware installed you may need to enter the environment settings again (after a reset).
 
If you wish to boot using a load script you need to enter the following environment settings (boots from SD and USB):
setenv initrd_addr 0x1100000 setenv image_name boot/Image setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo \"... booting from SD\";setenv boot_interface mmc;else echo \"... booting from USB/SATA\";usb start;setenv boot_interface usb;fi;if test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' setenv bootcmd "run get_images; run set_bootargs; run load_script;booti "\$kernel_addr \$ramfs_addr \$fdt_addr saveenv  
If that does not work in your use case - you can use the following environment settings:
#Boot from SD: #with a legacy kernel on SD you have to change rootdev to /dev/mmcblk0p1 setenv boot_interface mmc setenv image_name boot/Image setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb setenv fdt_name_b boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk1p1" setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "F0:AD:4E:03:64:7F" setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name_a;ext4load mmc 0:1 $fdt_addr $fdt_name_b;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' saveenv #Boot from SATA: setenv boot_interface scsi setenv image_name boot/Image setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb setenv fdt_name_b boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/sda1" setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "F0:AD:4E:03:64:7F" setenv bootcmd 'scsi scan; scsi dev 0; ext4load scsi 0:1 $kernel_addr $image_name;ext4load scsi 0:1 $initrd_addr $initrd_image; ext4load scsi 0:1 $fdt_addr $fdt_name_a;ext4load scsi 0:1 $fdt_addr $fdt_name_b;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' saveenv  
@TaNGSoFT Thanks for the info about the crypto-safexcel engine.
 

The vendor provided flash image released this month can be downloaded from here and I have tested it on a 1G board. There are currently only two flash-images available (1G and 2G, 1000_800).
 
I have selected an EspressoBin board that was not able to run stable with 1000_800 anymore after being exposed to excessive thermal strain for at least an hour (running fully loaded without any cooling) while being exposed to a gnd loop (not by myself :-) ). However that board was still stable with Armbian firmware 800_800 afterwards (even with cpufreq enabled).
 
I can confirm that the new vendor provided flash image for the 1G EspressoBin solves the stability issue - the above board now seems to run stable with 1000_800 again. I have tested that with ARMBIAN 5.41.180208 nightly Debian GNU/Linux 9 (stretch) 4.14.23-mvebu64 (with cpufreq enabled).
That are good news.
 
However, a quick RAM speed test seems to indicate a 14% lower RAM speed.
 
You are invited to post your observations in this thread.
 
Edit: RAM speed is reduced by only 2% on other boards.

Thanks Tazz for the hint. I have constantly monitored Marvell sources on github but I did not see any changes relevant to EspressoBin since October last year.
 
I have made available my build scripts to Armbian deveopers last year - to rebuild EspressoBin firmware with the refreshed parts should only take a few minutes.
 
(Unfortunately my  build system is currently not working due to a hardware issue)