ebin-dev

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

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




 
 

@Igor Thank you for the update. I have just contacted our friends from Free Electrons - support for the Marvell Security Engine of the EspressoBin is probably finished within the next weeks and is exprected to be part of the crypto tree in Mainline 4.16. I`ll keep you informed.
 
I have just updated my EspressoBin with the latest nightly builds: unfortunately 'armbian-config' has disappeared - is someone working on it ?

For the ones who like to try the Armbian xenial default image (4.4.88) (cpufreq ondemand governor and systemd-networkd enabled) - installation instructions and a download link are here:
 
Get the Armbian image (Armbian download link), flash it to an sd card (Etcher is recommended) and insert it into EspressoBin.
Connect the USB cable to the micro USB port and establish a serial connection with a computer (see wiki).
Connect the 12V power supply to boot EspressoBin and press a key to stop the boot process in u-boot.
At the "Marvell>>" prompt enter the following instructions (environment) to change the environment settings (skip setenv ethaddr ...).
Enter "saveenv" and press the reset button - that's it (https://pastebin.com/fq326KR3).
 
You will be greeted by the Armbian welcome screen (user: root, password: 1234).
You are invited to post your comments in this forum.
 
Edit: Disconnect the USB cable for the serial connection a.s.a.p. if your computer is connected to a power grid.
        Use 'ssh root@<ipaddress>' instead of the console (or use a battery driven laptop if you wish to permanently use the console)
Edit: If your EspressoBin produces a kernel panic you need to flash u-boot with a lower CPU frequency (u-boot 17.10.1 flash images)
Edit: If you select a flash-image with another CPU frequency than 1000MHz you must adapt min/max values in /etc/default/cpufrequtils to available values displayed by 'cpufreq-info' and reboot (otherwise cpufreq will not work).
 
If you are happy with Armbian please consider a donation.
 

You can safely use one of the flash images to update your board to the very latest version now (u-boot 17.10.1, atf1.3-17.10 for the 512MB and 1GB version released a week ago, atf1.3-17.08 for the 2GB version) (flash-instructions are included) (nobody bricked a device with them)
 
The sources are available on Github and the build process is not complicated - you have explained it earlier in this forum. Official support for the 2GB EspressoBin is also expected soon.
 
May be I do not understand you correctly - but any further tests using a bootloader on SATA drives to confirm that the images are working do not seem to be necessary.
 
Once you have updated your board any new u-boot can be chainloaded using tftp to test its functionality - the process works (but not with the preinstalled u-boot / atf 17.02). 
 
Nevertheless, I will see what needs to be done to boot directly from SATA leaving SPI alone.

You can safely use one of the flash images to update your board to the very latest version now (u-boot 17.10.1, atf1.3-17.10 for the 512MB and 1GB version released a week ago, atf1.3-17.08 for the 2GB version) (flash-instructions are included) (nobody bricked a device with them)
 
The sources are available on Github and the build process is not complicated - you have explained it earlier in this forum. Official support for the 2GB EspressoBin is also expected soon.
 
May be I do not understand you correctly - but any further tests using a bootloader on SATA drives to confirm that the images are working do not seem to be necessary.
 
Once you have updated your board any new u-boot can be chainloaded using tftp to test its functionality - the process works (but not with the preinstalled u-boot / atf 17.02). 
 
Nevertheless, I will see what needs to be done to boot directly from SATA leaving SPI alone.

Network Manager does have its weaknesses and behaves sometimes erratic.  SBCs with more than one network interface such as the ClearFog Pro, ClearFog Base and  EspressoBin may require more complex configurations (i.e. firewalled router) - to realise that in a reliable way using Network Manager is a nightmare. Even bridged interfaces lead to erratic interruptions during boot.
 
One could switch to systemd-networkd - it is already installed and just needs to be configured. No more hassles with jobs for raising network interfaces  .
 
Interfaces wan, lan0 and lan1 are hot-pluggable and work with full speed (iperf3 results are as expected: 112MByte/s and 103MBytes/s in reverse direction). A working example configuration for bridged network interfaces is here:
#purge network manager: apt-get --purge autoremove network-manager #copy three lines to the interfaces file: cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback #start services and create a symbolic link to resolv.conf: sudo rm /etc/resolv.conf systemctl start systemd-networkd.service systemctl start systemd-resolved.service systemctl enable systemd-networkd.service systemctl enable systemd-resolved.service ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf #create the 5 network configuration files in /etc/systemd/network/ #(do not delete empty lines): cd /etc/systemd/network/ cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge cat 10-dhcp-br0.network [Match] Name=br0 [Network] DHCP=ipv4 cat 10-dhcp-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 cat 10-bridged-lan0.network [Match] Name=lan0 [Network] Bridge=br0 cat 10-bridged-lan1.network [Match] Name=lan1 [Network] Bridge=br0 #and restart systemd-networkd: systemctl restart systemd-networkd  

You can compile your own Armbian xenial image with headers (still without asm/*) but with cpufreq support:
apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build nano ./config/sources/mvebu64.conf #change the last digit in case 'default' to: KERNELBRANCH='branch:linux-4.4.52-armada-17.06' #change to: MAX_SPEED=1000000 ./compile.sh BOARD=espressobin BRANCH=default BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes INSTALL_HEADERS=yes RELEASE=xenial During kernel configuration select: CPU Power Management - CPU Frequency Scaling - Default Governor - ondemand
and you may disable other governors. Output is Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.87.img with cpufreq ondemand governor enabled..
 
More information about the Armbian build system can be found here: https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
EDIT: @lanefu  A commit for changing /config/sources/mvebu64.conf to default KERNELBRANCH linux-4.4.52-armada-17.06 and to MAX_SPEED=1000000 would avoid breaking cpufreq when updating Armbian xenial 4.4.73 images.