Vivado 2018.2 -> unable to reprogram QSPI via JTAG in QSPI32 boot mode

[christian.fonger@solectrix.de]

Hi,

we use the XCZU19eg-FFVC1760 device on a custom board with a QSPI dual parallel flash as boot source.

At startup, when the flash is empty, I can program the flash (via Vivado or SDK) when the boot mode is QSPI32 (0x2).

After a power cycle the system boots successfully. But when I want to reprogram the flash I get no access in QSPI32 boot mode (see below). I must change the boot mode to JTAG (0x0) for a valid reprogramming.

Is it possible to reprogram the flash via Vivado or SDK when the boot mode is QSPI32? Is it possible to change the boot mode programmatically? I found  a XSCT snippet to change the boot mode register:

targets -set -nocase -filter {name =~ "*PSU*"}
stop
mwr  0xff5e0200 0x0100 
rst -system

But it don't works!

-----------------------------------------------------------------------------------

****** Xilinx Program Flash
****** Program Flash v2018.2.1 (64-bit)
  **** SW Build 2288692 on Thu Jul 26 18:24:02 MDT 2018
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.


Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-DLC10-0000128f454d01
    Device 0: jsn-DLC10-0000128f454d01-14758093-0

Retrieving Flash info...

Initialization done, programming the memory
===== mrd->addr=0xFF5E0204, data=0x00000222 =====
BOOT_MODE REG = 0x0222
WARNING: [Xicom 50-100] The current boot mode is QSPI32.
If flash programming fails, configure device for JTAG boot mode and try again.
Downloading FSBL...
Running FSBL...
Finished running FSBL.
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed

-----------------------------------------------------------------------------------

Regards, Christian

[bhunt]

After bootup, the SPI FLASH themselves are probably operating in QUAD mode. In this case, if you try to program the flash using the JTAG bootloader method, the core will not be able to communicate with the flash, since the bootloader starts in x1 mode and expects the flash also to be in x1 mode. 

I'm guessing that the mwr access you showed below was intended to reset the flash, but that would only work in that one specific setting. 

My suggestion is to either 1) disable the board from booting, maybe by holding a system reset active, and then connect via JTAG. Of course, this only works if you can reset the system without holding down INIT_B or PROG_B. Optionally you could reset the SPI flash if it has a reset pin.

Or 2) Figure out how to write a reset to each flash device, perhaps using a special design. For example, I've had a (single) quadSPI flash design, which runs in QUAD mode. To reprogram the flash I used a small SPI-writer design to send the SPI reset command. To reset the micron n25 I wrote to the WRITE ENHANCED VOLATILE CONFIGURATION REGISTER.  Writing 0xCF to that register would reset the micron flash to x1 mode. After that operation, I could use the JTAG indirect programming. 

Hope this helps,

BryanH

[stephan_hochmueller]

Hello,

did anyone found a solution for this problem? I am working on Trenz Te0782 board. On this Board a CPLD is used to set the boot mode. Thus by default the boot mode is QSPI. I will avoid to program the CPLD to be able to flash a new firmware version and reprogram the CPLD again. 

Until yet I was working with Vivado 2016.3. With this version it was absolut no Problem. Now I updated to Vivado 2018.2 and I am no even able to program the flash... 

Thank you,

Regards, Stephan

[denist]

BTW: JTAG boot mode is still the recommended mode for flash programming BUT your procedure should work.

This is what I used:

"

connect
targets -set -filter {name =~ "PSU"}
mwr 0xffca0038 0x1FF
targets -set -filter {name =~ "MicroBlaze PMU"}
# force jtag mode
mwr -force 0xff5e0200 0x0100    
# reset         
targets -set -filter {name =~ "PS TAP"}
rst -srst

"

[stephan_hochmueller]

Hello denist,

thank our for you fast response! Is this also possible on a Zynq? The TE0782 board is based on the Zynq7100.

Regards, Stephan

[denist]

