CubieTruck Metal Case Kit Getting Started Guide and Review

I’ve received CubieTruck Metal Case kit just over a month ago, but just like for Ubuntu on ODROID-XU3 Lite, the board could not get HDMI EDID info from my Panasonic TV, which led to a crash at boot time. CubieTech has now fixed the issue, so I’ve finally been able to complete the review with Cubieez (Cubie Easy) distribution, pre-installed on the board, and based on Debian 7.6. You can get the full hardware specs on my previous post, but the kits is comprised of four parts: CubieTruck development based on Allwinner A20 dual core processor, a rugged metallic enclosure, a 128GB SSD, and a 5,300 mAh battery acting as a UPS. I’ll start by showing how to setup the board, test SATA and Gigabit Ethernet performance,  check if the battery acts as expected, try to use the board as a desktop replacement with LibreOffice, Chromium, and so on, and run Phoronix Benchmark. I’ll also explain how to mvoe the rootfs from NAND flash to SSD to extract more performance from the kit.

Getting Started with CubieTruck Board

Even though the board is pre-loaded with Cubieez 2.1, it’s still good to know how to flash the image by yourself, and do the initial setup.

There are some tutorials for CuebiTruck, but the one dedicated to Cubieez is completely empty at the time of writing.

But the important part is to know that the firmware can be found @ http://dl.cubieboard.org/model/cubietruck/Image/Cubieez/ with images for HDMI or VGA output, and NAND flash or SD card boot.

So this is what I had to do to reflash Cubieez (Cubieez 2.2 has been released since then, probably with a fix with my HDMI issue):

You’ll need LiveSuit (Linux or Mac), or PhoenixSuit (Windows) to flash the firmware, which you can download here. I’ve already explained how to install LiveSuit to flash firmware on A80 OptimusBoard, and the procedure is the same for all Allwinner devices. Once the installation is complete simply run:

And load the uncompressed image (cubieez-ct-nand-hdmi-v2.1.img) as shown below:

Now connect a micro USB to USB cable between your computer, and CubieTruck OTG port, press the FEL button on the right side, power on the kit, and flash should complete automatically.

Then you can just reboot the board, and it should boot into LXDE, unfortunately for me, it did not work that way, and all I could see was the boot log on my HDMI TV.  So I asked some help on CubieBoard Google group, and got some help one or two days later pointing me in the right direction. However, it may have been better to ask on Cubieforums.com, these forums are more active than on Google group.

Nevertheless, the issue was a segfault reported in /var/log/Xorg.0.log:

[    47.423] (II) FBTURBO(0): using /dev/fb0

[    47.423] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support

[    47.423] (**) FBTURBO(0): Depth 24, (–) framebuffer bpp 32

[    47.423] (==) FBTURBO(0): RGB weight 888

[    47.423] (==) FBTURBO(0): Default visual is TrueColor

[    47.423] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0)

[    47.424] (II) FBTURBO(0): hardware:  (video memory: 16200kB)

[    47.424] (**) FBTURBO(0): Option “fbdev” “/dev/fb0”

[    47.424] (**) FBTURBO(0): Option “SwapbuffersWait” “true”

[    47.427] (II) FBTURBO(0): processor: ARM Cortex-A7

[    47.429] (EE) FBTURBO(0): Unknown EDID version 0

[    47.429]

[    47.430] Backtrace:

[    47.430]

[    47.431] Segmentation fault at address 0x8

[    47.432]

Fatal server error:

[    47.432] Caught signal 11 (Segmentation fault). Server aborting

[    47.432]

The bold line showed that my TV did not return EDID information, and fbturbo did not check for this case. So CubieTech sent me an updated fbturbo_drv.so, which I copied to  /usr/lib/xorg/modules/drivers/, and I was finally able to access the login prompt in LXDE. I believe this fix must be included in Cubieez 2.2 image.

You can login with cubie / cubieboard, or root / cubieboard. I normally prefer running the system as a user, and run sudo when needed, so I logged in with cubie user.

Cubieez features LXDE running on top of Debian 7.6 with Linux 3.4.79, and the default resolution is set to 1080p50, but you can click on Monitor Settings to change the resolution as needed.

The README recommends to run cubie-config in LXTerminal the first time, so let’s do that.

