Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎06-22-2018

2020.2 Petalinux ZCU102 rev1.1 hangs on u-boot when using NFS



Recently we have bought "new" ZCU102 evaluation board. This is our second ZCU102 board (the one we have had was rev. 1.0 and it was bought back in 2017). Our "old" ZCU102 is running Petalinux image created with 2019.1 tools. The image is configured to boot from SD card and mount NFS rootfs that is located on our server.  It seems to run flawlessly.

We wanted to recreate this system using the new ZCU102 board that we have bought.

First - to test the new ZCU102 board we have used the SD card that was plugged-in to the "old" board. Unfortunately the system did not boot - the UART printed out just the FSBL banner. Therefore we have migrated our design to Vivado 2020.2 and create a new image using Peta-tools 2020.2. To our surprise it did not work too.

We've decided to do some more testing. We have created a new project for ZCU102 rev 1.1 that includes only zynq_mp core (with the automatic presets of the board). Next we have exported the HW with the bitstream and upon this - created new Petalinux project. We left all the options in Petalinux Tools to default.

The system boots in QEMU.

Next, we have changed rootfs to NFS (just like explained in the UG1144). The system does not boot anymore in QEMU, nor on HW. I believe that it hangs just at the entry to the u-boot. You can see the console screen in the attachment (we have activated the ATF debug flags).


Here's the bootgen.bif that was generated in <peta-proj>/build catalog:

[bootloader, destination_cpu=a53-0] /tmp/tmp.ZdF30CIR5l/zynqmp_fsbl.elf
[pmufw_image] /tmp/tmp.ZdF30CIR5l/pmufw.elf
[destination_device=pl] /tmp/tmp.ZdF30CIR5l/system.bit
[destination_cpu=a53-0, exception_level=el-3, trustzone] /tmp/tmp.ZdF30CIR5l/bl31.elf
[destination_cpu=a53-0, load=0x00100000] /tmp/tmp.ZdF30CIR5l/system.dtb
[destination_cpu=a53-0, exception_level=el-2] /tmp/tmp.ZdF30CIR5l/u-boot.elf


My questions are:

 - according to the attachment - is the booting process stuck at loading u-boot?

 - if so, why does the change in rootfs ( NFS) result is u-boot not loading? How can we debug it further?

 - according to AR# 70045 the changes between board revisions were mostly mechanical. Is there any reason why design that works on rev 1.0 board can fail at rev 1.1?


Host OS: Ubuntu 18.04 LTS,

Xilinx Tools Version: 2020.2 (vivado, petalinux tools)

Board: ZCU102 rev. 1.1



Best regards,


0 Kudos
0 Replies