Timesys Getting Started Guide for Xilinx ZYNQ-7000 EPP


Contents

Introduction

This document will describe in detail the procedures for booting a Linux kernel image and mounting a root file system over NFS on the Xilinx ZYNQ-7000 EPP ZC702/ZC706 Evaluation Kit.

Note: For users of the LinuxLink Web Factory, the same steps for creating a bootable image and booting the Zynq apply to Web Build output. This procedure is described in section 5.1

Prerequisites

Host Requirements

To properly boot a board using software from Timesys, your host machine must meet the following requirements:

  • Modern GNU/Linux Distribution. While you can use nearly any modern Linux distribution released in the last 24 months, Timesys recommends one of the following:
    • Ubuntu (Most recent release or LTS)
    • Fedora (Most recent release)
  • An internet connection on the Development Host.
  • Root or sudo permission on the Development Host.
  • A copy of the Linux Kernel (uImage-4.4-ts-armv7l) and Root File System (rootfs.tar.gz) for the Target Board downloaded from Factory. These are found in the output directory of your online build, or in the directory build_armv7l-timesys-linux-<libc>/images/ on the command line.
  • If you are booting your root file system over the network, you will need two network cards installed and configured in the Development Host. One to communicate normally with your LAN/WAN while installing host packages, the other to communicate solely with the target board.
  • An available serial port on your Development Host.

Xilinx Vivado 2016.2

The Xilinx Vivado 2016.2 Design Suite is required to produce bootable images from Timesys Factory output. This will be included with your hardware evaluation kit; if not you may download from the following location: https://secure.xilinx.com/webreg/register.do?group=dlc&htmlfile=&emailFile=&cancellink=&eFrom=&eSubject=&version=2016.2&akdm=0&filename=Xilinx_Vivado_SDK_2016.2_0605_1_Lin64.bin Xilinx Vivado 2016.2 Web Installer *Registration is required.

Instructions for installing can be found at this link http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug973-vivado-release-notes-install-license.pdf.

Target Requirements

To boot the Xilinx ZYNQ-7000 EPP ZC702/ZC706 Evaluation Kit, you will need the following items:

  • Xilinx ZYNQ-7000 EPP ZC702/ZC706 Evaluation Kit Board
  • 12v Power Supply
  • USBA/MiniB for serial, USBA/MicroB for debug
  • Ethernet Crossover Cable or Ethernet hub/switch and Ethernet Patch Cables
  • SD Card
  • HDMI Cable for display (optional)

Once you have all of the necessary components, you should perform the following steps:

  1. Connect the USBA to your host and
  2. If you are using a cross-over cable, connect the Ethernet port of the board to the second Ethernet port of your workstation.
  3. If you are using an Ethernet hub or switch, connect the board to the hub with a straight-through Ethernet cable, then connect the hub to the second Ethernet port of your workstation.
  4. Connect the power supply to your board.

Preparing the Target

Configuring Serial Communication

The Zynq uses a USB serial debug port to communicate with the host machine. The commands discussed in this section are meant to be performed by a privileged user account. This requires the root login or prepending each command with sudo.

Using Minicom

  1. Start minicom on your host machine in configuration mode. As root:

    # minicom -o -s -w

  2. A menu of configuration should appear. Use the Down-arrow key to scroll down and select the Serial port setup option, and press Enter.
  3. Verify that the listed serial port is the same one that is connected to the target board. If it is not, press A, and enter the correct device. This is /dev/ttyUSB0 on most Linux distributions with a single USB to TTY converter connected; multiple devices would enumerate as ttyUSB1,tyUSB2...
  4. Set the Bps/Par/Bits option by pressing the letter E and using the next menu to set the appropriate values. You press the key that corresponds to the value 115200, then press Enter.
  5. Set Hardware flow control to No using the F key.
  6. Set Software flow control to No using the G key.
  7. Press Enter to return to the main configuration menu, and then press Esc to exit this menu.
  8. Reset the board, and wait for a moment. If you do not see output from the board, press Enter several times until you see the prompt. If you do not see any output from the board, and have verified that the serial terminal connection is setup correctly, contact your board vendor.

