Loading Images with U-Boot

While U-Boot is used to load and execute the OS after initial programming, it can also be used to program the OS images to the local flash. This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process. Review the U-Boot Overview page for an introduction to U-Boot before continuing.

Requirements

A TFTP server must be accessible on the local network. The specific details of TFTP server setup and configuration can be found on the Installing TFTP server page. Alternatively, NFS can be used in place of TFTP but will require an NFS server. Information on how to set up an NFS server can be found here. Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.

Configuration

In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration or DHCP can be used on some systems (requires DHCP server). Typically, the IP address of the board and the IP address of the TFTP server are the only settings that need to be defined. The network mask and broadcast address will be determined automatically from these settings, and no default gateway setting is required if the server is on the same subnetwork as the board. Before continuing, determine a valid static network address for your local network; contact your IT department for more information on what address to use if required. The example below shows the use of DHCP and setting the TFTP server IP address to 192.168.2.1

U-Boot> dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 DHCP client bound to address 192.168.2.2 (3007 ms) U-Boot> setenv serverip 192.168.2.1

The example below shows how to set a static IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:

U-Boot> setenv ipaddr 192.168.2.2 U-Boot> setenv serverip 192.168.2.1

Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:

U-Boot> ping 192.168.2.1 macb0: link up, 100Mbps full-duplex (lpa: 0x45e1) Using macb0 device host 192.168.2.1 is alive

Loading Images to RAM

Files are loaded directly into RAM through TFTP. In order to load the image, you must know the physical address of the RAM device on the system. Refer to the documentation for your target board if you are unsure what value to use. The U-Boot environment variable loadaddr should already be set and can be used in place of the hex addresses below. The standard addresses for some common EMAC systems are shown in Table 1 below.

Table 1: Physical RAM Addresses
Product	RAM Start Address
SoM-9260M	0x20000000
SoM-9G20M	0x20000000
SoM-9G45M	0x70000000
SoM-3517M	0x82000000
SoM-9x25M	0x22000000
Ipac-9x25M	0x22000000
SoM-9G25M	0x22000000
SoM-A5D35M	0x22000000
SoM-A5D36M	0x22000000
SoM-3354M	0x82000000
SoM-iMX6M	0x12000000
SoM-iMX6UL	0x82000000

WARNING!

Before transferring a file to the system, make sure that it does not exceed the size of the available RAM.

The tftp U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file into and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named uImage-2.6.30 to RAM on an SoM-9G45M.

U-Boot> tftp ${loadaddr} uImage-2.6.30 macb0: link up, 100Mbps full-duplex (lpa: 0x45e1) Using macb0 device TFTP from server 192.168.2.1; our IP address is 192.168.2.2 Filename 'uImage-2.6.30'. Load address: 0x70000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ############################ done Bytes transferred = 1472456 (1677c8 hex) U-Boot> printenv filesize filesize=1677C8

NOTE

Note that the filesize variable has been automatically updated to the size of the file that was loaded.

Executing kernel from RAM

In some situations, it is advantageous to execute the image directly from RAM after loading with TFTP rather than saving to flash. This is especially helpful when testing new Linux kernel images. Furthermore, the boot command can be set such that the image is automatically downloaded and executed on each boot, making testing more efficient.

After loading a bootable image to RAM, you can execute it directly using the bootm command for a uImage kernel or bootz for a zImage kernel. For example, after loading the kernel image above, running bootm 0x70000000 would boot the board using the new image without making any changes to the images stored on the flash.

To update the bootcmd variable to download the image on each boot, simply replace the command used to load the image from flash with the TFTP download command. The following example illustrates this process on an SoM-9G45M module.

U-Boot> printenv bootcmd bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000 U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000' U-Boot> saveenv Saving Environment to dataflash...

Copying to Flash

The process of copying an image from RAM to flash memory differs depending on what type of flash storage devices are available on the system. Many systems have more than one device, such as serial DataFlash and NAND flash. This section explains the process of storing an image to non-volatile storage.

NOR Flash

A combination of the erase and cp commands are used to program an image to a NOR flash device. NOR flash is directly memory-mapped to the system at a physical address. Also, each image (U-Boot, bootstrap, kernel, filesystem) must be stored at the correct offset for the system to operate correctly. Refer to the documentation for your hardware for more information on the correct address ranges to use. The flinfo command can be used to display the addressing of available flash devices on the system.

After loading the image to RAM, the flash device should be erased followed by copying the image to the appropriate offset in the flash. The example below illustrates the commands used to program a new kernel image to a SoM-9260M module. Note the use of the protect off all command, which is required to unlock the flash on some systems.

U-Boot> protect off all U-Boot> tftp 0x20000000 ${kernel_name} U-Boot> erase 0x10100000 0x103fffff U-Boot> cp.b 0x20000000 0x10100000 ${filesize}

NOTE

Note that NOR flash can take a significant amount of time to program if the image size is large.

Serial DataFlash

