Linux Core U-Boot User's Guide

From Texas Instruments Wiki
Jump to: navigation, search


Ti stk 1c rev rgb png.png


Overview

This document covers the general use of Linux Core Release of U-Boot on following platforms:

Board Wired ethernet USB gadget ethernet DFU NAND SD/eMMC USB Host (mass storage) SPI flash
AM335x EVM yes yes yes yes yes yes yes
AM335x EVM-SK yes yes yes N/A yes yes N/A
Beaglebone White/Black yes yes yes N/A yes yes N/A
DRA7xx EVM yes no yes yes yes (both) yes yes (QSPI)
AM43xx GP EVM yes no yes yes yes (both) yes yes (QSPI)
AM43xx ePOS EVM yes no yes N/A yes (both) yes yes (QSPI)
AM43xx EVM-SK yes no yes N/A yes (both) yes yes (QSPI)
AM57xx GP EVM yes no no N/A yes (both) yes N/A
K2H/K/E/L EVM yes no no yes no no yes
K2G EVM yes no no yes yes (both) no yes (QSPI)
OMAP-L138 LCDK yes no no yes yes (SD card only) no no

We assume that a GCC-based toolchain has already been installed and the serial port for the board has been configured. We also assume that a Linux Kernel has already been built (or has been provided) as well as an appropriate filesystem image. Installing and setting up DHCP or TFTP servers is also outside of the scope of this document, but snippets of information are provided to show how to use a specific feature, when needed.

Finally, please note that not all boards have all of the interfaces documented here.




General Information

Getting the U-Boot Source Code

The easiest way to get access to the U-boot source code is by downloading and installing the Processor SDK Linux. Once installed, the U-Boot source code is included in the SDK's board-support directory. For your convenience the sources also includes the U-Boot's git repository including commit history.
Alternatively, U-Boot sources can directly be fetched from GIT. The GIT repo URL, branch and commit id can be found in the Processor_SDK_Linux_U-Boot_Release_Notes

Device Trees

A note about device trees. With this LCPD release all boards are required to use a device tree to boot. To facilitate this in Sitara family devices, within U-Boot we have a command in the environment named findfdt that will set the fdtfile variable to the name of the device tree to use, as found with the kernel sources. In the Keystone-2 family devices (K2H/K/E/L/G), it is specified by name_fdt variable for each platform. The device tree is expected to be loaded from the same media as the kernel, and from the same relative path.

Building MLO and u-boot

We strongly recommend the use of separate object directories when building. This is done with O= parameter to make. We also recommend that you use an output directory name that is identical to the configuration target name. That way if you are working with multiple configuration targets it is very easy to know which folder contains the u-boot binaries that you are interested in.

Setting the tool chain path

We strongly recommend using the toolchain that came with the Linux Core release that corresponds to this U-Boot release. For e.g:

export PATH=$HOME/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/bin:$PATH

Cleaning the Sources

If you did not use a separate object directory:

$ make CROSS_COMPILE=arm-linux-gnueabihf- distclean

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

$ rm -rf ./am335x_evm

Compiling MLO and u-boot

Building of both u-boot and SPL is done at the same time. You must however first configure the build for the board you are working with. Use the following table to determine what defconfig to use to configure with:

Board SD Boot eMMC Boot NAND Boot UART Boot Ethernet Boot USB Ethernet Boot USB Host Boot NOR Boot SPI Boot
AM335x GP EVM am335x_evm_defconfig am335x_evm_defconfig am335x_evm_defconfig am335x_evm_defconfig am335x_evm_defconfig am335x_evm_norboot_defconfig am335x_evm_spiboot_defconfig
AM335x EVM-SK am335x_evm_defconfig am335x_evm_defconfig am335x_evm_defconfig
AM335x ICE am335x_evm_defconfig am335x_evm_defconfig
BeagleBone Black am335x_evm_defconfig am335x_evm_defconfig am335x_evm_defconfig
BeagleBone White am335x_evm_defconfig am335x_evm_defconfig
AM437x GP EVM am43xx_evm_defconfig am43xx_evm_defconfig am43xx_evm_defconfig am43xx_evm_defconfig am43xx_evm_defconfig am43xx_evm_usbhost_boot_defconfig
AM437x EVM-Sk am43xx_evm_defconfig am43xx_evm_usbhost_boot_defconfig
AM437x IDK am43xx_evm_defconfig am43xx_evm_qspiboot_defconfig (XIP)
AM437x ePOS EVM am43xx_evm_defconfig am43xx_evm_defconfig am43xx_evm_usbhost_boot_defconfig
AM572x GP EVM am57xx_evm_defconfig am57xx_evm_defconfig
AM572x IDK am57xx_evm_defconfig
AM571x IDK am57xx_evm_defconfig
DRA74x/DRA72x/DRA71x EVM dra7xx_evm_defconfig dra7xx_evm_defconfig dra7xx_evm_defconfig(QSPI)
K2HK EVM k2hk_evm_defconfig k2hk_evm_defconfig k2hk_evm_defconfig k2hk_evm_defconfig
K2L EVM k2l_evm_defconfig k2l_evm_defconfig k2l_evm_defconfig
K2E EVM k2e_evm_defconfig k2e_evm_defconfig k2e_evm_defconfig
K2G GP EVM k2g_evm_defconfig k2g_evm_defconfig k2g_evm_defconfig k2g_evm_defconfig
K2G ICE k2g_evm_defconfig
OMAP-L138 LCDK omapl138_lcdk_defconfig omapl138_lcdk_defconfig

