Linux.com

Home Learn Linux Linux Tutorials Cubieboard: ARM A8 CPU with SATA for Under $50

Cubieboard: ARM A8 CPU with SATA for Under $50

The Cubieboard brings SATA connectivity to a very low price point ARM Single Board Computer (SBC). The board has an ARM A8, 1Gb of RAM, 4Gb of Flash storage, HDMI output, and a whole bunch of IO pins. A recent update, the Cubieboard2 is now out, which replaces the Allwinner A10 CPU from the original Cubieboard (single A8 core) with a dual core Allwinner A20 (two A7 ARM cores). Given the Allwinner A10 CPU is an A8 core it might perform slightly better in single threaded tests per clock than the A7 cores in the Allwinner A20 CPU.

Shown in the picture is the Cubieboard and Developer Set. While no power transformer is supplied, you can run the Cubieboard off USB power with the supplied cable. If you are intending to power a SATA drive from the Cubieboard then you'll want to use a power supply rather than trying to power both the Cubieboard and SATA drive off the single USB power cable. In the top right of the picture you can see the two-piece case that is supplied which sandwiches the Cubieboard in clear plastic. In the center of the picture is the SATA cable: the lower two connectors go to the Cubieboard and the larger connector on the other end to a 2.5 inch SATA drive. In the top middle of the picture is the JTAG connector and a debug cable. The JTAG connector plugs into the microSD slot of the Cubieboard for debugging. A microSD card is shown for scale. Adding the Developer Set to the basic Cubieboard also makes the total cost more than $50.

Cubieboard and developer set

Booting with Linux

A major convenience of the Cubieboard having been around for a while is that there is a lot of support for running Linux on it. Unfortunately though, I found myself needing to compile vlc to get hardware accelerated decoding. My Cubieboard came with Android 4.0.4 preinstalled on it's internal 4Gb of Flash. When booting from the internal flash a green light near the CPU will be lit. When booting from the microSD card that green light remains off.

There is a Fedora 18 Remix for the Cubieboard and Ubuntu Images too. The Fedora 18 Remix is geared toward being expanded onto and run from a microSD card. Because uBoot is already part of the Remix image that you download, getting Fedora 18 up and running on the Cubieboard is as simple as using dd to copy the Remix image to a microSD card, inserting that card into the Cubieboard, and powering up the Cubieboard.

The first time you boot the Fedora 18 Remix it will resize itself to use the full size of the microSD card that you have copied it to. So setting up a 32Gb system is as easy as using a 32Gb microSD card. A few questions like first user creation are then asked and you are presented with an Xfce desktop. If you are using DHCP to assign IP Addresses to your machines you might like to add something like "mac_addr=c6:aa:aa:aa:aa:00" to the end of the mmcargs line in your /boot/uEnv.txt file to assign a selected fixed MAC address to your Cubieboard so that it doesn't move around on your network.

The internal 4Gb of NAND storage on the Cubieboard is exposed through the /dev/nand device files. I found that all were small partitions except nandg and handh which were 335 and 2592 Mb respectively. Once you have booted a Linux distribution from the microSD card, you might like to migrate it over to the 4Gb of internal flash storage to free up the card slot. Another option is to use a very fast microSD card and leave the Linux distribution on the microSD card and use the internal flash for other purposes.

Migrating Linux to Flash

I used the commands shown below to migrate a Fedora 18 installation over to the internal flash. I based the /boot partition on the one on the microSD card and used the remaining internal storage for the new root partition. The newly created /dev/nand1 will be the new 209Mb /boot partition and /dev/nand2 will be the 3874Mb system partition. Using volume labels for the filesystems avoids the need to keep remembering the exact paths. The combination of tar commands used to copy the root filesystem is based on the one in the XFS HOWTO but I added the --one-file-system flag to avoid issues with /sys, /proc, and having tar trying to recurse into /mnt and chase its own tail.

The two main references to the old system you have to update are /boot/uEnv.txt and /etc/fstab. Then you are going to want to put uBoot onto the start of the internal flash storage using the commands based on those used to install uBoot on a microSD card. Luckily the Cubieboard is set to boot from microSD before it's internal NAND flash so you can recover if you paint yourself into a corner.

wget http://dl.cubieforums.com/loz/boot_partition/bootloader/cubie_nand_uboot_partition_image.bin
dd if=cubie_nand_uboot_partition_image.bin of=/dev/nand
sync
partprobe /dev/nand
sync
... wait a minute
... reboot
# mkfs.ext4 -LNANDSYSTEM /dev/nandb
# mkdir /mnt/new
# mount LABEL=NANDSYSTEM /mnt/new
# cp -av /boot /mnt/new/
# cd /
# tar --one-file-system -lcf -  . | (cd /mnt/new/; tar xpvf - )
# vi /mnt/new/uEnv.txt
   Change root=UUID=78...1 to root=LABEL=NANDSYSTEM 