No, sorry. there's no option to do this in zynq-7000. You should really switch boot mode pins.

Maybe simply shorting the 1 to GND when releasing POR_B.

[jhartfiel]

Hi Stephan and Denist,

this limitation was introduced with Vivado 2017.3:

• https://www.xilinx.com/support/answers/70148.html

On older Vivado versions it was not needed. JTAG mode for QSPI programming was only a recommendation for older Vivado versions, because some applications on Zynq can stop JTAG access. Normally it's not a problem to write Flash if the boot mode is set to QSPI.

The problem on this changes from Xilinx is now, that default FSBL try to find a Boot.bin on QSPI. And if the flash is empty, it will stop on an error state, before QSPI will be programmed by Xilinx micro Uboot.

So for TE0782 you has 3 options:

1. Use older Vivado Version (only temporary a workaround and not a good solution for the future)

2. Change TE0782 CPLD firmware to JTAG (but this is only a fallback for this module and not good to handle for flash programming only)

3. Modify a second FSBL for Vivado/SDK GUI only (I would recommend this way, because it's very easy)

So for option 3 with second FSBL do following:

Use Boot.bin with "normal" FSBL and create a second modified FSBL for the Vivado/SDK GUI only.
On the second FSBL, you must only overwrite boot mode pin readback on main.c with JTAG Mode, see:

   /*
    * Read bootmode register
    */
   BootModeRegister = Xil_In32(BOOT_MODE_REG);
   BootModeRegister &= BOOT_MODES_MASK;
  
  /* Add this modification: */
   BootModeRegister = JTAG_MODE;
 

Optional you can also disable DDR initialisation, because it's not needed for QSPI programming.

Trenz Electronic will provide this special FSBL for QSPI programming on all 2017.4 and newer reference design for module with Zynq and ZynqMP devices.

Best regards

John

[polyee13]

Option 3 seemed to have work for me here with a Z7045 device. Can a Xilinx employee or someone experienced with many iterations of programming devices tell me if the modified fsbl_special.elf that is pointed to by the tools can be used on different devices or is it device specific? I was hoping since it's not the fsbl.elf in the .bin file that was modified and only a fsbl that is pointed to for programming, that this fsbl_special.elf can be used generically. 

[glena]

The FSBL used to program does not need to match the FSBL in the boot.bin.   It does need to match the hardware being programmed.   This FSBL is used to initialize u-Boot fdor programming the FLASH device, so it needs to be built from an hdf that represents the Zynq device.    

[jhartfiel]

Hi polyee13,

whats glena told you is correct. Every Zynq board has other PS configuration, which will be imported with the generated HDF from your vivado project. So in general do never use files from different boards. Also do not used files from different Vivado/Petalinux versions thogether.

What you can do to have this special FSBL for QSPI programming a little bit general:

First way (I would more recommend this way): is to create your own FSBL Template for QSPI programming, which can be loaded as local repository into your SDK project (See reference designs  for Vivado 2017.4 or newer of the Trenz Electronic Zynq modules --> you can also copy this template from on of these projects (named "zynq_fsbl_flash")). But you must create a new template for every new Vivado Version, so that all new Xilinx changes on FSBL are include.

Second way (I never tried out and here also some restrictions): Create Vivado Project with PS only. Configure QSPI, Zynq REF-CLK and MIO Bank Voltage link it is set on your board (see board schematics) and disable the default activated PS-PL AXI interface. Create HDF and modify FSBL   for QSPI programming (with the fix JTAG Boot Mode and DDR disabled). I think this ELF file should work on all Boards with the same QSPI connection, the same Zynq REF-CLK and the same MIO Bank Voltages. And the same like on the first way, create one for every new vivado version.

br

John

[hofo]

I have the same problem with Vivado 2018.3 and TE0722-02 after I performed the steps in https://wiki.trenz-electronic.de/display/PD/SDK+Projects#SDKProjects-Xilinx%22HelloWorld%22onZynq :(.

When I created the FSBL I tried both: "Zynq FSBL (TE modified for TE0722 without DDR!)" and "Zynq FSBL for Flash programming (TE modified).

It freezes when it is preparing for programming flash and I get a message that one source file is missing =>

Is there a way to fix this?

Best regards,

Oliver

[jhartfiel]

Hi,

you must use the FSBL "Zynq FSBL (TE modified for TE0722 without DDR!)" for Boot.bin and "Zynq FSBL for Flash programming (TE modified)" for GUI.

Power OFF/ON before and try again

Which power supply did you use for TE0722?

Never try to use default FSBL on TE0722, if you do this you can't get access again to the flash and you must follow(at the moment I didn't think this is your problem):

