This is a list of required items, necessary actions, and points to be considered, when debugging QSPI programming and booting on Zynq UltraScale+ MPSoC.
Before opening a Service Request, collect all of the information requested below.
Requirements are italicised below.
1) Is the QSPI flash and configuration supported by Xilinx?
See (Xilinx Answer 65463) to determine the support category (Supported, Limited Support, or Unsupported).
Important: Please provide the full flash name, the configuration type (single, dual parallel, dual stacked) and the voltage. If the configuration is not "standard" (muxes, level shifters or other), provide also the board schematics.
2) Is it Zynq Production Silicon?
Use XSCT to read:
Important: Please provide the IDCODE and PS_VERSION
3) Is the JTAG chain operating properly?
Use XSCT to try to connect to the CPU.
Below is a list of relevant Answer Records:
|(Xilinx Answer 67740)||XSDB (or any other JTAG user) needs to hold TMS signal high for 5 TCK cycles to enable PL TAP linking to the JTAG chain.|
|(Xilinx Answer 67818)||2016.3 PMU firmware loading via JTAG / SD Boot Modes and Running An Example|
Important: Please provide JTAG chain description (how many devices on the chain, how many Zynq, Zynq in cascade or independent JTAG, any level shifter in the chain). Report any XSCT error.
4) In which phase of booting Zynq is failing? BootROM or FSBL?
In order to determine this, program an image with FSBL debug prints enabled. #define FSBL_DEBUG_DETAILED in xfsbl_debug.h
If some printing comes out on the UART during boot:
Please provide a log of the FSBL print out on the UART. FSBL is a user application and can be easily debugged using SDK. Try to do a brief investigation before filing a Service Request.
- If nothing comes out on the UART during boot, first double check the UART baudrate.
Please provide the status of INIT_B, PS_ERROR_OUT, CSU_BR_ERROR and BOOT_MODE_POR registers after the boot failure.
- An easy way to provide this register dump is to use the attached .tcl script (boot_registers_log_revX_Y.tcl)
If the boot image was not programmed properly (continue to step 5).
|(Xilinx Answer 66715)||2016.1 Zynq UltraScale+ MPSoC - QSPI programming on a Zynq UltraScale+ device requires boot in JTAG mode|
|(Xilinx Answer 68237)||2016.x/2017.1 Zynq UltraScale+ MPSoC - QSPI programming requires the QSPI Feedback Clock on MIO6|
Please provide the version of the tool used. Be sure your image was built with the same version of the tool used to program.
Please provide the boot mode settings used for programming (booting from JTAG is recommended).
Please provide the log obtained using the XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES variable.
6) Is it working using u-boot?
Use the u-boot.elf pre-built from the latest released image on the wiki http://www.wiki.xilinx.com/Zynq+Releases
Please provide the log of the programming using pre-built u-boot image from the wiki. Specify the u-boot version used.
If u-boot is working, use (Xilinx Answer 68657) to program the QSPI flash with the desired BOOT.bin.
7) Is the board design to support the QSPI frequency used for programming?
Use u-boot and double check the clock settings to verify the QSPI clock frequency (QSPI_REF_CLK and QSPI_CLK on the CLK pin).
Remember that QSPI has various modes of operations depending on the clock frequency. Calculate and verify the QSPI clock speed.
Please provide the register settings and the calculation done to verify the QSPI clock frequency.
8) Is the Xilinx standalone example working?
Some Debugging is required to understand where the example is failing (through the SDK debugger or by adding debug prints).
Is the issue with the initial query of the QSPI or a mismatch between writes and reads?
Is there any error pattern in the read back data? (Maybe a particular bit stuck to 1 or 0).
Report the type of failure in the Xilinx standalone example