cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
thammer
Observer
Observer
3,308 Views
Registered: ‎10-09-2018

Programming QSPI flash failing

Jump to solution

Using SDK 2018.2 with a custom board built with Zynq-7000 (XC7Z020) and Cypress (Spansion) S25FL128S QSPI flash.

When I attempt to program flash (Xilinx --> Program Flash menu item), it fails:

cmd /C program_flash -f \
D:\Projects\Lam_Research\VIX_Probe_Interface\svn_repo-02\Firmware\ViX_App\bootimage\BOOT.bin \
-offset 0 -flash_type qspi_single -fsbl \
D:\Projects\Lam_Research\VIX_Probe_Interface\svn_repo-02\Firmware\ViX_FSBL\Debug\ViX_FSBL.elf \
-cable type xilinx_tcf url TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2018.2 (64-bit)
**** SW Build 2258646 on Thu Jun 14 20:03:12 MDT 2018
** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.


WARNING: Failed to connect to hw_server at TCP:127.0.0.1:3121
Attempting to launch hw_server at TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-HS3-210299A180FA
Device 0: jsn-JTAG-HS3-210299A180FA-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
===== mrd->addr=0xF800025C, data=0x00000001 =====
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
===== mrd->addr=0xF8007080, data=0x30800100 =====
===== mrd->addr=0xF8000B18, data=0x80000000 =====
Downloading FSBL...
Running FSBL...
Finished running FSBL.
READ: ARM_PLL_CFG (0xF8000110) = 0x30800100
READ: ARM_PLL_CTRL (0xF8000100) = 0x30800100
READ: ARM_CLK_CTRL (0xF8000120) = 0x00000000
READ: IO_PLL_CFG (0xF8000118) = 0x00000000
READ: IO_PLL_CTRL (0xF8000108) = 0x00000000
Info: Remapping 256KB of on-chip-memory RAM memory to 0xFFFC0000.
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0027DF0D
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x027E767B
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed

With FSBL_DEBUG_INFO defined in the FSBL, the UART output shows:

Xilinx First Stage Boot Loader
Release 2018.2 Jul 16 2019-12:15:07
Devcfg driver initialized
Silicon Version 3.1
Boot mode is QSPI
Single Flash Information
FlashID=0x1 0x20 0x18
SPANSION 128M Bits
QSPI is in single flash connection
QSPI is in 4-bit mode
QSPI Init Done
Flash Base Address: 0xFC000000
Reboot status register: 0x60502000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x88888888

I have defined XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES in my environment and restarted the SDK, there is no additional output on either the SDK console or the UART.

https://www.xilinx.com/support/answers/70148.html implies that the PLL/CLK info shown in the SDK console output may indicate a problem? We have reviewed the clock settings in the Vivado design and do not think anything is incorrect. In support of that, I am able to download and run the application through JTAG, including writing and reading pages in the QSPI flash memory.

In addition, I can connect the Digilent ARTYZ7 board that we used for early development before the custom board was built and programming flash there runs with no issues:

Attempting to launch hw_server at TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-Arty Z7-003017A70261A
Target 1 : jsn-JTAG-HS3-210299A180FA
Device 0: jsn-Arty Z7-003017A70261A-4ba00477-0

Retrieving Flash info...

Initialization done, programming the memory
===== mrd->addr=0xF800025C, data=0x00000000 =====
BOOT_MODE REG = 0x00000000
Downloading FSBL...
Running FSBL...
Finished running FSBL.
===== mrd->addr=0xF8000110, data=0x000FA220 =====
READ: ARM_PLL_CFG (0xF8000110) = 0x000FA220
===== mrd->addr=0xF8000100, data=0x00028008 =====
READ: ARM_PLL_CTRL (0xF8000100) = 0x00028008
===== mrd->addr=0xF8000120, data=0x1F000200 =====
READ: ARM_CLK_CTRL (0xF8000120) = 0x1F000200
===== mrd->addr=0xF8000118, data=0x001452C0 =====
READ: IO_PLL_CFG (0xF8000118) = 0x001452C0
===== mrd->addr=0xF8000108, data=0x0001E008 =====
READ: IO_PLL_CTRL (0xF8000108) = 0x0001E008
Info: Remapping 256KB of on-chip-memory RAM memory to 0xFFFC0000.
===== mrd->addr=0xF8000008, data=0x00000000 =====
===== mwr->addr=0xF8000008, data=0x0000DF0D =====
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0000DF0D
===== mwr->addr=0xF8000910, data=0x000001FF =====
===== mrd->addr=0xF8000004, data=0x00000000 =====
===== mwr->addr=0xF8000004, data=0x0000767B =====
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x0000767B

 


U-Boot 2018.01-00071-g0018654-dirty (May 01 2018 - 11:18:16 -0600)

 

Model: Zynq CSE QSPI Board

Board: Xilinx Zynq

Silicon: v3.1

DRAM: 256 KiB

WARNING: Caches not enabled

Using default environment

 

In: dcc

Out: dcc

Err: dcc

Zynq> sf probe 0 0 0


SF: Detected n25q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB

...

 

Any suggestions on how to resolve this issue?
Thanks!
.Tim

 

0 Kudos
Reply
1 Solution

Accepted Solutions
thammer
Observer
Observer
3,298 Views
Registered: ‎10-09-2018

As I was writing and posting this question, a colleague (@jott) was searching using a different string and was able to locate the answer in this post:  https://www.xilinx.com/support/answers/70548.html

Which in all of our previous searching had escaped us. We had an indication a separate FSBL was needed, but could not find the magic incantation till now.

View solution in original post

4 Replies
thammer
Observer
Observer
3,299 Views
Registered: ‎10-09-2018