Then:

# Use 'am335x_evm' and 'AM335x GP EVM' in this example
$ make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm am335x_evm_defconfig
$ make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm

Note that not all possible build targets for a given platform are listed here as the community has additional build targets that are not supported by TI. To find these read the 'boards.cfg' file and look for the build target listed above. And please note that the main config file will leverage other files under include/configs, as seen by #include statements.

U-Boot Environment

Please note that on many boards we modify the environment during system start for a variety of variables such as board_name and if unset, ethaddr. When we restore defaults some variables will become unset, and this can lead to other things not working such as findfdt that rely on these run-time set variables.

Restoring defaults

It is possible to reset the set of U-Boot environment variables to their defaults and if desired, save them to where the environment is stored, if applicable. To do so, issue the following commands:

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

Networking Environment

When using a USB-Ethernet dongle a valid MAC address must be set in the environment. To create a valid address please read this page. Then issue the following command:

U-Boot # setenv usbethaddr value:from:link:above

You can use the printenv command to see if usbethaddr is already set.

Then start the USB subsystem:

U-Boot # usb start

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

Working with USB Device Firmware Upgrade

When working with USB Device Firmware Upgrade (DFU), regardless of the medium to be written to and of the board being used, there are some general things to keep in mind. First of all, you will need to get a copy of the dfu-util program installed on your host. If your distribution does not provide this package you will need to build it from source. Second, the examples that follow assume a single board is plugged into the host PC. If you have more than one device plugged in you will need to use the options that dfu-util provides for specifying a single device to work with. Finally, to program via DFU for a given storage device see the section for the storage device you are working with.

USB Peripheral boot mode (SPL-DFU support)

The USB Peripheral boot mode is used to boot the EVM using USB interface using SPL-DFU feature. The steps involved

  1. Enable the SPL-DFU feature in u-boot and build MLO/u-boot binaries.
  2. Load the MLO and u-boot.img using the dfu-util from host PC.
  3. Once the u-boot is up, use DFU command from u-boot to flash the binary images from Host PC (using dfu-utils tool) to the eMMC, or QSPI to fresh/factory boards.
  • Example provided here is for dra7xx platform.
  • Use default "dra7xx_evm_defconfig" to build spl/u-boot-spl.bin, u-boot.img.
 # make dra7xx_evm_defconfig
 # make menuconfig

 select SPL/DFU support
 menuconfig->SPL/TPL--->
    ..
    [*] Support booting from RAM
    [*] Support USB Gadget drivers
    [ ]    Support USB Ethernet drivers
    [*]    Support DFU (Device Firmware Upgrade)
              DFU device selection (RAM device) -->
 Unselect CONFIG_HUSH_PARSER
 menuconfig--->Command Line interface
    [*] Support U-boot commands
    [ ]   Use hush shell
  • Build spl/u-boot-spl.bin and u-boot.img
 # make
  • Set SYSBOOT SW2 switch to USB Peripheral boot mode
 SW2[7..0] = 0010000 (refer to TRM for various booting order)
  • Connect EVM Superspeed port (USB1 port) to PC (Ubuntu) through USB cable.
  • From Ubuntu PC, load spl/u-boot-spl.bin to EVM. Issue below command and reset the board.
$ sudo ./usbboot -S spl/u-boot-spl.bin
  • Load the u-boot.img to RAM.
# sudo dfu-util -l
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=0, name="kernel"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=1, name="fdt"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=2, name="ramdisk"
$ sudo dfu-util c 1 -i 0 -a 0 -D "u-boot.img" -R
  • Now EVM will boot to u-boot prompt.




Using the network (Wired or USB Client)

This section documents how to configure the network and use it to load files and then boot the Linux Kernel using a root filesystem mounted over NFS. At this time, no special builds of U-Boot are required to perform these operations on the supported hardware.

Booting U-Boot from the network

