John J

Hi @JColvin. In your example, what is the process for creating definitions in the headers for XPAR_AXI_GPIO_BUTTONS_DEVICE_ID and XPAR_AXI_GPIO_LED_DEVICE_ID? Are these manually entered or generated by Vivado and Vitis. I have not seen those definitions anywhere. Thank you for your help.

Hi @JColvin Thank you for the example. I will check it out Monday, as I am out of the office today. My hardware config already pretty much matches yours, so that's perfect. Looking at your code, I believe the Xilinx example is the problem. (just off the top of my head) I don't think they wait the way your code does, and yours make sense. I should know better than to trust their examples. I did not need to connect with the PMU, but I was bit confused by your earlier comment. I'll let you know what I find out Monday. Thanks again.

@BogdanVanca In this attachment, I've added a project for the Genesys-ZU 5EV board in addition to the 3EG. You just have to change board_type in the script to create a project for the 5EG board. I have been working with the 3EG board and wanted to verify that the behavior on the 5EV is the same as the 3EG. It is. I've tested this on two Linux systems with Ubuntu 20.04 and 22.04 and under different user accounts. Both of the projects probably have UART1 enabled and mapped to EMIO pins. As @JColvin is working on an issue related to UART1. Thank you for your help. CreateProjScript-3eg-5ev.zip