As I was writing and posting this question, a colleague (@jott) was searching using a different string and was able to locate the answer in this post:  https://www.xilinx.com/support/answers/70548.html

Which in all of our previous searching had escaped us. We had an indication a separate FSBL was needed, but could not find the magic incantation till now.

View solution in original post

jott
Participant
Participant
3,280 Views
Registered: ‎09-27-2017

Just to be clear we are programming a board were the boot mode is hardwired to QSPI Flash.

When Using the Prgram Flash tool you are asked to supply a FSBL. This FSBL needs to run in JTAG boot mode inorder to program the flash. Since the board is hardwired to QSPI an un modified FSBL won't work as it will read the boot mode and run in QSPI boot mode.

What AR70548 shows is how to create a modified FSBL that overwrites the QSPI Boot mode and sets it to JTAG mode so that the Flash programming works.

Out project now has two FSBLs one un modified which is used when generating the BOOT.bin and a modified one which is only used for programming the flash.

Our only concern now is to not get them mixed up when generating teh BOOT.bin :)

 

HTH

 

Jott

jhartfiel
Participant
Participant
1,980 Views
Registered: ‎05-29-2018

Hello,

I’ve some problems with QSPI flash programming with Vivado 2019.2 (maybe also 19.1) and 2020.1 when the boot mode is set to QSPI. Change boot mode  or use third party software for QSPI programming is no option for me, but maybe somebody has some idea how this can solved.

Some background:

With Vivado 2017.2 and older, there was no problem to program flash when the boot mode is QSPI (sometime there was a problem in case Linux was running on Zynq, which can prevent JTAG access, but  booting could be stopped before). So everything was fine.

 

With Vivado 2017.3 up to 2018.3 programming procedure has changed (see Xilinx AR#70146) and  user must add additional FSBL now which initialise PS before Xilinx micro Uboot starts.

So recommendation to use JTAG boot mode switch more or less to must have. This can be problematic for all boards that were designed without this possibility to change boot mode.  In case the flash contains a valid boot files, everything was fine, but in case flash is empty, default FSBL stops working with error stage, because it didn't find bootable image on flash. This issue could be fixed easily when customer use a special FSBL where boot mode is set fix to JTAG in the source code of the FSBL, see Xilinx AR#70548   --> so this is the solution which Jott described above.

 

With Vivado 19.x (I’ve test 19.2) and newer (I’ve test 20.1 also but with 19.2 files) it seems something on the procedure is changed again.  As long as the QSPI flash is empty, everything is fine and Xilinx AR#70548 which works on older Vivado versions works also here. Bu there is a new problem now, when the flash contains a valid design. When Vivado try to program fsbl for flash programming, it no longer hold the FPGA into reset until FSBL programming finished, so  that the old designs starts (I could see part of the boot log on uart console), it looks like vivado did not recognized/ignore that another FSBL was started. Depending on the running design, I could see mainly 3 different behaviours:

  1. "fsbl for flash programming" was started (I see debug flags ) but it seems to crash
  2. "fsbl for flash programming"  was started and finished and Xilinx micro-uboot crash on qspi access
  3. "fsbl for flash programming" wasn’t started and it works.

Note: in all 3 cases, older design was started before and vivado background console always shows that Downloading FSBL..., Running FSBL..., Finished running FSBL state and some addition address accesses (read and write access) which are the same.

But when I use the same FSBL on programming GUI, which was used in the design itself on the QSPI Flash, it works and I can erase or reconfigure QSPI flash. Different between these two FSBL  are AR#70548,  I also has enabled the banner by default and I've also disabled the DDR (which was possible, see AR#70146). I tried out to enabled DDR again, but it makes no different.

So when Flash is empty I must use FSBL where JTAG mode is set fix to JTAG, and when the flash FSBL is not empty, I must use same FSBL which was used in the design which was programmed before (which can be problematic if I don't have the older design).  Or I must use older Vivado Version to erase flash before I start reprogramming.

I've try to programmed 19.2 generated files one time with 20.1 Vivado HW Manager, which also fails and one time with 18.3 Vivado HW Manager, which works.

So the changes between 19.2/20.1 and older vivado versions seems to be related with Vivado procedure to get JTAG access to the zynq, which makes it hard to find a good workaround. It seems that 7 series Zynq are effected primary on this issue. I had hoped that it would work again with 20.1 but the problem still exists. So does anyone know a way to solve this problem (possibly via Vivado TCL console and some hidden tcl functions or something like this)?

br

John

patocarr
Teacher
Teacher
1,665 Views
Registered: ‎01-28-2008

Hi @jhartfiel @thammer @jott 

  I've run into this issue in 2019.2 and 2020.1 as well. Quite surprising not many people seem to have hit it. By the way, I appreciate the information in this thread. I'm in the process of re-typing my response after the Xilinx forum ate my original post.

  Anyways, I have found a way to keep the target from loading U-Boot while the FSBL is running, and concocted a little script based on output from Vitis and Petalinux to load the binaries over JTAG.

  The secret sauce appears to be handling the CRL_APB.BOOT_MODE_USER register (0xFF5E0200) in a non-documented (afaict) alternate boot mode. Setting the use_alt [8] together with the alt_boot_mode bits [15:12] we can direct the target into changing its boot mode pins.

  The script expects the binaries to be found under ./images/linux, i.e. the Petalinux project root directory.

$ ls images/linux/
pmufw.elf  system.dtb  bl31.elf  system.dts  zynqmp_fsbl.elf
BOOT.BIN  image.ub  system.bit  u-boot.elf <...>

$ xsct jtag-boot.tcl [<hw_server_IP>]

Hope it works on your end.

Thanks,

-Pat

 

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog