We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome,
Firefox,
Internet Explorer 11,
Safari. Thank you!

Trying to bring-up custom hardware that uses a XCU19EG (ES2) device. I'm able to program the QSPI and get the FSBL and PMU to run but nothing happens after they run. The FSBL appears to handoff control to the ATF but I never see messages from the ATF/BL. I enabled debug in FSBL and below is the serial port output. Below that is the bif file contents. Seems like maybe a problem with building the bl31.elf but I'm using the pmufw.elf from the same build. Tools are 2018.1

bl31 was built with petalinux-build, the same build that built the fsbl, pmu and u-boot.

Turns out there is a UART0 dependency in the tools for the bl31 executable. I was able to duplicate my issue on a ZCU102 board by turning off UART0 in the ZynqMP block. Export hdf, config/build with petalinux (using UART1 in config menu) and I see the exact same problem on the ZCU102 board. Only the FSBL prints out on UART1 and hangs there. If I then enable the UART0 in the ZynqMP block, export hdf, config/build with UART1 still selected as the serial port in config menu, then it boots properly and what I see is FSBL, PMU, u-boot prints on UART1 but bl31 prints out on UART0. This is all with ZCU102. So bl31 doesn't execute properly unless the UART0 is enabled in the ZynqMP block in Vivado. It doesn't have to be used, but has to be enabled.

This was important for my hardware because we do not have any UART0 pins connected; only UART1. So I never had UART0 enabled for our custom hardware project. We did have unused pins that could be assigned to UART0, so I was able to enable UART0 in our project. After rebuilding everything, it now boots to u-boot. Of course I don't see the bl31/ATF prints because they are going out UART0 (presumably) but it does boot properly now.

I'm surprised no one else has had this issue, but maybe everyone else uses UART0 or at least has it enabled in their project.

bl31 was built with petalinux-build, the same build that built the fsbl, pmu and u-boot.

Turns out there is a UART0 dependency in the tools for the bl31 executable. I was able to duplicate my issue on a ZCU102 board by turning off UART0 in the ZynqMP block. Export hdf, config/build with petalinux (using UART1 in config menu) and I see the exact same problem on the ZCU102 board. Only the FSBL prints out on UART1 and hangs there. If I then enable the UART0 in the ZynqMP block, export hdf, config/build with UART1 still selected as the serial port in config menu, then it boots properly and what I see is FSBL, PMU, u-boot prints on UART1 but bl31 prints out on UART0. This is all with ZCU102. So bl31 doesn't execute properly unless the UART0 is enabled in the ZynqMP block in Vivado. It doesn't have to be used, but has to be enabled.

This was important for my hardware because we do not have any UART0 pins connected; only UART1. So I never had UART0 enabled for our custom hardware project. We did have unused pins that could be assigned to UART0, so I was able to enable UART0 in our project. After rebuilding everything, it now boots to u-boot. Of course I don't see the bl31/ATF prints because they are going out UART0 (presumably) but it does boot properly now.

I'm surprised no one else has had this issue, but maybe everyone else uses UART0 or at least has it enabled in their project.

I had the same issue as described here. In my case, I am using the XCZU6EG but the solution would be similar. The problem is that by default in the ZynqMP, bl31 uses UART0 (0xFF000000) and if the controller is not enabled, it hangs as described above. It is possible to force ATZ using UART1 (0xFF010000) by declaring the symbol "ZYNQMP_CONSOLE=cadence1" in the compilation command (https://github.com/Xilinx/arm-trusted-firmware/blob/master/plat/xilinx/zynqmp/platform.mk#L79). The resulting make command would be like this: