Which Zynq-7000 platform is affected?
Any Zynq-7000 platform that uses larger than 16MB QSPI flash for booting in any of these configurations: single, dual-stacked, dual parallel.
Note: A system with two 16MB QSPI flashes in dual -stacked or -parallel configuration (32MB total) is not affected by this requirement.
For Zynq-7000 supported QSPI devices, please review (Xilinx Answer 50991).
The Zynq QSPI controller is limited to 3-bytes addressing, therefore the bootimage can be fetched by BootROM only if it resides in the first 16MB of the flash (16MB is the maximum addressability with a single QSPI chip).
If a larger than 16MB QSPI flash is used, then in order to access data on the portion of the flash over 16MB, the software driver (standalone, u-boot, Linux) needs to extend the 3-bytes address storing the 4th byte into a vendor specific QSPI register called "extended address register".
This will be supported by 2013.3/14.7 software drivers and Xilinx tools.
The extended address register is sticky, which means that only external reset events (like power cycle of the flash or external reset of the flash) can clear it.
After a power cycle or an external reset of the QSPI flash, a recovery time needs to expire before accessing the device (see QSPI flash datasheet for more details).
BootROM is invoked on ALL system resets:
At the time of a system reset, the extended address register might be non-zero (modified by a read/write operation that was targeting a portion of the flash at >16MB).
BootROM has no knowledge of the QSPI extended address register, therefore it cannot clear it which leads to a failure loading the bootimage.
Note: For all questions related to the Zynq-7000 AP SoC, see the Zynq-7000 AP SoC Solution Center (Xilinx Answer 52512).
In order to resolve this situation, both the Zynq and the QSPI flash resets need to be managed together.
On any reset (POR or warm reset), an external SRST has to be applied to Zynq, and the QSPI has to be allowed to recover before de-asserting SRST.
An external entity (such as a CPLD) can be used to perform the management:
Detect All Zynq Platform Resets
A dedicated PS MIO (USER_IO) needs to be used for this, because there are no output pins on Zynq to indicate all warm reset events.
The board must be designed to strap it High or Low using weak pull-ups or pull-downs.
The FSBL pulls it in the other direction. This guarantees that the signal will be driven Low prior to any subsequent warm reset.
CPLD monitors POR_IN, SRST_IN and USER_IO, and drives POR_ZYNQ, SRST_ZYNQ, and QSPI_RESET/QSPI_POWER_EN.
NOTE: In the diagram SRST_IN is the OR of all SRST on the board, including the JTAG SRST line (that can be asserted for example from a debugger).
Keep Zynq in Reset Using SRST_ZYNQ or POR_ZYNQ
The advantage of using SRST_ZYNQ is that the warm resets are converted to another warm reset; thus debug registers, and as such stays intact.
Application needs might mandate using POR_ZYNQ instead.
Reset QSPI flash
If the QSPI flash has a reset pin, the CPLD drives it (QSPI_RESET).
If it does not have it, the CPLD controls the QSPI flash power rail (for example, via FET on the board) (QSPI_POWER_EN).
Depending on the recovery time for power rail versus RESET, it might be advantageous to use the power rail despite a reset pin being available.
Any ongoing writes or erases might result in flash corruption.
The higher level software/filesystem needs to account for this possibility.
Properly Handle POR_IN and SRST_IN Overlapping with SRST_ZYNQ
If either or both POR_IN and SRST_IN happen while this logic has asserted SRST_ZYNQ, the TRM guidelines have to be followed to assert and deassert SRST_ZYNQ/POR_ZYNQ in the proper order.
See section 6.2.4 "Reset Requirements" of the Zynq TRM, and (Xilinx Answer 52847).
Release Zynq Reset
The CPLD logic holds Zynq in reset until the QSPI flash is available (the recovery time has expired, see the QSPI flash datasheet for more details).
Note: the BootROM will access the QSPI (drive CS active) 3.2 ms after POR_ZYNQ is released (rising edge).
BootROM bootimage search
At this point, the BootROM starts looking for the bootimage in the first 16MB of the QSPI flash (extended address register is zero).
1) Some extra considerations to help with designing the CPLD logic can be found in chapter 26 "Reset System" of the Zynq-7000 AP SoC Technical Reference Manual.
See also (Xilinx Answer 52847) for Sequencing for SRST and POR signals.
2) Other considerations when booting from larger than 16MB QSPI can be found in the Zynq-7000 AP SoC Software Developers Guide.