elodg

Using Vivado Hardware Manager 2021.2 everything seems to be working: connect_hw_server: Time (s): cpu = 00:00:02 ; elapsed = 00:00:21 . Memory (MB): peak = 1414.113 ; gain = 0.000 open_hw_target INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/210383AFDD5CA open_hw_target: Time (s): cpu = 00:00:07 ; elapsed = 00:00:12 . Memory (MB): peak = 3092.043 ; gain = 1677.930 current_hw_device [get_hw_devices xczu5_0] refresh_hw_device -update_hw_probes false [lindex [get_hw_devices xczu5_0] 0] INFO: [Labtools 27-1435] Device xczu5 (JTAG device index = 0) is not programmed (DONE status = 0). current_hw_device [get_hw_devices arm_dap_1] refresh_hw_device -update_hw_probes false [lindex [get_hw_devices arm_dap_1] 0] current_hw_device [get_hw_devices xczu5_0] create_hw_cfgmem -hw_device [lindex [get_hw_devices xczu5_0] 0] [lindex [get_cfgmem_parts {is25lp256d-qspi-x4-single}] 0] set_property PROGRAM.BLANK_CHECK 0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.ERASE 1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.CFG_PROGRAM 1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.VERIFY 1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.CHECKSUM 0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] refresh_hw_device [lindex [get_hw_devices xczu5_0] 0] INFO: [Labtools 27-1435] Device xczu5 (JTAG device index = 0) is not programmed (DONE status = 0). set_property PROGRAM.ADDRESS_RANGE {use_file} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.FILES [list "C:/git/Zyboz7_rtl8211f/ws/hello_world_system/_ide/bootimage/BOOT.bin" ] [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.BIN_OFFSET {0} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.ZYNQ_FSBL {C:/git/zuca_bm_bist/ws/5ev_fsbl/Release/5ev_fsbl.elf} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.BLANK_CHECK 0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.ERASE 1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.CFG_PROGRAM 1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.VERIFY 1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] set_property PROGRAM.CHECKSUM 0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] startgroup program_hw_cfgmem -hw_cfgmem [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xczu5_0] 0]] f probe 0 0 0 Performing Erase Operation... Erase Operation successful. INFO: [Xicom 50-44] Elapsed time = 1 sec. Performing Program Operation... Program Operation successful. INFO: [Xicom 50-44] Elapsed time = 1 sec. Performing Verify Operation... INFO: [Xicom 50-44] Elapsed time = 2 sec. Verify Operation successful. INFO: [Labtoolstcl 44-377] Flash programming completed successfully program_hw_cfgmem: Time (s): cpu = 00:00:01 ; elapsed = 00:00:11 . Memory (MB): peak = 3173.844 ; gain = 0.000 endgroup In Vitis 2021.2 to avoid creating a hardware platform and project the GUI seems to require for flash programming I used XSCT instead. It works there too: xsct% exec program_flash -f 5ev_fsbl.elf -fsbl 5ev_fsbl.elf -verify -flash_type qspi-x4-single ****** Xilinx Program Flash ****** Program Flash v2021.2 (64-bit) **** SW Build 1967 on 2021-10-14-04:42:58 ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved. Connected to hw_server @ TCP:localhost:3121 Retrieving Flash info... Initialization done Using default mini u-boot image file - d:/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=0x00000003 ===== Finished running FSBL. U-Boot 2021.01-00102-g43adebe (Oct 11 2021 - 01:44:06 -0600) Model: ZynqMP MINI QSPI SINGLE Board: Xilinx ZynqMP DRAM: WARNING: Initializing TCM overwrites TCM content 256 KiB EL Level: EL3 Multiboot: 0 In: dcc Out: dcc Err: dcc ZynqMP> sf probe 0 0 0 SF: Detected is25lp256 with page size 256 Bytes, erase size 64 KiB, total 32 MiB ZynqMP> Sector size = 65536. f probe 0 0 0 Performing Erase Operation... sf erase 0 90000 SF: 589824 bytes @ 0x0 Erased: OK ZynqMP> Erase Operation successful. ... ZynqMP> Program Operation successful. ... ZynqMP> INFO: [Xicom 50-44] Elapsed time = 6 sec. Verify Operation successful. Flash Operation Successful While the USB-UART terminal has the FSBL messages: Xilinx Zynq MP First Stage Boot Loader Release 2020.1 Apr 16 2021 - 16:22:31 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU5EV 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 Xilinx Zynq MP First Stage Boot Loader Release 2020.1 Apr 16 2021 - 16:22:31 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU5EV 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 Xilinx Zynq MP First Stage Boot Loader Release 2020.1 Apr 16 2021 - 16:22:31 Reset Mode : System Reset Platform: Silicon (4.0), Running on A53-0 (64-bit) Processor, Device Name: XCZU5EV 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 Could you try the same with the attached FSBL for 3EG? Are you on JTAG mode? 3eg_fsbl.elf