In some cases we support loading SPL and U-Boot over the network because of ROM support. In some cases, a special build of U-Boot may be required. In addition, the DHCP server is needed to reply to the target with the file to fetch via tftp. In order to facilitate this, the vendor-class-identifier DHCP field is filled out by the ROM and the values are listed in the table below. Finally, you will need to use the spl/u-boot-spl.bin and u-boot.img files to boot.

Board make target Supported interfaces ROM vendor-class-identifier value SPL vendor-class-identifier value
AM335x GP EVM am335x_evm CPSW ethernet DM814x ROM (PG1.0) or AM335x ROM (PG2.0 and later) AM335x U-Boot SPL
AM335x GP EVM (PG2.0 and later) am335x_evm SPL and U-Boot via USB RNDIS AM335x ROM AM335x U-Boot SPL
AM335x GP EVM (PG1.0) am335x_evm SPL via UART, U-Boot via USB RNDIS N/A AM335x U-Boot SPL
AM43xx EVM am43xx_evm CPSW ethernet AM43xx ROM AM43xx U-Boot SPL
AM43xx EVM (PG1.2 and later) am43xx_evm SPL and U-Boot via USB RNDIS AM43xx ROM AM43xx U-Boot SPL

If using ISC dhcpd an example host entry would look like this:

host am335x_evm {
  hardware ethernet de:ad:be:ee:ee:ef;
  # Check for PG1.0, typically CPSW
  if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" {
    filename "u-boot-spl.bin";
  # Check for PG2.0, CPSW or USB RNDIS
  } elsif substring (option vendor-class-identifier, 0, 10) = "AM335x ROM" {
    filename "u-boot-spl.bin";
  } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
    filename "u-boot.img";
  } else {
    filename "zImage-am335x-evm.bin";
  }
}

Note that in a factory type setting, the substring tests can be done inside of the subnet declaration to set the default filename value for the subnet, and overriden (if needed) in a host entry.

If you have removed NetworkManager from your system (which is not the default in most distributions) you need to configure your /etc/network/interfaces file thusly:

allow-hotplug usb0
iface usb0 inet static
        address 192.168.1.1
        netmask 255.255.255.0
        post-up service isc-dhcp-server reload

If you are using NetworkManager you need to create two files. First, as root create /etc/NetworkManager/system-connections/AM335x USB RNDIS (and use \ to escape the space) with the following content:


[802-3-ethernet]
duplex=full
mac-address=AA:BB:CC:11:22:33

[connection]
id=AM335X USB RNDIS
uuid=INSERT THE CONTENTS OF 'uuidgen' HERE
type=802-3-ethernet

[ipv6]
method=ignore

[ipv4]
method=manual
addresses1=192.168.1.1;16;

Seccond as root, and ensuring execute permissions, create /etc/NetworkManager/dispatcher.d/99am335x-dhcp-server

#!/bin/sh

IF=$1
STATUS=$2

if [ "$IF" = "usb0" ] && [ "$STATUS" = "up" ]; then
	service isc-dhcp-server reload
fi

A walk through of these steps can be seen at Ubuntu 12.04 Set Up to Network Boot an AM335x Based Platform.

Multiple Interfaces

On some boards, for example when we have both a wired interface and USB RNDIS gadget ethernet, it can be desirable to change from the default U-Boot behavior of cycling over each interface it knows to telling U-Boot to use a single interface. For example, on start you may see lines like:

Net:   cpsw, usb_ether

So to ensure that we use usb_ether first issue the following command:

U-Boot # setenv ethact usb_ether

Network configuration via DHCP

To configure the network via DHCP, use the following commands:

U-Boot # setenv autoload no
U-Boot # dhcp

And ensure that a DHCP server is configured to serve addresses for the network you are connected to.

Manual network configuration

To configure the network manually, the ipaddr, serverip, gatewayip and netmask:

U-Boot # setenv ipaddr 192.168.1.2
U-Boot # setenv serverip 192.168.1.1
U-Boot # setenv gatewayip 192.168.1.1
U-Boot # setenv netmask 255.255.255.0

Disabling Gigabit Phy Advertising

On some boards like DRA72x Rev B or earlier, there is an issue like ethernet doesn't connect to 1Gbps switch. This issue is due to the use of an old ti phy with history of bad behaviour, due to this several J6 EVMs have been marked 100M only. So here is the U-Boot command to disable phy's 1Gbps support and connect as 100Mbps max capable.

=> mii modify 0x3 0x9 0x0 0x300      /* Disable Gigabit advertising */
=> mii modify 0x3 0x0 0x0 0x1000     /* Disable Auto Negotiation */
=> mii modify 0x3 0x0 0x1000 0x1000  /* Enable Auto Negotiation */

Booting Linux from the network