TIP: If you experience an error similar to Device /dev/ttyUSB0 is locked when starting minicom, it usually means that another process is using the serial port (which is usually another instance of minicom). You can find the process that is currently using the serial port by executing the following:

# fuser /dev/ttyUSB0
/dev/ttyUSB0:         28358

# ps 28358
  PID TTY      STAT  TIME COMMAND
  28923 pts/0    S+    0:00 minicom

This process can also be killed directly with fuser as root. Please use this command with caution:

# fuser -k /dev/ttyUSB0

Using GNU Screen

To quickly connect to a board using Gnu Screen, execute the following:

# screen /dev/ttyUSB0 115200

For more information about using screen, please consult the man page, or view the manual online at http://www.gnu.org/software/screen/manual/screen.html

Configuring the Network Interface

Finding and Changing the MAC Address

The MAC address on the Zynq is set by the ethaddr environment variable in U-Boot.

If ethaddr is not set, it can be set using the setenv command.

Example

> setenv ethaddr 12:34:56:78:9a:bc

The MAC Address can be found using the printenv command in U-Boot.

Example

> printenv
baudrate=115200
bootfile="uImage-4.4-ts-armv7l"
stdin=serial
stdout=serial
stderr=serial
ethaddr=12:34:56:78:9a:bc

Changing the IP Address

The IP address can be set manually by modifying the ipaddr environment variable, or automatically using the dhcp or bootp commands.

Preparing the Host

Setting up the network

The commands discussed in this section are meant to be performed by a privileged user account. This requires the root login or prepending each command with sudo.

Identify the network adapter connecting the Host to the Target

Timesys only supports direct Ethernet connections from the development Host to the Target board. Ideally, the development Host would have two network adapters; one adapter to connect to your LAN, and one Ethernet card to connect directly to the Target board with a crossover cable or Ethernet hub. If your development Host only has one network interface it must be directly connected to the Target board. The Ethernet adapter connected directly to the target board must be:
  • Configured with a proper static IP address and Subnet Mask.
  • Connected directly to the target board with either a crossover cable or its own Ethernet hub.
From a command prompt issue the command:
# /sbin/ifconfig
Each interface will report its IP address, Subnet Mask, and Default Gateway information:
eth0 Link encap:Ethernet HWaddr 00:19:bb:49:ff:0e      
        inet addr:192.168.3.244 Bcast:192.168.3.255 Mask:255.255.254.0
        inet6 addr: fe80::219:bbff:fe49:ff0e/64 Scope:Link      
        UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1      
        RX packets:57214 errors:0 dropped:0 overruns:0 frame:0      
        TX packets:47272 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000      
        RX bytes:43109083 (41.1 MB) TX bytes:6308206 (6.0 MB)
        Interrupt:16
eth1 Link encap:Ethernet HWaddr 00:10:b5:4a:c1:a9      
        inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.0.0.0      
        UP BROADCAST MULTICAST MTU:1500 Metric:1      
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0      
        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0     
        collisions:0 txqueuelen:1000      
        RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)      
        Interrupt:21 Base address:0x1100
lo  Link encap:Local Loopback      
        inet addr:127.0.0.1 Mask:255.0.0.0      
        inet6 addr: ::1/128 Scope:Host      
        UP LOOPBACK RUNNING MTU:16436 Metric:1      
        RX packets:1974 errors:0 dropped:0 overruns:0 frame:0      
        TX packets:1974 errors:0 dropped:0 overruns:0 carrier:0     
        collisions:0 txqueuelen:0      
        RX bytes:226637 (221.3 KB) TX bytes:226637 (221.3 KB)
Note the IP address and Subnet Mask of the appropriate network connection. You will use this to configure the DHCP server.

Installing the server daemons on the development host

  • On Ubuntu 11.04 and newer:
    # apt-get install xinetd tftp tftpd isc-dhcp-server \
                      nfs-kernel-server portmap
  • On Ubuntu 10.11 and older:
    # apt-get install xinetd tftp tftpd dhcp3-server \
                      nfs-kernel-server portmap
    NOTE: Older versions of Ubuntu use nfs-common and nfs-user-server in place of nfs-kernel-server
  • On Fedora Core:

    # yum install xinetd tftp tftp-server dhcp nfs-utils

