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.
Contents
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
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:
Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
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.
| 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.
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.
| 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.
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.
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.
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.imgOnce 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:
| 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
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