Expand Filesystem is only used for SD card images. Internationalisation Options lets you change the locale, timezone, and keyboard layout, and you can change the hostname, and enable/disable SSH in Advanced Options. Once you;’re done, select Finish, and you may have to reboot.

You’ll probably want to install some packages with apt-get or the Software Center, but the repositories are set to Spanish mirror, and changing the mirrors to one in your country may speed up download a lot. Changing from Spain to Thailand, increased the download speed with apt-get by 10 times in my case.

You can find the list of mirrors @ https://www.debian.org/mirror/list, once you have found the right mirror for your country, edit the source list:

And replace

by your country’s mirror. For example:

Finally refresh the system with:

You may want to install your favorite programs, for example:

I found some XMBC binaries for an earlier version of Cubieez, that you need to extract to the root of the system. You have to install some dependencies, then run XBMC as shown below:

But unfortunately XBMC will crash, so this version is not suitable for Cubieez 2.1/2.2.

Finally, the SSD included in the kit is not partitioned nor formatted, so it’s also something you’ll want to do, but I’ll explain that in the next section.

SSD SATA Performance and Gigabit Ethernet

CubieTruck is certainly not one of the fastest ARM Linux system currently available, but its SATA interface and Gigabit Ethernet port could make it one of the best platform for storing and moving data around.

First let’s prepare the SSD for testing. Most people will make a single partition, but since the SSD may be use for Android SATA testing as well in the future, I’ve create two partitions, one formatted with NTFS and the other with EXT-4. To create the partitions, start a Terminal windows in CubieTruck, and type:

Now create primary partition(s) with by selecting ‘n’,  and type the start and end of the partition. If you want a single partition, that’s easy as fdisk will select the start and end for you, and you can just press enter to confirm the choice. Finally press ‘w’ to write the partition table and exit.

Format your partitions are needed, and in my case:

The SSD is now ready. Let’s mount the partitions:

In Linux, I’m normally using Bonnie / Bonnie++ to benchmark storage device:

By default, bonnie will write a file with double the size of your RAM to perform its testing, which is a way to reduce the influence of the cache, and provide more accurate results.

Since bonnie output is not always easy to read, I’ve run the last line with bon_csv2html to have prettier results in HTML, also including the results for the NAND flash (bonnie++ -d /) as comparison.

You can check the full Bonnie++ results including sequential and random create results.

Sequential Output is write speed, and Sequential Input is write speed. Most of the time, Block speed is the important metric here. So first we see a large difference in performance between NTFS and EXT4 read and write speed on the SSD with respectively 8.7 MB/s and 50.5 MB/s for NTFS versus 36.31 MB.s, and 179.45 MB/s for EXT-4. That means CubieTruck can read data at 180MB/s from the SSD, or about 6 times faster than the typical performance of a USB 2.0 drive, and faster than the USB 3.0 drive connected to my Ubuntu computer (AMD FX8350) which achieves 115 MB/s read speed in the same test on its EXT-4 partition. As a side note, the maximum performance I’ve ever got from another ARM device via USB 3.0 was about 48 MB/s with ODROID-XU3 Lite, but this was in Android, and an NTFS partition, and with another tool (A1SD).

The NAND flash used in CubieTruck is also much slower than the SSD, writing at 6.4 MB/s and reading at 19.46 MB/s, and that’s why if you purchase this kit, you should probably move the rootfs to the SSD.

I’ve also tested raw Ethernet performance with the command line: iperf -t 60 -c 192.168.0.104 -d. Unfortunately Cubieboard Gigabit Ethernet performance (full duplex) is not that good, albeit still faster then Fast Ethernet.

Battery Life, Monitoring and UPS Function

This kit comes with a 5,300 mAh battery that’s mainly used as a UPS. So I’ve tried to disconnect the power while in used, and the system runs as expected. Once the battery is depleted, and the system off, as soon as the power comes back the system will boot again, so that part is also good in most cases, but not all…

I always wanted to check the battery life, to see how long the board could run on batteries. In my Ubuntu computer, I can run “last” to check the last power on./off event, bit with this firmware, it won’t work, complaining that /var/log/wtmp is missing. So instead I installed uptimed:

Once I left the battery discharge over night, and after 3 hours, I assumed it was fully charged, and in idle mode, the battery lasted two hours. I had only connected the HDMI cable, an Ethernet cable, and connected to the board with SSH.

