ZedBoard and Microzed Board Support

The page details how to run RTEMS on a ​ZedBoard and ​Microzed board. The ZedBoard and Microzed boards are supported by ​U-Boot and ​U-Boot can boot RTEMS. Please refer to the U-Boot documentation and the internet for documentation and example on using U-Boot. This page captures some examples on using U-Boot with these boards however is not all that can be done with U-Boot and running RTEMS.

Boot Mode

RTEMS can be run on the ZedBoard and the Microzed boards from a number of sources. You select the boot mode you need based on what you are wanting to do. For example, if you are developer writing an RTEMS application you may use JTAG, while production may boot from QSPI flash. A developer may also boot from QSPI or SD card and download RTEMS over the network using the RTEMS debugger.

JTAG Debugging

JTAG can used to reset and initialise the hardware, load software and debug applications. There are a range of JTAG debugging solutions with varying prices available that integrate with RTEMS.

JTAG lets you debug low level software such as boot loaders, exception handlers as well as support hardware watch points to help find difficult run time bugs.

Lauterbach

The Lauterbach debugger with trace support works with the ZedBoard and Microzed. The Lauterbach support a range of real-time trace options.

Flyswatter2

The Flyswatter2 pod from Tincan Tools combines with OpenOCD to provide an effective JTAG debugging solutions. Trace is not supported.

PS7 Initialisation

The Xilinx tools generate a set of files based on the System Z configuration call ps7_init. The Xilinx SDK embeds the ps7_init.c file in the First Stage Boot Loader (FSBL) to configure the Zynq hardware. Xilinx also creates a TCL version called ps7_init.tcl and it is used by Xilinx's XDM software to initialise the hardware before loading code.

The PS7 Initialisation page details how to do this.

Zedboard Jumpers

TDB

Microzed Jumpers

The jumpers to boot in JTAG mode are:

JP3	JP2	JP1
X	X	X
X	X	X

QSPI Flash

TDB

SD Card

The SD card mode boots from a DOSFS MBR partition. The Zynq's ROM code searches for the file BOOT.BIN in the root directory of a DOSFS partition and loads it. The BOOT.BIN file conforms the FSBL format documented in the Zynq TRM.

Be-careful updating the SD card on a host operating system that supports Long File Names (LNF). If you happen to rename a file that is a LFN format name to BOOT.BIN the directory entry in the root directory on the DOSFS may still be in the LFN format and the Zynq'c ROM code will not see it.

Microzed Jumpers

The jumpers to boot in QSPI flash mode are:

JP3	JP2	JP1
		X
X	X	X
X	X

U-Boot

The ​U-Boot boot loader supports the ZedBoard and Microzed boards.

I do not used the Xilinx version of U-Boot they provide on Github. I also do not use any binary builds available for download.

U-Boot License

U-Boot is license under GPL-2 which means you will need to make the source code for U-Boot available to users of your product. Please check the GPL-2 license to make sure you can use U-Boot and what you need to do to meet the license.

Building U-Boot

To build U-Boot for an ARM processor you need an ARM cross-compiler. The following list what you need to install for your host.

Host OS	Commands
FreeBSD	$ pkg install arm-none-eabi-binutils arm-none-eabi-gcc

Please add the set up your host if not listed.

Get the source code from the project's git repository:

$ git clone git://git.denx.de/u-boot.git

My last working build is b615267633996a9410a88b54a55965d8b021f6f8.

Change into the u-bootdirectory and run the following script mk-zed:

$ cat ../mk-zed
#! /bin/sh
gmake CROSS_COMPILE=arm-none-eabi- distclean
gmake CROSS_COMPILE=arm-none-eabi- zynq_zed_config
gmake CROSS_COMPILE=arm-none-eabi- HOSTCC=cc

Note: gmake is used because make on FreeBSD is a BSD compatible make and U-Boot requires the GNU make. The HOSTCC define is added to the U-Boot build command line because the FreeBSD's default compiler is clang and U-Boot defaults to gcc.

