Dusting off my CubieBoard2

[COTB]

Or... what can you REALLY do with a CubieBoard2 in 2020?

During the recent Covid lock-down I started sorting my technojunk boxes.  This came to a halt when I happened on some Cubie purchases from 2013 and fired up a CubieBoard2 I'd never really got to grips with.  So why not document my experiences in order to benefit others?  Well.. as you ask...! 

Android 4.2.2: slightly less useful than Fortran 77!

The CubieBord2 boots into Android.  Not too many of the in-ROM apps still work, and there's no longer much in Play Store that is compatible.  I've yet to find an image of a more up-to-date Android, and even then 1GB of RAM (less screen estate) is pathetically little for current Android versions.  The 4GB nand Flash capacity is further compromised by all the small partitions on it, resulting in very little free space where it matters.  Time to see if we can ditch Android and all its baggage!

The most up-to-date Linux distro I could readily find for the CubieBoad2 was Linaro 14.xx - this is a repackaged and much pruned Ubuntu 14 (Warthog?).  A boot block on the microSD gets priority over one on the on-board nand so there's no configuration to do in order to boot into an alternative OS.  Writing the image file to a microSD was easy and it booted straight away.

Here's how to prepare the card using a second Linux machine:

# First determine for SURE which device name represents your microSD in the current session (substitute in x below)

$ sudo umount /dev/sdx
$ sudo dd if=linaro-14.04-desktop-cb2-card0-hdmi-v1.0.img of=/dev/sdx
$ sync

WARNING: Triple check the outfile device name before invoking dd as there is huge potential here to trash your machine if you accidentally name a working drive!

After Linaro booted I copied the SD card's file system to the SSD (also using dd) and expanded the new SSD Linux root partition to 120GB or so.  The SSD read and write speeds were way above those from the flash card (and the nand), so even though the O/S was quite dated the overall system started to look very promising.  So how about booting directly to the SSD?  This isn't possible from the undocumented (and non-programmable) start-up ROM inside the A20.  That's understandable as this tiny bit of code that loads and transfers control to u-boot (the second stage of the boot process) isn't SATA aware.  The current u-boot doesn't seem to be terribly intelligent either!  In any case you need somewhere to locate u-boot that doesn't involve the SATA: this means either in the nand or on the microSD card.  First let's try booting through the nand by finding a more intelligent u-boot and flashing it, or somehow patching the nand image to force the Linux root to be on the SSD...

Getting serious: re-flashing the onboard Nand

Allwinner supply utilities to flash the A20's external nand memory for both Windows and Linux.  This is called Phoenix Suit for Windows and LiveSuit for Linux.  I went the Linux path, of course!   In good old Linux fashion you need to build it yourself.  First step is to clone the repo into a working directory on your own machine:

If you have a github.com account you can:

cd ~/workdir
git clone https://github.com/linux-sunxi/sunxi-livesuite.git

Or without a github.com account visit https://github.com/linux-sunxi/sunxi-livesuite download the .zip file and expand it into your working directory.

Now simply follow the directions in the READ.ME remembering you need to invoke make as superuser (sudo make works of course).  Except... the READ.ME omits a few very necessary steps.  In particular it fails to tell you that you must invoke depmod before modprobe, and I found that it's use of a kernel subdirectory didn't work (cp to the modules root directory).

sudo cp awusb.ko /lib/modules/`uname -r`/
sudo depmod -a
sudo modprobe awusb

________________________________

Problems you'll likely encounter:

My first attempt at a make threw up mysterious errors until I edited file awusb.c in the awusb directory.

The edit required was to change the #include <linux/signal.h> to #include <linux/sched/signal.h>.  Now it compiles!

A further problem was that Ubuntu (from about version 18 onwards) removed the libpng12-0 libraries that running the LiveSuit binary requires.  The fix (acknowledgement here to linuxuprising.com) was:

sudo add-apt-repository ppa:linuxuprising/libpng12
sudo apt update
sudo apt install libpng12-0

Something else the READ.ME doesn't tell you is that access to the USB port for non-root users is blocked until you enable it by adding a 50-awusb.rules file to the /etc/udev/rules.d directory containing the single line KERNEL=="aw_efex[0-9]*", MODE="0666" then reloading the user device rules with a...

sudo udevadm control --reload-rules

Reportedly the very latest Ubuntu v20.xx also throws up an additional error due to one of the Linux source code files not being found on the system.  The solution involves an apt install linux-source.

________________________________

Allwinner LiveSuit in action!

After installing Allwinner's USB driver I had a long hair-tearing session getting an image to flash.  Google soon appraised me that I was not alone, and that no one had actually documented a solution.  So how many experimenters have given up at this point?  LiveSuit was actually failing somewhat after a message about DRAM size, and others have clearly assumed that this was the problem.  The whole log output of LiveSuit is basically Chinglish and taking the messages literally is a blind alley to go down.  In fact LiveSuit was executing normally, and all the image files I had previously tried had a problem. It took me some time bumbling around the Internet until I found the essential source of cubie image files of unflawed nand images and after that SUCCESS!

LiveSuit takes a few minutes and does the image file flash in increments, but it gets there in the end.  Getting the Cubieboard2 into FEL mode in order to flash it is described at various places on the Internet, and also in Chinglish on the LiveSuit screen.  But on the Cubieboard2 these methods can be awkward (and painful) with the silly positioning of the FEL button right under the mini-USB OTG port.  I've found by far the easiest way is to remove both the mini-USB connector and the power jack.  Hold the FEL button in and them plug the power jack in.  The board is now in FEL mode, so you can release the button at your leisure without any gymnastics or any contact at all with the - also awkwardly placed - power button.  To initiate the flash simply plug the mini-USB connector in at your leisure.

Nice BUT...

Unfortunately my first successful flash was er... Android 4.2.2... because you can't simply take a disk image file and flash it to nand - it has to be in a special format which LiveSuit accepts.  Without the memory card we were now booting into a nicer version of Android 4.2.2 with a pretty Allwinner A20 splash screen.  Well, proof of concept anyway!  Time is pressing, so now that we at least have the technology to engineer a boot without the microSD card, it's time to create a working Linux system that executes out of a big fast SSD and leave the niceties of ditching the memory card to a later session.  Boot into the SSD Linux image proved surprisingly easy as all that was actually necessary was to edit the first line of the eEnv.txt text file in the first small partition of the memory card (not the image of this partition on the SSD) to read:

root=/dev/sd2

Running the storage system entirely from the SSD made a huge difference to performance and usability!  Some perspex plates that came with the board years ago; a few brass spacers; a cheapo hard drive caddy; and a generous helping of self-adhesive Velcro tape, tidied the whole thing up into a compact desktop development system.

I created a 2GB swap (Type 82) partition on the SSD and checked that it was working by maxing the swappiness and loading every GUI window I could whilst running the top utility.  Oh!   Linux doesn't like swapping out RAM: all I was able to force it to use was a paltry few KBytes!  2GB was obviously way excessive here, but even though the system wasn't very swappie I left the swap file in use, because with only 1GB of RAM every little bit helps; the SSD was a lot faster than a normal hard drive swap; and I had loads of unused space on the SSD.

Some of the other things I then did:

sudo apt remove chromium-browser
sudo apt install firefox
sudo apt-get autoremove
sudo apt install gdc    ### The D Language compiler

 

So that's it for now whilst I play with my new Linux development system.  Those 2mm row-pitch sockets in foreground of the second photo are to create some custom I/O connectors - but A20 I/O is a story for another day!