I looked at your capture and you seem to have covered your ground quite well. Signals Rdy and Vld do not change due to LockLostRst or Bitslip, so there was enough good data in the stream for lock in the beginning. Lock was achieved with 7-8 tap delays worth of eye size, or 81-92% unit interval, which is quite good. The only way Vde pulse can be generated in blanking is if something other than a control token is being received by the sink on the blue (zero) channel. It is not in the debug module, but you could add the three TMDS_Decoder/pDataInBnd(7:0) from the netlist to your ILA to confirm. It looks awfully lot like the Guard Band and Data Island Period specific to HDMI, not DVI are being sent. I've been thinking whether this can be due to some design issue on our board, but neither channel inversion (P/N), nor channel swap (0/1/2) could manifest this way. The blue channel is mostly correctly decoded to hsync and vsync pulses, except immediately after the hsync pulse. Confirm the 8b data words that you are receiving in the blanking period and we will go from there.

Can you upgrade to the latest dvi2rgb version and report back with a capture with the debug module enabled? How did you read the IDELAYE2 tap count and eye width values so far without the internal debug module? Can you check on the source side if DVI or HDMI sink is detected?

Yeah, that should not be happening. I do not know what the custom board has on it, there could be signal integrity issues. The ILA captures show the video in and video out IPs, but not DVI2RGB's RGB output, which you say the culprit is. Focus on that, if it is indeed the source of the downstream problems. Activate the internal debug module and post an ILA capture. BTW, non-tokens being sent in the blanking region is normal HDMI behavior, as opposed to DVI. The IP only supports the latter and the EDID should make sure the Source knows that.

That settles it, your code does not fit the instruction memory. Function printf is rather large, due to floating point support. You can use xil_printf, which does not have that and should fit. Use the Address Editor in Vivado to increase instruction memory.

Hello world fits comfortably and you could not have possibly added too much with extra lines. Most probably you have a build error, so the elf file does not get created, so there is nothing to download to the processor. Check the console and build log. If the code did not fit you would see a link error in the build log. In this case, check the Microblaze config of the hardware project, which specifies how much BRAM is to be used for instruction and data memory.

I admire your courage to write an RTL module with a master AXI4-Full interface. The validation errors stem from not having the m_axi interface connected (maybe only partially defined), but rather its composing signals individually. I think for proper AXI4 interface definition that you can use in block design you need to create a custom IP, that has all the AXI magic defined. Also pay attention to reset. The Zynq needs to be configured and out of reset before the S_AXI_HP0 port can respond.

