elodg

@elodgI am happy to report that using the "custom genesys zu5ev repo" inside vitis has been great and smooth. The DDR4 HyperX is initialized and run successfully using the 5ev board preset inside Vivado.
I typed "set_property CONFIG.PSU_DYNAMIC_DDR_CONFIG_EN 1 [get_bd_cells /zynq_ultra_ps_e_0]" in the tcl console to make sure the te dynamic ddr config feature is on.
Thanks for the help. Appreicate it!
Best,
Vincent

As explained in the RM, the DDR4 modules require dynamic DDR init, which is enabled in Vivado (sets a config parameter), and performed by the FSBL. The Xilinx FSBL code has conditional compiles only for Xilinx dev boards and our patches add the Genesys ZU too. You  may use the pre-compiled FSBL from https://github.com/Digilent/Genesys-ZU/releases/tag/5EV%2FHELLO-WORLD%2F2022.1-2 with your own application. Or you can add the following repo to your Vitis workspace: https://github.com/Digilent/embeddedsw/tree/genesys-zu-22.1. This latter has the patches applied to the FSBL and will pull those in whenever you generate an FSBL project.

As per manual:
So no 1.5 Gbps. Also watch out for the pinout - it seems like each MIPI device's manufacturer feels an obligation to invent his own pinout and ensure it's not compatible with any other devices.

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.

Your board revision is written on the silkscreen just below the barcode. Our published schematics are generally correct. Designators do not have to be sequential and some components can be left not loaded. Digilent does not publish board layouts.

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.

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 @Hamed
The Zybo Z7 uses a CLG400 part instead of a CLG225. The note in the TRM is referring to a different part with a package with less MIO pins (and pins in general) that doesn't include the physical connections required for SD card boot. The Zybo Z7-10 supports SD card boot through the process shown in this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot.
Thanks!
Arthur

The reference manual listing 25 MHz is correct. The comment in the xdc file was incorrect, which is now fixed and pushed to Github.
You can use Clocking Wizard in the FPGA to generate 125 MHz or configure the Ethernet PHY over MDIO to output 125 MHz on the sysclk port. 

Hello ! 

When you want to integrate the UART you must be careful how you connect the signal taking in account the constraint file. 
In the DSDB constraint file the UART signals are declared using the following names : 
 -uart_rxd_out
 -uart_txd_in

If you follow your defined UART port you will see that the TXD signal is the output and the RXD is the input. The constraint file is giving you a hint with the suffixes "out" and "in". 
the "uart_rxd_out" is the RXD input of the PS that waits for your TXD output of the port and the "uart_txd_in" is the TXD output of your PS that will send data to the RXD input of your port. 

So if your External Interface is called UART_0_0, you should change the constraint file like this: 
- uart_rxd_out  becomes UART_0_0_txd
- uart_txd_in becomes UART_0_0_rxd

Are you careful to open a terminal emulator software ( like Putty or Tera Term) with the proper settings (Baud rate: 115200, 8 data bits, 1 stop bit, no parity bit), in order to see your results ?

I've tested a project on Vitis 2021.1, on a DSDB and is working properly. I will attach here the BOOT.BIN file. All you have to do is to :
1. Put the BOOT.BIN file on a Micro SD
2. Insert the Micro SD into connector J15 on the DSDB
2. Set SW8 to “SD”
3. Prepare your settings on the terminal software 
4. Turn board on and start the session of the terminal software 
5. You should see the following output on the terminal 

"Hello World
Successfully ran Hello World application"

If it still doesn't work. I can send you the whole Vitis workspace and the Vivado project in order to be able to see all my settings and configurations. 

Feel free to write again, if you still have problems in order to be able to provide you the solution.
BOOT.zip

Our repo is a fork of the embeddedsw Xilinx repo. This sw lib comes with the Vitis installation and workspaces use it by default to generate an fsbl project for example.
All you need to do is to add our repo checked out at the right branch as a local software repo in the Vitis workspace. Regenerating fsbl will then pull source code from there.
We will extend the Getting Started guide with a start from scratch section.
As a general recommendation start from your example projects. For the GZU these pull in the right repos and generate projects correctly. 

That's right, our patches can only be re-used in the versions they were rebased on. Since the 2020.1 branch contains important patches related to the DDR4 initialization, I would upgrade to that version.
If you insist on 2019.1, you can try back-porting the 2020.1 embeddedsw commits. We were forced to expand the approved DDR modules we ship the Genesys ZU with and those can only be supported with the DDR4 init patches.

