UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
1,756 Views
Registered: ‎06-28-2018

ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

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

 

Without debug, this is the output:

Xilinx Zynq MP First Stage Boot Loader
Release 2018.1 Jul 18 2018 - 11:05:47
PMU Firmware 2018.1 Jul 18 2018 13:28:03
PMU_ROM Version: xpbr-v8.1.0-0

 

With debug turned on in FSBL, this is the output:

Xilinx Zynq MP First Stage Boot Loader
Release 2018.1 Jul 17 2018 - 20:07:15
Reset Mode : System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU19EG
Initializing DDR ECC
Address 0x0, Length 80000000, ECC initialized
Address 0x800000000, Length 80000000, ECC initialized
Processor Initialization Done
================= In Stage 2 ============
QSPI 32 bit Boot Mode
QSPI is in single flash connection
QSPI is using 4 bit bus
FlashID=0x20 0xBA 0x20
MICRON 512M Bits
Multiboot Reg : 0x0
QSPI Reading Src 0x0, Dest FFFF1C40, Length EC0
.QSPI Read Src 0x0, Dest FFFF1C40, Length EC0
Image Header Table Offset 0x8C0
QSPI Reading Src 0x8C0, Dest FFFD6148, Length 40
.QSPI Read Src 0x8C0, Dest FFFD6148, Length 40
*****Image Header Table Details********
Boot Gen Ver: 0x1020000
No of Partitions: 0x6
Partition Header Address: 0x440
Partition Present Device: 0x0
QSPI Reading Src 0x1100, Dest FFFD6188, Length 40
.QSPI Read Src 0x1100, Dest FFFD6188, Length 40
QSPI Reading Src 0x1140, Dest FFFD61C8, Length 40
.QSPI Read Src 0x1140, Dest FFFD61C8, Length 40
QSPI Reading Src 0x1180, Dest FFFD6208, Length 40
.QSPI Read Src 0x1180, Dest FFFD6208, Length 40
QSPI Reading Src 0x11C0, Dest FFFD6248, Length 40
.QSPI Read Src 0x11C0, Dest FFFD6248, Length 40
QSPI Reading Src 0x1200, Dest FFFD6288, Length 40
.QSPI Read Src 0x1200, Dest FFFD6288, Length 40
QSPI Reading Src 0x1240, Dest FFFD62C8, Length 40
.QSPI Read Src 0x1240, Dest FFFD62C8, Length 40
Initialization Success
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x485F
Data word offset: 0x485F
Total Data word length: 0x485F
Destination Load Address: 0xFFDC0000
Execution Address: 0xFFDC8C08
Data word offset: 0x66B0
Partition Attributes: 0x83E
QSPI Reading Src 0x19AC0, Dest FFDC0000, Length 1217C
.QSPI Read Src 0x19AC0, Dest FFDC0000, Length 1217C
Partition 1 Load Success
======= In Stage 3, Partition No:2 =======
UnEncrypted data Length: 0x339
Data word offset: 0x339
Total Data word length: 0x339
Destination Load Address: 0xFFDD66E0
Execution Address: 0x0
Data word offset: 0xAF10
Partition Attributes: 0x83E
QSPI Reading Src 0x2BC40, Dest FFDD66E0, Length CE4
.QSPI Read Src 0x2BC40, Dest FFDD66E0, Length CE4
Partition 2 Load Success
======= In Stage 3, Partition No:3 =======
UnEncrypted data Length: 0x100
Data word offset: 0x100
Total Data word length: 0x100
Destination Load Address: 0xFFDDF6E0
Execution Address: 0x0
Data word offset: 0xB250
Partition Attributes: 0x83E
QSPI Reading Src 0x2C940, Dest FFDDF6E0, Length 400
.QSPI Read Src 0x2C940, Dest FFDDF6E0, Length 400
PMU Firmware 2018.1 Jul 18 2018 13:28:03
PMU_ROM Version: xpbr-v8.1.0-0
Partition 3 Load Success
======= In Stage 3, Partition No:4 =======
UnEncrypted data Length: 0x31F4
Data word offset: 0x31F4
Total Data word length: 0x31F4
Destination Load Address: 0xFFFEA000
Execution Address: 0xFFFEA000
Data word offset: 0xB350
Partition Attributes: 0x117
QSPI Reading Src 0x2CD40, Dest FFFEA000, Length C7D0
.QSPI Read Src 0x2CD40, Dest FFFEA000, Length C7D0
Partition 4 Load Success
======= In Stage 3, Partition No:5 =======
UnEncrypted data Length: 0x2E910
Data word offset: 0x2E910
Total Data word length: 0x2E910
Destination Load Address: 0x8000000
Execution Address: 0x8000000
Data word offset: 0xE550
Partition Attributes: 0x114
QSPI Reading Src 0x39540, Dest 8000000, Length BA440
.QSPI Read Src 0x39540, Dest 8000000, Length BA440
Partition 5 Load Success
All Partitions Loaded
================= In Stage 4 ============
PM Init Success
Protection configuration applied
Running Cpu Handoff address: 0xFFFEA000, Exec State: 0
Exit from FSBL

 

 

And here is the bif file used:

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
[fsbl_config]a53_x64
[bootloader]C:\Users\brucep\brucep_p4\ft\nx6\hw\fpga\nx6_pcie4\xproj\nx6_pcie4.sdk\nx6_fsbl\Debug\nx6_fsbl.elf
[destination_cpu = pmu]R:\HW_wip\NX6\wip\g4pb_2018\pmufw.elf
[destination_cpu = a53-0, exception_level = el-3, trustzone]R:\HW_wip\NX6\wip\g4pb_2018\bl31.elf
[destination_cpu = a53-0, exception_level = el-2]R:\HW_wip\NX6\wip\g4pb_2018\u-boot.elf

}

 

bap3ball
0 Kudos
1 Solution

Accepted Solutions
1,828 Views
Registered: ‎06-28-2018

Re: ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

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.

 

bap3ball

View solution in original post

5 Replies
Xilinx Employee
Xilinx Employee
1,708 Views
Registered: ‎10-11-2011

Re: ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

Something seems to be wrong with your ATF. How did you build it?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,829 Views
Registered: ‎06-28-2018

Re: ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

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.

 

bap3ball

View solution in original post

Xilinx Employee
Xilinx Employee
1,677 Views
Registered: ‎10-11-2011

Re: ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

I found Xilinx internal records about this issue, so it's known, but I can't find anything public.

I will write a Xilinx Answer Record and make it public.

Thanks!

  

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,202 Views
Registered: ‎06-21-2018

Re: ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

Hello,

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:

make CROSS_COMPILE="/your_path_to_cc_tools/bin/aarch64-none-linux-gnueabi-" ARCH=aarch64 PLAT=zynqmp ZYNQMP_CONSOLE=cadence1 RESET_TO_BL31=1 bl31

Then you regenerate the boot.bin image with the new bl31.elf and you should see information prompted out in the console.

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
1,190 Views
Registered: ‎10-11-2011

Re: ZynqU+ Boot from QSPI hangs after FSBL and PMU messages - XCU19EG device

Jump to solution

https://www.xilinx.com/support/answers/71272.html 2018.1/2 Zynq UltraScale+ MPSoC: PetaLinux ATF cannot boot up in QSPI flash mode when only UART1 is enabled in a Vivado design

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos