U-Boot

Support for sunxi devices is increasingly available from upstream U-Boot. This page describes that support. We have a separate page for the sunxi branch of U-Boot.

= Status =

The current u-boot release (v2014.07) only contains basic sunxi support. The next release (v2014.10) will have a much more functionality.

v2014.07
v2014.07 Release branch
 * sun7i (AKA A20) processors
 * MMC
 * GMAC Ethernet
 * Boards:
 * Cubietech Cubietruck

v2014.10 (git)

 * AHCI (SATA)
 * sun4i (AKA A10) and sun5i (AKA A10s and A13) processors
 * EMAC Ethernet
 * AXP152 and AXP209 power controllers
 * EHCI USB
 * SMP support for sun7i via PSCI.

v2015.01 (sunxi/next development)

 * sun6i (A31) processor support
 * Boards:
 * Mele M3
 * Olimex A20-OLinuXino-Lime2
 * WITS Colombus Board

In Progress

 * P2WI
 * AXP221
 * sun8i (A23) processor support
 * sun6i/sun8i reset support
 * Boards:
 * LeMaker Banana Pi

= Supported Devices = 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.

Clone the repository
For u-boot version v2014.10-rc1 and later:

You can clone the u-boot repository by running: git clone git://git.denx.de/u-boot.git

Determine build target
For u-boot version v2014.10-rc1 and later:

Go to your u-boot tree and search in the directory configs/ for your board, the file name looks like _defconfig. So, Cubieboard2_defconfig for the Cubietech Cubieboard2.

You will notice that some  are duplicates, but with _FEL attached. These are for use with USBBoot, while the standard ones will boot from SD.

Build
For u-boot version v2014.10-rc1 and later:

When you have determined what  you want to build, configure: make CROSS_COMPILE=arm-linux-gnueabihf- _defconfig

Then just build it: make CROSS_COMPILE=arm-linux-gnueabihf-

Boot
When the build has completed, there will be u-boot-sunxi-with-spl.bin, spl/sunxi-spl.bin and u-boot.img available in your u-boot tree.

For getting these bits loaded onto the hardware, please refer to the respective howto:
 * SD Card
 * USB

For booting from sd with mainline u-boot and sunxi linux kernel, the recommended way is:


 * create a file boot.cmd on the first partition:

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 fatload mmc 0 0x43000000 script.bin || ext2load mmc 0 0x43000000 boot/script.bin fatload mmc 0 0x48000000 uImage || ext2load mmc 0 0x48000000 uImage boot/uImage bootm 0x48000000


 * convert boot.cmd in boot.scr:

mkimage -C none -A arm -T script -d boot.cmd boot.scr


 * install uboot

dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8


 * copy uImage (linux kernel) to the first partition

Look at Manual build howto for more details.

= Configure U-Boot =

Please refer to our configuring U-Boot howto.

= Adding a new device to upstream U-Boot =

Failsafe DRAM settings, based on standard JEDEC timings
The DDR3 specification from JEDEC defines a set of standard speed bins and provides timings for them. Every DDR3 chip manufacturer is expected to support at least the standard timings, but is naturally allowed to do even better job. The following DRAM configuration for u-boot is based on the standard DDR3-1333H timings (running at 360MHz clock frequency instead of 667MHz): static struct dram_para dram_para = { /* DRAM timings: 6-5-5-13 (360 MHz) */ .clock    = 360, .type     = 3, .rank_num = 1, .cas      = 6, .zq       = 0x7b, .odt_en   = 0, .tpr0     = 0x248d5590, .tpr1     = 0xa088, .tpr2     = 0x22a00, .tpr3     = 0x0, .tpr4     = 0x0, .tpr5     = 0x0, .emr1     = 0x0, .emr2     = 0x0, .emr3     = 0x0, .active_windowing = 1, }; These settings are automatically generated by the a10-dram-timings-calculator script from a10-dram-tools. No attempt is made to enable ODT or configure impedance. Just the DRAM clock frequency is assumed to be low enough to work on any device. If this setup happens to be actually unreliable on some real Allwinner A10/A13/A20 device, then the DRAM clock frequency for the failsafe setup can be reduced even more.

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.

= External links =


 * Our mainline kernel howto.