Hi @BogdanVanca. To answer your question about psu_init(), I believe you are correct, but it has been a couple of weeks since I was trying to debug it. I know that I tracked it down to the about the lowest level if statement where the failure happens, but I did not make note of it as I did not have the time to do the research to properly debug it. I'm providing the script in the attached zip file, as well as the directory structure, a copy of the Digilent FSBL, and my hardware files needed to use with the script. The hardware files include a Vivado built Genesys-ZU 3EG XSA file with it's Vivado 2022.1 project, but you can use your own, if you properly name it by replacing the one that is included. Note: I wrote the script for Linux, I have not thought about what needs to be done to run it in Windows. Note: In Vitis, you will have to rebuild the FSBL, re-select the FSLB ELF in the platform project, rebuild the platform, rebuild the boot and system projects to run or debug the code in Vitis. I have not figured out how to get around that yet. The script tries to do it, but it does not quite work yet. If you unzip the file in your Linux home directory, you will end up with the following directory and file under ~/source. The details are documented in the script. ~/source/MyProj_MyApp/* ~/source /CreateVitisProject.tcl At that point you can source the Vitis settings64.sh for the Vitis version that you would like to work with and run the script. xsct ~/source/CreateVitisProject.tcl Using the script, in Vitis 2020.1, The hello world app successfully runs. In Vitis 2022.1 with only rebuilding the projects as generated by the script, I get the following output followed by the standard memory write error when the app tries to load. XFSBL_DDR_INIT_FAILED Fsbl Error Status: 0x3FFFFFFF Fallback not supported Exit from FSBL If I define FSBL_DEBUG_INFO in the FSBL project properties, and make sure I rebuild the FSBL, reselect the FSBL ELF in the platform project and rebuild the platform project. I get the following output. Note: This IS Vitis 2022.1. I did not update SDK_RELEASE_YEAR the Digilent FSBL code. Xilinx Zynq MP First Stage Boot Loader Release 2020.1 Aug 25 2022 - 17:32:52 Reset Mode : System Reset Platform: Silicon (4.0), Cluster ID 0x80000000 Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init Processor Initialization Done ================= In Stage 2 ============ In JTAG Boot Mode ================= In Stage 4 ============ PMU-FW is not running, certain applications may not be supported. Protection configuration applied PL Configuration done successfully Exit from FSBL Hello World Successfully ran Hello World application I have repeated this project creation process over 30 times, and run the generated apps many more times over with the same result every time--as long as I follow the procedure. See the header in the script to find out how to use and customize it. While the XSA files are in the ZIP file, the 3EG/5EV hardware projects can be modified/rebuilt with Create HDL wrapper, Generate Output Products, Generate Bitstream and Exporting Hardware while including the bitstream. Let me know if you have any further questions. I appreciate your help. CreateProjScript.zip

@JColvin Huh? Even though I don't have the FTDI schematic page, the PMU should be connected to port 2 on the FTDI chip per the naming in the schematic. The board reference also states this. UART1 on the PS is not even mapped in the Genesys-ZU board files, as all pins that it can be mapped to are connected to other I/O devices. I did try to use MIO pins to run the internal loopback self-test in the driver library code on UART1, but it failed. While debugging, I saw that all data is returned as 0. Is the code even interacting with the UART1 hardware? On a side note, it would be helpful to have the FTDI schematic page, and Xilinx does provide it for their boards.

I was hoping that this question about being able to use Vitis 2022.1 with the Genesys-ZU would generate some interest on the baremetal user side as well as the with the Digilent staff members, but all is quiet. Ping.

@zygot, I appreciate all input that anyone can provide. I would like to try implementing a PL UART, but we have a design that uses the PS UART already. That's additional scope for my project. Also, it's not the example that is failing, but the self-test in the bare metal driver, XUartPs_SelfTest(), that fails. it also fails the internal loopback test when I map to MIO pins, but I can't actually use those to see if it's the self-test in the driver that is failing, as the available pins are already connected on the Genesys-ZU board. I believe you are right about the provided code confusing the ports, as I have found more than one minor error in the code. The UART interrupt example has had the wrong interrupt controller number for years. In addition, even if I set the FSBL stdout to use UART1, that doesn't work. I do see videos where people swap FSBL ports without issue. It would be nice to find the root cause here. John J

@JColvin, Is this something that you still can take a look at? I'd appreciate any help. Thank you, John J

I created a script which produces a generic clean Hello World project in Vitis 2020.1 for a Genesys-ZU 3EG/5EV. It automatically adds the custom Genesys-ZU FSBL and imports an XSA file. The script did not appear to work in Vitis 2022.1, but it actually does. The problem appears to be in the Digilent custom DDR initialization when used with the current tool chain, but I can easily consistently make it work. But it's not a valid "production" solution to the issue. When I define FSBL_DEBUG_INFO for the FSBL project in C++ Build->Settings->Symbols, DDR initialization completes properly. I have not seen it fail in over 30 runs. Without FSBL_DEBUG_INFO defined, DDR initialization fails every time. This appears to be a timing issue with the custom Digilent DDR initialization. Since I believe that I've pinned it down to a small chunk of Digilent code, that is not compatible with the current compiler, can someone take a look at this issue? It would be really helpful. I can provide the generic project creation script, if it will help. It requires very little setup to use. You just have to put the custom FSBL source files and a Vivado XSA in to specific directories and run it. Thank you for your help.

I'm using Vivado and Vitis 2020.1 projects created from the bare metal Genesys-ZU Hello World example as a base to create an application which will be controlled over UART1. In Vivado, I've enabled UART1 and mapped it to EMIO pins. Using the Xilinx UART polled example UART0 passes and UART1 fails XUartPs_SelfTest(). Is there something special that needs to be done to UART1 to get it to at least pass the self-test? I've also: Created my own base project using XSCT and replacing the Xilinx FSBL with the Digilent custom FSBL with the same result Changed the standard output of the FSBL and application to use UART1 as default with the same result Mapped UART1 to MIO pins to see if it would pass the self test but got the same result I have been through several tutorials and browsed the available information, but I still appear to be missing some step in the configuration of the port. Does someone have any ideas on what I'm missing here? I've tried this on a 3EG and a 5EV Genesys-ZU board. Thank you for your help. JJJ

@elodg I was not able to get 2021.2 to program the flash. The boot loader returns an incorrect flash ID. As I mentioned above, the U-Boot included for programming the flash returns the same bad ID. I don't understand why it works differently for me. I'd like to try 2022.1 to see how it behaves, but creating a new project becomes more complicated, due to the lack of the older library versions. Vitis 2020.1 will program the flash, but I've found that in 2020.1 the Genesys ZU "Hello World" project gets corrupted very easily and in multiple ways. When changing anything in the project structure, I often find that the build breaks for reasons that appear to not be related to the actual change. Tracking down the cryptic Vitis errors is a real struggle. I would like to be able to create a "clean" project, but have not successfully pulled in the Digilent FSBL into a new project. What would be very helpful is a more detailed guide on importing the custom Digilent FSBL into a new project. Thank you for your help.

@vcb1 I don't think that "Getting started" applies to UltraScale+ boards. UltraScale+ devices require a first stage boot loader, FSBL. Specifically, the Genesys-ZU also requires a custom boot loader from Digilent to support the DDR. See the first paragraph in section 3 of the reference guide. I had the same issue, as this is a requirement that is not very prominently documented. You can see the discussion here. The gist of it is that I ended up starting with the "Hello World" app specifically with 2020.1 of Vitis to get anything working. 2021.2 can be made to work but has issues with things like programing the onboard QSPI flash.

If you have an SSH key, Git is inconsistent about reporting all submodule interactions, and would properly checkout the files. Notice that in your log that you see lots of details bout "digilent-vivado-scripts", but not much on "embeddedsw". The relative path that you fixed now works for me too. By the way, In recent Git versions, you can use one command to do the whole submodule clone in desired proper branch. git clone --recurse-submodules https://github.com/Digilent/Genesys-ZU.git temp -b 3eg/master I was trying to avoid using the older 2020.1 to match other projects and stay up-to-date, but 2020.1 appears to be the only way to properly start a project for this hardware. Thank you for your help.

Hi @elodg, Actually, the reason that the repo directory was empty is that some of the Digilent Git submodules are unfortunately referenced via SSH protocol. I can't do that, so I had to modify the URLs in both .gitmodules and the .git/modules/*/config files to update the submodules. After completing the steps below, Vitis opened with a platform project only. There was no FSBL or system projects. Again, what am I not doing correctly? The end of the checkout.tcl script output showed the following. ... Finished building libraries INFO: Running /home/jjurisoo/source/Genesys-ZU/sw/src/3eg_master/45_standalone_app.tcl No system project exists, creating new system project. Changing back working dir to: /home/jjurisoo/source/Genesys-ZU/sw/ws Empty Application is not valid application template name use repo -apps to get the available templates Here is the procedure for what I did. git clone --recurse-submodules https://github.com/Digilent/Genesys-ZU.git cd Genesys-ZU # Checkout latest fixes git checkout --recurse-submodules 3eg/master git submodule update --recursive --init # Command failed, edit .gitmodles and .git/modules/*/config to use https: protocol # Re-run the “submodule update” command # Get an updated git workflow script that fixes an important issue cd sw git checkout 3eg/master cd .. cd sw/ws xsct setws "/home/user/source/Genesys-ZU/sw/src" source [getws]/../src/checkout.tcl exit vitis (open the workspace in sw/ws) Thank you for your help.