Serial DataFlash is an SPI-based NOR flash device that is used on many systems that employ NAND flash as the primary storage device. On these systems, low-level boot code such as the bootstrap, U-Boot, and OS kernel are typically stored on the DataFlash device. As with NOR flash, the flinfo command can be used to determine the memory addressing layout of the DataFlash device. The erase command does not support the DataFlash devices and should not be used before programming an image. The cp command is capable of copying an image from RAM to DataFlash.

The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.

U-Boot> tftpboot 0x70000000 ${kernel_name} U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}

NAND Flash

Generally, NAND flash is used to store only the root filesystem and auxiliary storage partitions of the OS. Storing an image to NAND flash under U-Boot uses a different set of commands than NOR or DataFlash devices. See help nand for more information on the available commands for examining and manipulating NAND flash devices. To gain information on what NAND devices are available on the system, use the command nand info. In general, programming a NAND flash device is much faster than programming NOR or DataFlash devices.

The example below illustrates the process of loading the root JFFS2 filesystem onto an SoM-9G45M device. Note that the device is erased prior to programming it.

U-Boot> nand erase U-Boot> tftp 0x70000000 ${rootfs_name} U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}

SPI NOR/eMMC Flash

Most of EMAC's newer SoM offerings utilize an eMMC flash for filesystem and auxiliary storage partitions of the OS and an SPI flash to store the bootloader and kernel. To reprogram the eMMC, see Loading Images onto eMMC Devices. Be sure that the loadaddr variable is set and matches the table above. The example below illustrates the commands used to program a new kernel image to a SoM-9x25M module.

U-Boot> pri loadaddr U-Boot> tftp ${loadaddr} zImage U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize} U-Boot> setenv kernelsize ${filesize};saveenv

Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.

Scripting

U-Boot also includes a scripting feature that allows a script file with U-Boot commands to be loaded and executed. This can make the task of programming multiple systems much more efficient. The mkimage utility is required on a Linux development system in order to create a valid U-Boot image from a script. This section gives a brief example of a U-Boot script for programming a Linux kernel and filesystem.

Creating a text file with all of the desired commands is the first step in creating a U-Boot script. The example below is a script file used by EMAC to program SoM-9260M modules:

echo ===== Setting Environment =====
setenv bootdelay 1
setenv rev sl013-aon-30010
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv kernel_name ${rev}-uImage
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
saveenv
echo ===== Loading Kernel =====
protect off all
tftpboot 0x20000000 ${kernel_name}
erase 0x10100000 0x103fffff
cp.b 0x20000000 0x10100000 ${filesize}
setenv kernelsize ${filesize}
echo ===== Loading Root Filesystem =====
tftpboot 0x20000000 ${rootfs_name}
erase 0x10400000 0x11ffffff
cp.b 0x20000000 0x10400000 ${filesize}
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
saveenv
echo ===== DONE! =====

Once the file has been created and saved, the mkimage utility must be used to create a U-Boot script image. A shell script such as the one shown below may be used to aid in this process:

#!/bin/sh
 
if [ ! -f "$1" ] || [ $# -lt 2 ]
then
        echo "Usage: $0 SCRIPTNAME OUTPUTNAME"
        exit 1
fi
 
mkimage -T script -C none -A arm -n 'SoM9260 Load Script' -d $1 $2

Note that the script assumes that mkimage is installed in the user's PATH. The script should be run with the name of the existing file as the first argument and the desired output filename as the second argument:

developer@ldc:~# ./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img

Once an image file has been created, it should be copied to the TFTP server root directory, in this example /srv/tftp is used.

developer@ldc:~# sudo cp sl013-aon-30010-flash-script.img /srv/tftp/

The image file can now be transferred to the board and executed as illustrated below:

U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img U-Boot> source 0x20000000

NOTE

Note that the U-Boot command source was not available on older versions of U-Boot. If the command is not recognized, use autoscr instead.

U-Boot will execute all commands in the script line-by-line until the script has finished, at which point the U-boot prompt will be returned to the user.

Conclusion

In this article, you have seen how to load an image into RAM using U-Boot. You have seen how to execute an image from RAM. You have also seen how to copy an image from RAM to flash; how to configure your system to boot from an image once it has been saved to flash is documented elsewhere (see Related Information, below). You have also seen a brief description of how to create scripts for U-Boot.

With the information provided by this document, you are set to begin loading alternate kernels and filesystems onto EMAC hardware. These kernels and filesystems could be alternatives provided to you by EMAC, or they could be ones you create yourself. This provides you with a great deal of flexibility for your development work.

Further Information

Where to Go Next

• Loading Linux Kernels Onto a Board
• Loading JFFS2 Images Onto a Board
• Archiving JFFS2 Images

Pages with Related Content

• U-Boot Overview
• Creating JFFS2 Images
• Mounting JFFS2 Images on a Linux PC
• Repartitioning NAND Flash with JFFS2 for Linux
• Loading Images onto eMMC Devices
• Booting with an NFS Root Filesystem