The EspressoBin: Something completely different? // Review


Booting

EspressoBin have provided a quick start tutorial along with a pre-formatted SD card. This is a good idea, because loading up an O/S currently isn’t as straightforward as burning an image to the SD card and will throw off a lot of novice users.

All you need is Ethernet, USB console and power. However, there’s a bit of an issue here. Notice this LED lights up when I apply power.Doing the same without DC power, lights up the same LED, which means the USB bus is powering the board in some way.

Looking at the schematics, it seems that either the 12v rail is being back powered, or the schematics are wrong for the LED indicator.Since the USB 5v rail is powering all the other voltage rails, then LED2, or LED1 would light up when the USB cable is connected.Either way, the CPU won’t have enough power to run the board, and will only boot up properly when the DC power jack is connected. The LED will glow brighter as well indicating a higher current flowing through it.

Testing this theory out: With the DC jack in, I was correctly seeing 12v and 5v in the right spot.

However, removing the DC jack saw the 12v line drop to a little under 5v. This means that the 12v line is being back-powered in some way and is the reason for the LED being dimmer.

Essentially, it will not boot until you have 12v in.

Logging in was fairly simple, the board will appear as a serial USB device and you’re presented with an install of Ubuntu 16.04.You’ll see a bunch of network devices already configured up. Along with the dual core Cortex-A53 Armada CPU.


Testing GPIOs

Since this board has a bucket load of GPIOs I went to see what was available. This is when the trouble started. I started seeing kernel crashes constantly, happening a couple of minutes in to boot.

Turns out it was a script attempting to change the CPU governor from the default “performance” to “ondemand”. Clearly there’s something wrong with the kernel module here.

So I simply disabled this from running using systemd, as I wanted performance mode anyway.

systemctl disable ondemand.service
systemctl stop ondemand.service

So, finally time for some GPIO tests. Turns out there’s no SPI available, but there’s I2C and a bucket load of GPIOs.Remember that these outputs are 1.8v logic levels, so driving an LED will result in a dim output. You can connect the LED to the 5 or 3.3 volt line and then toggle the GPIO low, but when the GPIO is high there will still be 3.2 or 1.5 voltage drop across it. Not particularly good.

Testing other GPIOs is something for a review update, as my stock of logic level converters were being used elsewhere.

Network Tests

So, moving on to network tests. I was surprised that I was seeing only 509 Mb/s on TCP throughput. It is slow and should have been faster.However, UDP tests showed up a fairly low jitter.So the low TCP throughput was possibly due to the fact that software bridging was enabled. This is something else I need to look into for the review update.