I am having an issue with the Digilent Git workflow. When trying to run the checkout.tcl script, errors occur. If I run the script as described in the Git workflow listed above, it fails as below. When running from above the repo directory... xsct% source Genesys-ZU/sw/src/checkout.tcl INFO: Running Genesys-ZU/sw/src/checkout.tcl. INFO: Targeting /home/user/source/Genesys-ZU/sw/ws for workspace creation. Changing back working dir to: /home/user/source ERROR: Self not found while deep searching /home/user/source/Genesys-ZU/sw/src When running from the sw/ws directory... xsct% source [getws]/../src/checkout.tcl couldn't read file "/../src/checkout.tcl": no such file or directory So I assume that "getws" something that Vitis defines. If I define "getws", I get. xsct% puts [getws] /home/user/source/Genesys-ZU/sw/ws xsct% pwd /home/user/source/Genesys-ZU/sw/ws xsct% source [getws]/../src/checkout.tcl INFO: Running /home/user/source/Genesys-ZU/sw/ws/../src/checkout.tcl. INFO: Targeting /home/user/source/Genesys-ZU/sw/ws for workspace creation. INFO: Found the following subscripts: /home/user/source/Genesys-ZU/sw/src/repo/0_sw_repo.tcl /home/user/source/Genesys-ZU/sw/src/3eg_hw_pf/5_hw_pf_xsa.tcl /home/user/source/Genesys-ZU/sw/src/3eg_standalone_bsp/25_standalone_bsp.tcl /home/user/source/Genesys-ZU/sw/src/3eg_domain_fsbl/25_standalone_bsp.tcl /home/user/source/Genesys-ZU/sw/src/3eg_master/45_standalone_app.tcl /home/user/source/Genesys-ZU/sw/src/3eg_fsbl/45_standalone_app.tcl /home/user/source/Genesys-ZU/sw/src/3eg_master/145_build_app.tcl /home/user/source/Genesys-ZU/sw/src/3eg_fsbl/145_build_app.tcl INFO: Running /home/user/source/Genesys-ZU/sw/src/repo/0_sw_repo.tcl Changing back working dir to: /home/user/source/Genesys-ZU/sw/ws Repo directory /home/user/source/Genesys-ZU/sw/repo is inexistent or empty. Perhaps you forgot to check out the submodule? Try git submodule update. As the error says, the repo directory is empty, but I did checkout the submodules. If I follow the instructions that I was given here, which says to run the XSCT command from within Vitis. I get the following error. "Workspace already exists and needs to be closed first" What am I missing here?