https://wiki.trenz-electronic.de/display/PD/TE0722-Recovery

When you begin, try out prebuilt files of the reference design delivery and please follow instructions of the reference design decription:

https://wiki.trenz-electronic.de/display/PD/TE0722+Test+Board

and

https://wiki.trenz-electronic.de/display/PD/TE0722+Getting+Started

From your error message, it seems to be more a SDK Software problem of your SDK project.

It seems you use Linux, correct? Which one? Native or VM?

br

John

[polyee13]

I use this method every time without issues. It seems like it's only an issue with a brand new flash that hasn't been programmed yet though.  

[hofo]

Re: Vivado 2018.2 -> unable to reprogram QSPI via JTAG in QSPI32 boot mode

Hello John,

Sorry I'm novice to Zynq designs, but I'm getting closer.

My setup:

Vivado 2018.3
Refernce design: TE0722-test_board-vivado_2018.3-build_05_20190510163659
TE0722-02 powerd with TE0790-03 (firmware: XMOD_DIP40)

The steps I performed as described in https://wiki.trenz-electronic.de/display/PD/SDK+Projects#SDKProjects-Xilinx%22HelloWorld%22onZynq

1. Create FSBL with "Zynq FSBL (TE0722 without DDR!), no change to FSBL-BSP
2. Create Hello_World (Template: Hello World)
3. Create Boot Image for Hello_World
4. Programing Flash fails!
5. Closing SDK, Power off TE0722, etc. (procedure described in TE0722-Recovery)
6. Open SDK
7. Programing Flash is now OK!
8. When I start the SDK Terminal I receive =>
   Read LIGHT SENSOR ID: Si1143 Revision: 0 Sequencer Revision: A11
   LED D4 on (Remaining Loops 0x8)
   LED D4 off (Remaining Loops 0x8)
   ...
   Now I can start hello_world and receive "Hello World" in the SDK Terminal

But now comes the problem:
When I power ON/OFF it is not possible to programe the flash again and I have to perform the recovery sequence =>

cmd /C program_flash -f D:\FPGA\test_board\workspace\sdk\hello_world\bootimage\BOOT.bin \
-offset 0x0 -flash_type qspi-x4-single -fsbl \
D:\FPGA\test_board\workspace\sdk\fsbl\Debug\fsbl.elf -verify -cable type xilinx_tcf url \
TCP:127.0.0.1:3121

****** Xilinx Program Flash
****** Program Flash v2018.3 (64-bit)
**** SW Build 2405991 on Thu Dec 6 23:38:27 MST 2018
** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-ONB4-251633002A2EA
Device 0: jsn-JTAG-ONB4-251633002A2EA-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=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=0x000FA240 =====
READ: IO_PLL_CFG (0xF8000118) = 0x000FA240
===== mrd->addr=0xF8000108, data=0x00030008 =====
READ: IO_PLL_CTRL (0xF8000108) = 0x00030008
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
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed

Is this the intended behavior? Is it always necessary to perform the TE0722-Recovery procedure?

Thank you for your help.

Best regards,

Oliver

[jhartfiel]

Hi,

TE0722-Recovery procedure is needed when you write an non working design into Flash.

TE0722 without DDR is really not a module to learn how zynq works.

