Difference between revisions of "Loading Images with U-Boot"

From wiki.emacinc.com
Jump to: navigation, search
(Added SPI NOR section)
(12 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{todo|SEOKWREV; (12.16.13-01:25->MD-);(12.31.13-11:02->MW+);(12.31.13-11:30->KY+);(12.31.13-11:35->MG+);(03.06.14-15:30->BS-);(04.11.14-15:55->BS+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,SEOKWREV}}
 
 
 
{{#seo:
 
{{#seo:
 
|title=Loading Images with U-Boot
 
|title=Loading Images with U-Boot
Line 10: Line 8:
  
 
== Requirements ==
 
== 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.
+
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 [[Setting_up_an_NFS_File_Server | can be found here]].  Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.
  
 
== Configuration ==
 
== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration is recommended, although DHCP can be used on some systems. 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 how to set the IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:
+
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 how to set the 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
+
{{clop}}<nowiki>U-Boot> setenv ipaddr 192.168.2.2
U-Boot> setenv serverip 192.168.2.1
+
U-Boot> setenv serverip 192.168.2.1
U-Boot> saveenv
+
U-Boot> saveenv
Saving Environment to dataflash...
+
Saving Environment to dataflash...
U-Boot> reset
+
U-Boot> reset</nowiki>{{closp}}
  
 
Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
 
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
+
{{clop}}<nowiki>U-Boot> ping 192.168.2.1
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
+
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
+
Using macb0 device
host 192.168.2.1 is alive
+
host 192.168.2.1 is alive</nowiki>{{closp}}
  
 
== Loading Images to RAM ==
 
== Loading Images to RAM ==
Files are loaded directly into RAM from 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 standard addresses for some common EMAC systems are shown in Table 1 below.
+
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 <code>loadaddr</code> 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.
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 53: Line 51:
 
|-
 
|-
 
| SoM-3354M || 0x82000000
 
| SoM-3354M || 0x82000000
 +
|-
 +
| SoM-iMX6M || 0x12000000
 +
|-
 +
| SoM-iMX6UL || 0x82000000
 
|}
 
|}
  
{{mbox | type = warning | text = Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}
+
{{ warning | Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}
  
The <code>tftp</code> U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file to and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
+
The <code>tftp</code> 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 <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
U-Boot> tftp 0x70000000 uImage-2.6.30
+
{{clop}}<nowiki>U-Boot> tftp ${loadaddr} uImage-2.6.30
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
+
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
+
Using macb0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
+
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage-2.6.30'.
+
Filename 'uImage-2.6.30'.
Load address: 0x70000000
+
Load address: 0x70000000
Loading: #################################################################
+
Loading: #################################################################
          #################################################################
+
        #################################################################
          #################################################################
+
        #################################################################
          #################################################################
+
        #################################################################
          ############################
+
        ############################
done
+
done
Bytes transferred = 1472456 (1677c8 hex)
+
Bytes transferred = 1472456 (1677c8 hex)
U-Boot> printenv filesize
+
U-Boot> printenv filesize
filesize=1677C8
+
filesize=1677C8</nowiki>{{closp}}
  
{{mbox | type = notice | text = Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}
+
{{ note | Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}
  
 
== Executing kernel from RAM ==
 
== 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.
 
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 <code>bootm</code> command. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.
+
After loading a bootable image to RAM, you can execute it directly using the <code>bootm</code> command for a uImage kernel or <code>bootz</code> for a zImage kernel. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.
  
 
To update the <code>bootcmd</code> 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.
 
To update the <code>bootcmd</code> 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
+
{{clop}}<nowiki>U-Boot> printenv bootcmd
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
+
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
+
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
U-Boot> saveenv
+
U-Boot> saveenv
Saving Environment to dataflash...
+
Saving Environment to dataflash...</nowiki>{{closp}}
  
 
== Copying to Flash ==
 
== Copying to Flash ==
Line 95: Line 97:
  
 
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 <code>protect off all</code> command, which is required to unlock the flash on some systems.
 
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 <code>protect off all</code> command, which is required to unlock the flash on some systems.
U-Boot> protect off all
+
{{clop}}<nowiki>U-Boot> protect off all
U-Boot> tftp 0x20000000 ${kernel_name}
+
U-Boot> tftp 0x20000000 ${kernel_name}
U-Boot> erase 0x10100000 0x103fffff
+
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}
+
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}</nowiki>{{closp}}
  
{{mbox | type = notice | text = Note that NOR flash can take a significant amount of time to program if the image size is large.}}
+
{{ note | Note that NOR flash can take a significant amount of time to program if the image size is large.}}
  
 
=== Serial DataFlash ===
 
=== Serial DataFlash ===
Line 106: Line 108:
  
 
The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.
 
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}
+
{{clop}}<nowiki>U-Boot> tftpboot 0x70000000 ${kernel_name}
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}
+
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}</nowiki>{{closp}}
  
 
=== NAND Flash ===
 
=== NAND Flash ===
Line 113: Line 115:
  
 
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.
 
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
+
{{clop}}<nowiki>U-Boot> nand erase
U-Boot> tftp 0x70000000 ${rootfs_name}
+
U-Boot> tftp 0x70000000 ${rootfs_name}
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}
+
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}</nowiki>{{closp}}
  
 
=== SPI NOR/eMMC Flash ===
 