As I said in the other similar post too, this is due to clock primitives being placed in a different region than the I/O primitives it should clock. In your case, since the RGMII input pins are fixed by the FMC pinout, you have to figure out why is bufio_rgmii_rx_clk placed in a different region. You might be trying to clock I/O primitives across multiple regions, which the BUFIO cannot do.
 

The mini-DP connector on the Genesys ZU is not a Dual-mode DisplayPort (DP++). In other words, it does not send DVI/HDMI signals, that a passive adapter cable could wire into a DVI/HDMI Sink. Use mini-DP to DP cables.

Yes, please create a pull request.

What the BIOS too does during a PC boot: reading out the memory module characteristics via SPD and configuring the memory controller accordingly.

It does not look like the kernel panic is due to the new memory module. Although it is worth double-checking memory settings in Vivado for correctness, the kernel panic seems to appear late in the boot process, memory being exercised a lot before it. The stack dump localizes the issue in the i2c driver probe function. Please check the following Xilinx forum post with similar issue: https://support.xilinx.com/s/question/0D52E00006hpluwSAA/ultrascale-kernel-panic?language=en_US.
It seems that you are starting from our OOB project (https://github.com/Digilent/Genesys-ZU/tree/3eg/oob/master), although using an older version, 2019.1. Make sure that you are exporting the xsa from Vivado with bitstream and importing to Petalinux with the proper flow (petalinux-config --get-hw-description). Double-check the addresses in "Address Editor" in Vivado and the generated device tree (./components/yocto/layers/meta-xilinx-tools/recipes-bsp/device-tree/files/pl.dtsi).
To test your memory module you could also try the latest OOB image, which has dynamic DDR4 initialization done by FSBL during boot, so no Vivado changes are needed to accommodate different memory topologies. Follow the steps in https://digilent.com/reference/programmable-logic/genesys-zu/getting-started#getting_the_out-of-box_image. This image should work both with the bundled and any other supported DDR4 module.
 

I will have a look at this as soon as I have some time.

It look like you board flow interfaces are not picked up. Dig further.

If you open the synthesized design and navigate to the InputBuffer cell of dvi2rgb you will probably see the input tied to a constant, which causes placement to complain. Check the block design where the TMDS port of IP is tied to. It must go to a top-level port and it has to be constrained to a pin. If you are using board flow and it connects to a board interface, it should be set. Check the top-level wrapper vhd to confirm the top-level ports are generated for the HDMI/DVI input.

Yeah, ISE is no good as it does not work on Win 10. It last worked on Win 7, but that is outdated as well. You need to go with Vivado.
OPTION#1 Vivado 2021.1 can pull in the board catalog form XilinxBoardStore, which is has the Zedboard defined. Just click Refresh.

The XilinxBoardStore lists it under avnet.com as vendor:

 
OPTION#2: You can install our board files using the steps from https://digilent.com/reference/vivado/installing-vivado/2018.2?s[]=vivado&s[]=init&s[]=tcl#installing_digilent_board_files.

I added the maximum theoretical data rates for SATA (600MB/s) and PCIe (500MB/s) to the reference manual. I do not have benchmarks at the moment, but I recommend mSATA. Good mSATA modules should bench at least 200MB/s read speed.

The Genesys ZU was validated with a 16GB 2Rx8 ECC module (SQR-SD4I16G2K4SEBB).
The PS DDR4 controller is limited to 34GB, so theoretically a sixteen-component 2Rx8 module (32GB) would also work. Keep in mind that dual-rank components max out at a one step lower data rate (1600-3EG; 1866-5EV).

A quick note here. The source files that need editing are part of a library (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841939/xilisf) compiled into a bsp/domain. By navigating to the source files in SDK/Vitis, the local copy of the library's source files are opened. Any modification is done on this local copy and built into the static library (and application) upon build. However, when the source files of the bsp/domain are re-generated (context menu, Regenerate BSP sources), the changes are overwritten from the originals in the Xilinx install directory. Take care this does not happen.
A more permanent solution is forking the library repository (https://github.com/Xilinx/embeddedsw) editing the sources there and including a path to the modified repository in SDK/Vitis Xilinx->Repositories->Global.