Boot Mode is fix QSPI on TE0722 and TE022 has no DDR.  DDR will not automatically disabled on FSBL --> that's the reasion for the special FSBL template for TE0722 where I've done this --> see FSBL source code. Default FSBL try to get access to DDR (this will not automatically disabled), which is not available and than system crashs. In this state is the Flash not accessable over JTAG. The only why to recover the modul is to change the boot mode on power up,on TE0722it must be done like it was shown on the link.

So know to your problem: Normal boot procedure of Zynq is following:  Zynq Boot ROM load FSBL from QSPI(Boot Mode QSPI) into OCM, FSBL initialize Zynq system, load bitstream (FPGA part), load application into DDR and start application.

TE0722 has no DDR, so where did you try to write your Hello World application?

One wy is to use the OCM, the easiest way to do this is to write your application directly into the FSBL code. Do this in the FSBL hooks, where I put I2C sensor and LED access as example with the output message "Read LIGHT SENSOR ID: Si1143 Revision: 0 Sequencer Revision: A11 LED D4 on (Remaining Loops 0x8)..."  in the reference desgin.

Or you must change linker scripts, but pay attanion that you not overwrite FSBL or your instanciate blockram on PL as memory and use it for zynq as memory or.....

You should check following document to understand how zynq works:

https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

From your programming log: which FSBL did you use on this part "... -fsbl \
D:\FPGA\test_board\workspace\sdk\fsbl\Debug\fsbl.elf..."? Here you must use this FSBL for Flash programming, this is needed since Vivado 2017.3 and newer. On older version it works without additional FSBL.

PS: is possible to get an extended log of the flash programming part, set enviroment variable: XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES

see: https://www.xilinx.com/support/answers/59311.html

br

John

[denist]

In case it wasn't mentioned before, you can use https://www.xilinx.com/support/answers/70548.html to "try" programming the flash when booting in QSPI boot mode.

[hofo]

Hello John,

my proof of concept design is now working. I can modify the block diagramm in vivado with additional IP-cores, generate the bitstream and reconfigure the qspi flash with the FSBL.

I think I have had several problems. Ay you mention in the getting started guide for the TE0722 it es really not recommended to use power via the TE0790 debugger... for me it is not working at all so it shoudn't be an option.

The second thing that was preventing me from reprogramming the qspi is the "I2C sensor and LED access"-example within the FSBL. It takes very long to complete and during that time it is not possible to program the qspi.

