Does PYNQ support ZU67DR?

FPGA: zu67DR
PYNQ: 3.01
tried GitHub - Xilinx/PYNQ: Python Productivity for ZYNQ and GitHub - Xilinx/RFSoC-PYNQ: Python productivity for RFSoC platforms

Hi ,
Does PYNQ support ZU67DR? From description, it should support it .
I tried above links to build image, always failed : stick to “starting kernel”.

later , if need, i will update fail info .

thanks

build spec

Copyright (C) 2022 Xilinx, Inc

SPDX-License-Identifier: BSD-3-Clause

ARCH_zynq_pi := aarch64

BSP_zynq_pi :=

BITSTREAM_zynq_pi := base/base.bit

FPGA_MANAGER_zynq_pi := 0

STAGE4_PACKAGES_zynq_pi := pynq ethernet

  • PYNQ version & Board name & Tool Version
  • Full details of the error message you see, or a detailed description of the problem you experience.
  • Steps to reproduce the problem, and if needed: source code and bitstream or any relevant files
  • Debug steps that you have taken to resolve the problem →

Hi there,

There are currently no officially supported development boards for the RFSoC DFE. However, you should be able to build a PYNQ image for the ZCU670 development board using the flow shown in the PYNQ documentation.

You can also check the documentation in this repo, which shows the steps to build a v2.7 image for the unsupported RFSoC ZCU216 development board. You can use as a guide for a PYNQ v3.0 build.

The potential gotcha for the ZCU670 is that the clocking infrastructure is a bit different. As far as I’m aware, the ZU67DR has two methods of clocking the RF-DCs: the CLK104 daughter board, and the on-board SI5381A chip.

If you’re using the CLK104 board this should be fine, as PYNQ already has drivers for this. However, if you’re using the SI5381A chip then you’ll need to write a custom driver. The PYNQ xrfclk driver only deals with the TI LMK/LMX chips found on the supported Gen1 and Gen3 boards.

You can find more info on the clocking requirements of the ZCU670 development board in UG1532.

thanks a lot. and thanks your team contribution for this project.

Here comes failure log:
1: stuck to starting kernel
U-Boot 2022.01 (Apr 04 2022 - 07:53:54 +0000)

CPU: ZynqMP
Silicon: v3

Board: Xilinx ZynqMP
DRAM: 1023 MiB
PMUFW: v1.1
EL Level: EL2
Chip ID: zu67dr
NAND: 0 MiB
MMC: mmc@ff160000: 0, mmc@ff170000: 1
Loading Environment from FAT… *** Error - No Valid Environment Area found
*** Warning - bad env area, using default environment

In: serial
Out: serial
Err: serial
Bootmode: SD_MODE
Reset reason: EXTERNAL
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 3, interface rgmii-id
zynq_gem ethernet@ff0e0000: Failed to read eth PHY id, err: -2

Warning: ethernet@ff0e0000 (eth0) using random MAC address - da:ec:43:f7:24:13
eth0: ethernet@ff0e0000
scanning bus for devices…
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
Found U-Boot script /boot.scr
2779 bytes read in 10 ms (270.5 KiB/s)

Executing script at 20000000

Trying to load boot images from mmc0
23188620 bytes read in 1495 ms (14.8 MiB/s)

Loading kernel from FIT Image at 10000000 …

Using ‘conf-1’ configuration
Trying ‘kernel-0’ kernel subimage
Description: Linux Kernel
Created: 2024-03-17 11:28:41 UTC
Type: Kernel Image
Compression: uncompressed
Data Start: 0x100000d4
Data Size: 23147008 Bytes = 22.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x00080000
Entry Point: 0x00080000
Hash algo: sha1
Hash value: 59f220f3e2470fe145abaaccdfea913faf9d9de7
Verifying Hash Integrity … sha1+ OK

Loading fdt from FIT Image at 10000000 …

Using ‘conf-1’ configuration
Trying ‘fdt-0’ fdt subimage
Description: Flattened Device Tree blob
Created: 2024-03-17 11:28:41 UTC
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x116133cc
Data Size: 39785 Bytes = 38.9 KiB
Architecture: AArch64
Hash algo: sha1
Hash value: 8cdb9a87e3e58d0a34cfa946e3186bbe0d8e64f2
Verifying Hash Integrity … sha1+ OK
Booting using the fdt blob at 0x116133cc
Loading Kernel Image
Loading Device Tree to 000000003fef3000, end 000000003feffb68 … OK

Starting kernel …

2: info at U-boot
ZynqMP> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
→ start = 0x0000000000000000
→ size = 0x000000003ff00000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x000000003fc8e000
reloc off = 0x0000000037c8e000
Build = 64-bit
current eth = ethernet@ff0e0000
ethaddr = a6:bf:b1:01:aa:b4
IP addr =
fdt_blob = 0x000000003bc04220
new_fdt = 0x000000003bc04220
fdt_size = 0x0000000000009b80
FB base = 0x000000003fde0000
lmb_dump_all:
memory.cnt = 0x1
memory[0] [0x0-0x3fefffff], 0x3ff00000 bytes flags: 0
reserved.cnt = 0x1
reserved[0] [0x3bbffd90-0x3fdfffff], 0x04200270 bytes flags: 0
arch_number = 0x0000000000000000
TLB addr = 0x000000003fde0000
irq_sp = 0x000000003bc04210
sp start = 0x000000003bc04210
ARM frequency = 33 MHz
DSP frequency = 0 MHz
DDR frequency = 0 MHz
Early malloc usage: 1330 / 8000
ZynqMP>