The files built by U-Boot you need to use are:

File	Description
spl/boot.bin	U-Boot's FSBL
arch/arm/dts/zynq-zed.dtb	ZedBoard device tree blob
arch/arm/dts/zynq-microzed.dtb	Microzed board device tree blob
u-boot.img	U-Boot executable loaded by the U-Boot FSBL

U-Boot Environment

You need to create a suitable environment file that defines how U-Boot loads your RTEMS executable. U-Boot lets you ​script commands. U-Boot has a large number of ​commands and you can script these to boot your RTEMS executable.

You can use the U-Boot control to enter commands to figure what works.

Network Booting RTEMS

Create a U-Boot script file called uEnv.txt to boot RTEMS from the network using the DHCP and TFTP protocols.

# cat sd/uEnv.txt     
bootfile=zed/rtems.img
loadaddr=0x02000000
uenvcmd=echo Booting RTEMS from net; set autoload no; dhcp; set serverip 10.10.5.1; tftpboot zed/rtems.img; bootm;

Note:

1. The bootfile is the file name used by the TFTP protocol. The path is relative to the top level path the TFTP server is configured to serve file from. This path is available to the development host machines so the executable can be updated after a build.
2. The loadaddr is the address U-Boot loads the image before it is relocated to the address RTEMS is built with. This value needs to be valid RAM and it is best if it does not overlap with the image's final located address.
3. The subnet is 10.10.5.0/24 and it has a DHCP server. The dhcp; command tells U-Boot to get an IP address using the DHCP protocol and optionally download an executable using the TFTP protocol. I do not define a boot file in the DHCP server so it can vary for each board on networking that is net booting.
4. The TFTP server IP address is manually set to 10.10.5.1.

SD Card Set Up

Create a MBR DOSFS partition on an SD card with enough space to hold the files needed. The card I have:

# df -h /dev/da0s1
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/da0s1     64M    1.3M     63M     2%    /mnt/sd

Copy the files:

# mount -t msdosfs /dev/da0s1 /mnt/sd
# cp spl/boot.bin /mnt/sd/boot.bin
# cp arch/arm/dts/zynq-microzed.dtb /mnt/sd/system.dtb
# cp u-boot.img /mnt/sd/u-boot.img
# cp uEnv.txt /mnt/sd/uEnv.txt
# umount /mnt/sd

Note: the mount command is for FreeBSD.

RTEMS Application

The RTEMS executable is an ELF format file and U-Boot requires custom image format which means you need to convert the RTEMS ELF executable file to the custom image format.

The following script is an example of how you perform this conversion:

$ cat rtems-zynq-mkimg
#! /bin/sh

OBJCOPY_FOR_TARGET=arm-rtems4.12-objcopy
OBJCOPY="$OBJCOPY_FOR_TARGET"

EXE_NAME=$1

START_ADDR=0x00104000
ENTRY_ADDR=0x00104000

${OBJCOPY} -R -S --strip-debug -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1
cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
mkimage \
  -A arm -O rtems -T kernel -a $START_ADDR -e $ENTRY_ADDR -n "RTEMS" \
  -d "$EXE_NAME.gz" "$EXE_NAME.img"

Note:

1. The arm-rtems4.12-objcopy is part of the RTEMS ARM binutils package built by the RSB.
2. The START_ADDR the base address the RTEMS executable is linked too. This is set in the RTEMS BSP code for the ZedBoard and Microzed board.
3. The ENTRY_ADDR is the entry point to the RTEMS executable. This again is BSP specific. For the ZedBoard? the entry point is the base address.
4. The RTEMS executable is stripped of any debugging information and converted to a binary image and then compressed. Stripping the executable or debugging information does not effect your ability to debug the application because debugging uses the ELF image which still contains the debugging information.
5. The host tool mkimage is built as part of U-Boot. You can find it under toos/mkimage. You need to copy it somewhere in your path or add a path so it can be executed.