Why does PYNQ occupy card0?

[ 10.545551] zocl: loading out-of-tree module taints kernel.
[ 10.761242] [drm] Probing for xlnx,zocl
[ 10.761304] zocl-drm axi:zyxclmm_drm: IRQ index 0 not found
[ 10.780984] [drm] PR[0] Isolation addr 0x0
[ 10.819819] [drm] Initialized zocl 0.0.0 for axi:zyxclmm_drm on minor 0

I compared the boot logs of Petalinux and PYNQ and found the above content in the logs. It seems that axi:zyxclmm_drm is not used for display output, but it still creates the card0 device.

This has caused some issues for me, as my gui application keeps treating card0 as the output device, resulting in the following log:

[ 48.901160] zocl-drm axi:zyxclmm_drm: zocl_destroy_client: client exits pid(389)
[ 65.591902] zocl-drm axi:zyxclmm_drm: zocl_create_client: created KDS client for pid(653), ret: 0

So, I was wondering if the creation of card0 is caused by some service in PYNQ. If so, is it possible to adjust the service order so that my HDMI driver creates the card0 device first, and then PYNQ uses card1?

I tried modifying my GUI application KlipperScreen to run on minor 1, but for some reason, it really prefers card0. It’s driving me crazy and nearly making me lose my hair! So, is there any way to give card0 back to me?

Hi @bonkbonk

What board are you using?

Hello,

I make the board by myself.

I designed this board for my 3D printer to run Klipper firmware, and since Klipper also uses Python, it would be awesome to use PYNQ with it. But I’ve been having a lot of trouble with the HDMI display GUI.

Pynq version: 3.0.1

Hi @bonkbonk

What device is it? Zynq or Zynq UltraScale+?

Hi @joshgoldsmith

I’m using the Zynq 7020.

Hi @bonkbonk

Then I’m not sure why that is happening, unfortunately.

On ZU+ devices we “Create a new driver instance bound to card0 which should always be the hardened DisplayPort”. But we don’t do this for Zynq devices. You can see the code for that here.

For ZU+ devices we also include an X11 server so you can use a desktop environment on the board through the display port interface. You can see the x11 package we install here. However, we only install x11 package for ZU+ devices, not for Zynq devices.

More information about video can be found in the PYNQ video library documentation.

hi @joshgoldsmith

# Copyright (C) 2022 Xilinx, Inc
# SPDX-License-Identifier: BSD-3-Clause

ARCH_zynq-7020 := arm
BSP_zynq-7020 :=
BITSTREAM_zynq-7020 :=

STAGE4_PACKAGES_zynq-7020 := xrt pynq

That’s really strange! In the PYNQ sdbuild process, the chip type should be defined in the board/<custom>/*.bsp file, right?

In my bsp file, I explicitly specified ARM and didn’t declare X11, but the generated image uses a different chip and has X11 installed.

Is there any other place where the chip type can be set? I’d like to see if there’s an issue with my build configuration.

As far as I know the only place the build process looks for the architecture type is in the board *.spec file.

You can see an example of the ZCU104 (ZU+) here.

And the Pynq-Z2 (Zynq) here

The Makefile parses these .spec files and uses the ARCH_$1 (where $1 is the board name, e.g. ARCH_ZCU104) to determine the architecture of the board.

The stage 3 packages (e.g. x11) are then defined around here in the Makefile (where $1 is the architecture)

Thank you for your explanation. I can’t believe I’ve been developing on the wrong CPU architecture all along.

hello @joshgoldsmith

Yesterday, I reinstalled PYNQ 3.0.1, and after packaging, card0 still appeared. This is really puzzling to me.

First, my BSP file is indeed set to ARM, and if I were to directly package it as aarch64, I shouldn’t be able to boot the image.

Moreover, PYNQ’s /ps.py uses CPU_ARCH = platform.machine() to obtain the CPU architecture, and when I tested it on the system, it also showed ARM architecture. So, if card0 is created by drm.py, this seems unlikely, doesn’t it?

boot log:

[ 10.176717] zocl: loading out-of-tree module taints kernel.
[ 10.192481] [drm] Probing for xlnx,zocl
[ 10.192576] zocl-drm axi:zyxclmm_drm: IRQ index 0 not found
[ 10.245202] [drm] PR[0] Isolation addr 0x0
[ 10.252532] [drm] Initialized zocl 0.0.0 for axi:zyxclmm_drm on minor 0

system-suer.dtsi

/include/ “system-conf.dtsi”

/{
chosen {
bootargs = “console=ttyPS0,115200 earlyprintk uio_pdrv_genirq.of_id=generic-uio”;
};

usb_phy0: phy0@e0002000 {
	compatible = "ulpi-phy";
	#phy-cells = <0>;
	reg = <0xe0002000 0x1000>;
	view-port = <0x0170>;
	drv-vbus;
};

};

&usb0 {
dr_mode = “host”;
usb-phy = <&usb_phy0>;
};

&i2c0 {
clock-frequency = <100000>;
status = “okay”;
};

build command:

make clean

make BOARDS=zynq-7020

Here is some additional information I can provide. Is there any other possibility? Should axi:zyxclmm_drm be present on an ARM-based system? Could i remove it?

sdbuild/boot/meta-pynq/recipes-bsp/device-tree/files/pynq_zocl_poll_zynq.dtsi

sdbuild/boot/meta-pynq/recipes-bsp/device-tree/files/pynq_zocl_poll_zynqmp.dtsi

&amba {
zyxclmm_drm {
compatible = “xlnx,zocl”;
status = “okay”;
};
};

It seems that both Zynq and ZynqMP have used zyxclmm_drm.