Status

The current U-Boot release fully supports major functions (except NAND) on
all the older Allwinner SoCs (A10/A10s/A13/A20/A23/A31/A31s) and has basic support for the more recent A33, A64, A80, A83T, H2+, H3, H5, and V3s(No MPI-DSI Lcd).

You might observe the PHY not initializing (e.g. no LED activity), and the command mii info likely will list useless information on all available PHY slots (0x00-0x1F). Commit fc8991c fixes it again, but unfortunately that means U-Boot release v2016.03 is affected.

Beware: some of the above might only be supported in the latest development version.

Compile U-Boot

Get a toolchain

If you haven't done so before, get a suitable toolchain installed and added to your PATH.

Get the Device-tree Compiler

Depending on your desired U-Boot version, a sufficiently up-to-date dtc may be required. (The build process will error on an outdated dtc, and request you to upgrade it.) The installation of dtc is described in the Device tree article.

If you are going to build a Linux kernel alongside U-Boot, it might also be worth to examine the kernel sources - as they come with dtc included under ${KERNEL_DIR}/scripts/dtc/.

Clone the repository

You can clone the u-boot repository by running:

git clone git://git.denx.de/u-boot.git

You should prefer using a stable release, unless you're testing recently added boards or experimental features that have not yet made into stable release:

git checkout v2016.01 # or whatever is latest

Determine build target

Go to your u-boot tree and search in the directory configs/ for your board, the file name looks like <board_name>_defconfig.

Build

When you have determined what <board_name> you want to build, configure:

make CROSS_COMPILE=arm-linux-gnueabihf- <board_name>_defconfig

There is also menuconfig to play with settings if you feel like it:

make CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

Then just build it:

make CROSS_COMPILE=arm-linux-gnueabihf-

or for A64:

make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-

(When compiling natively, omit the CROSS_COMPILE=…)

When the build has completed, there will be u-boot-sunxi-with-spl.bin available in your u-boot tree. The installation step will instruct how to install this on the installation media (e.g. a SD card), but first U-Boot needs to be configured.

Configure U-Boot

This article provides a collection of various scenarios for booting with U-Boot.

Boot

For getting these bits loaded onto the hardware, please refer to the respective howto:

If you also want to use an initramfs, please refer to the Initial Ramdisk article for details.

If you're wondering why setting bootm_boot_mode might be necessary for older kernels, have a look at the details of PSCI.

Note: Directly using a zImage is also supported by U-Boot for the sunxi platform. Substitute zImage in place of uImage in the commands above, and then use the bootz command instead of bootm.

Booting with extlinux.conf

Mainline U-Boot also use syslinux/extlinux as payload.

You need to install the boot configuration file extlinux.conf in an ext2/3/4 partition of SD card and U-Boot will find and execute it. This is conceptually identical to creating a GRUB configuration file on a desktop PC.

For a 3.4 kernel you need uImage (linux kernel) and script.bin (binary representation of FEX).

For a device tree based kernel ("mainline", 4.x) you need the kernel image (uImage or zImage) and the device-specific .dtb file (the one referenced in the ${fdtfile} above) that is generated as part of your kernel compilation.

Troubleshooting

USB 1.x, USB keyboards (U-Boot < v2015.07)

U-Boot v2015.07 and later shouldn't have problems supporting mixed USB 1.x/2.0 devices. OHCI and EHCI no longer conflict with each other (after the switch to device model).

Previous U-Boot versions (v2015.04 and older) have a problem supporting both USB 1.x (OHCI) and USB 2.0 (EHCI) at the same time - the latter includes the SUNXI_EHCI driver for Allwinner boards.

Unfortunately, this also affects many USB HID / keyboard devices which would not be detected properly by U-Boot. The typical message in this case is "cannot reset port N!?", where N is whichever USB port those devices were attached to.

A possible workaround is to place an external USB 2.0 hub between your board and these USB devices.

U-Boot 2015.07+ won't start

If you're using a recent (device model based) U-Boot, and the SPL just hangs after initializing the DRAM (CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 or something similar), chances are that your main U-Boot binary may be missing DTB information / a proper device tree. Depending on the (possibly outdated) instructions you followed: double-check that you're not incorrectly using u-boot.bin instead of u-boot-dtb.bin, or u-boot.img instead of u-boot-dtb.img.

Legacy kernel won't start

If your 3.4.x kernel refuses to boot / gets stuck right after "Starting kernel ...": Double-check that bootm_boot_mode is set to "sec"! (see above)

If you don't have a serial console and only use VGA/HDMI/LCD, then it might be also the case of "Unrecognized/unsupported machine ID" (see below).

Unrecognized/unsupported machine ID

The sunxi-3.4 kernel may fail to boot with one of the following error messages on the serial console (but this message is not visible on a HDMI monitor or a LCD display!):

In this case either upgrade to a recent stage/sunxi-3.4 kernel (github branch) - or try to "Enable workarounds for booting old kernels" in U-Boot:

make menuconfig or make CROSS_COMPILE=arm-linux-gnueabihf- menuconfig, the option is located under "ARM architecture". (Make sure to rebuild your U-Boot after changing it.)

If upgrading to stage/sunxi-3.4 is not an option (i.e. using some old and very much diverged
sunxi-3.4 fork is really necessary), then the following patches can be cherry-picked (= selectively merged as a set):

It is required to apply all of them, as they contain important stability/safety changes. The last patch in this series only takes care of the safety guard, which exists there specifically to block booting problematic kernels. Just removing the safety guard alone without applying all the bugfixes will lead to obscure runtime problems, please don't be tempted to do this.

ImportError: No module named _libfdt

If you see the following error when compiling on Arch Linux arm

ImportError: No module named _libfdt

install dtc

sudo pacman -S dtc

Adding a new device to upstream U-Boot

DRAM Settings

Failsafe DRAM settings, based on standard JEDEC timings

Each device has DRAM settings configured in its defconfig file in the U-Boot "configs" directory (here is an example for the Cubietruck board). The slow failsafe DRAM settings for an A10/A13/A20 device may look like:

The settings from the Android firmware

Somewhat better settings can be retrieved by the meminfo tool from the stock Android or GNU/Linux system, provided by the device manufacturer. It still makes sense to test the reliability of the resulting DRAM configuration. Because some vendors are providing poor configuration for ZQ or EMR1, but nevertheless trying to optimistically set the DRAM clock speed too high.

Performance optimized DRAM settings

Tuning DRAM setting for each individual board can provide much better performance than the failsafe defaults. This involves trial and error testing of different settings using a tool until an optimal combination is found. The DRAM Controller page provides links to start researching this topic. This approach will be time consuming, so a satisfactory solution using one of the other approaches may be best to start with.