Important:

After installing these packages the DHCP server software may start automatically. Having the DHCP server running while you are connected to a LAN can interfere with the operation of other computers. After the DHCP service installs and starts issue these commands to stop the DHCP service and prevent it from starting automatically at boot:

  • To stop the dhcp service:

    • On Ubuntu 11.04 and newer:

      # service isc-dhcp-server stop

    • On Ubuntu 10.11 and older:

      # service dhcp3-server stop

    • On Fedora Core:

      # /etc/init.d/dhcp stop

  • To prevent the service from starting automatically:

    • On Ubuntu 11.04 and newer:

      # chmod 644 /etc/init.d/isc-dhcp-server

    • On Ubuntu 10.11 and older:

      # chmod 644 /etc/init.d/dhcp3-server

    • On Fedora Core:

      1. Click the System Menu
      2. Select Administration
      3. Select Services
      4. Select dhcpd
      5. Click the Customize button
      6. Uncheck Runlevel 2, 3, 4 and 5

Disable SELinux and Firewall on Fedora Core

On Fedora Core, SELinux and the firewall will interfere with many of the services that are needed to work with the target board. These should be disabled before continuing.

Generally Ubuntu does not have these services running by default.

  1. Disable SELinux:

    1. Click the System Menu
    2. Select Administration
    3. Select SELinux Management
    4. Change System Default Enforcing Mode to Disabled

  2. Disable Firewall:

    1. Click the System Menu
    2. Select Administration
    3. Select Services
    4. Select iptables
    5. Click the Customize button
    6. uncheck Runlevel 2, 3, 4 and 5

Setting up DHCP

  1. Edit the dhcpd configuration file:

    • On Ubuntu, edit /etc/dhcp/dhcpd.conf and include the following lines (note: on older versions of Ubuntu this file is at either /etc/dhcp3/dhcpd.conf or /etc/dhcpd.conf):

      subnet 10.0.0.0 netmask 255.0.0.0 {
       host targetboard {
        fixed-address 10.0.0.10;
        hardware ethernet 12:34:56:78:9a:bc;
        option root-path "/full/path/to/rfs";
        filename "uImage-4.4-ts-armv7l";
       }
      }

    • On Fedora Core, edit /etc/dhcpd.conf and include the following lines:

      ddns-update-style ad-hoc;
      subnet 10.0.0.0 netmask 255.0.0.0 {
       host targetboard {
        fixed-address 10.0.0.10;
        hardware ethernet 12:34:56:78:9a:bc;
        option root-path "/full/path/to/rfs";
        next-server 10.0.0.1;
        filename "uImage-4.4-ts-armv7l";
       }
      }

  2. Test the DHCP server on the network card that is connected to your development board. For this example assume eth1. This command will start the DHCP server in the foreground and output any status or error messages to the screen.

    • On Ubuntu up to 12.04 LTS:

      # service dhcp3-server restart

    • On Ubuntu 12.04 LTS and later:

      # service isc-dhcp-server restart

    • On Fedora Core:

      # /usr/sbin/dhcpd -d eth1

    • It is recommended to start the DHCP server in this manner each time you need to boot your Target board.

