elodg

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.

Some SD cards work better than others, and we tested the one in the kit for compatibility at the maximum data rate supported.
Your failing images get stuck in u-boot after the BootROM and the FSBL have already successfully read the SD card. I suspect it has to do with the u-boot driver trying for UHS-I speeds at 208 MHz. Something fails during line tuning and results in errors. Going back to High-Speed mode at 3.3V should work with any SD card out there. This can be done from the device-tree: https://support.xilinx.com/s/article/69978?language=en_US.
There are plenty of bugs in the SD controller driver and you can check Xilinx's changelog here: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842090/SD+controller.

We are trying hard to avoid changes between revisions that might break gateware/software compatibility.
Our repo for xdcs is https://github.com/Digilent/digilent-xdc. Here are the differences between the two revs:
$ diff Genesys-ZU-3EG-D-Master.xdc Genesys-ZU-3EG-Master.xdc 1c1 < #### This file is a general .xdc for the Genesys ZU-3EG Rev. D --- > #### This file is a general .xdc for the Genesys ZU-3EG Rev. B 261,263d260 < < ## Power-good input for VADJ supply rail < #set_property -dict {PACKAGE_PIN AA12 IOSTANDARD LVCMOS33 } [get_ports { pg_vadj_r }]; #IO_L12N_AD8N_44/24 Sch=pg_vadj_r Our published reference projects support both revs and you can ignore the "revB" in the constraint file name.

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.

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.

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.
 

The IP conforms the AXI4-Stream Video IP and System Design Guide https://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf, sub-section "Encoding Multiple Pixels - Static TDATA Configuration":
LSB corresponds to leftmost pixel in a scanline.

The ML Standard edition (formerly WebPACK) does not install device support for bigger parts. You will need to re-install the ML Enterprise edition with Kintex-7 support. The license you generated will be needed upon Synthesis or Bitstream generation.

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).

$ git clone https://github.com/Digilent/Zybo-Z7-20-pcam-5c.git $ git checkout v2018.2-2 $ git submodule init $ git submodule update $ python digilent-vivado-scripts/git_vivado.py checkout This will re-create the Vivado project for the block design sources. Documentation for the scripts here: https://github.com/Digilent/digilent-vivado-scripts/blob/7b4d88aaa3c2c760167b2c563942f56e4a4cfce1/README.md.