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: 
Visitor ian.maw
Visitor
360 Views
Registered: ‎02-03-2014

Possible way to work around the Zynq 7000 QSPI 16M limit issue but is it practical ?

Hi,

For reference we intend to support the 030, 035 and 045 devices.

Would the following be practical please ? :-

We store our program in the first 'page' of flash memory i.e. with the extended address register and zero and our bitstream in the second page. We could then switch the extended address register to zero after configuring the fabric thereby removing the need for the workaround mentioned in AR# 57744 (Design Advisory for Zynq-7000 SoC - Zynq and QSPI reset requirements when using larger than 16MB flash).

If a soft reset were to occur during code execution we would, I assume, restart with the first page of flash thereby booting normally. 

I know this might seem wasteful but we have 64MB.

Thanks,

Ian

 

0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
308 Views
Registered: ‎10-11-2011

Re: Possible way to work around the Zynq 7000 QSPI 16M limit issue but is it practical ?

To be 100% recovery on the reset without a reset going to the flash you should copy the FSBL at every 16MB (or 32MB if you are Dual Parallel) boundary.

Is that what you are proposing?

If not, you might have a window in time where, if a reset is receive, the part will be trying to boot from the sencond page NOT finding the image.

If you can guarantee that no reset is received during that time, then swithing back to the first page after bitstream programming should work fine.

0 Kudos
Visitor chriswampler
Visitor
181 Views
Registered: ‎05-03-2019

Re: Possible way to work around the Zynq 7000 QSPI 16M limit issue but is it practical ?

Have you been able to test and verify this solution to AR# 57744?

We are designing a board and 4KB of memory lost to the duplication of first stage boot loader code at 16MB boundaries seems preferable to the additional CPLD hardware and bitfile overhead of the orriginally proposed solution.

Have you experienced any other issues with implementing this work around?

 

Thanks,

Chris

0 Kudos
Xilinx Employee
Xilinx Employee
140 Views
Registered: ‎10-11-2011

Re: Possible way to work around the Zynq 7000 QSPI 16M limit issue but is it practical ?

I am pretty sure the duplication of FSBL at every boundary works.

You could try it on the Avnet ZED board if you want to be 110% sure. There's a 32MB flash in there.

0 Kudos