The project seems to have been written in 2017.4 (https://github.com/ATaylorCEngFIET/Hackster/blob/430230fc0cfca0c2108baed7470be8551cf9165c/Sobel_zybo_z7/block_compile.srcs/sources_1/bd/design_1/design_1.bd#L2). If you are a beginner, it is best to use the same Xilinx tool version.

Base address for frame buffers defined here: https://github.com/Digilent/Zybo-Z7-SW/blob/f0965519d72cd14d039215ca6b35c885a71405df/src/Zybo-Z7-20-pcam-5c/src/main.cc#L25 Passed to AXI_VDMA constructor here: https://github.com/Digilent/Zybo-Z7-SW/blob/f0965519d72cd14d039215ca6b35c885a71405df/src/Zybo-Z7-20-pcam-5c/src/main.cc#L82 Frame addresses calculated for each buffer here: https://github.com/Digilent/Zybo-Z7-SW/blob/f0965519d72cd14d039215ca6b35c885a71405df/src/Zybo-Z7-20-pcam-5c/src/ov5640/AXI_VDMA.h#L158 You can get an interrupt when a complete frame is written: https://github.com/Digilent/Zybo-Z7-SW/blob/f0965519d72cd14d039215ca6b35c885a71405df/src/Zybo-Z7-20-pcam-5c/src/ov5640/AXI_VDMA.h#L232 Then either read is fast enough before the VDMA cycles through the other two buffers and begin overwriting the frame, or stop the pipeline until you can read out the frame.

Signal locked should be used as aRst_n for dvi2rgb and rgb2dvi to keep the IP in reset until RefClk stabilizes. (https://github.com/Digilent/vivado-library/blob/master/ip/dvi2rgb/docs/dvi2rgb.pdf) The same doc also requires timing constraints to be added to the TMDS Clk input, which I do not see in your constraint file. Port clk does not need a create_clock constraint, if a Clocking Wizard is used, which constraints its input on its own. Not a big issue, just causes double definition. If the QSPI out-of-box demo works, why don't you start from there: https://digilent.com/reference/programmable-logic/arty-z7/demos/oob?redirect=1 ?

Hi, This is very odd because the onboard flash is an ISSI IS25LP256D (manual), with JEDEC ID 9d, 60, 19 (datasheet). Both Vitis and Vivado flash programming requires an FSBL to correctly configure clocking and pinout for the QSPI controller. I suggest you look at the hardware configuration (Vivado), and the hardware platform and fsbl in Vitis. Second, our Software Support is for 2020.1, where I could program the flash successfully: $ git clone --recurse-submodules https://github.com/Digilent/Genesys-ZU.git $ git checkout --recurse-submodules 3EG/HELLO-WORLD/2020.1-1 $ git submodule update --recursive --init Open Vitis workspace Genesys-ZU/sw/ws xsct% source [getws]/../src/checkout.tcl Set FSBL path in hardware platform project to Genesys-ZU/sw/ws/3eg_fsbl/Release/3eg_fsbl.elf Re-build 3eg_master system project to get the hello-world boot.bin. Xilinx -> Program Flash ****** Xilinx Program Flash ****** Program Flash v2020.1 (64-bit) **** SW Build 2902540 on Wed May 27 19:54:49 MDT 2020 ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved. WARNING: Failed to connect to hw_server at TCP:127.0.0.1:3121 Attempting to launch hw_server at TCP:127.0.0.1:3121 Connected to hw_server @ TCP:127.0.0.1:3121 Available targets and devices: Target 0 : jsn-Genesys ZU - 3EG-210383AF7ECEA Device 0: jsn-Genesys ZU - 3EG-210383AF7ECEA-14710093-0 Device 1: jsn-Genesys ZU - 3EG-210383AF7ECEA-5ba00477-0 Retrieving Flash info... Initialization done, programming the memory Using default mini u-boot image file - C:/Xilinx/Vitis/2020.1/data\xicom\cfgmem\uboot\zynqmp_qspi_x4_single.bin ===== mrd->addr=0xFF5E0204, data=0x00000EEE ===== BOOT_MODE REG = 0x0EEE WARNING: [Xicom 50-100] The current boot mode is SD1-LS. If flash programming fails, configure device for JTAG boot mode and try again. Downloading FSBL... Running FSBL... Finished running FSBL. U-Boot 2020.01-08125-g1c9cef3 (May 05 2020 - 15:11:32 -0600) Model: ZynqMP MINI QSPI SINGLE Board: Xilinx ZynqMP DRAM: WARNING: Initializing TCM overwrites TCM content 256 KiB EL Level: EL3 Multiboot: 0 In: dcc Out: dcc Err: dcc ZynqMP> sf probe 0 0 0 SF: Detected is25lp256 with page size 256 Bytes, erase size 64 KiB, total 32 MiB You can also follow the instructions here to get the hello world project without git: https://digilent.com/reference/programmable-logic/genesys-zu/demos/hello-world

You are driving aRst correctly from the MMCM locked output. One RefClk is stable and aRst is de-asserted, the receiver state machine needs to perform the following in sequence: clock recovery (confirm with TMDS_Clocking/aLocked), phase alignment (pAligned/pMeVld), and channel bonding (pMeRdy). It sounds like the clock has not been recovered yet and everything downstream is still in reset. Otherwise timeout would be counting if no token is detected.

Correction: FMC Pcam Adapter offers limited compatibility on ZU+, like the Genesys ZU. At least one camera out of four can always be mapped to any pin-out. Full info here: https://digilent.com/reference/add-ons/fmc-pcam-adapter/reference-manual?redirect=1#fpga_io_architecture_compatibility. Yes, this is in addition to the two MIPI ports on-board.

How do you know it is not working? What is printed on the console? What is the status of the LEDs?

The very same instructions you linked tackle this expected error in the last 4 steps of the "Build a Vitis Application" section. Did you perform those? The background is that due to a platform build bug the boot components have been separated out from the platform and you need to provide the links to the external executables.

Versioning with Xilinx tools is problematic. You should be using the same version the project was generated in. We have seen issues with absolute paths stored in project settings, Xilinx quirks all over. User I/O interfaces like LEDs and switches should be working in board flow, we will verify. Add repos here:

The warnings mean the get_ports command is not returning any objects. Also, your block design does not have 28 ports. Check the top-level vhd wrapper of the block design for correct ports and their names.

Just make sure all the ports are replicated, there are no name conflicts and it is declared as an interface of the correct type with the right parameters in the Package IP dialog. Use the working or a Wizard-generate IP as an example.

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.

Simple pointer to the vdma address space. Watch for cache, needs to be invalidated to force read from DDR.

It is hard to see in your photo, but it does not seem like you are sending 00001 for PHY address. Also, make sure the PHY is not held in reset. I trust you are outputting the MDIO input on a Pmod output, so that you see driven logic from both the PHY and FPGA.

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

This is a tough nut to crack. Even 75 degrees ambient could work if the design itself does not dissipate much power and the cooling is efficient enough to not let the Zynq die temperature go above 85 degrees. I see that SanDisk SD cards too tap out at 85 degrees. If the source of the CRC error is exclusive to I/O, you could try lowering the data rate. I assume you are trying 25MB/s (50MHz)?

Yes, please create a pull request.

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.