lupus

u-boot 17.08.1 flash images for all combinations of Marvell supported CPU/DDR3 frequencies (600/600, 800/800, 1000/800, 1200/750)
 
With kind support of @Igor and @aldzune I could build and test u-boot 17.08.1 and 17.06.3 flash images for all frequency combinations indicated above (boot snippets 17.08: https://pastebin.com/kKTvP5sx and 17.06: https://pastebin.com/8DZ37Wti , available functions: https://pastebin.com/kN5WBjW9 ). 
 
The flash-image.bin files (u-boot-images.tar.gz are attached below) just have to be resident in the root directory of a USB stick attached to the Espressobin and they can be flashed at the u-boot prompt:
 
Marvell>> bubt flash-image-XXX_YYY.bin spi usb       
(XXX: CPU Frequency, YYY: DDR3 Frequency)
 
'ARMBIAN 5.32.170817 nightly Debian GNU/Linux 9 (stretch) 4.4.82-mvebu64' boots smoothly in all 4 scenarios (see i.e. https://pastebin.com/KkZsU8sk ). (A static IP address is assigned in /etc/network/interfaces to get rid of the 'raise network interface' issue)
 
EDIT:
With the new firmware I receive I/O errors after some time while accessing the sd card.
The firmware needs to be properly tested by Marvell / Globalscale Technologies and made available by them.
Please contact Globalscale Technologoies / Marvell if you are interested in a more recent firmware.
 

u-boot 17.08.1 flash images for all combinations of Marvell supported CPU/DDR3 frequencies (600/600, 800/800, 1000/800, 1200/750)
 
With kind support of @Igor and @aldzune I could build and test u-boot 17.08.1 and 17.06.3 flash images for all frequency combinations indicated above (boot snippets 17.08: https://pastebin.com/kKTvP5sx and 17.06: https://pastebin.com/8DZ37Wti , available functions: https://pastebin.com/kN5WBjW9 ). 
 
The flash-image.bin files (u-boot-images.tar.gz are attached below) just have to be resident in the root directory of a USB stick attached to the Espressobin and they can be flashed at the u-boot prompt:
 
Marvell>> bubt flash-image-XXX_YYY.bin spi usb       
(XXX: CPU Frequency, YYY: DDR3 Frequency)
 
'ARMBIAN 5.32.170817 nightly Debian GNU/Linux 9 (stretch) 4.4.82-mvebu64' boots smoothly in all 4 scenarios (see i.e. https://pastebin.com/KkZsU8sk ). (A static IP address is assigned in /etc/network/interfaces to get rid of the 'raise network interface' issue)
 
EDIT:
With the new firmware I receive I/O errors after some time while accessing the sd card.
The firmware needs to be properly tested by Marvell / Globalscale Technologies and made available by them.
Please contact Globalscale Technologoies / Marvell if you are interested in a more recent firmware.
 

Openssl speed performance of Espressobin with kernel 4.12.1-ebin and security offload enabled:
 
Configuraton options used for the kernel are: 'CONFIG_CRYPTO_HW=y'  and  '# CONFIG_CRYPTO_DEV_MARVELL_CESA is not set'
(CPU frequency is assumed to be 1000MHz, cpufreq support is currently not enabled)
root@ebin:~# cat /proc/version Linux version 4.12.1-ebin-g4b13ed5-dirty (ubuntu@ebin) (gcc version 6.3.0 20170519 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) ) #1 SMP PREEMPT Wed Jul 12 16:25:39 UTC 2017 root@ebin:~# openssl speed -elapsed -evp aes-128-cbc root@ebin:~# openssl speed -elapsed -evp aes-192-cbc root@ebin:~# openssl speed -elapsed -evp aes-256-cbc OpenSSL 1.1.0f 25 May 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. combined output: Espressobin / Marvell 3720 @ 1000MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 68509.24k 216097.11k 453277.35k 649243.99k 741862.06k 748459.35k aes-192-cbc 65462.17k 194529.30k 375030.70k 503817.22k 559303.34k 563014.31k aes-256-cbc 63905.67k 181436.03k 328664.06k 423431.51k 462012.42k 464972.46k I wonder how the results will change if the Marvell Security Engine is enabled ...
 
Update:
Please find attached the content of /proc/crypto : https://pastebin.com/ub4J4AiG 

ODROID HC1 Mini Review
 
ODROID XU4 is one of the most powerful boards Armbian supports (due to being a big.LITTLE design with 4 x A15@2GHz and 4 x A7@1.4GHz). Though the SoC is a bit old performance is still impressive, the SoC features 2 independent USB3 ports (on XU3/XU4 one is connected to an USB Gigabit Ethernet chip, the other to an internal USB3 hub providing 2 USB3 receptacles) but in the past many users had troubles with USB3 due to
 
cable/connector problems (the USB3-A receptacle specification/design is a total fail IMO, unfortunately we've still not USB-C everywhere) underpowering problems with Hardkernel's Cloudshell 1 or XU4 powered disk enclosures and also some real UAS issues with 4.9 kernel (UAS --> USB Attached SCSI, a way more efficient method to access USB storage compared to the old MassStorage protocol)  
Hardkernel's answer to these issues was a stripped down XU4 version dropping the internal USB hub, display and GPIO support but adding instead a great performing and UAS capable USB-to-SATA bridge (JMS578) directly to the PCB so no more cable/contact issues, no more underpowering and no more UAS hassles with some disk enclosures (that contain a broken SATA bridge or combine a working UAS capable chip with a branded/broken firmware).
 
Thanks to Hardkernel I received a developer sample a week ago and could test/optimize already. I skip posting nice pictures and general information since as usual everything available at CNX already: just take a look here and there (especially take the additional hour to read through comments!).
 
So let's focus on stuff not already covered:

 
 
On the bottom side of the PCB in this area the Exynos 5422 SoC is located and attached with thermal paste to the black aluminium enclosure acting as a giant heatsink. While this works pretty well the octa-core SoC also dissipates heat into the PCB so if you plan to continously let this board run under full load better check temperature of the SD card slot if you're concerned about the temperature range of the SD card used Green led used by JMS578, starts to blink with disk activity and might be better located next to SD card slot on a future PCB revision for stacked/cluster use cases Blue led used as heartbeat signal by default (adjustable --> /sys/class/leds/blue/trigger but only none, mmc1 and heartbeat available, no always-on) Red led (power, lights solid when board is powered on) Drilled hole to fix a connected 2.5" disk. I didn't find a screw of the necessary length -- few more mm are needed than normal -- so I hope Hardkernels adds one when shipping HC1 to securely mount disks (7mm - 15mm disk height supported) Not an issue (was only one for me)! Hardkernel responded: 'We’ve been shipping the HC1 with a machine screw (M3 x 8mm) except for several early engineering samples. So all new users will receive the screw and they can fasten the HDD/SSD out of the box.'  
In my tests I found it a bit surprising that position of the heatsink fins doesn't matter that much (one would think with heatsink fins on top as shown on the right above reported temperatures would be a lot lower compared to the left position but that's not the case -- maybe 1°C difference -- which is also good news since the HC1 is stackable). The whole enclosure gets warm so heat disspation works really efficient here and when running some demanding benchmarks on HC1 and XU4 in parallel HC1 always performed better since throttling started later and was not that aggressive.
 
I had a few network problems in my lab the last days but could resolve them and while testing with optimal settings I decided also to move the usb5 interrupt (handling the USB3 port to which the USB Gigabit Ethernet adapter on ODROID XU3/XU4/HC1/HC2/MC1 is connected) from cpu3 (little) to cpu7 (big core):

As a quick comparison performance with same OS image but with XU4 and same SSD in an external JMS576 enclosure this time:
 
Tested with our Armbian based OMV image, kernel 4.9.37, ondemand cpufreq governor (clocking little/big cores down to 600 MHz when idle and allowing 1400/2000 MHz under full load), some ondemand tweaks (io_is_busy being the most important one) and latest IRQ affinity tweak. The disk I tested with is my usual Samsung EVO840 (so results are comparable with numbers for other Armbian supported devices -- see here). When combining HC1 with spinning rust (especially with older notebook HDDs) it's always worth considering adjusting cpufreq settings since most HDDs aren't that fast anyway so you could adjust /etc/default/cpufrequtils and configure there for example 1400 MHz max limiting also the big cluster to 1.4 GHz max which won't hurt performance with HDDs anyway but you'll have ~3W less consumption with full performance NAS workloads.
 
While this is stuff for another review it should be noted that DVFS (dynamic voltage frequency scaling) has a huge impact on consumption especially with higher clockspeeds (allowing the cores to clock down to 200 MHz instead of 600 MHz somewhat destroys overall performance but saves you only ~0.1W on idle consumption while limiting the big cluster's maximum cpufreq from 2000 MHz down to 1400 MHz saves you ~3W under full load while retaining same NAS performance at least when using HDDs). Also HDD temperature is a consideration since the giant heatsink also transfers some heat back into a connected disk though with my tests this led to a maximum increase of 7°C (SSD temperature read out via SMART after running a heavy benchmark on HC1 comparing temperatures on SSD attached to HC1 and attached to a XU4 where SSD was lying next to the board).
 
People who want to run other stuff on HC1 in parallel might think about letting Ethernet IRQs being handled by a little core again (reverting my latest change to move usb5 interrupts from cpu3 to cpu7) since this only slightly affects top NAS write performance while leaving the powerful big cores free to do other stuff in parallel. IRQ/SMP/HMP affinity might become a matter of use case on HC1 so it's not easy to find settings that work perfect everywhere. To test through all this stuff in detail and to really give good advises wrt overall consumption savings I lack the necessary equipment (would need some sort of 'smart powermeter' that can feed the results in my monitoring system) so I'll leave these tests for others.
 
So let's finish with first preliminary conclusions:
 
HC1 is a very nice design addressing a few of XU3/XU4 former USB3 issues (mostly related to 'hardware' issues like cable/contact problems with USB3-A or underpowering) Heat dissipation works very well (and combining this enclosure design with a huge, slow and therefore silent fan is always an option, Hardkernel evens sells a large fan suitable for 4 HC1 or MC1 units) The used JMS578 bridge chip to provide SATA access is a really good choice since this IC does not only support UAS (USB Attached SCSI, way more efficient than the older MassStorage protocol and also the reason why SSDs perform twice as fast on HC1 now with 4.x kernel) but also SAT ('SCSI / ATA Translation') so you can make use of tools like hdparm/hdidle without any issues and also TRIM (though software support is lacking at least in 4.9 kernel tested with) Dealing with attached SATA disks is way more reliable than on other 'USB only' platforms since connection/underpowering problems are solved Only downside is the age/generation of the Exynos 5422 SoC since being an ARMv7 design it's lacking for example 'ARM crypto extensions' compared to some more recent ARM SoCs which can do stuff like AES encryption a lot more efficient/faster  
Almost forgot: Software support efforts needed for HC1 (or the other variants MC1 or HC2) are zero since Hardkernel kept everything 100% compatible to ODROID XU4  
 
Edit: Updated 'screw situation' after Hardkernel explained they ship with an M3/8mm screw by default
 

I have tested kernel 4.4.79-mvebu64 from beta.armbian.com - it runs fine and is rock stable. 
 
Thanks to @umiddleb I have access to mainline kernels for the espressobin - I tried 4.12.1-ebin and 4.13.0-rc4-ebin. They are booting from SD and SATA ( see i.e. https://pastebin.com/jYsrkypw ). 
 
Unfortunately the Helios LanTest crashes renders the system on both 4.12 and 4.13 unresponsive. (I have recompiled Netatalk, but to no avail)
Could this be related to clock frequencies selected ?
 
Booting the Armbian Ubuntu Image with any kernel is very often interrupted by a job for raising network interfaces: "[**    ] A start job is running for Raise ne... interfaces (1min 41s / 5min 4s)".  Could this be fixed ?
 
Update:
As a stability test I compiled squid3 on 4.13.0-rc4-ebin without any problems (both cpus fully loaded for about an hour).
Helios LanTest does not complete since espressobin stops responding over the network but it is still accessible via the console.
Mainline kernels seem to work well, but network interfaces need to be fixed.
Ubuntu 16.04.3 LTS espressobin ttyMV0 espressobin login: root Password: Last login: Mon Aug 14 11:47:57 CEST 2017 on ttyMV0 _____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.13.0-rc4-ebin-130271-gabe3c92 System load: 0.04 0.18 0.14 Up time: 8 min Memory usage: 16 % of 992MB IP: 192.168.240.42 HDD temp: 30??C Usage of /: 5% of 110G storage/: 5% of 110G [ General system configuration: armbian-config ] root@espressobin:~# ping google.com ping: unknown host google.com  

The puzzle seems to be solved - the ondemand governor does not scale up the cpu frequencies as expected.
Armbianmonitor -m always displays a maximum of 200MHz as the current cpu frequency:
root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 15:26:36: 200MHz 0.16 13% 3% 9% 0% 0% 0% 15:26:41: 0MHz 0.14 13% 3% 9% 0% 0% 0% 15:26:46: 200MHz 0.13 13% 3% 9% 0% 0% 0% 15:26:51: 200MHz 0.20 13% 3% 9% 0% 0% 0% 15:26:56: 0MHz 0.39 14% 3% 9% 0% 0% 1% 15:27:01: 0MHz 0.36 14% 3% 9% 0% 0% 1% 15:27:07: 200MHz 0.41 14% 3% 9% 0% 0% 1% 15:27:12: 200MHz 0.38 14% 3% 9% 0% 0% 1% 15:27:17: 200MHz 0.35 14% 3% 9% 0% 0% 1% 15:27:22: 0MHz 0.32 14% 3% 9% 0% 0% 1% 15:27:27: 200MHz 0.29 14% 3% 8% 0% 0% 1% 15:27:32: 200MHz 0.27 14% 3% 8% 0% 0% 1% Manually setting the frequency of both cpus to 1GHz leads to expected results of iperf3:
root@espressobin:~# cpufreq-set -c 1 -d 1000000 -u 1000000 -g performance root@espressobin:~# cpufreq-set -c 0 -d 1000000 -u 1000000 -g performance root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 15:38:48: 1000MHz 0.15 8% 2% 3% 0% 0% 1% 15:38:53: 1000MHz 0.13 8% 2% 3% 0% 0% 1% 15:38:58: 1000MHz 0.12 7% 2% 3% 0% 0% 1% 15:39:04: 1000MHz 0.19 8% 2% 3% 0% 0% 1% 15:39:09: 1000MHz 0.26 8% 2% 3% 0% 0% 1% 15:39:14: 1000MHz 0.24 8% 2% 3% 0% 0% 1% MacBookPro: admin$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 4] local 192.168.240.41 port 49642 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 73.5 MBytes 616 Mbits/sec [ 4] 1.00-2.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 108 MBytes 904 Mbits/sec [ 4] 3.00-4.00 sec 105 MBytes 881 Mbits/sec [ 4] 4.00-5.00 sec 105 MBytes 881 Mbits/sec [ 4] 5.00-6.00 sec 104 MBytes 874 Mbits/sec [ 4] 6.00-7.00 sec 106 MBytes 885 Mbits/sec [ 4] 7.00-8.00 sec 106 MBytes 885 Mbits/sec [ 4] 8.00-9.00 sec 106 MBytes 886 Mbits/sec [ 4] 9.00-10.00 sec 103 MBytes 867 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.00 GBytes 860 Mbits/sec sender [ 4] 0.00-10.00 sec 1.00 GBytes 860 Mbits/sec receiver iperf Done. MacBookPro: admin$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 4] local 192.168.240.41 port 49645 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 4] 1.00-2.00 sec 112 MBytes 936 Mbits/sec [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 4] 4.00-5.00 sec 112 MBytes 937 Mbits/sec [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec [ 4] 7.00-8.00 sec 112 MBytes 936 Mbits/sec [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec [ 4] 9.00-10.00 sec 112 MBytes 937 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec receiver iperf Done.  

Thanks to @lupus I don't have to wait for Amazon shipping my board since one is already on my desk. Firtst surprise: my ASM1062 in the background can not be used due to SATA connector placement. So then I'm going to test AP functionality instead with a AR9380 3x3 MIMO Wi-Fi mPCIe card ($9 on eBay)

There are only specific frequencies supported with the current system:
root@espressobin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 200000 250000 500000 1000000 However, cpufrequtils is currently configured to use another maximum value:
root@espressobin:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=200000 MAX_SPEED=800000 GOVERNOR=ondemand I have changed MAX_SPEED to 1000000 but unfortunately espressobin does not boot reliably anymore (crashes upon login).
 
I have received my order of 10 espressobin this week ($49 each plus shipping) - I still have 7 to give away for the price I have paid. I have sent to you a PM with my contact details in any case ...

I have installed Netatalk 3.1.11 and tried the Helios Lan Test. The storage used by netatalk is an SSD (OCZ Vertex 128G) attached to the SATA port of espressobin (see the test results below).
 
Additionally, I manually uploaded a 2260MB file via the macOS finder (afpd) to espressobin in 52s (43MB/s) and downloaded it again to a MacPro in 20s (113 MB/s).
I guess that the write speed is limited by the SSD - read speed of netatalk/espressobin is pretty impressive ...
 
I have used the latest Armbian image (Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z) - If you have a more recent image to test, please let me know.
 
 

Power consumption of espressobin during the boot process is between 4.5 - 5.0 W.
I am running Armbian on SD - idle power consumption is 3.0 W (ondemand governor).
Consumption rises to 3.6 W while compiling source code using both kernels ...
(Armbian already runs perfectly stable)
root@espressobin:# cat /proc/version Linux version 4.4.73-mvebu64 (root@devel) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #9 SMP PREEMPT Sun Jun 25 22:02:55 CEST 2017 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: 50.0 us. 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 current policy: frequency should be within 200 MHz and 800 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 250 MHz. cpufreq stats: 200 MHz:83.97%, 250 MHz:8.44%, 500 MHz:7.09%, 1000 MHz:0.51% (998) 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: 50.0 us. 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 current policy: frequency should be within 200 MHz and 800 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 250 MHz. cpufreq stats: 200 MHz:83.97%, 250 MHz:8.44%, 500 MHz:7.09%, 1000 MHz:0.51% (998)  

I realised today that I have the same issue - here is how to solve it
(I am running Jessie with Kernel 4.7.3 and sysv-init - not systemd)
 
The problem is that /etc/init.d/armhwinfo starts before /etc/init.d/ramlog.
 
You can change that in the following way:
 
1.) add ramlog to Required-Start and Required-Stop in /etc/init.d/armhwinfo:
 
#!/bin/bash
### BEGIN INIT INFO
# Provides:          armhwinfo
# Required-Start:    ramlog
# Required-Stop:     glibc ramlog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Armbian gathering hardware information
### END INIT INFO
  2.) enter the following commands as root:   dpkg-reconfigure insserv update-rc.d armhwinfo defaults shutdown -r now        # reboot at least two times   Cheers, lupus