It should be emphasized that the "Hello World" example (https://wiki.trenz-electronic.de/display/PD/SDK+Projects) is not intended to be used for the TE0722 board. Would be really helpfull to add a section with "Hello World" for DDR-less Zynq design for TE0722. This would have saved me a lot of time :).

The setup that is working for me now is the following:

For loading the bitstream without my application =>

• FSBL generated with Zynq FSBL (TE modified for TE0722 without DDR!)
  
  • Uncommented: "Read LIGHT SENSOR ID: Si1143 Revision: 0 Sequencer Revision: A11 LED D4 on (Remaining Loops 0x8)..."
• For debugging/testing I can create now different application projects with the "Hello World" template. The code sections are placed in the OCM/256kB SRAM.

For loading the bitstream with my application I then have to place the application in the FSBL. Hope that I will figure out another way to do this but atm this the only way that is working for me.

One thing that still confuses me is the "Zynq FSBL for Flash programming (TE modified)" template. You mentioned it is for "GUI". Which GUI do you mean?

Best regards,

Oliver

[jhartfiel]

Hi,

thanks your for feedback.

At the moment I add only some note on the general description on https://wiki.trenz-electronic.de/display/PD/SDK+Projects , but I'll figure something out for the future.

"Read LIGHT SENSOR ID: Si1143 Revision: 0 Sequencer Revision: A11 LED D4 on (Remaining Loops 0x8)..."

I will disable this output by default and add a define to enable this example code on the FSBL, to prevent this kind of issue

"one thing that still confuses me is the "Zynq FSBL for Flash programming (TE modified)" template. You mentioned it is for "GUI". Which GUI do you mean?"

I mean this one:

default FSBL doesn't work, when the flash is empty. See mey decription on the beginning of this post or Xilinx AR#70538( https://www.xilinx.com/support/answers/70548.html ) which was linked by denist

br

John

[hofo]

Hello John,

thank you for your help.

Here is a really nice technical article: Zynq-7000 AP SoC Boot - Booting and Running Without External Memory Tech Tip

• Shows FSBL XIP execution.
• Provide sample routine to do preloading of the data/code to L2-cache, in FSBL.
• Shows L2-cache Lockdown feature in Zynq-7000 SOC.
• Reference design for AXI Timer in PL.
• Shows Interrupt working concept.
• C and C++ application to run in L2-cache lock down mode.

I think this would be a very helpfull reference design for the TE0722.

Best regards,

Oliver

[jhartfiel]

Hi,

thanks to post this link.
I already know the link and I want to ceate a demo for TE0722, but didn't find time for this task until now. It's on my TODO list but unfortunately I have some more modules + assembly variants to take care of:  https://wiki.trenz-electronic.de/display/PD/TE+Reference+Designs+Overview#TEReferenceDesignsOverview-Xilinx.1

This link can also be helpfull for you(in case you has a fix PS setup) with TE0722:

https://www.xilinx.com/support/answers/66846.html

In this case FSBL(so also PS configuration) is load from QSPI, but Bitstream a.s.o. ... will be load directly from SD.

br

John

[isaakian]

Hi - I know this is an old thread, but I recently had a very similar problem with 2018.3 and I did not find any conscise answers via google/forum that solved my problem.   So I'm posting this information to see if it is hopefully helpfull to others.

HW Configuration:

- Were using a TE803 ZU2EG Ultrascale+ MPSOC board from Trenz electronics. 

- Board works fine (using seperate applications on R5-RPU lockstep, and each of the 4x APU cores) when running from JTAG mode.

- Board boots the same application (and PL image) from a APU0 FSBL when booting from QSPI (x8 dual parallel).

However when were in production mode (boot permanently set to QSPI; NOTE this is NON-SECURE mode) the JTAG Tap controller does not respond anymore from JTAG (xsdk) and we cannot attach for debug, or to reprogram the QSPI externally via xilinx program_flash comand.  

The solution that worked for me is:

1. Implemented a command (666) (via UART) on RPU (r5) to execute the following lines when needed (NOTE This is FreeRTOS so some of these commands are not needed - Only the Italic/Bold register access are important. 

   case 666: {

    // Prevent the RTOS kernel swapping out the task.
    vTaskSuspendAll();

    // BOOT_MODE_USER (CRL_APB) Register
    // Update BOOT_MODE_USER reg to use alt boot mode:
    unsigned char alt_boot_mode = 0x00; // JTAG
    bool use_alt = 1; // use Software AltBootMode on reset
    *(volatile unsigned int*) 0xFF5E0200 =   alt_boot_mode << 12 | use_alt << 8; // note bits[3:0] are RO (current HW boot mode)

    // RESET_CTRL (CRL_APB) Register
    // now reboot unit
    *(volatile unsigned int*) 0xFF5E0218 = 0x00000010; // set bit 4 (soft_reset) to 1; leave bit 0 (srst_dis) unset.
    // system will reboot now via PMU -> FSBL.  TCM is not stated as being cleared, so it should remain powered on and valid....

    // The operation is complete.  Restart the RTOS kernel.
    xTaskResumeAll(); // never going to get here....

   } break;

After you execute this command you can successfully attach via JTAG and re-program QSPI

[denist]

I like what you have done. Do you still see issues or the mechanism that leverage the ALT_BOOT_MODE is working?

[isaakian]

Thanks - This solves our problem.  It allows JTAG connection for debug and to succesfully reprogram the QSPI flash.

[denist]

Great! Please mark the solution post!