Fri, 03 Jan 2014 by Bolshevik in General | Comments

This post is late by about 7 months. But still it is an interesting topic. Allwinner A10 is an ARM system on chip that integrates a 1GHz ARMv7 CPU, Mali400 video accelerator and the CedarX video decoder. It also has support for USB 2.0, Ethernet and SATA, HDMI and VGA displays. There are several devices and boards that employ the SoC: Mele A1000, Mele A2000, MK802 and Cubieboard. All of the SoCs are shipped with pre-installed Android image, but the hardware is capable to run Linux kernel. Although there are still some issues with integrated Graphics and Codecs.

Of course this is not a high-end hardware and one should not expect enormous performance, but it is capable to run a simple home server and act as a NAS if a hard drive is attached.

Comparing to Raspberry Pi, which is a bit cheaper ~$40 comparing to ~$70 for the cubieboard, the A10 chip is much faster I've been trying Raspberry Pi as a media centre using Raspbmc the media centre application consumes 30% of CPU while idle. Remote shell is lagging a bit most of the time. While I can't compare cubiboard media performance, but as a server it performs fine and quick.

Cubieboard can be powered using 5V PSU but requires stable and sufficient power. Additionally if you want to use 2.5" HDD and power it with the board you should carefully estimate the consumed power.

Hardware

  1. Allwinner A10 based SoC.
  2. 2.5" or 3.5" HDD.
  3. PSU.

My current setup is running the SoC, 2TB Seagate HDD, 50mm FAN using LCD PSU purchased on eBay.

Software

One may choose any ARM enabled distributive to be installed: Debian, Arch, Ubuntu, Fedora.

If you are a Debian fan I would advice to start with Roman's website. There are a minimal Debian image and all the instructions on how to run it.

Note it is important to use correct script.bin file belonging to your board, otherwise the device won't boot or some of the hardware e.g. NIC won't be initialized properly.

Installation

First of all one needs to write a bootable Debian image onto SD/MicroSD card and update script.bin file.

Next, after booting the device one must partition the HDD and move rootfs onto it.

Then adding a uEnv.txt file to a boot partition containing correct kernel parameters will enable the kernel to use on HDD rootfs.

root=/dev/sda2 ro rootwait rootflags=data=journal raid=noautodetect

Downside of the setup is requirement to have the SD card in the device all the time.

Installing on NAND

Cubieboard and Mele A1000 have internal flash on board. It is possible to install the OS onto the NAND. This is a bit complicated because it is impossible to debug the boot sequence in an easy way. One will need PL2303 USB cable (supplied in cubieboard package) to forward the serial line to USB of a PC and connect to it using PuTTY or screen utility:

screen /dev/ttyUSB0 115200

There is a separate utility called nand-part at the sunxi-tools repository. It is required to compile it in order to reparition the NAND. I repartitioned by device in order to make /boot filesystem big enough.

2 partitions
partition  1: class =         DISK, name =         boot, partition start =    32768, partition size =   262144 user_type=0
partition  2: class =         DISK, name =         root, partition start =   294912, partition size =        0 user_type=0

Allwinner uses U-boot to boot the OS. There are two branches of the U-boot in the respective git repository. Latest U-boot version contains a lot of improvements allowing to boot from ext4 FS but doesn't support NAND boot. The older version supports NAND boot but is very limited and must be manually compiled. In order to make the configuration extendible I had to modify the default boot line to the following:

#define CONFIG_EXTRA_ENV_SETTINGS \
    "bootdelay=3\0" \
    "console=ttyS0,115200\0" \
    "init=/init\0" \
    "loglevel=8\0" \
    "init=${init} loglevel=${loglevel}\0" \
    "boot_recovery=nand read 50000000 recovery; boota 50000000\0" \
    "boot_fastboot=fastboot\0" \
    "baudrate=115200\0" \
    "scriptaddr=0x44000000\0" \
    "bootenv=uEnv.txt\0" \
    "loadbootenv=fatload nand 0 ${scriptaddr} ${bootenv} || fatload nand 0 ${scriptaddr} boot/${bootenv}\0" \
    "boot_nand=fatload nand 0 0x43000000 script.bin && fatload nand 0 0x48000000 ${kernel} && bootm 0x48000000\0" \
    "kernel=uImage\0" \
    "root=/dev/nandb\0" \
    "setargs=setenv bootargs console=${console} root=${root} loglevel=${loglevel} ${panicarg} ${extraargs}\0" \
    "bootcmd=if run loadbootenv; then \\ \
            env import -t ${scriptaddr} ${filesize}; \\ \
    fi; \\ \
    if test -n ${uenvcmd}; then \\ \
            run uenvcmd; \\ \
    fi; \\ \
    run setargs boot_nand;\0"

The following uEnv.txt allows to boot Linux kernel and initrd:

root=/dev/sda2 ro rootwait rootflags=data=journal raid=noautodetect
initrd_boot=fatload nand 0 0x43000000 script.bin; fatload nand 0 0x48000000 uImage; fatload nand 0 0x43100000 uInitrd; run setargs; bootm 0x48000000 0x43100000;
uenvcmd=run initrd_boot

After a few debugging sessions via serial interface one will get a bootable device that uses NAND boot partition and NAND or sda as a root partition.

Fault tolerance and performance

It is important to select correct data mode for ext4 filesystem, consider to use data=journal mode for the root file system to prevent its corruption. noatime and relatime options will decrease HDD writes, but some of the applications may relay on the correctness of the dates.

As the server fully depends on power supply I would advice to use initial ramdrive with SSH daemon configured. This will allow login and fix file systems in case of root file system failure. On Debian it is easily done by installing dropbear SSH client and initramfs-tools . But the image must be converted to a format supported by U-boot by running:

mkimage -A arm -O linux -T ramdisk -C none -n initrd-`uname -r` -d initrd.img-`uname -r` uInitrd

Additionally I've moved all the services to the 3rd runlevel and added the following check in the /etc/rc.local file:

if mountpoint -q /home && mountpoint -q /var then
    telinit 3
fi

These two pints allow to access the box in case of root filesystem failure by using remote SSH and dropbear, and in case of failing /home or /var filesystems the box won't start any services, will stay at the 2nd runlevel and will allow to log into the shell to fix the problems.

See the previous post describing automated Debian server configuration.

Comments

comments powered by Disqus

About

PHP web developer, python developer