The EOMA68-A20 Computer Card has been using the older u-boot and sunxi-3.4 kernels for some time. This update shows a recent mainline u-boot (2016.07) and a sunxi-next near-mainline 4.7.0-rc5 Linux kernel.
One of the primary reasons for using the sunxi-3.4 kernel developed by Allwinner is that, after various people had beaten them about the head with big sticks to obtain GPL-compliant code, it was (and still is) actually the best choice for supporting all of the hardware of the A20 processor. For example, dual simultaneous LCD and HDMI output (whether it be single or dual separate framebuffers) and full support for raw NAND ICs (even if it was quirky) - everything works.
The mainline linux-sunxi kernel team has therefore been working slowly for years to catch up, develop and then submit the various patches, doing a really decent job along the way. They’ve also fixed a number of the quirks. For example, in the USB code that Allwinner developed, somebody noticed by reviewing the Allwinner source that actually it was licensed from Mentor Graphics, the address offsets for data structures were 16-bit, and drivers already exist for musb (with 32-bit data structure alignment), but that Allwinner’s team had not been aware of this, had developed (badly and inefficiently) a re-implementation of musb that did not use DMA.
It turns out however that enough development has taken place so that the critical interfaces for EOMA68 are now fully supported, both in u-boot mainline and Linux kernel mainline. The only gotcha: the way that the framebuffer is set up is extremely odd, and is not suited to how EOMA68 works. The framebuffer is not initialised in the A20 Linux kernel: it’s initialised by u-boot. This makes it difficult if not flat-out impossible to switch between EOMA68 Housings without a full reboot, and it has yet to be investigated whether dual simultaneous LCD and HDMI output is possible.
Other than that small quirk, it is extremely exciting to find that, with very few devicetree modifications and no Linux kernel modifications or u-boot modifications, mainline u-boot and Linux kernel works straight out-of-the-box. This update’s video therefore walks through the boot-up process, using what turns out to be a little-known tool, "fex-boot," that’s included in the sunxi-tools. Searching on various forums I was amazed to find that there are people still struggling with the proprietary and Windows-only LIVESUIT.EXE to recover their A20 devices! Surely people have known about the fex-boot utility since it was reverse-engineered over three years ago?
Apparently not, so this video shows and explains the process.
On compiling u-boot, if SPL is selected in the configuration, a tiny sub-16k program is created (which normally is tacked onto the front of u-boot itself), which purely carries out very low-level initialisation such as setting up the DDR3 RAM, some of the clocks and PLLs, and letting us know what’s going on over one of the UARTs. Following the upload into the first level cache and subsequent execution of this code, more data may be uploaded absolutely anywhere into DDR3 RAM and then executed. We choose in this instance to upload a mainline u-boot binary. Once that is running u-boot can take over, initialise all the rest of the hardware (NAND, MMC, and HDMI in this case) and it all rolls forward from there in a straightforward fashion.
Later, we will do another (shorter) video where u-boot will have been put onto the NAND flash (and will include testing the ThinkPenguin TP150N USB-WIFI 802.11n dongle), but it has been found to be best to use the fex-boot first for this kind of experimentation (to get different versions of u-boot and kernels up and running), as it is very quick: no need to mess about removing SD.MMC cards, no need to worry about breaking the NAND flash with too many overwrites and erases - just load over USB and go. Really useful.