Hi @elodg After fixing one broken include path in my existing project, other include paths have been corrupted by Vitis. I'm just going to have to recreate the Vitis project again and add my existing code and HW design. I've been suspecting that the flash programming issue is in the project, so I already wanted to recreate it. I'd like to use your method of starting with the repos, but when I have used that method in the past, I run into an issue. After running the checkout script, I get a "Workspace already exists and needs to be closed first" error. I am obviously missing something simple here, but I have not found a solution to the problem, which is why I've just been importing the zip file. I would like to get the method you described above working. Do you have any suggestions. Thank you, John J

The U-Boot that Vitis 2021.2 provides does not recognize the flash on the Genesys board. The "sf probe" fails. It looks like the Digilent FSBL is loading properly, but I don't think the PL is getting programmed correctly. The "Done" LED is not lit up after the process fails, and there is no clock on the QSPI showing on my scope. Is there a way to tell of the PL is getting programmed with the correct bitstream? Terminal output during programming Xilinx Zynq MP First Stage Boot Loader Release 2020.1 Mar 23 2022 - 17:53:51 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Digilent Genesys ZU board-specific init In JTAG Boot Mode PMU-FW is not running, certain applications may not be supported. Protection configuration applied Exit from FSBL Output from either the Console window when using the Vitis GUI and from the XSCT console when typing the commands. . Using default mini u-boot image file - /tools/Xilinx/Vitis/2021.2/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=0x00000000 ===== ===== mrd->addr=0xFFD80044, data=0x00000000 ===== ===== mrd->addr=0xFFD80044, data=0x00000003 ===== Finished running FSBL. ... U-Boot 2021.01-00102-g43adebe (Oct 11 2021 - 01:44:06 -0600) ... ZynqMP> sf probe 0 0 0 jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 8c, 20, 08 ... Using the OOB PetaLinux U-Boot, I get the following. ZynqMP> sf probe 0 0 0 SF: Detected is25lp256 with page size 256 Bytes, erase size 64 KiB, total 32 MiB I'm just wondering if anyone has ideas on pinning this down a little closer, it will be kind of painful to go back to using the older Vitis at this point. Thanks.

The U-Boot that Vitis 2021.2 uses does not work with the Genesys board. The "sf probe" fails. Using default mini u-boot image file - /tools/Xilinx/Vitis/2021.2/data/xicom/cfgmem/uboot/zynqmp_qspi_x4_single.bin U-Boot 2021.01-00102-g43adebe (Oct 11 2021 - 01:44:06 -0600)