Within the default environment for each board that supports networking there is a boot command called netboot in AM EVMs and boot=net in KS2 EVMs that will automatically load the kernel and boot. For the exact details of each use printenv on the netboot variable and then in turn printenv other sub-sections of the command. The most important variables in AM57x/DRA7x are rootpath and nfsopts, and tftp_root and nfs_root in K2H/K/E/L/G.


Using NAND

This section documents how to write files to the NAND device and use it to load and then boot the Linux Kernel using a root filesystem also found on NAND. At this time, no special builds of U-Boot are required to perform these operations on the supported hardware. Finally, for AM57x/DR7x platforms we assume the files are being loaded from an SD card, and from tftp server for KS2 platforms. Using the network interface (if applicable) is documented above. Please note that for specific boards you may need to perform physical hardware configuration first, please see Linux_Core_NAND_User's_Guide#Board_specific_configurations for more details.

Writing to NAND from U-Boot

Note for AMx/DR7x platforms:

  • From the U-Boot build, the MLO and u-boot.img files are the ones to be written.
  • We load all files from an SD card in this example but they can just as easily be loaded via network (documented above) or other interface that exists.
  • The default layout of the NAND that each supported device supports has the same partition names which is why all of the nand write locations are the same for that section.
  • We use nand erase.chip to ensure everything is erased but when updating an existing setup or only some of the contents nand erase.part should be used instead.
  • This series of commands will write MLO to the default location and then the backup locations that the ROM will look in as well.
Board Config target
AM335x GP EVM am335x_evm_nandboot_config
J6 / J6 Eco EVM dra7xx_evm_nandboot_config
U-Boot # mmc rescan
U-Boot # nand erase.chip
U-Boot # load mmc 0 0x81000000 MLO
U-Boot # nand write 0x81000000 NAND.SPL
U-Boot # nand write 0x81000000 NAND.SPL.backup1
U-Boot # nand write 0x81000000 NAND.SPL.backup2
U-Boot # nand write 0x81000000 NAND.SPL.backup3
U-Boot # load mmc 0 0x81000000 u-boot.img
U-Boot # nand write 0x81000000 NAND.u-boot
U-Boot # load mmc 0 0x81000000 zImage
U-Boot # nand write 0x81000000 NAND.kernel
U-Boot # run findfdt
U-Boot # load mmc 0 0x81000000 $fdtfile
U-Boot # nand write 0x81000000 NAND.u-boot-spl-os
U-Boot # saveenv

Note for K2H/K/E/L/G platforms:

  • From the U-Boot build, the MLO file is the one to be written.
  • We load the file from tftp server in this example.
  • This series of commands will write MLO to the default location.
U-Boot # env default -f -a
U-Boot # setenv serverip <ip address of tftp server>
U-Boot # setenv tftp_root <tftp root directory>
U-Boot # setenv name_uboot MLO
U-Boot # run get_uboot_net
U-Boot # run burn_uboot_nand

After the burn command is completed, power off the EVM and set the SW1 dip switch to ARM NAND boot mode (Please refer to the Hardware Setup Guide of each platform) and power on the EVM. Now, the EVM boots the u-boot image pm the MAMD flash. Please also refer to u-boot/board/ti/ks2_evm/README for more info.

Writing to NAND via DFU

Currently in boards that support using DFU, the default build supports writing to NAND, so no custom build is required. To see the list of available places to write to (in DFU terms, altsettings) use the mtdparts command to list the known MTD partitions and printenv dfu_alt_settings to see how they are mapped and exposed to dfu-util.

U-Boot # mtdparts

device nand0 <nand0>, # parts = 8
 #: name                size            offset          mask_flags
 0: NAND.SPL            0x00020000      0x00000000      0
 1: NAND.SPL.backup1    0x00020000      0x00020000      0
 2: NAND.SPL.backup2    0x00020000      0x00040000      0
 3: NAND.SPL.backup3    0x00020000      0x00060000      0
 4: NAND.u-boot         0x001e0000      0x00080000      0
 5: NAND.u-boot-env     0x00020000      0x00260000      0
 6: NAND.kernel         0x00500000      0x00280000      0
 7: NAND.file-system    0x0f880000      0x00780000      0

active partition: nand0,0 - (SPL) 0x00080000 @ 0x00000000
U-Boot # printenv dfu_alt_info_nand
dfu_alt_info=NAND.SPL part 0 1;NAND.SPL.backup1 part 0 2;NAND.SPL.backup2 part 0 3;NAND.SPL.backup3 part 0 4;NAND.u-boot part 0 5;NAND.kernel part 0 7;NAND.file-system part 0 8

This means that you can tell dfu-util to write anything to any of:

  • NAND.SPL
  • NAND.SPL.backup1
  • NAND.SPL.backup2
  • NAND.SPL.backup3
  • NAND.u-boot
  • NAND.kernel
  • NAND.file-system