We can check the record uptimes with uprecords:

However, afterwards I had a doubt whether I had a full charge or not, so let it run all day, and tested it again, and this time, the battery lasted for over four hours and 20 minutes, meaning the first time, the battery was not fully charged, and it might take many hours to charge the battery:

LXDE desktop will not run the system run on batteries (or I missed that), but you can monitor the battery status, health, voltage and more with sysfs:

So that means your program, or a script, could detect when the battery is charging or discharging, check the health status and/or voltage, and decide to run in lower power mode, and cleanly turn off the system when the voltage drops too low.

More options can be found on power_supply_class.txt kernel documentation.

Installing Debian rootfs to the SSD

Have we’ve seen above the read speed of the SSD is about 9 times faster than the NAND flash, and the write speed nearly 6 times faster, so you should really move the rootfs to the SSD, unless you have specific reasons not to do so. Another advantage will be the increased space for programs.

Let’s check the rootfs usage n the NAND flash first:

So we have a 6.9GB rootfs out of the 8GB flash, with 3.9GB free after I installed a few programs.

The rootfs is located in /dev/nandb partition, and you’ll want to move it to /dev/sda1 (in my case /dev/sda2, but I’ll use sda1 in this section, as it’s what most people will do). I’ll assume here that you have already partitioned and formatted the SSD as specified in the SSD SATA performance section.

Then we have to tell the system the root filesystem is located in the SSD, by changing uEnv.txt located in nanda partition of the flash:

sudo vi /mnt/nanda/uEnv.txt

Where you’ll need to change:

by

Now unmount the partitions, sync, and reboot

After login, you can check that the rootfs is now on the SSD with close a 120GB partition (in my case 60G since I have two partitions):

Using CubieTruck Metal Kit as a Desktop PC

Just like I did with ODROID-XU3 Lite and Ugoos UM3, I’ve tried to use this Linux computer as a desktop computer, and shot a video with:

1. Boot time from SSD: 42 seconds. Note that the LED on the front panel take about 10 seconds to lit up.
2. Checking UPS function by disconnecting the power
3. cubie-config utility for setup
4. List of installed applications
5. LibreOffice (Writer)
6. Chromium – Multi-tabs, YouTube (embedded / full screen; VP9 / H.264/AVC1), and Candy Crush Saga (Flash game) in Facebook
7. Video Playback with GNOME Player
8. Power off

CubieTruck (Cubieboard 3) can be used as a desktop computer for Office tasks, but web browsing may become an issue with high CPU usage in Chromium, and watching YouTube video amounts to torture. Video playback (software decode) appears to be relatively OK up to 720P using GNOME player, but 1080p/H.264 video are not watchable. There are now VPU driver for Allwinner A10/A20, but these do not seem to be in use in this image, same for Mali drivers for 2D/3D GPU acceleration.

Phoronix Benchmarks

I’ve also run some of Phoronix Test Suite benchmarks:

After configuring batch test, I’ve run MP3 encode, 7-zip compression, and Apache server tests:

Contraty to ODROID-XU3 Lite, where compress-7zip failed because of a lack of memory, all three tests could complete successfully. I find Openbenchmarking website very confusing to use, and I did not find a way to compare to old results. So I included CubieTruck NAND, CubieTruck SSD, and ODROID-XU3 Lite in the picture below.

You can also click on the pages on OpenBenchmarking for Cubietruck (NAND), CubieTruck (SSD), and ODROID-XU3 Lite (eMMC) for full details.

I was not expecting the SSD to make much difference with the MP3 encoding, and 7-zip compression benchmarks, but I though it would yield a significant increase in performance for the Apache test. I was wrong, as the Apache test only improved from 771.6 requests per second to 785.20 rps, so it must mean this benchmark is not a I/O bound test. As should be expected ODROID-XU3 Lite is much faster for both MP3 encoding (45 seconds vs 165 seconds), and Apache (2382 rps vs 785 rps).

CubieTruck Metal Case kit includes CubieTruck board, a 120GB SSD, a 5,300 mAh battery, a rugged metallic enclosure, a 5V/2.5A power, and relevant cables. It can be purchased for $169 on Seeedstudio, or 149 Euros exc. VAT on EmbeddedComputer.nl.

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress