Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎09-04-2019

Zynq7035 won't boot after accessing upper 16 MB of QSPI Flash


We are working on the Picozed zynq7035-adrv9361 board.

While trying to boot from QSPI, we noticed a weird bug.

Every time we try to reboot (SRST) after reading the upper 16MB of our 32MB nand, BootRom is unable to find FSBL (which is located in the beginning of the qspi), and exists with error code 0x2000.

We believe that, for some reason, the BootRom is trying to find the fsbl in the upper 16MB of the qspi.

If after reading from the upper 16MB, we read from the first 16MB, the reboot succeeds!


So basically,  we are trying to figure out how to prevent this reboot bug in a case of a WatchDog reset for example (when we can't predict it)

Any thought might help

Thank you!!


0 Kudos
1 Reply
Registered: ‎05-28-2013

Hopefully you are aware of AR #57744 (

Basically it boils down to ensuring that the QSPI chip:
- has its RESET pin hooked up to the Zynq so that it will be reset when Zynq CPU resets
- is a QSPI device that actually has a reset function (some have a pin, but inside the QSPI it is not connected).

If you are unable to fix the hardware, then the best you can do is a partial hack in the kernel. Since the Zyqn QSPI controller does not support 4-byte addressing, you have to use the extended address register + a 3 byte address. The kernel normally just leaves the extended address register as-is, only changing it when needed (small speedup). But you can modify the kernel to always set the extended address register back to zero. Thus if reset happens, you'll be in the proper "half" of the QSPI, anytime the QSPI device is idle. It won't help if you are accessing the upper half, that's why this is a partial hack...

For a controlled reboot (eg. user initiated shutdown) things are a bit simpler, you can just ensure that chip is put back into 3-byte addressing before reboot. I provided some kernel patches to do that in here.

0 Kudos