Allwinner Linux Bring-Up: F1C100s, V3s and T113 from Boot ROM to Root Filesystem

Why Allwinner parts keep showing up in cost-driven Linux products

The F1C100s, V3s and T113 families give a small team a Linux-capable processor with DRAM already inside the package, a handful of passive components and a two- to four-layer board. That makes them a natural fit for panels, controllers, gateways and audio or video appliances where a Raspberry Pi-class module is too expensive or too large, and a microcontroller cannot run the software. They are also unforgiving: the documentation is thinner than for mainstream vendors, the boot flow has its own conventions, and a board that almost works can fail in ways that look random.

This guide is the order in which we bring these boards up, and the places where time is usually lost.

Decide first: mainline kernel or the vendor BSP

Allwinner ships a vendor BSP (the Tina Linux SDK is one form of it) with an old kernel, vendor drivers and closed pieces for display, video and some peripherals. Mainline Linux and U-Boot, maintained by the sunxi community, support the F1C100s (the suniv family), the V3s and, more recently, the T113 family, with a growing but incomplete set of peripherals.

• Vendor BSP is the faster route when the product depends on hardware video encode or decode, a vendor camera pipeline or a display feature that mainline does not cover yet. The price is an old kernel, security fixes you must backport yourself and a build system that is hard to move to another chip.
• Mainline is the better long-term base for products that only need the CPU, storage, network, USB, GPIO, I2C, SPI, UART and a plain RGB display. Updates are possible, the toolchain is standard and the device tree is under your control.

Decide this before the first schematic review, because it changes which peripherals you can rely on. We have shipped both: an Allwinner R528 control board ran the vendor Tina Linux, with the network services, GPIO, UART and USB drivers integrated around it.

The boot chain, and why it decides your debugging order

Every Allwinner part boots the same way. The on-chip boot ROM looks for a boot image on its supported media in a fixed order, loads a small first-stage loader (the SPL) into on-chip memory, and that loader initialises DRAM and loads U-Boot, which loads the kernel. Three consequences follow.

• Until the SPL has initialised DRAM, you have no memory and almost no output. A dead board almost always fails here, so check the serial console on the UART the boot ROM and SPL use, and watch the first lines.
• The DRAM settings in the SPL must match the actual DRAM. For parts with DRAM in the package, the community configuration for that part normally works. For boards with external DRAM, the timing and drive parameters must be taken from the memory datasheet and verified, not copied from a reference board.
• Boot media selection is by order of probing. A blank SPI flash, an SD card left in the slot and a boot-select strap can combine into a board that boots one day and not the next.

Keep FEL mode as your recovery path

All these parts include FEL, a USB boot mode in the boot ROM. With the board in FEL mode, the sunxi-fel tool can load and run code over USB, read memory and flash SPI memory, so a corrupted flash is never a bricked board. Make sure your design gives access to it: a way to pull the FEL select pin during reset, and the USB OTG port wired to a connector the production fixture can reach. The same path is how most factories flash boards, so it pays back twice.

DRAM is the first thing to test properly

A board that boots and then crashes under load usually has a memory problem, not a kernel problem. Before spending days on drivers, run a memory test for several hours under temperature and with the other peripherals active. Check three things:

• The power rails for the core and the DRAM, measured under a load step, not at idle.
• The DRAM clock and drive settings, especially on boards with external memory, where layout length matching makes a difference.
• Whether the instability changes with temperature. If it does, it is margin, and no software workaround is a cure.

Storage: SD card, SPI NOR, SPI NAND or eMMC

SD cards are convenient during development and unreliable in the field. For a product, choose SPI NAND or NOR for small systems and eMMC where the part supports it, and plan a read-only root filesystem with a separate writable data area. Use a file system suited to raw flash on NAND, and expect to tune the partition layout, bad block handling and, for NAND, the ECC settings the boot ROM expects. Test power loss deliberately: pull the supply while the system is writing and confirm that it boots afterwards, many times over.

The device tree is where the board lives

Start from the closest reference board in the kernel tree, copy it to a new file for your hardware and change one thing at a time: pin multiplexing, the regulators, the display timing, the Ethernet PHY or the USB role. Most bring-up delays are an unnoticed pin conflict or a regulator that the kernel switches off because nothing declared it in use. When a peripheral does not appear, check, in order, that its clock and reset are enabled, that its pins are muxed to it, that its supply is on and that the driver actually matched the node.

A root filesystem you can reproduce

For these small systems, Buildroot is usually the right size: it builds the toolchain, the kernel, U-Boot and a minimal user space from a configuration file you keep in version control. Do not hand-assemble images. A product has to be rebuilt bit for bit a year from now, when the person who built the first image has moved on.

Production flashing and test

Design the factory process while designing the board: how the board enters FEL or boots from a programmed device, how the image is written and verified, how the fixture records the result, and which self-test the firmware runs on first boot (memory, storage, network, display, the sensors). A board that cannot be tested in thirty seconds on a fixture will cost more in the factory than in engineering.

Where we can help

We bring up Linux on Allwinner and other application processors, from the boot chain and device tree to drivers and a reproducible root filesystem, and we design the boards around them. See our Linux BSP and driver service and the longer general bring-up guide.