Setting up TFTP

  1. Edit the xinetd.conf file

    • On Ubuntu, edit /etc/xinetd.conf and add the following lines just above the line that reads includedir /etc/xinetd.d.

      service tftp
      {
       socket_type = dgram
       protocol = udp
       wait = yes
       user = root
       server = /usr/sbin/in.tftpd
       server_args = -s /tftpboot
       disable = no
      }

    • On Fedora Core, the tftp-server package creates a /etc/xinetd.d/tftp file. Edit this file and change the disable line from yes to no. The contents of the file are:

      service tftp
      {
       socket_type     = dgram
       protocol      = udp
       wait       = yes
       user       = root
       server       = /usr/sbin/in.tftpd
       server_args     = -s /tftpboot
       disable      = no
       per_source      = 11
       cps       = 100 2
       flags       = IPv4
      }

  2. Create the /tftpboot folder if it does not exist:

    # mkdir /tftpboot

  3. Copy the kernel image to the /tftpboot directory:

    # cp /path/to/kernel/image/uImage-4.4-ts-armv7l \
                      /tftpboot/uImage-4.4-ts-armv7l

    NOTE Also copy other files that are required for booting, such as a device tree blob, to /tftpboot.

  4. Restart the xinetd server with the following command:

    # /etc/init.d/xinetd restart

  5. Test the TFTP server with the following commands

    # tftp localhost
    tftp> get uImage-4.4-ts-armv7l
    Received 1456898 bytes in 0.4 seconds
    tftp> quit

  6. Set xinetd to start automatically on Fedora Core.

    Ubuntu users will skip this step.

    1. Click the System Menu
    2. Select Administration
    3. Select Services
    4. Select xinetd
    5. Click the Customize button
    6. Check Runlevel 2, 3, 4 and 5

Setting up NFS

  1. As root, extract rootfs.tar.gz to a directory and note the path. This path will be referred to as /full/path/to/rfs in this document.

    # mkdir /full/path/to/rfs
    # cd /full/path/to/rfs
    # sudo tar xvf rootfs.tar.gz

  2. Export this path by editing /etc/exports to include a line similar to the following:

    /full/path/to/rfs 10.0.0.10(rw,no_root_squash)

  3. Restart the NFS services

    • On Ubuntu issue the following commands in order:

      # service portmap stop
      # service nfs-kernel-server stop
      # service portmap start
      # service nfs-kernel-server start
      NOTE: Older versions of Ubuntu use nfs-common and nfs-user-server in place of nfs-kernel-server

    • On Fedora Core:

      # /etc/init.d/nfs restart

  4. Set nfsd to start automatically on Fedora Core. Ubuntu users will skip this step.

    1. Click the System Menu
    2. Select Administration
    3. Select Services
    4. Select NFS
    5. Click the Customize button
    6. Check Runlevel 2, 3, 4 and 5

Booting the Board

Xilinx Boot Images

Note: Xilinx Vivado SDK, version 2016.2 is required to perform the following operations. The Zynq requires the use of tools present in the Xilinx Vivado SDK to create bootable images, combine kernel and FPGA bit files, and also perform flashing of the qSPI memory and programming of the FPGA. This section describes how to use Factory output in conjunction with Xilinx tools to produce functional images. Documentation on using the Xilinx tools is referenced at the end of this document.

Boot Image Creation with Xilinx Bootgen tool

Note: The Bootgen utility is detailed in section 3.4 of the Zynq-7000 EPP Software Developers Guide, found here http://www.xilinx.com/support/documentation/user_guides/ug821-zynq-7000-swdev.pdf
Creating a bootable image from Factory output requires creating a Boot Image Format or .bif file, similar to the example below, which details the location of the files to be included and combined by bootgen.
While a complex boot image can be created, as explained in the Xilinx SDG, this simple example combines an FPGA bit file with a Factory built u-boot.elf.
A sample boot.bif file:
the_ROM_image:
{
 [bootloader]/home/path/to/Xilinx_Zynq/boot_files/fsbl.elf
 /home/path/to/FPGA_bit_file/your_zc702_fpga.bit
 /home/path/to/timesys_factory/build_armv7l-timesys-linux-gnueabi/images/bootloader/u-boot.elf
}

The fsbl.elf is a First Stage Boot Loader elf image used to create the BOOT.BIN image; this can be downloaded as part of 2016.1-release.tar.gz from the following link, http://www.wiki.xilinx.com/Zynq+2016.1+Release. This is required for creating BOOT.bin images.

Bitstream file(fpga.bit) can be generated using the Xilinx Vivado design tool or you can also use the prebuilt system.bit file available at the below location https://reference.digilentinc.com/_media/zedboard/zedboard_oob_design.zip.