Before writing you must erase at least the area to be written to. Then to start DFU on the target on the first NAND device:

U-Boot # nand erase.chip
U-Boot # setenv dfu_alt_info ${dfu_alt_info_nand}
U-Boot # dfu 0 nand 0

Then on the host PC to write MLO to the first SPL partition:

$ sudo dfu-util -D MLO -a NAND.SPL

Booting from NAND

Within the default environment for each board that supports nand there is a boot command called nandboot that will automatically load the kernel and boot. For the exact details of each use printenv on the nandboot variable and then in turn printenv other sub-sections of the command. The most important variables for AMx/DR7x platforms are nandroot and nandrootfstype. For Keystone-2 platforms, it is configured to be ARM NAND boot mode using SW1 dip switch setting. Please refer to the Hardware Setup of each Keystone-2 EVM.

Using SD, eMMC or USB storage

The commands for using SD cards, eMMC flash and USB mass storage devices (hard drives, flash drives, card readers, etc) are all very similar. The biggest difference is that on some hardware we may not be able to run U-Boot out of ROM from the storage device as it is unsupported. Once U-Boot is running however, any of these may be used for the kernel and the root filesystem.

Partitioning eMMC from U-Boot

The eMMC device typically ships without any partition table. We make use of the GPT support in U-Boot to write a GPT partition table to eMMC. In this case we need to use the uuidgen program on the host to create the UUIDs used for the disk and each partition.

$ uuidgen
...first uuid...
$ uuidgen
...second uuid...
U-Boot # printenv partitions
uuid_disk=${uuid_gpt_disk};name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
U-Boot # setenv uuid_gpt_disk ...first uuid...
U-Boot # setenv uuid_gpt_rootfs ...second uuid...
U-Boot # gpt write mmc 1 ${partitions}

A reset is required for the partition table to be visible.

Updating an SD card from a host PC

This section assume that you have created an SD card following the instructions on Sitara Linux SDK create SD card script or have made a compatible layout by hand. In this case, you will need to copy the MLO and u-boot.img files to the boot partition. At this point, the card is now bootable in the SD card slot. We default to using /boot/zImage on the rootfs partition and the device tree file loaded from /boot with the same name as in the kernel.

However, if you are using OMAP-L138 based board (like the LCDK), then you need to write the generated u-boot.ais image to the SD card using dd command.

 $ sudo dd if=u-boot.ais of=/dev/sd<N> seek=117 bs=512 conv=fsync




Updating an SD card or eMMC using DFU

To see the list of available places to write to (in DFU terms, altsettings) use the mmc part command to list the partitions on the MMC device and printenv dfu_alt_settings_mmc or dfu_alt_settings_emmc to see how they are mapped and exposed to dfu-util.

U-Boot# mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

Partition     Start Sector     Num Sectors     Type
    1                   63          144522       c Boot
    2               160650         1847475      83
    3              2024190         1815345      83
U-Boot# printenv dfu_alt_info_mmc
dfu_alt_info=boot part 0 1;rootfs part 0 2;MLO fat 0 1;u-boot.img fat 0 1;uEnv.txt fat 0 1"

This means that you can tell dfu-util to write anything to any of:

  • boot
  • rootfs
  • MLO
  • u-boot.img
  • uEnv.txt

And that the MLO, u-boot.img and uEnv.txt files are to be written to a FAT filesystem.

To start DFU on the target on the first MMC device:

U-Boot # setenv dfu_alt_info ${dfu_alt_info_mmc}
U-Boot # dfu 0 mmc 0

On boards like AM57x GP EVM or BeagleBoard x15, where the second USB instance is used as USB client, the dfu command becomes:

U-Boot # dfu 1 mmc 0

Then on the host PC to write MLO to an existing boot partition:

$ sudo dfu-util -D MLO -a MLO

On the host PC to overwrite the current boot partition contents with a new created on the host FAT filesystem image:

$ sudo dfu-util -D fat.img -a boot

Updating an SD card or eMMC with RAW writes

In some cases it is desirable to write MLO and u-boot.img as raw images to the MMC device rather than in a filesystem. eMMC requires this, for example. In that case, the following is how to program these files and not overwrite the partition table on the device. We assume that the files exist on a SD card. In addition you may wish to write a filesystem image to the device, so an example is also provided.

U-Boot # mmc dev 0
U-Boot # mmc rescan
U-Boot # mmc dev 1
U-Boot # fatload mmc 0 ${loadaddr} MLO
U-Boot # mmc write ${loadaddr} 0x100 0x100
U-Boot # mmc write ${loadaddr} 0x200 0x100
U-Boot # fatload mmc 0 ${loadaddr} u-boot.img
U-Boot # mmc write ${loadaddr} 0x300 0x400
U-Boot # fatload mmc 0 ${loadaddr} rootfs.ext4
U-Boot # mmc write ${loadaddr} 0x1000 ...rootfs.ext4 size in bytes divided by 512, in hex...