3: reset ,then md ffff8000000000 at u-boot:
Hit any key to stop autoboot: 1
ZynqMP>
ZynqMP>
ZynqMP>
ZynqMP> md ffff8000000000
md ffff8000000000
“Synchronous Abort” handler, esr 0x96000004
elr: 00000000080cef40 lr : 00000000080cee8c (reloc)
elr: 000000003fd5cf40 lr : 000000003fd5ce8c
x0 : 000000000000000f x1 : 000000003bc039ce
x2 : 00000000fffffff8 x3 : 0000000000000020
x4 : 0000000000000000 x5 : 000000003bc039c0
x6 : 0000000000000030 x7 : 000000003bc03910
x8 : 0000000000000010 x9 : 0000000000000008
x10: 00000000ffffffd8 x11: 0000000000000010
x12: 000000000001869f x13: 000000003bc03c38
x14: 000000003bc03d40 x15: 0000000000000021
x16: 000000003fca5d84 x17: 0000000000000000
x18: 000000003bc0dda0 x19: 0000000000000004
x20: 0000000000000004 x21: 0000000000000004
x22: 00ffff8000000000 x23: 000000003bc039cf
x24: 0000000000000000 x25: 000000003bc03978
x26: 000000003fd80cc4 x27: 0000000000000008
x28: 0000000000000004 x29: 000000003bc03910

Code: 2a0403f3 17ffffca 7100129f 54000181 (b94002c3)
Resetting CPU …

ERROR ### Please RESET the board

<Fatal error: Timeout while waiting for “root@” or “”>

Thank you for sharing this information.

Hi there,

Judging from the output here I can see you already have an SD card image for this board. What board are you using?

Additionally, it would be best if you detail the steps you took to create your own SD card image. It is likely the problem is stemming from there.

thanks,
Below is my procedure:Using a ZU67DR custom design suppoting 4T4R.
1: Vivado/petalinux 2022.1 version ,Ubuntu20.04.01 ;GitHub - Xilinx/PYNQ: Python Productivity for ZYNQ get the 3.0.1 code, downloaded https://bit.ly/pynq_aarch64_v3_0_1 and https://bit.ly/pynq_sdist_v3_0_1 ,changed name to pynq_rootfs.aarch64.tar.gz and pynq_sdist.tar.gz,located at sdbuild/prebuilt folder.put base.xsa at boards/zynq_pi/hardware_project, system-users.dtsi at meta-user/recipes-bsp/device tree/files. system-users.dtsi is simplified for issue debug:
/include/ “system-conf.dtsi”
/ {
model = “Hallasan 8T8R”;

leds {
compatible = “gpio-leds”;
FAULT_NORMAL_REDLED_D1V8_led {
label = “FAULT_NORMAL_REDLED_D1V8”;
gpios = <&gpio 78 GPIO_ACTIVE_HIGH>;
linux,default-trigger = “heartbeat”;
default-state = “on”;
};
};

leds {
compatible = “gpio-leds”;
FAULT_NORMAL_GREENLED_D1V8_led {
label = “FAULT_NORMAL_GREENLED_D1V8”;
gpios = <&gpio 79 GPIO_ACTIVE_HIGH>;
linux,default-trigger = “timer”;
default-state = “on”;
};
};

leds {
compatible = “gpio-leds”;
STATUS_REDLED_D1V8_led {
label = “STATUS_REDLED_D1V8”;
gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
linux,default-trigger = “heartbeat”;
default-state = “on”;
};
};

leds {
compatible = “gpio-leds”;
STATUS_GREENLED_D1V8_led {
label = “STATUS_GREENLED_D1V8”;
gpios = <&gpio 81 GPIO_ACTIVE_HIGH>;
linux,default-trigger = “timer”;
default-state = “on”;
};
};

};
&gem3 {
status = “okay”;
phy-mode = “rgmii-id”;
phy-handle = <&phy0>;
mdio@0 {
compatible = “snps,dwmac-mdio”;
#address-cells = <0x1>;
#size-cells = <0x0>;
phy0: eth-phy@3 {
reg = <3>;
yt,phy-delay = <0x001f>;
phy-connection-type = “rgmii-id”;
};
};
};

&sdhci0 {

no-1-8-v; /* for 1.0 silicon */
disable-wp;
};

&sdhci1 {

disable-wp;
};

2:running command: make BOARDS=zynq_pi ,get image successfuly, burn image into 32G SD card.
3:same XSA, more complicated system-users.dtsi ,petalinux built minimum image(not using pynq image) can boot up successfully.
XSA only contain DDR,QSPI, EMMC,I2C, SPI, Ethernet, UART ,EMIO ,no other PL section.
attach log for PYNQ and ZYNQ image boot up log .
The first PYNQ build can boot up ,but failed at filesystem starting at 2nd SD partition (due to not set disable-wp for SD0), abnormally, checked log , it is U-Boot 2020.01, and 2G DDR ,it is not true for acutal H/W. after i revised disable-wp into system-users.dtsi ,and rebuilt PYNQ image, the U-Boot is correct 2022.1 and 1G DDR ,but stuck to “starting kernel”
I also tried GitHub - Xilinx/RFSoC-PYNQ: Python productivity for RFSoC platforms code, same results :stuck to “starting kernel”

pynq_log.txt (347.0 KB)

attach decoded pynq device tree from image .
pynq_system.dts.txt (43.6 KB)

sorry. missed zynq_pi.spec

Copyright (C) 2022 Xilinx, Inc

SPDX-License-Identifier: BSD-3-Clause

ARCH_zynq_pi := aarch64

BSP_zynq_pi :=

BITSTREAM_zynq_pi :=

FPGA_MANAGER_zynq_pi := 0

STAGE4_PACKAGES_zynq_pi := pynq ethernet