I get the error listed below in Vitis 2021.2 when I use the Program Flash option and have tried several "Flash Type" settings in the programming window. Is there a procedure for getting this to work? Are there any special steps when booting from flash that need to be taken to create a proper boot image? Thank you for your help.

I had the same issue, but it just went away after a few clean and build iterations while I was inspecting the configuration. I have not had that particular problem since. I'm using the Vivado/Vitis 2021.2 version and latest Digilent files. I repeated the instructions mentioned above several times and added additional steps to write my own procedure for creating new projects for a specific external hardware configuration. Oddly, I ran into different issues every time--even when I knew I had very closely duplicated the steps. The Xilinx Vivado/Vitis tools have many project related issues that appear to manifest themselves in many ways. Sometimes just viewing particular project properties appears to change or fix the issues, but many times it takes some serious digging. For example, I'm developing on a Linux machine, but after using the project for a couple of weeks, it still has Windows paths in the configuration files that won't go away and are very hard to track down in Vitis. I ended up fixing some by manually editing the project files.

Hi @singhhgurii8, I had too many issues creating a project from scratch and mainly could not get the the custom FSBL repo to import into a project correctly. I ended up starting with the Digilent Hello World app, creating a customized Vivado design, and updating the platform in the Vitis project. It is not ideal, but at least I have a starting point. I did also modify the constraints file so that the signal names in it match up with the signal names in the board files. I'm not an experienced FPGA developer, so I just did it because it made sense to me. It started working after that, but I have not verified if was required. John J

@BogdanVanca, Is there an updated preset.xml file for the genesys-zu-3eg/D.0? I don't see any recent updates to the repo, and I'm getting a 3eg board soon. John

Thank you @elodg, I have been using the Hello World project as a starting point--somewhat successfully. There are a couple of issues that I have run into. First, I'm getting inconsistent results while updating the hardware platform in the Vitis project. After an update, there are sometimes references to files that don't exist, but the next time I work through the exact same procedure, there is no problem. I do believe this is an issue with the Hello World project being used in Vitis 2021.2. The upgrade and directory reorganization appears to be flakey. Also, as a side comment, I see occasional references to files in the project configuration with Windows file names that still exist after longer periods of development in a Linux environment. I know... It's more than likely a Vitis issue. Another thing I noticed is that it appears that not all of the board features are defined for the GZU boards as they are in other Digilent products. An example would be the LEDs and switches. I may be missing something here. I would definitely appreciate the added information to the Getting Started page, as this would avoid having to deal with the project version issues caused by the newer Vitis software, and allow starting with a pristine hardware project. I'm still not clear on how you add the repo from the description you gave. When I tried to do that as described by BogdanVanca, there were many file reference issues. This also may be a Vitis version issue. Thanks again. John J

Hi @BogdanVanca, You are correct that I did not use the custom code. The custom code is only referenced once in the Digilent documentation for the ZU board, and the reference is in a bit of an odd location. It is very easy to miss. It would be more than very helpful to have a description of how to create a working application project from scratch. Unless I'm missing something, there is no simple way to actually import the custom repo into an existing Vitis project. There are several steps that would have to be taken to actually turn the repo into a Vitis project that could be built and edited within Vitis as part of an application project. I built the custom FSBL separately, but there is also no Digilent specific documentation that I can find to help with that either. The repo contains lots of directories with make files and a readme from Xilinx that has instructions on how to build, but that procedure does not produce a working FSBL for the Digilent board. How do you build a working FSBL for the Genesys ZU 5EV board with that code? I've tried both the commit that you sent, and the latest without producing a working FSBL. Thank you for your help in advance. John J

Hi @BogdanVanca, I replaced the board file and created a new project by creating the platform and adding the application, and got the same error. Essentially, I followed the Xilinx tutorial referenced above. The parameter shows up correctly as 0. Do you have any other suggestions? I appreciate your help.