Booting Linux from SD card or eMMC

Within the default environment for each board that supports SD/MMC there is a boot command called mmcboot that will set the boot arguments correctly and start the kernel. In this case however, you must first run loaduimagefat or loaduimage to first load the kernel into memory. For the exact details of each use printenv on the mmcboot, loaduimagefat and loaduimage variables and then in turn printenv other sub-sections of the command. The most important variables here are mmcroot and mmcrootfstype.

Booting Linux from USB storage

To load the Linux Kernel and rootfs from USB rather than SD/MMC card on AMx/DRA7x EVMs, if we assume that the USB device is partitioned the same way as an SD/MMC card is, we can utilize the mmcboot command to boot. To do this, perform the following steps:

U-Boot # usb start
U-Boot # setenv mmcroot /dev/sda2 ro
U-Boot # run mmcargs
U-Boot # run bootcmd_usb

On K2H/K/E/L EVMs, the USB drivers in Kernel needs to be built-in (default modules). The configuration changes are:

CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_STORAGE=y
CONFIG_USB_DWC3=y
CONFIG_USB_DWC3_HOST=y
CONFIG_USB_DWC3_KEYSTONE=y
CONFIG_EXTCON=y
CONFIG_EXTCON_USB_GPIO=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y

The USB should have boot partition of FAT32 format, and rootfs partition of EXT4 format. The boot partition must contain the following images:

keystone-<platform>-evm.dtb
skern-<platform>.bin
k2-fw-initrd.cpio.gz
zImage

where <platform>=k2hk, k2e, k2l

The rootfs partition contains the filesystem from ProcSDK release package.

# mkdir /mnt/temp
# mount -t ext4 /dev/sdb2 /mnt/temp
# cd /mnt/temp
# tar xvf <Linux_Proc_Sdk_Install_DIR>/filesyste/tisdk-server-rootfs-image-k2hk-evm.tar.xz
# cd /mnt
# umount temp

Set up the following u-boot environment variables:

setenv args_all 'setenv bootargs console=ttyS0,115200n8 rootwait'
setenv args_usb 'setenv bootargs ${bootargs} rootdelay=3 rootfstype=ext4 root=/dev/sda2 rw'
setenv get_fdt_usb 'fatload usb 0:1 ${fdtaddr} ${name_fdt}'		
setenv get_kern_usb 'fatload usb 0:1 ${loadaddr} ${name_kern}'
setenv get_mon_usb 'fatload usb 0:1 ${addr_mon} ${name_mon}'
setenv init_fw_rd_usb 'fatload usb 0:1 ${rdaddr} ${name_fw_rd}; setenv filesize <hex_len>; run set_rd_spec'
setenv init_usb 'usb start; run args_all args_usb'
setenv boot usb
saveenv
boot

NoteNote: : <hex_len> must be at least the hex size of the k2-fw-initrd.cpio.gz file size.




Using SPI

This section documents how to write files to the SPI device and use it to load and then boot the Linux Kernel using a root filesystem also found on SPI. At this time, no special builds of U-Boot are required to perform these operations on the supported hardware. The table below however, lists builds that will also use the SPI flash for the environment instead of the default, which typically is NAND in AM57x and DRA7x EVMs, but in Keystone-2 EVMs, it is only NOR. Finally, for simplicity we assume the files are being loaded from an SD card. Using the network interface (if applicable) is documented above.

Writing to SPI from U-Boot

Note for AM57x and DRA7x platforms:

  • From the U-Boot build, the MLO.byteswap and u-boot.img files are the ones to be written.
  • We load all files from an SD card in this example but they can just as easily be loaded via network (documented above) or other interface that exists.
  • At this time the SPI mtd partition map has not yet been updated to include an example location for the device tree.
Board Config target
AM335x EVM am335x_evm_spiboot_config
U-Boot # mmc rescan
U-Boot # sf probe 0
U-Boot # sf erase 0 +80000
U-Boot # fatload mmc 0 ${loadaddr} MLO.byteswap
U-Boot # sf write ${loadaddr} 0 ${filesize}
U-Boot # fatload mmc 0 ${loadaddr} u-boot.img
U-Boot # sf write ${loadaddr} 0x20000 ${filesize}
U-Boot # sf erase 80000 +${spiimgsize}
U-Boot # fatload mmc 0 ${loadaddr} zImage
U-Boot # sf write ${loadaddr} ${spisrcaddr} ${filesize}

Note for Keystone-2 (K2H/K/E/L/G) platforms:

  • From the U-Boot build, the u-boot-spi.gph file is the one to be written.
  • We load the file from a tftp server via netowrk in this example.
  • The series commands burns the u-boot image to the SPI NOR flash
U-Boot # env default -f -a
U-Boot # setenv serverip <ip address of tftp server>
U-Boot # setenv tftp_root <tftp root directory>
U-Boot # setenv name_uboot u-boot-spi.gph
U-Boot # run get_uboot_net
U-Boot # run burn_uboot_spi

Booting from SPI

Within the default environment for each board that supports SPI there is a boot command called spiboot that will automatically load the kernel and boot. For the exact details of each use printenv on the spiboot variable and then in turn printenv other sub-sections of the command. The most important variables here are spiroot and spirootfstype. For Keystone-2 platforms, it is configured to be ARM SPI boot mode using SW1 dip switch setting. Please refer to the Hardware Setup of each Keystone-2 EVM.

Using QSPI

QSPI is a serial peripheral interface like SPI the major difference being the support for Quad read, uses 4 data lines for read compared to 2 lines used by the traditional SPI. This section documents how to write files to the QSPI device and use it to load and then boot the Linux Kernel using a root filesystem also found on QSPI. At this time, no special builds of U-Boot are required to perform these operations on the supported hardware. For simplicity we assume the files are being loaded from an SD card. Using the network interface (if applicable) is documented above.


DRA7xx support

Memory Layout of QSPI Flash

+----------------+ 0x00000
|      MLO       |
|                |
+----------------+ 0x040000
|   u-boot.img   |
|                |
+----------------+ 0x140000
|   DTB blob     |
+----------------+ 0x1c0000
|   u-boot env   |
+----------------+ 0x1d0000
|   u-boot env   |
|    (backup)    |
+----------------+ 0x1e0000
|                |
|     uImage     |
|                |
|                |
+----------------+ 0x9e0000
|                |
|  other data    |
|                |
+----------------+

Writing to QSPI from U-Boot

Note:

  • From the U-Boot build, the MLO and u-boot.img files are the ones to be written.
  • We load all files from an SD card in this example but they can just as easily be loaded via network (documented above) or other interface that exists.

Writing MLO and u-boot.img binaries.

For QSPI_1
 BUild uboot with dra7xx_evm_config
U-Boot # mmc rescan
U-Boot # fatload mmc 0 ${loadaddr} MLO
U-Boot # sf probe 0
U-Boot # sf erase 0x00000 0x100000
U-Boot # sf write ${loadaddr} 0x00000 ${filesize}
U-Boot # fatload mmc 0 ${loadaddr} u-boot.img
U-Boot # sf write ${loadaddr} 0x40000 ${filesize}
change SW2[5:0] = 110110 for qspi boot.

For QSPI_4
Build uboot with dra7xx_evm_qspiboot_config
U-Boot # mmc rescan
U-Boot # fatload mmc 0 ${loadaddr} MLO
U-Boot # sf probe 0
U-Boot # sf erase 0x00000 0x100000
U-Boot # sf write ${loadaddr} 0x00000 0x10000
U-Boot # fatload mmc 0 ${loadaddr} u-boot.img
U-Boot # sf write ${loadaddr} 0x40000 0x60000
change SW2[5:0] = 110111 for qspi boot.

Writing to QSPI using DFU

Setup: Connect the usb0 port of EVM to ubuntu host PC. Make sure dfu-util tool is installed.

 #sudo apt-get install dfu-util

From u-boot:

U-Boot # env default -a
U-Boot # setenv dfu_alt_info ${dfu_alt_info_qspi}; dfu 0 sf "0:0:64000000:0"

From ubuntu PC: Using dfu-util utilities to flash the binares to QSPI flash.

# sudo dfu-util -l
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=0, name="MLO"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=1, name="u-boot.img"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=2, name="u-boot-spl-os"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=3, name="u-boot-env"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=4, name="u-boot-env.backup"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=5, name="kernel"

Flash the binaries to the respective regions using alternate interface number (alt=<x>).

# sudo dfu-util -c 1 -i 0 -a 0 -D MLO
# sudo dfu-util -c 1 -i 0 -a 1 -D u-boot.img
# sudo dfu-util -c 1 -i 0 -a 2 -D <DTB-file>
# sudo dfu-util -c 1 -i 0 -a 5 -D uImage

Booting from QSPI from u-boot

The default environment does not contain a QSPI boot command. The following example uses the partition table found in the kernel.

U-Boot # sf probe 0
U-Boot # sf read ${loadaddr} 0x1e0000 0x800000
U-Boot # sf read ${fdtaddr} 0x140000 0x80000
U-Boot # setenv bootargs console=${console} root=/dev/mtdblock19 rootfstype=jffs2
U-Boot # bootz ${loadaddr} - ${fdtaddr}