Also, note that you will need to rename build_armv7l-timesys-linux-gnueabi/images/bootloader/u-boot to u-boot.elf.

Once you have created a bif file, point it to the FSBL .elf, FPGA .bit, and u-boot.elf, and run the bootgen utility as explained below.

This binary can be found in the Xilinx Vivado 2016.2 install at:

/path/to/Xilinx/SDK/2016.2/bin/bootgen

The help text for bootgen is as follows:

Xilinx BootGen
Build-2016.2, Date-Apr 15, 2016
Copyright (c) 1995-2016 Xilinx, Inc. All rights reserved.

Command Line Options:
 -h, -help                                        : Print the help summary
 -bif_help                                        : Print the BIF help summary
 -arch               [zynq | zynqmp | fpga]       : Xilinx Architecture
 -image              <filename>                   : Input Boot Image File (.bif)
 -split              [mcs | bin]                  : Split partitions to diff files
 -fill               <hex-byte>                   : Fill byte for padding
 -o                  <filename>                   : Output filename in MCS/BIN format
 -p                  <string>                     : Part name
 -w                  [on | off]                   : Overwrite mode
 -efuseppkbits       <filename>                   : Generate PPK hash for e-fuse
 -generate_hashes                                 : Generate SHA hashes (PKCS#1v1.5)
 -legacy                                          : For legacy operations
 -padimageheader     [0 | 1]                      : Pad header tables
 -process_bitstream  [mcs | bin]                  : Outputs bitstream in bin/mcs format
 -spksignature       <filename>                   : Generate SPK signature file
 -debug                                           : Info messages
 -packagename        <partname>                   : Part name from bit file (FPGA devices only)
 -encrypt            [bbram | efuse]              : AES Key storage in chip (Zynq only)
 -generate_keys auth [rsa | pem]                  : Generate Authentication Keys
 -dual_qspi_mode     [parallel | stacked <size>]  : Generate 2 output files for Dual QSPI
 -log                [error | warning | info |    : Generate log file
                          debug | trace]

The correct usage in this case is:

bootgen -image bootimage.bif -o /home/path/to/output_dir/bootfile.bin

Copy the resulting binary to SD card for booting purposes, or, use the QSPI flashing method detailed below or Xilinx SDK flashing utility to write to the hardware.

Device Trees and the Xilinx Zynq

The Xilinx implementation of Device Trees should be reviewed at the following link, as there are differences between the current Xilinx implementation and industry standards. http://www.wiki.xilinx.com/Zynq+Linux

Note: Currently, the Zynq receives boot arguments from the compiled device tree. However, if the bootargs variable is set in U-Boot, it will override the bootargs set in the DTS file.

Customizing DTS file in Factory

The default dts file used by Factory is located at:

ZC702

factory/target/configs/kernel/zc702/dts-4.4

ZC706

factory/target/configs/kernel/zc706/dts-4.4

The default bootargs being passed to the kernel are:

 bootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=:::::eth0:dhcp earlyprintk"

To customize this file, copy to a known location, and update your Factory configuration to point to the location of this file via menuconfig at:

  • Target Software -> Kernel -> Create Device Tree Blob -> Device Tree Filename.
Fully qualified path example:

file:///home/user/factory/target/configs/kernel/board/dts-4.4

Relative path example:

file://$BASE_DIR/../../path/to/dts-4.4

Note: Changes made in this fashion will not persist after running the kernel-distclean target. You will need to copy the resulting DTB file to your /tftpboot directory, or replace the DTB present on SD card. Be sure to back up previous known working files.

Programming QSPI Flash

When you have successfully created a new working boot image with the Xilinx bootgen utility, you can program this image to flash.
These steps are detailed at http://www.wiki.xilinx.com/U-boot, and repeated below:

uboot> sf probe 0 0 0
SF: Detected N25Q128 with page size 256, total 16 MiB
16384 KiB N25Q128 at 0:0 is now current device
uboot> sf erase 0 0x200000
uboot> sf read 0x08000000 0 100
 
// you can use any location in DDR as destination. make sure it
// doesnt overwrite u-boot code/data area. u-boot is at 0x04000000.
 
uboot> md 08000000
08000000: ffffffff ffffffff ffffffff ffffffff    ................
 
zynq-boot> loadb 0x08000000
 
// load the boot image through KERMIT protocol after this step
// it is assumed that you should have a boot image generated using
// the bootgen utility
 
## Ready for binary (kermit) download to 0x08000000 at 115200 bps...
## Total Size      = 0x0003e444 = 255044 Bytes
## Start Addr      = 0x08000000
uboot> md 08000000 100
uboot> sf write
Usage: sf write addr offset len
uboot> sf write 0x08000000 0 0x3E444
 
// U-boot read command can be used to see what is programmed in to
// QSPI memory. Following is the syntax of the "sf read" command.
 
zynq-boot> sf read <destination address in RAM> <source address in QSPI> <length of data to read>
 
NOTE: The "destination address" should not be ZERO.
 
Example:
 
uboot> sf read 0x800 0x0 0x2000

Additional Zynq boot methods

The Xlinx Zynq is capable of booting from a variety of methods, these are detailed in the Zynq-7000 EPP Evaluation Kit Getting Started Guide.

Additional boot methods will be detailed in future releases and documentation.

ZC702

http://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/2013_4/UG926_Z7_ZC702_Eval_Kit.pdf.

Default switch settings are detailed starting on page 13, settings for the Built In Self Test (BIST) starting on page 15, and settings to boot from SD-MMC for either the Demo SD images, or your own, are on page 32.

ZC706

http://www.xilinx.com/support/documentation/boards_and_kits/zc706/ug954-zc706-eval-board-xc7z045-ap-soc.pdf

Setting for the Built In Self Test (BIST) starting on page 13 in the Zynq-7000 EPP ZC706 Evaluation Kit Getting Started Guide.

http://www.xilinx.com/support/documentation/boards_and_kits/zc706/2014_4/ug961-zc706-GSG.pdf

Set Environment Variables

You must set a few environment variables in order to boot the board over TFTP and DHCP. This is done with the setenv and saveenv commands in U-Boot. On the target, set the following environment variables:

Variable Value
bootargs console=ttyPS0,115200 ip=dhcp root=/dev/nfs rw
bootcmd bootp\;tftpboot 0x2a00000 devicetree.dtb\;bootm 0x3000000 - 0x2a00000
loadaddr 0x3000000

If you are not using bootp to load the kernel, you must also specify the following values:

Variable Value
serverip 10.0.0.1
ipaddr 10.0.0.10
bootfile uImage-4.4-ts-armv7l
bootargs console=ttyPS0,115200 ip=${ipaddr} root=/dev/nfs rw nfsroot=${serverip}:/full/path/to/rfs
bootcmd tftpboot\;tftpboot 0x2a00000 devicetree.dtb\;bootm 0x3000000 - 0x2a00000

Example

> setenv bootargs console=ttyPS0,115200 ip=dhcp root=/dev/nfs rw
> setenv bootcmd  bootp\;tftpboot 0x2a00000 devicetree.dtb\;bootm 0x3000000 - 0x2a00000
> setenv loadaddr 0x3000000
> saveenv

Load The Kernel

You can use bootp or tftpboot to load the kernel. Note that the DHCP server needs to be set up for bootp, and tftp is necessary for both.

Example

> bootp
Speed: 100, full duplex
BOOTP broadcast 1
Using eTSEC1 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.10
Filename 'uImage-4.4-ts-armv7l'.
Load address: 0x3000000
Loading: #################################################################
         #################################################################
         ##################################################
done
Bytes transferred = 2632869 (282ca5 hex)

Load The Device Tree Blob

You can use tftpboot to load the device tree. The previous bootp command will have set up the interface for you.

Example

> tftpboot 0x2a00000 devicetree.dtb
Speed: 100, full duplex
Using eTSEC1 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.10
Filename 'devicetree.dtb'.
Load address: 0x2a00000
Loading: #
done
Bytes transferred = 13395 (3453 hex)

Boot the Kernel

The bootm command is used to boot the kernel. It loads the file that was previously uploaded using the bootp, dhcp, or tftpboot commands.

Example

> bootm 0x3000000 - 0x2a00000
## Booting kernel from Legacy Image at 00x3000000 ...
   Image Name:   Linux-4.4
   Image Type:   Linux Kernel Image (gzip compressed)
   Data Size:    2632805 Bytes =  2.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 000x2a00000
   Booting using the fdt blob at 0x0x2a00000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 007f9000, end 007ff452 ... OK

Booting via SD card for Zynq

Preparing the Secure Digital Card

The Zynq boots from an SD card. Some kits may be shipped with one that contains a sample kernel and RFS preloaded. We will be replacing these with the kernel and RFS from Factory. If you are using a blank SD card or have trouble replacing the software on the preloaded one, see Partitioning the SD Card. Otherwise, skip directly to Writing Boot Files to the SD Card.

Before you begin, you should determine the name of your SD card on your host system. To do so:

  1. Connect the SD card to your host system. Many modern systems have SD card slots on the case, or you can purchase a USB SD Card Reader for around $15 US.
  2. Determine the device name of the SD Card. This can be done using dmesg. In the following example, the device is /dev/sdX, which contains one partition sdX1.

    $ dmesg | tail
    [88050.184080] sd 4:0:0:0: [sdX] 1990656 512-byte hardware sectors: (1.01 GB/972 MiB)
    [88050.184821] sd 4:0:0:0: [sdX] Write Protect is off
    [88050.184824] sd 4:0:0:0: [sdX] Mode Sense: 03 00 00 00
    [88050.184827] sd 4:0:0:0: [sdX] Assuming drive cache: write through
    [88050.185575] sd 4:0:0:0: [sdX] 1990656 512-byte hardware sectors: (1.01 GB/972 MiB)
    [88050.186323] sd 4:0:0:0: [sdX] Write Protect is off
    [88050.186325] sd 4:0:0:0: [sdX] Mode Sense: 03 00 00 00
    [88050.186327] sd 4:0:0:0: [sdX] Assuming drive cache: write through
    [88050.186330]  sdX: sdX1

Partitioning the SD card

If you want to use a different SD card or its contents become corrupted, you can use the fdisk tool to create two partitions on your SD card. Please note that all data on the card will be lost upon completion of these steps.
  1. Unmount the partition if it was automounted by using the umount command.
    $ umount /dev/sdX1
  2. As root, run the fdisk utility on the drive.
    $ sudo fdisk /dev/sdX
  3. In fdisk, Delete the existing partition table and create a new one using the o command.
    Command (m for help): o
    Building a new DOS disklabel with disk identifier 0x8b025602.
    Changes will remain in memory only, until you decide to write them.
    After that, of course, the previous content won't be recoverable.
  4. Create a new primary partition using the n command. The first partition will be a FAT partition for storing the boot files. 64 MB is typically more than enough for this purpose.
    Command (m for help): n
    Partition type:
       p   primary (0 primary, 0 extended, 4 free)
       e   extended
    Select (default p): p
    Partition number (1-4, default 1): 1
    First sector (2048-30679039, default 2048):
    Using default value 2048
    Last sector, +sectors or +sizeK,M,G (2048-30679039, default 30679039): +64M
  5. Set the first partition as W95 FAT32 (LBA) using the t command and entering the Hex code c.
    Command (m for help): t
    Selected partition 1
    Hex code (type L to list codes): c
  6. Set the bootable flag on the first partition using the a command.

    Command (m for help): a
    Partition number (1-4): 1

  7. Create a second primary partition using the n command. This partition will be a linux partition for storing the root filesystem. It will fill the rest of the SD card.

    Command (m for help): n
    Command action
       e   extended
       p   primary partition (1-4)
    p
    Partition number (1-4, default 2): 2
    First sector (133120-30679039, default 133120):
    Using default value 18432
    Last sector, +sectors or +sizeK,M,G (133120-30679039, default 30679039):
    Using default value 30679039

  8. Verify that the partition table is correct by using the p command. It should look similar to the following:

    Command (m for help): p                                                         
                                                                                    
    Disk /dev/sdX: 15.7 GB, 15707668480 bytes
    64 heads, 32 sectors/track, 14980 cylinders, total 30679040 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x6eaae8f8

       Device Boot      Start         End      Blocks   Id  System
    /dev/sdX1   *        2048      133119       65536    c  W95 FAT32 (LBA)
    /dev/sdX2          133120    30679039    14773960   83  Linux

  9. This step will destroy all data on the SD Card - Write the partition table to the card using the w command.

    Command (m for help): w
    The partition table has been altered!

    Calling ioctl() to re-read partition table.

    WARNING: If you have created or modified any DOS 6.x
    partitions, please see the fdisk manual page for additional
    information.
    Syncing disks.

  10. Format the first partition of the SD card with a FAT filesystem using the mkfs.vfat tool.

    $ sudo /sbin/mkfs.vfat -n boot /dev/sdX1

  11. Format the second partition using an ext4 filesystem using the mkfs.ext4 tool.

    $ sudo /sbin/mkfs.ext4 -L rfs /dev/sdX2

Writing Boot Files to the SD Card

  1. Mount the partitions. You can remove and reinsert the card to trigger the automount, or you can use the mount command to mount the partition to an arbitrary location.

    $ sudo mount /dev/sdX1 /media/boot
    $ sudo mount /dev/sdX2 /media/rfs

  2. Copy the bootloader files into the vfat partition.

    $ sudo cp BOOT.BIN /media/boot/

  3. Copy the kernel image into the vfat partition as a file named kernel.img.

    $ sudo cp  uImage-4.4-ts-armv7l /media/boot/

  4. Copy the device tree blob into the vfat partition.

    $ sudo cp  devicetree.dtb /media/boot/

  5. As root, extract the rootfs.tar.gz archive to the RFS partition.

    $ sudo tar xzf rootfs.tar.gz -C /media/rfs

  6. Unmount both partitions before removing the card from the Development Host. Then place the card in the SD slot on the Zynq.

    $ sudo umount /dev/sdX1
    $ sudo umount /dev/sdX2

Booting from SD

Set Environment Variables

You must set a few environment variables in order to boot the board from the SD card. This is done with the setenv and saveenv commands in U-Boot.

On the target, set the following environment variables:

Variable Value
bootargs console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait
load_kernel fatload mmc :1 0x3000000 uImage-4.4-ts-armv7l
load_dtb fatload mmc :1 0x2a00000 devicetree.dtb
bootcmd mmc rescan\; run load_kernel load_dtb\; bootm 0x3000000 - 0x2a00000

Example

> setenv bootargs console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait
> setenv load_kernel fatload mmc :1 0x3000000 uImage-4.4-ts-armv7l
> setenv load_dtb fatload mmc :1 0x2a00000 devicetree.dtb
> setenv bootcmd mmc rescan\; run load_kernel load_dtb\; bootm 0x3000000 - 0x2a00000
> saveenv

Load The Kernel

You can use the mmc subsystem to load the kernel from the SD card.

Example

> mmc rescan
> fatload mmc :1 0x3000000 uImage-4.4-ts-armv7l
reading uImage-4.4-ts-armv7l

3008612 bytes read

Load The Device Tree

You can use the mmc subsystem to load the device tree file (dtb) from the SD card. Example

> mmc rescan
> fatload mmc :1 0x2a00000 devicetree.dtb
reading devicetree.dtb

24612 bytes read

Boot the Kernel

The bootm command is used to boot the kernel. It loads the file that was previously loaded using the fatload command.

Example

> bootm 0x3000000 - 0x2a00000
## Booting kernel from Legacy Image at 00x3000000 ...
   Image Name:   Linux-4.4
   Image Type:   Linux Kernel Image (gzip compressed)
   Data Size:    2632805 Bytes =  2.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 000x2a00000
   Booting using the fdt blob at 0x0x2a00000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 007f9000, end 007ff452 ... OK

Additional Information

Factory Documentation

Xilinx Documentation