cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
logicaledge
Observer
Observer
1,135 Views
Registered: ‎12-16-2014

ZU+ PL configuration failure

Our ZU+ (zu6eg) system using Vivado v2018.2 has been loading from QSPI and running our baremetal application on R5-0 at 300Mhz and configuring the PL bitstream, and using the PS-connected DDR4 memory system with no problems for some time. Deciding that we wanted a bit more performance, we increased the R5-0 frequency to its maximum of 500MHz. That one change caused our previously functioning system to now fail booting during the FSBL PL configuration with error:

XFSBL_ERROR_BITSTREAM_LOAD_FAIL
Partition 4 Load Failed, 0x37

This error occurs when the CSU_PCAP_STATUS register is polled after the FSBL DMA's the bitstream into the PCAP interface and the pl_done bit does not assert within the FSBL poll count timeout.

I swapped out our app for a basic SDK generated memory test one, and again the PL fails to configure the PL with R5-0@500MHz instead of 300MHz. Removing the PL bitstream from the boot image, however, allows the memtest app to load and run without problem on R5-0@500MHz.

I also tried the same two app+PL configurations (memtest w/o PL, memtest w/ PL) targeting the A53-0 at is maximum frequency with similar results, i.e. the PL fails to config when it is included, but the app loads and runs fine when the PL is excluded.

Any ideas? The most puzzling aspect is that it all works fine on R5-0@300MHz. All other clock frequencies (e.g. DDR, QSPI) are identical across configurations.

2 Replies
logicaledge
Observer
Observer
1,076 Views
Registered: ‎12-16-2014

This looks like an FSBL bug. Enabling the SHA3 hash on the partitions and also enabling bitstream compression results in the PL successfully configuring. But a large partition later on in the boot image now fails its SHA3 check. A common feature that followed the error is the FSBL thinking that it needs to stop and restart at a flash bank boundary, as seen in this FSBL output:

 

======= In Stage 3, Partition No:4 ======= 
UnEncrypted data Length: 0x55E0AB 
Data word offset: 0x55E0AB 
Total Data word length: 0x55E0AB 
Destination Load Address: 0x70000000 
Execution Address: 0x0 
Data word offset: 0xC00000 
Partition Attributes: 0x3016 
QSPI Reading Src 0x3000000, Dest 70000000, Length 15782AC
.QSPI Read Src 0x3000000, Dest 70000000, Length 1000000
.QSPI Read Src 0x4000000, Dest 71000000, Length 5782AC
CheckSum Type - SHA3
QSPI Reading Src 0x4578380, Dest FFFDDB08, Length 30
.QSPI Read Src 0x4578380, Dest FFFDDB08, Length 30
XFSBL_ERROR_HASH_FAILED 
XFSBL_ERROR_PARTITION_CHECKSUM_FAILED 
Partition 4 Load Failed, 0x4F

Prior to compressing the bitstream, FSBL was reading that partition in two separate operations also. After compressing, though, it took only a single read to complete the PL configuration, and the PL configuration now completes successfully.

 

So it appears that perhaps data read from QSPI flash is being corrupted due to the multiple read transfers performed by FSBL when it thinks a bank boundary is being crossed.

However, the flash device in this system (MT25QL02G) does not have multiple banks and is being correctly identified:

Xilinx Zynq MP First Stage Boot Loader 
Release 2018.2   Aug 23 2019  -  10:45:21
Reset Mode	:	System Reset
Platform: Silicon (4.0), Cluster ID 0xC0000100
Running on R5-0 Processor, Device Name: XCZU6EG
Initializing TCM ECC
Address 0x400000DF, Length FFE00020, ECC initialized 
Address 0x400000DF, Length FFE20000, ECC initialized 
Processor Initialization Done 
================= In Stage 2 ============ 
QSPI 24bit Boot Mode 
QSPI is in single flash connection
QSPI is using 4 bit bus
FlashID=0x20 0xBA 0x22
MICRON 2G 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 FFFD8980, Length 40
.QSPI Read Src 0x8C0, Dest FFFD8980, Length 40
*****Image Header Table Details******** 
Boot Gen Ver: 0x1020000 
No of Partitions: 0x5 
...

Removing the code from FSBL that splits the read into multiple operations copies and hashes all partitions successfully.

I'd rather not rely on an FSBL modification, however. If anyone else has had a similar experience, please post to this thread.

0 Kudos
masheeen
Contributor
Contributor
695 Views
Registered: ‎05-22-2018

Good day!

I found your post because I'm having a very similar issue with my FSBL loading. You mentioned removing the part of the code where it splits the reads, but didn't mention where that code is. Would you be able to point me to it? I keep getting lost trying to find the right file and function to look into.

Thanks!

0 Kudos