Unable to FLASH QSPI. Vivado Rev. 2022.1 5ev eval board

[Luigee]

I am using Vitis to try and program my flash QSPI device on the 5ev evaluation board. I am not having any luck. Does anyone know of any issue with rev. 2022? It seems like it can't even see the spi flash device. I do have it enabled in the Zynq UltraScale + MPSoc I/O configuration setup. 

error Print out:

Initialization done
Using default mini u-boot image file - /tools/Xilinx/Vitis/2022.1/data/xicom/cfgmem/uboot/zynqmp_qspi_x4_single.bin
===== mrd->addr=0xFF5E0204, data=0x00000000 =====
BOOT_MODE REG = 0x0000
Downloading FSBL...
Running FSBL...
===== mrd->addr=0xFFD80044, data=0x00000000 =====
===== mrd->addr=0xFFD80044, data=0x00000003 =====
Finished running FSBL.

U-Boot 2022.01-06940-g8ed6b9e (Feb 24 2022 - 09:50:51 -0700)

Model: ZynqMP MINI QSPI SINGLE
Board: Xilinx ZynqMP
DRAM:  WARNING: Initializing TCM overwrites TCM content
256 KiB
EL Level:    EL3
Multiboot:    0
Loading Environment from <NULL>... OK
In:    dcc
Out:   dcc
Err:   dcc
ZynqMP> sf probe 0 0 0
Failed to initialize SPI flash at 0:0 (error -2)
ZynqMP> Sector size = 0.
f probe 0 0 0
Performing Erase Operation...
sf erase 0 50000
No SPI flash selected. Please run `sf probe'
ZynqMP> Error while communicating with SPI flash device - No SPI flash selected.
Erase Operation failed.
INFO: [Xicom 50-44] Elapsed time = 0 sec.

ERROR: Flash Operation Failed

[John J]

I have done more research on this issue.  Any help would be appreciated.

Info:

• Vitis versions used: 2020.1, 2022.1 and 2023.1
• Vitis is running under Ubuntu 18.04 and 22.04
• There is no difference in the failure modes between the Vitis/Ubuntu versions is used
• This has been tested in the Vitis GUI and with the program_flash command with the same results.
• Boards tested:  Two Genesys-ZU 3EG boards and one Genesys-ZU 5EV board all are Rev D.
• Two boards fail with the error @Luigee listed above.
• The third board sometimes works, but less than half of the time. It has never failed with the error that occurs on the other boards.  It usually fails with a single bit error on verify.

Please let us know if there is anything else that we ca try to make this work, as we have used the same flash design on our custom boards.

Thank you for your help.

Edited June 28, 2023 by John J

[John J]

@Luigee discovered that the QSPI flash can be programmed reliably using the default Xilinx FSBL from the Vitis templates, but fails with the Digilent provided Genesys-ZU FSBL.

I tried replacing the xfsbl_qspi.* files in the Digilent FSBL with the current Xilinx provided files, but programming still fails.

This does make me wonder what else in the Digilent provided FSBL may have issues.  The Digilent FSBL is required to initialize the DDR properly.

The workaround is to generate an FSBL ELF file with the Xilinx provided files just for programming.  This works, but it is another thing to keep track of.

Edited July 5, 2023 by John J

[Ionut]

Hello,

 

I tried to reproduce the problem on Genesys ZU-5EV, using the Hello World demo, which we recently migrated to Vivado 2023.1. I tried to program the QSPI flash from Vitis multiple times, starting from offset 0, and it completed without error every time.

For reference, I used this repo: https://github.com/Digilent/Genesys-ZU, which I cloned and then checked out the 5EV/HELLO-WORLD/2023.1 tag.

To rebuild the project, I followed the instructions from this page: https://digilent.com/reference/programmable-logic/genesys-zu/demos/hello-world.

NOTE: In the respective page, the instructions marked with orange ("After recreating a Vitis workspace from source...") under the "Using the Latest Release" tab were very important in correctly compiling the sw project.

However, when trying to boot from QSPI, I encountered the following error:

Xilinx Zynq MP First Stage Boot Loader

Release 2020.1   Jul  5 2023  -  17:32:44

Reset Mode      :       System Reset

Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU5EV

Digilent Genesys ZU board-specific init

QSPI 32 bit Boot Mode

FlashID=0x9D 0x60 0x19

XFsbl_SpkVer: XFSBL_ERROR_INVALID_EFUSE_SELECT

Failure at boot header authentication

Boot Device Initialization failed 0x74

Fsbl Error Status: 0x0

We are investigating the issue, and we will post here as soon as we have a fix for it.

Best Regards!

Edited July 10, 2023 by Ionut

[John J]

@Ionut,

Thank you for your response, and I do hope a solution is found to the issue you have described.  I would like to know when that update is available.

It would also be helpful to know what this "wrong FSBL BSP optimization flag bug" that the demo instructions are referring to is.  I wasn't easily able to find anything that sounds like what is being referred to in the demo instructions in either the Digilent or Xilinx forums.

Can you give me a pointer to the description of this "bug"?

Thank you.

Edited July 11, 2023 by John J

[John J]

By the way:  The the tag you mentioned above in the HelloWorld repo currently can't be cloned without a GitHub account, as the submodules are referenced by SSH URLs.  This is not the first time this has been an issue in this repo.

[Ionut]

The respective tag corresponds to the latest 5EV release for the HELLO-WORLD demo project: https://github.com/Digilent/Genesys-ZU/releases/tag/5EV%2FHELLO-WORLD%2F2023.1. You can download the zip files and follow the corresponding instructions in the Genesys ZU Hello World Demo page, as an alternative to cloning the repo.

Regarding the wrong FSBL BSP optimization flag bug, from what I know this was an issue in an older version of Vitis, regarding the -Os optimization flag for the FSBL included in the HW platform. This has since been fixed in more recent versions of Vitis. The Xilinx FSBL optimization flags are mentioned here: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842019/Zynq+UltraScale+FSBL.

 

Best Regards!

[thinkthinkthink]

On 7/5/2023 at 4:33 PM, John J said:

The workaround is to generate an FSBL ELF file with the Xilinx provided files just for programming.  This works, but it is another thing to keep track of.

How'd you implement this workaround exactly and are you sure it works ? I'm also using Xilinx files to generate the FSBL elf but after booting from QSPI I still get the error that @Ionut mentioned.

As a side note, QSPI flashing and booting works fine on the Geneys-ZU-3EG.

[John J]

Hi @thinkthinkthink.

• For flashing process only, you need to generate an FSBL ELF using the generic Xilinx code using any XSA that is valid for the Genesys-ZU and that has the QSPI enabled.  You can just create an FSBL project using the template in Vitis and build it to generate an ELF that can be booted for flashing only.  It probably fails DDR initialization on the Genesys-ZU, but that doesn't matter for the flashing process.
• This ELF should be specified as the "Init File" in the "Program Flash" dialog.
• You then just need to specify the proper Project and Image File and leave the rest at default.
• You should be able to flash any application code that currently can be run using the debugger in Vitis by specifying the projects BOOT.BIN file.
• The FSBL code in the project's BOOT.BIN should have the Digient FSBL source files and the psu_init.c/psu_init.h from your current XSA file.

I know this is brief, but I tried to provide the information that is specific to the procedure for the Genesys-ZU boards and not go into details about how to use Vitis.

JJJ

 

[thinkthinkthink]

We don't have a fix yet but the easiest and most reliable workaround I found was to set the zynq ultrascale QSPI controller in x2 mode from Vivado.

 

Again, writing the flash and booting from it in x4 mode works fine on the 3EG.