Booting from QSPI from SPL (Single stage or Falcon mode)

In this boot mode SPL (first stage bootloader) directly boots the Linux kernel. Optionally, in order to enter into U-Boot, reset the board while keeping 'c' key on the serial terminal pressed. When falcon mode is enabled in U-Boot build (usually enabled by default), MLO checks if there is a valid uImage present at a defined offset. If uImage is present, it is booted directly. If valid uImage is not found, MLO falls back to booting u-boot.img.

MLO, u-boot.img (optional), DTB, uImage are stored in QSPI flash memory. Refer the "Memory Layout" section for offset details. To flash binaries to QSPI, you can use DFU, for example.

The QSPI boot uses uImage. Build the kernel uImage. You will need to keep the U-Boot tool mkimage in your $PATH

# make uImage modules dtbs LOADADDR=80008000

If kernel is not build with CONFIG_CMDLINE to set correct bootargs, then add the needed bootargs in chosen node in DTB file, using fdtput host utility. For example, for DRA74x EVM:

# fdtput -v -t s arch/arm/boot/dts/dra7-evm.dtb "/chosen" bootargs "console=ttyO0,115200n8 root=<rootfs>"

Set the board boot from QSPI and reset the EVM. The SPL directly boots the kernel image from QSPI.




AM43xx support

Using QSPI on AM43xx platforms is done as eXecute In Place and U-Boot is directly booted.

Writing to QSPI from U-Boot

Note:

  • From the U-Boot build the u-boot.bin file is the one to be written.
  • We load all files from an SD card in this example but they can just as easily be loaded via network (documented above) or other interface that exists.
U-Boot # mmc rescan
U-Boot # fatload mmc 0 ${loadaddr} u-boot.bin
U-Boot # sf probe 0
U-Boot # sf erase 0x0 0x100000
U-Boot # sf write ${loadaddr} 0x0 ${filesize}

Booting from QSPI

The default environment does not contain a QSPI boot command. The following example uses the partition table found in the kernel.

U-Boot # sf probe 0
U-Boot # sf read ${loadaddr} 0x1a0000 0x800000
U-Boot # sf read ${fdtaddr} 0x100000 0x80000
U-Boot # setenv bootargs console=${console} spi-ti-qspi.enable_qspi=1 root=/dev/mtdblock6 rootfstype=jffs2
U-Boot # bootz ${loadaddr} - ${fdtaddr}




Using NOR

This section documents how to write files to the NOR device and use it to load and then boot the Linux Kernel using a root filesystem also found on NOR. In order for NOR to be visible to U-Boot a special build of U-Boot is required on the supported hardware. The table below lists builds that see NOR and in some cases also use theit for the environment instead of the default, which typically is NAND. Finally, for simplicity we assume the files are being loaded from an SD card. Using the network interface (if applicable) is documented above.

Writing to NOR from U-Boot

Note:

  • From the U-Boot build, the u-boot.bin file is the one to be written.
  • We load all files from an SD card in this example but they can just as easily be loaded via network (documented above) or other interface that exists.
  • At this time the NOR mtd partition map has not yet been updated to include an example location for the device tree.
Board Config target
AM335x EVM am335x_evm_nor_config / am335x_evm_norboot_config
U-Boot # mmc rescan
U-Boot # load mmc 0 ${loadaddr} u-boot.bin
U-Boot # protect off 08000000 +4c0000
U-Boot # erase 08000000 +4c0000
U-Boot # cp.b ${loadaddr} 08000000 ${filesize}
U-Boot # fatload mmc 0 ${loadaddr} zImage
U-Boot # cp.b ${loadaddr} 080c0000 ${filesize}

Booting from NOR

Within the default environment there is not a shortcut for booting. One needs to pass root=/dev/mtdblockN where N is the number of the rootfs partition in bootargs.

Using UART

This section documents how to use the UART to load files to boot the board into U-Boot. After that the user is expected to know how they want to continue loading files.

Booting U-Boot from the console UART

In some cases we support loading SPL and U-Boot over the console UART. You will need to use the spl/u-boot-spl.bin and u-boot.img files to boot. As per the TRM, the file is to be loaded via the X-MODEM protocol at 115200 baud 8 stop bits no parity (same as using it for console). SPL in turn expects to be sent u-boot.img at the same rate but via Y-MODEM. An example session from the host PC, assuming console is on ttyUSB0 and already configured would be and the lrzsz package is installed

$ sx -kb /path/to/u-boot-spl.bin < /dev/ttyUSB0 > /dev/ttyUSB0
$ sx -kb --ymodem /path/to/u-boot.img < /dev/ttyUSB0 > /dev/ttyUSB0

Archived

Sitara Linux 07.0X U-boot User's Guide