Table of Contents

U-Boot is an open source Universal Boot Loader that is frequently used in the Linux community. Xilinx provides a Git tree located at https://github.com/Xilinx/u-boot-xlnx which includes U-Boot to run on Xilinx boards. The Xilinx U-Boot project is based on the source code from http://git.denx.de.

U-Boot Build Dependencies

Install required packages on the host platform before building U-Boot

Building with GCC — Das U-Boot unknown version documentation

U-Boot Commands

The list of U-Boot commands can be accessed while in the U-Boot prompt. Type "help" or "?" for a complete listing of available commands. Below an example is given:

Programming QSPI Flash

U-Boot provides the SF command to program serial flash devices. On all Xilinx platforms from u-boot, you can use SF command to program a QSPI device. Here is an example of loading an image file to QSPI device.

Programming NAND Flash

U-Boot provides the nand command to program nand devices. Here is an example of loading an image file to nand device. The command sequence for nand is same as QSPI except the commands.Below nand command sequence for writing an image to nand device. The read command at the end just to ensure the data was written properly and you can use cmp command for comparing written data with original data which was lready present in DDR..

Programming NOR Flash

U-Boot uses the regular memory command to program NOR devices. Here is command sequence of loading an image file to NOR device.

Authentication and Decryption in Zynq U-Boot

The authentication and decryption feature present in Zynq U-Boot can be found at page Authentication and Decryption in Zynq u-boot

Authentication and Decryption in ZynqMP U-Boot

The authentication and decryption feature present in ZynqMP U-Boot can found at Authentication and Decryption in Zynq US+ u-boot

Boot application images

U-Boot provides bootm command to boot application images (i.e. Linux) which expects those images be wrapper with a U-Boot specific header using mkimage. This command can be used either to boot legacy U-Boot images or new multi component images (FIT) as documented in U-Boot images wiki page. The standard Linux build process builds the wrapper uImage and Petalinux projects generates by default the multi component FIT image as well.

The following U-Boot commands illustrate loading a Linux image from a SD card using either individual images and a FIT image using the bootm command.

With the bootm command, U-Boot is relocating the images before it boots Linux such that the addresses above may not be what the kernel sees. U-Boot also alters the device tree to tell the kernel where the ramdisk image is located in memory (initrd-start and initrd-end). The
bootm command sets the r2 register to the address of the device tree in memory which is not done by the go command.

The differences and use cases of using the booti commands and the bootm command have evolved over time.  As of U-Boot 2020.01, the primary difference is in handling of uncompressed Linux Image files (common for 64-bit Arm platforms) versus compressed Linux zImage files (common on 32-bit Arm platforms) as denoted in the U-Boot help.  As a general rule of thumb, only differentiate in usage depending on Linux image type rather than solely based on architecture.

The full help for booti and bootm individually fully details the differences in usage.

Supported Drivers list for Zynq and Zynq Ultrascale

Driver Information:

There are a number of drivers in the u-boot tree and they may work, but the following list of drivers are currently what's tested and users are encouraged to use these rather than others.

Supported SoftIP drivers

Supported File systems

Below are the file systems supported in u-boot against flash devices for platform and Zynq UltraScale+. "Raw" in below table means that it supports raw read/write to respective flash devices without any need of file systems.

Issues/Workaround

Please note that SD does not work in SD3.0 UHS modes by default. The dt parameter no-1-8-v has to be removed from corresponding sdhci node to work in UHS mode. Having no-1-8-v in sdhci node makes it to operate till SD High speed only, on Xilinx ZynqMP/Versal boards UHS mode will not work.

MRMAC

1)The IDT/Renasas Clocking device is used for generation of the ToD clock (TS clock) and the GT Reference clock for Ethernet port.
This needs to be configured using BEAM tool.
2)The TRD design was created for supporting PTP. On every RX packet, 16 bytes are inserted in the beginning of the packet in-line.
This is done between MRMAC and MCDMA. For non-PTP packets, the SW discards this timestamp.
It contains some PTP functionality enabled by default on RX packets that uboot cannot recognize.

3) Use default tftp block size (1468) for tftpboot till u-boot 2025.1 release.

NAND:

1) Currently only hw ecc is supported in U-Boot. If any other ecc mode is given in DT, it simply ignores and switches to hw ecc, as the software stack (i.e., u-boot, fsbl & BootRom) which uses on-host hw-ecc engine in their read and write path. 

OSPI:

1. For DDR(Double Data Rate) mode, default PHY mode is enabled and the reference clock needs to be updated based on the flash part datasheet.

QSPI:

1) For Spansion flashes  "s25fl256l" and "s25fs_s" (info→id[5] == 0x81) doesn't support Bank Address Register(BAR). The config CONFIG_SPI_FLASH_BAR needs to be disabled for ZynqMP platform, as by default the CONFIG_SPI_FLASH_BAR is enabled for ZynqMP platform.

Disable the Caches:

1. Disable the Caches CONFIG_SYS_ICACHE_OFF=y and CONFIG_SYS_DCACHE_OFF=y will result in u-boot compilation issues. Issue is present Upstream U-BOOT also.

Silent Console:

Add “silent” environment variable to enable silent console output on Xilinx platforms when CONFIG_SILENT_CONSOLE and CONFIG_SILENT_U_BOOT_ONLY are set.

Example for ZynqMP:

Add “silent” environment variable in include/configs/xilinx_zynqmp.h

#define CFG_EXTRA_ENV_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
"usb_pgood_delay=1000\0" \
"silent=1\0" \
BOOTENV

Add silent configs in xilinx_zynqmp_virt_defconfig

CONFIG_SILENT_CONSOLE=y
CONFIG_SILENT_U_BOOT_ONLY=y

Adds new reserved node in bdi:

As per the LMB allocator code
"if the memory is marked as reserved in Device tree the below bdi command shows with the flags "no-map", no-overwrite".
Say if we write some data to the memory
like sf write 0x2000000 0 0x1000000 ---> still this shows as reserved when we run the bdi command with the flag as "none" means someone from UBOOT has written some data to the memory address 0x2000000 but that doesn't mean it is really reserved. From UBOOT we can still read/write/erase to that memory location. The reserved[] with the flag "none" indicates the UBOOT has written/read/erase to that memory location it really doesn't mean we cannot touch that memory.

lmb_dump_all:
memory.count = 0x2
memory[0] [0x0-0x7fffffff], 0x80000000 bytes, flags: none
memory[1] [0x800000000-0x97fffffff], 0x180000000 bytes, flags: none
reserved.count = 0x3
reserved[0] [0x2000000-0x2ffffff], 0x1000000 bytes, flags: none
reserved[1] [0x77e9c910-0x7fffffff], 0x81636f0 bytes, flags: no-map
reserved[2] [0x97fffd000-0x97fffffff], 0x3000 bytes, flags: no-overwrite, no-map

USB:

Type C support is not present in UBOOT, still framework need to be implemented.

SD/MMC:

Patroit 16gb SD card with UHS mode:

Observing "mmc fail to stop cmd" in UHS Mode for patriot 16gb SD Card.

Tried this; retrying the stop command works without failure. We only see the print "mmc fail to stop cmd," and functionality is unaffected.

pr_err("mmc fail to send stop cmd\n");

-return 0;
+ pr_err("retrying...\n");
+ if (mmc_send_cmd(mmc, &cmd, NULL)) {
+ pr_err("failed again\n");
+ return 0;

As this issue is present only on this "patriot 16gb SD card".

Release Notes

U-boot Release Notes

Child Pages

Related Links

• Build U-Boot