U-Boot/Legacy U-Boot

U-boot is the bootloader commonly used on our allwinner SoCs. Amongst others, it provides the basic infrastructure to bring up a board to a point where it can load a linux kernel and start booting your operating system.

= 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
You can clone our u-boot repository by running:

git clone https://github.com/linux-sunxi/u-boot-sunxi.git

This should checkout the sunxi branch, which allows booting from SD, over  USB and over  ethernet, but it still lacks support for booting off the NAND. For more information about booting from NAND, check the NAND howto.

Determine build target
You can list the available u-boot targets by running:

grep sunxi boards.cfg | awk '{print $7}'

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

Build
When you have determined what target you want to build, configure:

make CROSS_COMPILE=arm-linux-gnueabihf- {TARGET}_config

Then just build it:

make CROSS_COMPILE=arm-linux-gnueabihf-

You might want to add '-j4' to make use of 4 processors (or any number that matches your system), to speed up the build.

Boot
When the build has completed, there will be 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
 * Ethernet
 * NAND

= Configure U-Boot =

Setting environment variables
There is a difference in setting environment variables between the boot script and the u-boot shell.

Inside the shell you would set, for instance: setenv root /dev/sda1

But in the script you would use: root=/dev/sda1

SD Card
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 ${extra} ext2load mmc 0 0x43000000 script.bin ext2load mmc 0 0x48000000 uImage bootm 0x48000000

NAND
Example u-boot environment from a stock android u-boot environment partition

bootdelay=0 bootcmd=run setargs boot_normal console=ttyS0,115200 nand_root=/dev/nandc mmc_root=/dev/mmcblk0p4 init=/init loglevel=8 setargs=setenv bootargs console=${console} root=${nand_root} init=${init} loglevel=${loglevel} boot_normal=nand read 40007800 boot;boota 40007800 boot_recovery=nand read 40007800 recovery;boota 40007800 boot_fastboot=fastboot

NFS
Recent version of u-boot are able to boot from NFS as well as TFTP, but you have to get rid of the automatic setup of FTP. Check Ethernet for more information.

Note: on the A20 based cubieboards, this only seems to work on the stable kernel, not on stage.

= Adding a new device to U-Boot =

dram config
With the output from bootinfo or  a10-meminfo, you can now create a dram file for your device in board/sunxi/ The output from either program trivially applies to a u-boot sunxi dram file.

First, try to match your settings with an existing dram file. There are a lot of generic dram files available for a10, perhaps one of those matches your config. If an existing board config for another device matches yours, then please consider turning this into a generic dram file.

If nothing matches, copy an existing file to a filename relevant for your device and edit the entries manually. Do not forget to git add this new file.

Add dram file to build system
Edit board/sunxi/Makefile to add a line which links your device with the right dram_ object.

Add board to boards.cfg
boards.cfg, in the top level of your u-boot tree, holds all board configurations.

Scroll down until you find the sunxi devices, and create an entry for your device.

Build and run the new u-boot
That's it. You should now be able to compile and  test u-boot. It makes sense to also get a kernel and operating system running to more completely test the u-boot dram settings before committing code.

Commit your work to the git tree and send in the patch
You can now commit your changes, and with: git format-patch -M -C HEAD^

You will create a git mbox patch file which you can mail to our mailinglist. If you have set up git correctly, you can just run: git send-email 0001-*.patch