# vi /mnt/new/etc/fstab
LABEL=NANDSYSTEM   /   ext4   defaults   1 1

The LiveSuit tool allows you to write an image directly to the 4Gb of internal NAND flash on the Cubieboard. To do this you have to put the Cubieboard into FEL mode which allows LiveSuit to write data to its NAND over a USB cable. To do this, turn off the Cubieboard by holding its power button down for 10 seconds. While holding down the button below the mini-usb plug on the Cubieboard, use a cable from the mini-USB port on the Cubieboard to connect it to a USB port of a desktop computer and then hold the power button down for a while on the Cubieboard. This should have the Cubieboard recognized on the desktop machine and you will be able to write a new image to the Cubieboard internal flash.

Power Usage and Video Playback

At a logged in 1080p desktop the Cubieboard drew 1.6 watts. When I was compiling openssl that went up to around 2.9 watts. During hardware accelerated playback of the 1080 big buck bunny file power usage was at around 1.8 watts.

Compiling vlc with support for the CederX hardware video decoding took me hours of tinkering, downloading source, and building. At the end I found some container formats were problematic but I could play back the 1080p big buck bunny mov file with only a few minor stutters here and there. I'm not sure if the final kinks iron out with more tinkering or not. There are also some known issues with 1080 playback with CederX hardware decoding.

Next time around we'll see benchmarks for the CPU, Graphics and NAND for the Cubieboard. As for the SATA port, I'm hoping to connect an SSD to see just how quickly data can be shuffled to and from storage on the Cubieboard. With a sub-$100 SSD the Cubieboard might be a great, low-run cost, lower volume, always available MySQL database server. We would like to thank Miniand Tech for providing the Cubieboard review hardware.

Read other reviews in this series:

Getting Started With the BeagleBone Black: A 1GHz ARM Linux Machine for $45

BeagleBone Black Part 2: Linux Performance Tests

How to Run Linux on ODROID-U2: A Monster of an ARM Machine

ODROID-U2 Part 2: Benchmarking the ARM Beast

OMAP5432 Review: Texas Instruments' Dual Core ARM A15

Benchmarking Performance of TI's OMAP5432 Board

 

Comments

Subscribe to Comments Feed
  • Romain Said:

    Nice article and interesting platform but I would not format the NAND with ext4... ext4 has been designed to work on top of "standard" block devices such as hard disks and MMC/SD cards with an internal controller which hides the complexity of NAND chips handling. ext4 will not account for bad blocks management, wear-leveling,... which will sooner or later lead to a corrupt file system. For "bare" NAND chips without internal controller providing a standard block interface file systems designed explicitly to deal with NAND specificity should be preferred. Android uses YAFFS2 (http://www.yaffs.net/) but other NAND FS have been around for a while: - JFFS2 (not especially well suited for large NAND devices) - UBI + UBIFS For more info on NAND file systems Linux MTD website is really instructive: http://www.linux-mtd.infradead.org/doc/nand.html

  • Popolon Said:

    The link known issue is broken? Note that, if you want to do a benchmark, note that there is lot of recent great improvement that could really change the results: * there is an still experimental opensource driver for the CedarX, that works just fine with mplayer : http://www.cnx-software.com/2013/08/30/preliminary-reverse-engineered-vpu-driver-cedarx-for-allwinner-a10-plays-h-264-videos/ * There is some experiment of 2d acceleration 2 or 3 times faster than Mali official ARM open source X11 driver: http://ssvb.github.io/2013/02/01/new-xf86-video-sunxifb-ddx-driver.html * There is work in progress for an opensource 3d driver for Mali (called Lima) * GCC 4.8 improve greatly NEON SIMD autovectorization (should be better on Cortex a7), cortex a8 is a really slow version of arm SIMD: http://gcc.gnu.org/gcc-4.8/changes.html * defaut kernel is a hack by allwinner, now Allwinner CPU are integrated in mainline linux kernel (3.8 for allwiner a10 (cortex a8), 3.11 manage allwinner a20 (dual cortex a7) without SMP, greater management should reach linux in v3.12: http://linux-sunxi.org/Linux_mainlining_effort * openssl (often in some benchmarks) has now some hand made NEON optimisations.

  • Marc Said:

    anyone know of a cheap board like this that can PXE boot?


Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board