John J

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!

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!

Has anyone gotten any basic interrupt code to work using FreeRTOS on the Genesys ZU board?

(This question has been posted at Xilinx, but I'm posing it in this forum in case someone has run into the same issue here.)
The FreeRTOS example that Xilinx provides does not run on our Zynq UltraScale+. We have enabled the appropriate timers in Vivado, but the interrupt handler is never called in our applications running on a FreeRTOS domain. Are there any other configuration options that are required to make this work?
Does anyone have an example of using interrupts with FreeRTOS on an UltraScale+.
We would like to see a working example using a UART, but any device that we can easily generate an interrupt from would helpful.
Thank you for your help!
We were using the following example.
https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/bsp/freertos10_xilinx/examples/freertos_intr_example.c

From pg201:

Port sdio_data_out[4] is SDIO_SEL in our schematic. It is a control signal for the level translator instead of SDIO interface proper. We determine drive levels using board-level simulation and prototype validation.

Hey @John J,
We could reproduce the issue and I wanted to share the debug process and the solution.
Checked out the 3eg/master hello_world reference project. Activated UART1 in Vivado, exported and imported into Vitis. Added driver init calls for UART0 and UART1. Calling SelfTest on UART0 works, UART1 does not.
Tried reading addresses 0xFF000000 and 0xFF010000 with mrd in the XSCT console. Reading 0xFF010000, which is the UART1 base address fails:
xsct% mrd 0xFF010000 Memory read error at 0xFF010000. Blocked address 0xFF010000. Block level reset, bit 2 in RST_LPD_IOU2 Indeed register RST_LPD_IOU2 (CRL_APB) at address 0x00FF5E0238 reads with bit 2, uart1_reset, set to 1. UART1 is being kept in reset, which is the reason for SelfTest (and any other action) failing.
Block-level resets should be de-activated during PSU init by the FSBL. If UART1 is enabled in Vivado, there should be a corresponding write to its reset in the exported psu_init.c. The exported psu_init.c indeed de-asserts reset, but the 3eg_fsbl/src/psu_init.c does not:
$ diff /D/git/zuca/sw/ws/3eg_hw_pf/export/3eg_hw_pf/hw/psu_init.c /D/git/zuca/sw/ws/3eg_fsbl/src/psu_init.c 1064,1087d1063 < * Register : UART1_REF_CTRL @ 0XFF5E0078 < < * Clock active signal. Switch to 0 to disable the clock < * PSU_CRL_APB_UART1_REF_CTRL_CLKACT 0x1 < < * 6 bit divider < * PSU_CRL_APB_UART1_REF_CTRL_DIVISOR1 0x1 < < * 6 bit divider < * PSU_CRL_APB_UART1_REF_CTRL_DIVISOR0 0xf < < * 000 = IOPLL; 010 = RPLL; 011 = DPLL; (This signal may only be toggled af < * ter 4 cycles of the old clock and 4 cycles of the new clock. This is not < * usually an issue, but designers must be aware.) < * PSU_CRL_APB_UART1_REF_CTRL_SRCSEL 0x0 < < * This register controls this reference clock < * (OFFSET, MASK, VALUE) (0XFF5E0078, 0x013F3F07U ,0x01010F00U) < */ < PSU_Mask_Write(CRL_APB_UART1_REF_CTRL_OFFSET, < 0x013F3F07U, 0x01010F00U); < /*##################################################################### */ < < /* 16267,16269d16242 < * Block level reset < * PSU_CRL_APB_RST_LPD_IOU2_UART1_RESET 0 < 16272c16245 < * (OFFSET, MASK, VALUE) (0XFF5E0238, 0x00000006U ,0x00000000U) --- > * (OFFSET, MASK, VALUE) (0XFF5E0238, 0x00000002U ,0x00000000U) 16275c16248 < 0x00000006U, 0x00000000U); --- > 0x00000002U, 0x00000000U); Vitis does not automatically update the psu_init.* local copies in standalone application projects. These should actually be linked from the platform, but Vitis does not do that.
There are three work-arounds possible:
Overwrite psu_init.* in 3eg_fsbl after every xsa import. Export xsa to sw/src/3eg_hw_pf. Checkout Vitis workspace again using sw/src/checkout.tcl. Generate boot components in platform project, internalizing fsbl and automatizing psu_init update. This hinges on Xilinx fixing the FSBL BSP optimization flag bug, which is the reason for externalizing the FSBL in the first place.

Hi @John J,
I'm sorry for my late response.
The generic project creation script will be very helpful.  To make everything a little bit more clear, the system initialization trough psu_init() is returning  back an DDR initialization error, and when you are enabling the debug prints by adding the FSBL_DEBUG_INFO symbol, this error is disappearing? 
If this is the case, I have to somehow recreate your setup, because I'm not experiencing the same issue on my local machine. You also said that you are experiencing this in 2022.1, and you didn't had problems in 2020.1, am I right?
Best regards,
Bogdan Vanca

Hi @John J,
I will see if I can replicate this behavior. Based on what you have described, you seem to be doing everything correctly.
Thanks,
JColvin

Hi @John J,
I am in the process of downloading 2021.2 (garsh these downloads get bigger every year) and will let you know what I experience. From your very detailed description, you seem to have done every step correctly so I don't have anything to directly recommend to try differently at the moment.
Thanks,
JColvin