=== 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|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.
+
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|Loading Images onto eMMC Devices]]. Be sure that the <code>loadaddr</code> 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
+
{{clop}}<nowiki>U-Boot> pri loadaddr
U-Boot> tftp ${loadaddr} zImage
+
U-Boot> tftp ${loadaddr} zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
+
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
U-Boot> set kernelsize ${filesize};saveenv
+
U-Boot> setenv kernelsize ${filesize};saveenv</nowiki>{{closp}}
 +
 
 +
Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.
  
 
== Scripting ==
 
== Scripting ==
Line 128: Line 132:
  
 
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:
 
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 =====
+
<syntaxhighlight lang=php>
setenv bootdelay 1
+
echo ===== Setting Environment =====
setenv rev sl013-aon-30010
+
setenv bootdelay 1
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
+
setenv rev sl013-aon-30010
setenv kernel_name ${rev}-uImage
+
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
+
setenv kernel_name ${rev}-uImage
saveenv
+
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
echo ===== Loading Kernel =====
+
saveenv
protect off all
+
echo ===== Loading Kernel =====
tftpboot 0x20000000 ${kernel_name}
+
protect off all
erase 0x10100000 0x103fffff
+
tftpboot 0x20000000 ${kernel_name}
cp.b 0x20000000 0x10100000 ${filesize}
+
erase 0x10100000 0x103fffff
setenv kernelsize ${filesize}
+
cp.b 0x20000000 0x10100000 ${filesize}
echo ===== Loading Root Filesystem =====
+
setenv kernelsize ${filesize}
tftpboot 0x20000000 ${rootfs_name}
+
echo ===== Loading Root Filesystem =====
erase 0x10400000 0x11ffffff
+
tftpboot 0x20000000 ${rootfs_name}
cp.b 0x20000000 0x10400000 ${filesize}
+
erase 0x10400000 0x11ffffff
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
+
cp.b 0x20000000 0x10400000 ${filesize}
saveenv
+
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
echo ===== DONE! =====
+
saveenv
 +
echo ===== DONE! =====
 +
</syntaxhighlight>
  
 
Once the file has been created and saved, the <code>mkimage</code> 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:
 
Once the file has been created and saved, the <code>mkimage</code> 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:
Line 163: Line 169:
  
 
Note that the script assumes that <code>mkimage</code> 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:
 
Note that the script assumes that <code>mkimage</code> 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:
./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img
+
{{cli|username=developer|hostname=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 <code>/srv/tftp</code> is used.
 +
{{cli|username=developer|hostname=ldc|sudo cp sl013-aon-30010-flash-script.img /srv/tftp/}}
  
Once an image file has been created, it can be transferred to the board and executed as illustrated below:
+
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
+
{{clop}}<nowiki>U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img
U-Boot> source 0x20000000
+
U-Boot> source 0x20000000</nowiki>{{closp}}
  
{{mbox | type = notice | text = Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> instead.}}
+
{{ note | Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> 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.
 
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      ******************************************/ -->
 +
<!-- /*********************************************************************************************************/ -->
 +
{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
 +
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.
 +
 +
<!-- /*********************************************************************************************************/ -->
 +
<!-- /******************************************  More Information  *****************************************/ -->
 +
<!-- /*********************************************************************************************************/ -->
 +
{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
 +
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]
 +
* [[Loading_JFFS2_Images_Onto_a_Board | Loading JFFS2 Images Onto a Board]]
 +
* [[Archiving_JFFS2_Images | Archiving JFFS2 Images]]
 +
 +
{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
 +
* [[U-Boot_Overview | U-Boot Overview]]
 +
* [[Creating_JFFS2_Images | Creating JFFS2 Images]]
 +
* [[Mounting_JFFS2_Images_on_a_Linux_PC | Mounting JFFS2 Images on a Linux PC]]
 +
* [[Repartitioning_NAND_Flash_with_JFFS2_for_Linux | Repartitioning NAND Flash with JFFS2 for Linux]]
 +
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
 +
* [[Booting_with_an_NFS_Root_Filesystem | Booting with an NFS Root Filesystem]]
  
  
 
<!--[[Category:Bootloaders]]-->
 
<!--[[Category:Bootloaders]]-->

Revision as of 14:26, 15 April 2019

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 how to set the 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 U-Boot> saveenv Saving Environment to dataflash... U-Boot> reset

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
Pages with Related Content