AMSDK u-boot User's Guide

Overview

This document covers the following platforms:

• am335x EVM
• BeagleBone
• am3517 EVM
• am37x
• Beagleboard

For am180x information please see this page.

Starting with the v05.03.00.00 release, the following targets now use SPL to provide the interface between the ROM and full U-Boot in place of x-loader or u-boot-min.

• am335x EVM
• BeagleBone

Starting with the v05.03.01.00 release, the following targets now use SPL as well.

• am3517 EVM
• am37x
• Beagleboard

Building MLO and u-boot

We strongly recommend the use of separate object directories when building. This is done with O= parameter to make. This value can either be relative to your current directory or a full path.

Cleaning the Sources

If you did not use a separate object directory:

$ make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm distclean

If you used 'O=am335x' as your object directory:

$ rm -rf ./am335x

Compiling MLO and u-boot

Building of both u-boot and SPL is done with a single make command. The make target depends on the board in question:

Board	make target
AM335x EVM	am335x_evm
BeagleBone	am335x_evm
AM3517 EVM	am3517_evm
AM37x EVM	omap3_evm
BeagleBoard	omap3_beagle

$ make O=am335x CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm make_target_from_table_above

Installing MLO and u-boot

With a switch to SPL you now need to use u-boot.img and MLO from the build to boot the target. If you are going to load via UART then you may need to use spl/u-boot-spl.bin rather than MLO as when loading via UART the board typically requires a raw binary rather than one with a special header at the start. ced

SD card booting

All targets, when configured to boot from SD card, need MLO and u-boot.img placed onto the SD card in the manner described in the board specific manual.

NAND

First, note that the BeagleBoard xM and BeagleBone do not have NAND and this section does not apply. Second, please see the Additional Information section for further details and explanation for each target.

Note:

• The default layout of the NAND that each supported device supports is the same which is why all of the nand erase and write locations are the same.
• While each board uses the same 'nandecc' command, the mode this sets on the target is not the same. Again, refer to the Additional Information section for details about a specific target.
• This series of commands will write MLO to the default location and then the backup locations that the ROM will look in as well.

The following will load the binaries from an SD card. For other methods (such as UART), please see Additional Information.

U-Boot # mmc rescan
U-Boot # nand erase 0x0 0x280000
U-Boot # saveenv
U-Boot # nandecc hw 2
U-Boot # fatload mmc 0 0x81000000 MLO
U-Boot # nand write 0x81000000 0x0 0x20000
U-Boot # nand write 0x81000000 0x20000 0x20000
U-Boot # nand write 0x81000000 0x40000 0x20000
U-Boot # nand write 0x81000000 0x60000 0x20000
U-Boot # fatload mmc 0 0x81000000 u-boot.img
U-Boot # nand write 0x81000000 0x80000 0x1E0000

Installing the Linux Kernel

NAND

First, note that the BeagleBoard xM and BeagleBone do not have NAND and this section does not apply. Second, please see the Additional Information section for further details and explanation for each target.

The following will load the binaries from an SD card. For other methods (such as UART), please see Additional Information. When issuing the commands please see the following table to see the proper size to erase and nandecc command to issue.

Board	NAND Kernel Partition Size	'nandecc' command
AM335x EVM	0x500000	nandecc hw 2
AM37x EVM	0x500000	nandecc hw 1
AM3517 EVM	0x500000	nandecc hw 1
BeagleBoard	0x400000	nandecc hw 1

U-Boot # mmc rescan
U-Boot # nand erase 0x280000 <NAND Kernel Partition Size>
U-Boot # <nandecc command>
U-Boot # fatload mmc 0 0x81000000 uImage
U-Boot # nand write 0x81000000 0x280000 0x500000

U-Boot Environment

Restoring defaults

It is possible to reset the set of U-Boot environment variables to their defaults, and save them to flash by doing the following:

U-Boot # env default -f
U-Boot # saveenv

NOTE: If you do not issue a saveenv the changes will only exist until reset. This can be useful for testing.

Networking Environment

The default behavior of U-Boot is to utilize all information that a DHCP server passes to us when the user issues the dhcp command. This will include the dhcp parameter next-server which indicates where to fetch files from via TFTP. There may be times however where the dhcp server on your network provides incorrect information and you are unable to modify the server. In this case the following steps can be helpful:

U-Boot # setenv autoload no
U-Boot # dhcp
U-Boot # setenv serverip correct.server.ip
U-Boot # tftp

Another alternative is to utilize the full syntax of the tftp command:

U-Boot # setenv autoload no
U-Boot # dhcp
U-Boot # tftp ${loadaddr} server.ip:fileName