ZUBoard - Recent Threads

ZUBoard 1CG - AMD EDF 2025.2 build example

Tim5000 — Mon, 16 Mar 2026 17:50:25 GMT

Hi has anyone tried to build linux/uboot for the 1CG using the 2025.2 AMD EDF?

I've recently had an opportunity to dig my board out again and I'm trying to run it using the latest toolchains as petalinux is being deprecated.

My previous toying with this were simple ones based on the Adam Taylor ones back in 2023 using petalinux loaded via tftpboot.

I've regenerated the XSA and Vitis artifacts using the 2025.2 Vivado and Vitis applications but trying to get a successful Linux/u-boot build via AMD EDF v2025.2 seems to be eluding me.

Generating the SDT from the XSA appears to go OK but building eventually fails - it seems many things are trying to be built that aren't needed e.g.(mali GPU) so I've ended up with a lot of things modified in my local.conf and still no success which makes me think it's not correctly targetting the board.

meta-avnet doesn't appear to be updated for some time.

ZUBoard 1CG - Vitis debugging halts when communicating with GPIO over at PL side

tstern — Tue, 10 Feb 2026 10:03:12 GMT

I've setup a minimal project in Vivado, basically I only have the a GPIO block connected to one of the RGB LEDs on the board:

Next, I tried modifying an example code so I can toggle the LED, but once I execute a command that tried reading or writing to the PL side (AXI?) the debugging halts and I must stop debugging to reset the system. The hardware export from Vivado includes the bit file.

Here is the code that I'm running, it will hang on: XGpio_SetDataDirection(&Gpio, 1, 0);

I'll appreciate it greatly if anyone could point out what's wrong here. I'm using the latest Vivado & Vitis.

#include "xparameters.h"
#include "xgpio.h"
#include "xstatus.h"
#include "xplatform_info.h"
#include <xil_io.h>
#include <xil_printf.h>
#define XGPIOPS_BASEADDR    XPAR_XGPIO_0_BASEADDR

#define LED_DELAY       10000000

#define LED_MAX_BLINK       0x10    /* Number of times the LED Blinks */

#define printf          xil_printf  /* Smalller foot-print printf */

static int GpioOutputExample(void);
static int GpioInputExample(u32 *DataRead);
#ifndef SDT
int GpioPolledExample(u16 DeviceId, u32 *DataRead);
#else
int GpioPolledExample(UINTPTR BaseAddress, u32 *DataRead);
#endif

static u32 Input_Pin; /* Switch button */
static u32 Output_Pin; /* LED button */

XGpio Gpio; /* The driver instance for GPIO Device. */

/*****************************************************************************/
/**
*
* Main function to call the example.
*
*
* @return
*       - XST_SUCCESS if the example has completed successfully.
*       - XST_FAILURE if the example has failed.
*
* @note     None
*
******************************************************************************/
int main(void)
{
    int Status;
    u32 InputData;

    printf("GPIO Polled Mode Example Test \r\n");
#ifndef SDT
    Status = GpioPolledExample(GPIO_DEVICE_ID, &InputData);
#else
    Status = GpioPolledExample(XGPIOPS_BASEADDR, &InputData);
#endif
    if (Status != XST_SUCCESS) {
        printf("GPIO Polled Mode Example Test Failed\r\n");
        return XST_FAILURE;
    }

    printf("Data read from GPIO Input is  0x%x \n\r", (int)InputData);
    printf("Successfully ran GPIO Polled Mode Example Test\r\n");
    return XST_SUCCESS;
}

/*****************************************************************************/
/**
*
* The purpose of this function is to illustrate how to use the GPIO driver to
* turn on/off an LED and read the inputs using the pin APIs.
*
* @param    DeviceId is the XPAR_<GPIO_instance>_DEVICE_ID value from
*       xparameters.h
* @param    DataRead is the pointer where the data read from GPIO Input is
*       returned.
*
* @return
*       - XST_SUCCESS if the example has completed successfully.
*       - XST_FAILURE if the example has failed.
*
* @note     This function will not return if the test is running.
*
******************************************************************************/
#ifndef SDT
int GpioPolledExample(u16 DeviceId, u32 *DataRead)
#else
int GpioPolledExample(UINTPTR BaseAddress, u32 *DataRead)
#endif
{
    int Status;
    XGpio_Config *ConfigPtr;
    int Type_of_board;

    /* Initialize the GPIO driver. */
#ifndef SDT
    //ConfigPtr = XGpio_LookupConfig(GPIO_DEVICE_ID);
#else
    ConfigPtr = XGpio_LookupConfig(BaseAddress);
#endif
    Type_of_board = XGetPlatform_Info();
    switch (Type_of_board) {
        case XPLAT_ZYNQ_ULTRA_MP:
            Input_Pin = 1;
            Output_Pin = 0;
            break;

        case XPLAT_ZYNQ:
            Input_Pin = 14;
            Output_Pin = 10;
            break;
#ifdef versal
        case XPLAT_VERSAL:
            /* Accessing PMC GPIO by setting field to 1 */
            Gpio.PmcGpio =  1;
            Input_Pin    = 56;
            Output_Pin   = 52;
            break;
#endif
    }

    Status = XGpio_CfgInitialize(&Gpio, ConfigPtr,
                       ConfigPtr->BaseAddress);
    if (Status != XST_SUCCESS) {
        return XST_FAILURE;
    }

    Status = XGpio_Initialize(&Gpio, XPAR_XGPIO_0_BASEADDR);

    if (Status != XST_SUCCESS) {
        return XST_FAILURE;
    }
    
    /* Run the Output Example. */
    Status = GpioOutputExample();
    if (Status != XST_SUCCESS) {
        return XST_FAILURE;
    }

    return XST_SUCCESS;
}

/*****************************************************************************/
/**
*
* This function does a minimal test on the GPIO device configured as OUTPUT.
*
* @param    None.
*
* @return   - XST_SUCCESS if the example has completed successfully.
*       - XST_FAILURE if the example has failed.
*
* @note     None.
*
****************************************************************************/
static int GpioOutputExample(void)
{
    u32 Data;
    volatile int Delay;
    u32 LedLoop;

    /*
     * Set the direction for the pin to be output and
     * Enable the Output enable for the LED Pin.
     */

    XGpio_SetDataDirection(&Gpio, 1, 0);

    /* Set the GPIO output to be low. */
    XGpio_DiscreteWrite(&Gpio, 1, 0);


    for (LedLoop = 0; LedLoop < LED_MAX_BLINK; LedLoop ++) {

#ifndef __SIM__
        /* Wait a small amount of time so the LED is visible. */
        for (Delay = 0; Delay < LED_DELAY; Delay++);

#endif
        /* Set the GPIO Output to High. */
        XGpio_DiscreteWrite(&Gpio, 1, 0b111);
        /*
         * Read the state of the data and verify. If the data
         * read back is not the same as the data written then
         * return FAILURE.
         */
    

#ifndef __SIM__
        /* Wait a small amount of time so the LED is visible. */
        for (Delay = 0; Delay < LED_DELAY; Delay++);

#endif

        /* Clear the GPIO Output. */
        XGpio_DiscreteWrite(&Gpio, 1, 0);

        /*
         * Read the state of the data and verify. If the data
         * read back is not the same as the data written then
         * return FAILURE.
         */

    }
    return XST_SUCCESS;
}

Custom AXI4 Lite I2C checking

MATRIX7878 — Fri, 30 Jan 2026 07:01:44 GMT

Hello,

I have been working on a custom AXI4 Lite I2C core for the ZuBoard 1CG on board temp sensor. The best I can do is read back a value of 0x00 for the WHO_AM_I register. It should be 0xA0. Since Xilinx's AXI4 IP creator is broken, I have created a custom AXI4 protocol. I need help understanding what the problem with my design is. I do not know if it is with my VHDL, or my C. Everything in my C executes, so it seems like the hardware I built does not have errors in it, it just does not work. The VHDL is 2019 version: MATRIX7878/AXI4-I2C: A simple I2C for AXI4. I have confirmed the sensor works by using the Avnet IIC temp sensor AXI4.

Thank you

Contradictory Pins

MATRIX7878 — Tue, 06 Jan 2026 02:26:03 GMT

Hello,

I am using a ZuBoard 1CG. I plan on using the temperature sensor (I2C) and am creating my own AXI4 to control it. The schematic and the user manual give contradictory information on which pin is which. To whomever has used this board before: is SCL B7, or A6 and then SDA the same question.

Thank you

ZUB1CG - xdc file

salasidis — Tue, 14 Oct 2025 00:33:26 GMT

Is there a ready made .xdc file somewhere where this can be downloaded.

I am used to the Digilent boards where all the files were provided for all their boards.

Thanks

ZUB1CG - BDF for Vivado 2024.2

salasidis — Mon, 13 Oct 2025 19:03:38 GMT

On the Avnet website, it says the BDF is deprecated, but does not seem to say what the workaround is.

What is the correct way to install a BDF for this board

Thanks

ZUBoard PYNQ with SSD/M.2 - FOR YOU

tjaekel — Thu, 02 Oct 2025 03:52:48 GMT

ZUBoard running PYNQ (Python and PL bit files) with a AVNET SSD/M.2 - works.
No need to setup a build environment, no need to check out source code repositories like PYNQ, Petalinux BSP, in order to modify and build it...

I have placed all needed files in order to "patch" the original ZUBoard PYNQ image 3.0.1 to make the SSD/M.2 working,
plus the instruction steps to modify (see below):

community.element14.com/.../patch_5F00_files.zip

Steps to do:

Have a regular PYNQ image on SD card:
- boot this regular image
- you should be able to use network in order to copy the needed files to the
PYNQ working (home) directory and to work from there then in an UART terminal
- for instance: have all files from the ZIP extracted in a folder patch_files on $HOME directory
(copy to ZUBoard PYNQ system running via network device)
check if the boot partition of the SD card is mounted (often visible as /boot):
lsblk
if mmcblk0p1 is not mounted - mount it, e.g. as boot

- sudo cp the files:
BOOT.BIN
image.ub
boot.scr
into this boot partition (on mmcblk0p1)
take the tar file modules_pl and extract it into folder:
/lib/modules
- you should have a folder with the name 5.15.36-xilinx-v2022.2 now
- the folder 5.15.19-xilinx-v2022.1 : you could delete later (when all works fine), rename it
for now to make sure it is not used anymore
- extract modules_pl via command:
sudo tar -xvf modules_pl -C /lib/modules
- check if you see now a folder /lib/modules/5.15.36-xilinx-v2022.2
create an entry in sudoers in order to avoid to provide a password if you do 'sudo':
edit the file /etc/sudoers and add this line:
xilinx ALL=(ALL:ALL) NOPASSWD: ALL
copy the file create_dri.sh into folder:
/etc/profile.d
do the command:
sync && sync
You can reboot:
- stop the U-Boot (any key hit) and change the bootargs:
setenv bootargs "console=ttyPS0,115200 earlycon clk_ignore_unused uio_pdrv_genirq.of_id=generic-uio root=/dev/mmcblk0p2 rw rootwait cma=512M"
saveenv
boot

You should see now the SSD via
lsblk
as nvme0n1 !
if not:
- check if you see it as /dev/nvme0 :
potentially, you might need to create a partition on SSD and to format it (use just ext4 format)

As a cross check if all works:
- check if the I2C interrupt is now set to 126:
cat /proc/interrupts
a0030000.i2c should use now 126 (not 121 anymore)!
- check also if a folder
/dev/dri/by-path
was created.
- check also if sudo does not ask anymore for a password, e.g.:
sudo ls /dev/dri/by-path

Now your system should be good to continue with the Python part.
If you want to use a BITFILE in the Python scripts (as PL Overlay):
sudo cp this BITFILE into folder:
/lib/firmware
remark: in the Python script we will load this via a shell command, but using ol.Overlay(..., download=False),
and before you might need to load the device tree overlay dt.dtbo as well - if you want to use INTerrupts
- keep the dt.dtbo together with your BITFILE in /home/xilinx/pynq/overlays/BITFILE_folder
Your Python script should look like this:

from pynq import Overlay, Interrupt, devicetree
from cffi import FFI
import os

#load the FPGA file: works only manually with SSD module support:
os.system("echo ZUBOARD_SPI.bit > /sys/class/fpga_manager/fpga0/firmware")

#load the device tree to add 'fabric', needed if we want to use INTerrupts
dt = devicetree.DeviceTreeSegment("/home/xilinx/pynq/overlays/BITFILE_folder/dt.dtbo")
dt.insert()
if dt.is_dtbo_applied():
print("APPLIED")
else:
print("NOT applied")

#create the Overlay but without to load!
ol = Overlay("BITFILE.xsa", download=False)
Now your BITFILE should be loaded and Python should be able to use all its features,
including having INT signals and axi_intc in your design, etc.
as a cross check after your BITFILE was loaded and works in Python... - check if you can use SSD:
mkdir ssd
sudo mount /dev/nvme0n1 ~/ssd
ls ssd
This should work (if SSD is partitioned and formatted). You should see the SSD working even you have
loaded your BITFILE.
(not sure?: if not: maybe we have to enable the PCIe in the user block diagram on the PS block, but I have not
seen an issue so far with my own simple bit files)

REMARK:
There is already a bit file loaded during boot (obviously needed for the PCIe/SSD). It has also blocks
like I2C or GPIO in it (like a system.bit file). On one of the I2C blocks (I guess the second) we have changed the INT vector number!
(we must do so in order to have INT working in our bitfile overlay)
So, one of the I2Cs in system.bit file cannot use anymore INT! (I guess it is intended for reading the I2C DNA chip on an external module).

The files:
dt.dtsi
boot.txt
boot2.txt
are just source files to create the binary file versions needed (via dtc and mkimage, on Linux host).
The files
boot2.txt and boot2.cmd (binary)
are not anymore used (U-BOOT is doing the device tree modification which is now in file boot.scr).

Options:
You have the option, after you have partitioned and formatted the SSD module (as ext4), to "copy" the entire Linux rootfs file system,
the content of the SD card partition 2, visible as /dev/mmcblk0p2, to the SSD module:
- SSD cannot have a boot partition, so you create just one primary ext4 partition for the Linux files system
(we could not boot anyway from SSD, so no boot partition needed)
- best is not to use cp - instead use tar, at best dd, with keeping symbolic links correct in tar archive or "copy" directly as it is
- ATTENTION:
you cannot tar or dd the entire active root directory, starting from /, when you want to store also the tar file on the same device in use
(a recursive tar!)
==> use an USB memory stick as temporary storage:
- format the USB memory stick as ext4 (for large file size and Linux file system)
- tar the entire rootfs / to a tar file on USB stick
- now you can use tar to unpack the USB stick tar file into the SSD partition
- BTW: instead of tar, better to use:
dd if=... of=... ...
to do it.
- after the SSD has now the same rootfs - check if you see the / and all files on SSD device, nvme0n1, after you have mounted the SSD
you have to boot but stop the U-Boot (by hitting keys right at the beginning of the boot process, watch the UART terminal)
- now you have to set the bootargs for the U-Boot to use the SSD for the rootfs:
setenv bootargs "console=ttyPS0,115200 earlycon clk_ignore_unused uio_pdrv_genirq.of_id=generic-uio root=/dev/nvme0n1 rw rootwait cma=512M"
saveenv
boot
- now, it should boot from SD card but it uses the main Linux filesystem rootfs on SSD - much faster!
The SD card is still needed to boot (partition 1 with BOOT files) but their second partition mmcblk0p2 is now free as a regular device.

REMARK:
For me, only one specific SSD/M.2 module works on ZUBOARD:
- try to find the KingSpec 256G module with B+M key
- it must have a B (+M) key, as PCIe Gen3x2 (2-lanes, not 4! and not just an M key!)

The correct way is actually:

update the Petalinux BSP in PYNQ
add the PCIe and NVME to it
build a new PYNQ image and
provide a newer ZUBoard PYNQ image - thank you

ZUBoard with SSD (M.2) and PYNQ - WORKS

tjaekel — Wed, 01 Oct 2025 04:16:45 GMT

I have the SSD module (the AVNET module with the M.2 SSD memory) working on the official PYNQ image (which does not support eMMC, neither SSD).
It works to boot from SD card (mmcblk0) and to have the SSD module available as nvme0n1 device.
It works also to load an FPGA Overlay, even using INT signals (e.g. from axi_gpio, as axi_gpio_0/ip2intc_irpt and axi_intc_0/intr).

The only drawback:
If loading an FPGA Overlay using such INT signals - it needs two manual steps done by the user.
Loading an FPGA Overlay without using an INT signal works as intended in the regular way.

How to modify PYNQ image for using SSD?

Here is what you would need:

have two SD cards which you can flash with images
have also an USB stick, formatted as ext4, to use on the ZUBoard PYNQ system (we need just as temporary storage device)

Steps to modify the PYNQ image:

flash one SD card with the original PYNQ image
flash the second SD card with the TEST image:
get it from here (download the image via the link there):
https://www.hackster.io/tom-curran/zuboard-add-wifi-bluetooth-and-nvme-ssd-f90be2
boot the Petalinux TEST image first (first SD card):
- copy the BOOT.BIN and image.ub to USB device (to keep it there temporarily)
- tar the directory in: /lib/modules, seen as 5.15.36-xilinx-v2022.2 , to USB, as a tar file keeping the symbolic links
now boot the SD card with the original PYNQ image:
- copy the BOOT.BIN and image.ub (from USB device) into the SD card /boot folder
- extract the tar file with the /lib/modules/5.15.36-xilinx-v2022.2 folder into /lib/modules
Remark: this makes sure that the image.ub fits to the version of the dynamic modules (petalinux build 2022.2, not 2022.1 as PYNQ!)

If you have done this, you can boot now again. Now it should be possible to load an FPGA Overlay in the usual way,
as long as it does not use axi_intc, not using interrupt signals in Overlay.
Otherwise, see the further steps below what to do.

The SSD module is visible as device /dev/nvme0n1 and can be mounted.

Using FPGA Overlay with interrupts

Info: the Petalinux image.ub loads an FPGA bit file, in order to initialize the PCIe (the two GP lanes needed, on the PS system).
Unfortunately, it comes as a full FPGA bit file (like an Overlay but already loaded during boot), which has also GPIO, I2C blocks in it.
One of the I2Cs (i2c@ff030000) uses also interrupts via /amba_pl@0/i2c@a0030000!
So, the index 70 in command:

cat /proc/interrupts

is already used for vector number 121. The same vector we would need for our interrupts.
In addition: the device tree does not have the node fabric defined (which we need to map this vector 121 to it as generic-uio).
Otherwise, if the vector 121 is still in use - we get errors when loading the device tree overlay or the UIO device for it will not be found.

So,

we have to move the used vector 121 away:
we do it by modifying the device tree during u-boot:
stop u-boot (hit a key during boot), execute commands to modify the device tree (e.g. via a u-boot command script boot.cmd)
and boot from memory after the device tree modification was done - via bootm
We assign a different INT vector number to the I2C block which is using it already, we give it a new vector number.
Now the vector 121 is fee.
But we have to load a device tree overlay which defines and adds the node fabric, using this vector 121:
this is done via using a device tree blob file as overlay, dt.dtbo, which we load via Python before we load the FPGA Overlay.
Unfortunately, in this mode the load of the FPGA overlay does not work anymore in the regular way:
the directory /dev/dri/by-path is not available.
we have to create this directory path (just to make Python happy) and we have to load the FPGA Overlay manually!
We can do it via a shell script create_dri.sh, located in /etc/profiled.d directory, creating this directory path on startup in case
it does not exist (Python wants to see it, even we specify downlad=False - a bug?).
copy the BIT file into the folder /lib/firmware
do the commands:
su root #password is xilinx - we can only do as root!
echo BIT > /sys/class/fpga_manager/fpga0/firmware #BIT is the name of the BIT file
now you can start the Jupyter Notebook with the Python script related to use the FPGA bit file.
But:
You cannot load the BIT file (it is already done via this echo BIT... command).
So, your Python scripts should like this:

dt = devicetree.DeviceTreeSegment("/home/xilinx/pynq/overlays/MY_OVERLAY/dt.dtbo")
dt.insert()
if dt.is_dtbo_applied():
print("APPLIED")
else:
print("NOT applied")
ol = Overlay("MY_OVERLAY.xsa", download=False)

Now, the FPGA Overlay bit file should be loaded, working, including using interrupt signals.

You can check if the interrupt vector was properly moved and the fabric with vector 121 was properly added via:

cat /proc/interrupts

The SSD is still working, check it via mounting and using it (via UART console):

mkdir ssd
sudo mount /dev/nvme0n1 ~/sdd
ls sdd

Remarks

The correct way to support PYNQ with SDD is actually to merge a newer Petalinux BSP version (at least 2022_2) to the PYNQ build repository.
Not sure, but it looks like, enabling SSD (PCIe) is a bit more complex, e.g. the TEST image is different as the BSP files (I assume, the BSP files do not enable PCIe/SSD).

If we want to keep going with this "patch" approach:

best is to modify the boot.scr file and add the commands we need to modify the device tree before we boot via bootm command
(should be possible)
how to load the FPGA BIT file, requiring su root login (with password)?
(not possible, sudo does not work: the /sys/class/... path is just writable for root!)

But:

If you do not need interrupt signals - this approach works fine to load FPGA overlay bit files in the regular way.
And:
It keeps the SSD, M.2 device, working - COOL!

ZUBoard memory speeds - results

tjaekel — Thu, 25 Sep 2025 00:24:58 GMT

For all interested in the memory speeds possible (what to expect) and comparing the options to use the fastest memory,
e.g. for recording or transferring live data to a fast media.

I have measured the ZUBoard memory speeds (plus ETH speed):

	eMMC	SD card (boot)	USB 1) 4)	SSD 2) 5)	RAM (as ref.)
wr	4.6 MB/s	21 MB/s - best 26	8 MB/s - best 38	174 MB/s	395 MB/s
rd	85 MB/s	23 MB/s - best 35	7 MB/s - best 40	427 MB/s	805 MB/s - best 883

Ethernet speed:

	ETH to host (iperf3)
tx	860 .. 910 MB/s 3)
rx	860 .. 905 MB/s 3)

1) depends on USB stick type, USB 3.x etc.
2) on Petalinux image (not PYNQ), with 256GB SSD and AVNET SSD/M.2 module
3) depends a bit where the rootfs is running on, e.g. a faster SD card vs. eMMC module
4) ATT: even faster as SD card - it is not possible to boot from USB: boot still via SD card (/boot) and change to /dev/sda as rootfs and main filesystem)? - possible?:
Not possible to change during boot to USB (as /dev/sda) for the rootfs, to continue there!
5) I had a lot of trouble to use an SSD inside an USB enclosure:
- most of the time the ZUBoard does not see /dev/sda
- if it sees it: often with size 0
- if it sees it properly with a valid size - I can "damage" quickly the SSD USB memory
ATT: it looks also dead as USB SSD on Windows PC! Hard to recover such a "bricked" USB SDD! (just via Windows host)

Conclusion:

the SD card is OK (20 MB/s), but an USB memory can be faster (up to 2x faster as SD card):
unfortunately, we cannot mount the rootfs to USB (/dev/sda) during boot:
the USB (/dev/sda) seems to enabled later, boot will hang
the eMMC module is faster on READ (85 MB/s) compared to SD card,
but very bad on WRITE to eMMC (the worst: 4.5 MB/s):
not an option when we need a lot of WRITE data on rootfs (yes, eMMC can host and run rootfs,
possible to change from SD card boot to continue on eMMC)
USB memory sticks can be faster as SD card (2x faster as SD card):
but I have trouble to use SSD in USB enclosure as USB stick (often not seen or "bricked" after use)
SSD would be the best option:
BUT: SSD is not supported on PYNQ image (yet)!
It can also host and run the rootfs: boot from SD card, change bootargs and change to nvme0n1 as rootfs device.
Remark: it is not possible to image SSD and boot from SSD (directly, via BOOT.BIN, image.ub, still from SD card needed)

Fasted Speed to transfer data:

The best option to bring data with fastest speed is:
use ETH (1G PHY) and transfer the data to a host PC: 900 MB/s is possible (measured with iperf3).

ZUBoard with AVNET SSD module and PYNQ

tjaekel — Sun, 21 Sep 2025 21:13:00 GMT

After getting AVNET eMMC working fine on ZUBoard PYNQ image (with a modified BSP version, device tree with &sdhci0 added),
I try still to see also SSD/M.2 module working on a ZUBoard PYNQ image...

What works:

image the SD card with regular ZUBoard PYNQ image
boot via SD card, running on SD Card
take the files:
BOOT.BIN
image.ub
from a Petalinux test image, e.g from here:
https://www.hackster.io/tom-curran/zuboard-add-wifi-bluetooth-and-nvme-ssd-f90be2

you can flash another SD card with this test image,
after it has booted,
copy these Petalinux files to the USB (/dev/sda), so that you have it available for patching

boot again the PYNQ SD card,
copy the saved Petalinux files from USB to the /boot folder on PYNQ SD card
or: you extract the image file and copy these files from a host PC to ZUBoard
After you have "patched" the BOOT.BIN and image.ub - reboot your system with this modified PYNQ SD card:
if the SSD/M.2 module is connected on J2:
you should see now a device nvme0n1:
lsblk

Remarks:

1. The AVNET SSD/M.2 works for me with just one SSD card type: B + M connector, KingSpec, 256GB.
Not with a similar SSD card, even B + M, e.g. 512GB - I cannot see any other SSD module installed on the AVNET SSD/M.2
module.

2. This Petalinux (test image) kernel does NOT have FPGA_Manager enabled!
Even I see the correct PYNQ Python boot log, I can open Jupyter Notebook in web browser, regular Python scripts are working...
NOT possible to load an overlay (obvious, without FPGA_Manager, not enabled in kernel).

So, at least with a 'correct' BSP (at least version 2022_2) it is possible to see and use the SSD nvme device.
It is also possible to:

boot from SD card (as mmc0, the /boot files loaded from SD card)
but to mount the rootfs via bootargs to the nvme0n1: root=/dev/nvm0n1
required to flash the SSD nvme0n1 with the entire rootfs system, e.g. by copying via dd the mmcblk0p2 to the nvme0n1
(just one partition, for rootfs, no partition for the /boot on SSD: it is anyway not possible to boot from SSD)

So, I can use the SSD as my main file system, running Linux from SSD (SD card just needed for boot).
The SSD is way faster:
the write speed on SSD: >200 MB/s - compared to 20 MB/s on a regular SD card (26 MB/s with the best SD card)

Updated BSP needed:

So, we need just an updated BSP (2022_2, not the original zuboard_1cg.bsp) with the FPGA_Manager enabled (assuming
PCIe support and device tree already enabled in such a newer BSP).
Then we could "patch" the ZUBoard PYNQ image with these two /boot files and it should work (SSD plus FPGA_Manager for
loading overlays in Python).
Actually, the correct way would be to use a newer BSP during the PYNQ build (remark: the buildzu.sh script loads all the time
the original, old BSP from server: we had to modify the build script...).

Just: I am struggling to build such a BSP: even I can build it - it crashes on boot:
I seems to configure the UART (for bootlog) with a wrong baudrate and it hangs afterwards.

Please,
who could help to generate a newer BSP for ZUBoard, with FPGA Manager enabled?
(e.g. the zub1cg_base_base_2022_2 or this zub1cg_sbc_m2_test_2022_2 "just" plus FPGA_Manager enabled)

AVNET ZUBoard eMMC so slow on write...

tjaekel — Fri, 19 Sep 2025 03:45:01 GMT

I tried all my best to get a better performance out from the (optional) AVNET eMMC module,
compared to using an SD card...

The AVNET eMMC module is so SLOW on write!

I get (on command line test and even measuring with Python code):
WR speed: 4.2 MB/s (best as 5.7 MB/s) - REDICOLOUS SLOW!
RD speed: 18.75 MB/s

eMMC is way SLOWER as any SD card used!
WR speed: 20..26 MB/s
RD speed: 50 MB/s

Why is AVNET eMMC with an 8bit interface (compared to 4bit on SD card) so slow??

ZUBoard with SSD/M.2 - is so fast...

tjaekel — Fri, 19 Sep 2025 02:32:39 GMT

Please, support the AVNET SSD/M.2 module in the latest ZUBoard PYNQ image!

The SSD/M.2 module is so impressive fast - it would be nice if I can use it as the main storage in my system
(instead of a slow SD card).

Details:

I did a speed measurement via the Petalinux image (supporting SSD/M.2).
ATT: the ZUBoard PYNQ does not support eMMC, neither SSD/M.2.

I get these IMPRESSIVE results:

SSD/M.2 (256GB module):
WRITE speed: 207, 206, 205 MB/s - avg: 206 MB/s
READ speed: 425, 405 MB/s - avg: 410 MB/s (twice the write speed)

compare it with the results using a "typical" SD card (e.g. Sandisk, 32GB):
WRITE speed: 22 MB/s - better as 26 MB/s I have never seen (Lexar Gold)
READ speed: 24 MB/s - maybe up to 75 MB/s possible

So, the SSD/M.2 is so fast that I wish to have these options in ZUBoard PYNQ:

support in AVNET ZUBoard PYNQ image also the (optional) use of the SSD/M.2 module!
flash the SSD with the rootfs (the main Linux file system, with working directories, swap device, user space...)
boot from (slow) SD card: mmcblk0p1 as boot but changing over to SSD/M.2 (via bootargs, to nvme0n1 with rootfs)
run entire system on SSD/M.2

It would be a dramatic speed improvement. Make the SSD/M.2 available in PYNQ image for ZUBoard!

How to measure?
If you flash the Petalinux test image (without Python and PYNQ support), you get a command line.
You will see that SSD/M.2 or even if eMMC module is connected.

No Python, so, you have to test on Linux (UART) command line.
Use these commands:

WRITE speed test:
dd if=/dev/zero of=/run/media/nvme0n1/tmpfile bs=1M count=1024
It will write a 1GB tmpfile to SSD/M.2.
Check the results.

READ speed test:
dd if=/run/media/nvme0n1/tmpfile of=/dev/null bs=1M count=1024
read back the SSD/M.2 file without to write to another media (SD card as of=... would limit the speed by its write speed!)

Conclusion:
The AVNET SSD/M.2 module is so fast, way faster as SD card (or even optional AVNET eMMC module, which is even slower as SD card!),
it would be "cool" if we could use it for our system memory.
Please,
make the SSD/M.2 module available in ZUBoard PYNQ image.
Thank you.

Remark:
Unfortunately, the AVNET SSD/M.2 modules supports only one type of SSD: I found only one 256GB module
with a B+M key which works. A larger module (e.g. 512GB) and also fitting - does not work.

Anyway: to have 256GB SSD of such a fast system memory in ZUBoard PYNQ would be great.

ZUBoard PYNQ eMMC vs. SD card speed - eMMC is slower!

tjaekel — Wed, 17 Sep 2025 23:17:49 GMT

I am surprised (shocked):
The AVNET eMMC module on ZUBoard is way slower as any SD card! Why?

The eMMC uses an 8bit interface - SD card just a 4bit interface. I have configured eMMC to use 200MHz clock.
But the eMMC module is way slower as any SD card!

Speed Measurement Results:

eMMC write: 4..5 MB/s (max., seldom at 5 MB/s) - very slow compared to SD cards
eMMC read: varies a lot, typical 20..58 MB/s

SD Cards:
it depends heavily which SD card manufacturer (and SD card type) you use.
ATT: some SD cards can even fail immediately when using, with an I/O Error, bad blocks... Use a fast and
well known brand.

Tested:

SanDisk, 32GB:
write: 10..11 MB/s - OK, but Samsung is 2x faster
read: 34..80 MB/s

Samsung EVO, 512GB:
write: 19..23 MB/s
read: 36..49 (sometimes 121) MB/s

Samsung Pro Plus, 1TB:
write: 20..24 MB/s - a little bit faster, even 180 MB/s read, 130 MB/s write announced
read: 20..55 (55, 99) MBs
--> a little bit faster

Lexar, 64GB:
write: 26 MB/s - the fastest on write
read: 49..79 MB/s
--> this seems to be the fastest

Anyway, the eMMC module is way slower on WRITE, just 4 MB/s, compared to achieve at least 10 MB/s with an SD Card!
So, AVNET eMMC module with Petalinux settings provided is 2.5..5 times SLOWER as SD Card! (on write)

Why?
I assume, some settings for the delay values on SD0/mmc0 are too "strong", or: the mmc0 driver is not optimized, takes
a lot of time to erase and write sectors on eMMC, or not using INT or DMA...?

How to speed up eMMC, so that it is for sure faster as any SD card (esp. due to an 8bit interface)?

I was expecting that eMMC module is at least 2x faster as SD card. But it is not!:
- a write to eMMC module is way slower as to SD card
- maybe, running from eMMC module (reading) is similar to SD card, a bit faster

Maybe, the eMMC module uses a chip with a large page/sector erase delay or the driver is polling for erase done.

CONCLUSION

if you need fast write performance on the system - use a good SD Card and expect as max. write speed (e.g. to record measurement data) as:

10..20 MB/s

ZUBoard PYNQ - patch for eMMC support

tjaekel — Tue, 16 Sep 2025 02:17:09 GMT

So, I do not have yet a general solution to substitute the image.ub on a ZUBoard PYNQ image,
supporting eMMC as well as SSD/M.2 (for now just eMMC).

But:
you can "patch" a regular ZUBoard PYNQ image with my boot files so that - at least - the eMMC works.

How to enable ZUBoard PYNQ for eMMC?
(seeing it as device or even booting from it)

Download and flash the regular ZUBoard PYNQ image:
https://www.pynq.io/boards.html
Boot with this SD card image:
you do not see yet eMMC...
Download the ZIP with the modified BOOT.BIN and image.ub:
http://www.tjaekel.com/emmc_boot.zip
(there is a virus warning - no idea why) or see below attached here
Extract this ZIP so that you have:
BOOT.BIN
image.ub
when booted via original SD card with ZUBoard PYNQ image:
copy the two files to SD card on the ZUBoard (regular, via SAMBA and file manager)
now you can copy / overwrite the original files on SD card:
copy BOOT.BIN and image.ub into:
mmcblk0p1 - potentially mounted as /boot
in the UART terminal session
Do a:
sync && sync
and reboot the system (still with SD card boot):
you should see now also mmcblk1:
use command:
lsblk

The two boot files needed...:

community.element14.com/.../emmc_5F00_boot.zip

Unzip and copy the two files into the SD card /boot directory, reboot the system, ... see if you have the emmc as mmcblk1,
via lsblk

Afterwards, you should be able to configure (fdisk, fsck) the eMMC module, flash it with "same" files (flash the boot and rootfs partition),
just set the bootargs for mmcblk1 boot properly (see other threads in this forum).
It should also boot and run from eMMC.

Booting from eMMC:

In general, you do the same:

you image the original PYNQ image to the eMMC (mmcblk1, both partitions)
you boot from SD card and you see the mmcblk1
you mount mmcblk1p1 and overwrite the (BOOT.BIN and) image.ub
You change boot switches (now eMMC mode)
you interrupt the boot process (u-boot command line)
and set the bootargs (see in forum how)

It would be cool, if anybody could generate a (BOOT.BIN and) image.ub which would support
eMMC as well as SSD/M.2, with FPGA manager (from a PetaLinux project with a newer BSP),
so that we can patch original/official ZUBoard PYNQ image with it
(and have the options to use eMMC or SSD/M.2 AVNET modules working with PYNQ on ZUBoard).
Thank you.

ZUBoard PYNQ with eMMC and SSD - an easier way?

tjaekel — Mon, 15 Sep 2025 00:17:30 GMT

I was thinking...:
is there an easier way to add and enable eMMC (and even SSD/M.2 module) for ZUBoard running PYNQ?

Potentially, there is!

Tests done:

If I image SD card with PYNQ image, boot it, afterwards I copy/overwrite the BOOT.bin and image.ub with the one from a PetaLinux image
(used to demonstrate that eMMC and SSD/M.2 works):
- oh, yes, I see eMMC and even nvme device
- I can mount and use: all looks fine

BUT:
the FPGA Manager is not enabled!
So, even PYNQ seems to boot fine - just: it cannot load any overlay.bit file!
Obvious: the FPGA Manager is not enabled, not added in the (BSP and) PetaLinux kernel.

So, what about to build a new PetaLinux kernel for the ZUBoard (only the kernel, not all, not the entire PYNQ image)?

I assume,

if you use a newer BSP, e.g. "zub1cg_sbc_base_2022_2.bsp", not the original one used in ZUBoard PYNQ build as "zuboard_1cg.bsp"
you build just the PetaLinux kernel and u-boot
but before the build: you configure the PetaLinux project to enable/add the FPGA Manager (petalinux-config)

maybe, it is enough to exchange the kernel (image.ub, and UBOOT.BIN) so that:

a PYNQ SD Card (with patched BOOT.BIN and image.ub) boots fine
sees also if eMMC module is connected
sees also if SSD/M.2 module is connected instead (and you can mount SSD/M.2 as a drive in system)
and you can also load dynamically custom overlay.bit files

So, I think:

supporting eMMC or SSD/M.2 is just an issue with the PetaLinux kernel (image.ub) itself:
changing the kernel with one supporting both (optional) devices, but having also FPGA Manager enabled in it...
should do the job.

Just: build a PetaLinux image based on a newer BSP repository, change the files on the PYNQ image (e.g. after system has booted,
to overwrite the BOOT.BIN and esp. image.ub)... and it should be done.

I am testing this approach right...

Please:
can anybody generate a PetaLinux kernel (image.ub) which would support eMMC and SSD/M.2?
It should be OK to image SD card with original PYNQ image but after it has booted - to overwrite (patch) these files,
so that is sees both devices and still works to load custom overlay.bit files in Python.
It should not be big deal.

AVNET ZUBoard PYNQ with eMMC - WORKS!

tjaekel — Fri, 12 Sep 2025 22:36:53 GMT

I have the AVNET ZUBoard working with PYNQ and eMMC:
- to boot from and run on AVNET eMMC module
- also using the axi_intc component and an INT signal in FPGA a overlay - works now

Enable eMMC in ZUBoard PYNQ image

The official ZUBoard PYNQ image, download via:
https://www.pynq.io/boards.html

does NOT support SD0 (as mmc1, mmcblk1), needed for eMMC!
You have to checkout the ZUBoard PYNQ GitHub project and build a MODIFIED version (on Linux):
https://github.com/Avnet/ZUBoard_1CG-PYNQ

Remark: do not forget to install the BDF files for the ZUBoard after installing Vivado (not mentioned there as a mandatory step to do)

Steps to do

setup a Linux system (or Ubuntu VM on Windows) as required:
go really with the right/mentioned Vivado, Petalinux tool and Linux versions (otherwise the build process is broken or must be modified)
Remark:
it can take up to TWO DAYS just to setup a VM, the tools, the Git repositories and to build the original PYNQ image!
BTW:
I could not generate the custom overlay: it results in errors to generate the "ZUBoard_1CGOverlay":
- I assume, the BDF files are not matching, they do not find some user I/O pins:
- you can comment this step in the "buildzu.sh" script (the overlay is not really needed for booting)
- forget the generated image: it will not work for eMMC, anyway
check if all is correct by building the "original" ZUBoard PYNQ image (and test it) - before we modify the build source
Download the latest ZUBoard BSP, a link can be found here:
https://www.hackster.io/tom-curran/zuboard-boot-linux-from-emmc-5d9447
Now: add a device tree node in file:
~/ZUBoard_1CG-PYNQ/ZUBoard_1CG/petalinux_bsp/meta-user/recipes-bsp/device-tree/files/system-user.dtsi
Add the node and aliases for mmc0, mmc1 and node sdhci0.
Remark: SD0 is for eMMC (8bit interface, it appears as mmcblk1), SD1 is SD Card (default, as mmcblk0)
If you would compile now - and it goes well:
it is not yet enough!
During boot it will complain with something about:
mmc1 cannot be connected to PM manager domain, domain9, error -13
Reason:
The BSP file used during build as "zuboard_1cg.bsp" is too old and does not have anything for SD0:
check the file psu_init.c as different versions of the BSP files and you will see:
- original BSP does not enable anything for SD0 (needed for eMMC, sdhci0)
- newer BSP (e.g. used for the Petalinux projects to demo eMMC) has much more config for SD0 (power, SD0 itself, MDIO_PINs...)
Change to the newer BSP:
modify script buildzu.sh (and ZUBoard_1CG.spec) to use the newer BSP
Potentially, you have to patch also some other directories to use the newer psu_init.c - and other files! - in other
directories where these files are used (e.g. .../petalinux_project/project-spec/hw-description/)
build the PYNQ again with buildzu.sh:
hope it will go through and generate a new ZUBoard_1CG-3.0.1.img
flash this image to a SD card (16GB or larger!), e.g. via Etcher (on Windows, dd on Linux)
Boot it, test it...:
it should now see the eMMC (when it is connected), as mmcblk1 (SD card is mmcblk0)

OK, almost done... Now you have a ZUBoard PYNQ image which runs on/from SD card but sees also the (optional) eMMC module (if connected).

You might think: "OK, let me image eMMC with the same one".
Technically yes, but:
- you have to modify the bootargs when booting such an (identical) image from eMMC (otherwise it does not work).
- see at the end how to set the bootargs for booting and running from eMMC.

Flash my image for ZUBoard PYNQ with eMMC

If you want to save time (instead to setup, build, modify, rebuild... the ZUBoard PYNQ image - it is "painful", very time consuming...,
a new build after all installed properly takes still 2..3 hours!),
you can try to download and flash my generated, modified ZUBoard PYNQ image with eMMC support:

http://www.tjaekel.com/ZUBoard_1CG_emmc.zip

ATT: there is a virus warning! (no idea why)

Now:

unzip the file so that you get the "ZUBoard_1CG_emmc.img"
flash this to a SD card (16GB)
boot this image, and check if you see also mmcblk1
if so, now you can image the eMMC module:
copy the file "ZUBoard_1CG_emmc.img" to your SD card (so that you have it as a separate file)
if mmcblk1 partitions are there and mounted: unmount (they are potentially not mounted on an unformatted eMMC module)
flash this copied file "ZUBoard_1CG_emmc.img" to the eMMC module (which is mmcblk1)
afterwards, you might want to resize/enlarge the file system (it will flash eMMC so that it has just 9GB of user space, instead of approx. 29GB usable)

Change the BOOT switches (to eMMC: ON - OFF - OFF - ON), boot from eMMC now, but hit immediately any key on UART to interrupt to boot process!
You have to modify the bootargs!

we have to tell the bootloader that it also should mount and use the rootfs from eMMC (mmcblk1p2)
So, we have to set the u-boot bootargs.

If u-boot has paused, change the bootargs:

setenv bootargs "console=ttyPS0,115200 earlycon clk_ignore_unused uio_pdrv_generic.of_id=generic-uio root=/dev/mmcblk1p2 rw rootwait cma=512M"

saveenv

boot

Now, watch the boot (from mmc0): it should end up in a similar boot log (dmesg), ending up on the PYNQ user command line.
Check via:

lsblk

if you see now that mmcblk0 (the SD card) and mmcblk1 (eMMC) are there, potentially already mounted.
Even if not mounted - try to mount one or the other and check if you can see the files on it.
Now, you should be fine to use eMMC (running from it, having user space on it, e.g. for your Python scripts, overlays, SD card
now available as optional memory storage...).

BTW:
In the bootargs the option "uio_pdrv_generic.of_id=generic-uio" is important.
If you forget to add this:
- you cannot use axi_intc, interrupt signals in your custom overlay (but an y overlay without interrupts and w/o axi_intc should be fine)
- it will complain with "missing UIO", "I/O error interrupt 121" etc,
So, even flashing the same image working for SD card needs a different and correct bootargs for the u-boot!

Next to enable

So, my eMMC works now on ZUBoard PYNQ with eMMC module.
The next step would be to add - in a similar way - also the SSD/M.2 module, with the 256GB memory module on it.
I hope, in the BSP (and psu_init.c) is already the support for it, just the device-tree nodes missing and to add.

Please, add eMMC and SSD/M.2 to ZUBoard PYNQ image
(build an image for official download with eMMC)

It would be great, if anybody, AVNET, AVNET-TRIA, ... could update the AVNET GitHub for PYNQ image build and
publish an updated PYNQ image file for this ZUBoard.
It would be great, if ZUBoard PYNQ image supports directly the (optional) eMMC and SSD/M.2 modules
(without a need to modify and build the PYNQ GitHub).

Thank you.

ZUBoard PYNQ not supporting eMMC - WHY?

tjaekel — Thu, 11 Sep 2025 00:32:39 GMT

Issue: the official AVNET ZUBoard PYNQ image does not support the AVNET eMMC module!

AVNET offers an eMMC module (also an SSD/M.2 module for nvme),
but:
it is not enabled, it is not supported to see and use the eMMC in the ZUBoard PYNQ image - Why NOT?
It just works with the AVNET Petalinux image, but this does not have the FPGA Manager enabled
and no Python support (not a PYNQ system, but working fine with eMMC and even SSD/M.2).

So, technically, the eMMC module should work as HW extension (on header J2), on the ZUBoard,
even with PYNQ image booted (from SD or even better to flash PYNQ to eMMC).

The reason, why ZUBoard PYNQ image does not support the AVNET eMMC module:
--> the mmc@ff160000 device (which is sd0) is "DISABLED" !

WHY?

You can see it if you display, de-compile... the device-tree view on a running ZUBoard PYNQ image,
running on SD card.
It give you this:

The mmc@ff160000 is set to "disabled"

You can also see the same, if you unzip the ZUBoard PYNQ image for SD card, you open the image.ub file
in a Hex Editor (on Windows e.g. HxD) and you see:

You see here also that mmc@ff160000 is "disabled"

BTW:
I tried to patch this "disabled" into an "okay" (plus zeros to fill the string, in Hex Editor):
It does not work: booting from SD card with this 'patch': I get many errors and at the end it stops booting.

So, it tells me also:
even I would be able to rebuild the ZUBoard PYNQ image - not sure if just adding such a node in device tree or setting
this node to "okay" would work... ? (e.g. the fabric, the PS engine, is not configured to use the MIO pins for the eMMC (SD0)
interface, potentially the "system" (XSA) will not have SD0 enabled or MIO configured.

BTW: it looks to me, when I try to build the AVNET PYNQ image: this node for mmc (sd0) is not there.
(therefore no eMMC as mmcblk0, sd0, ...!)

"rrrrr"....
How to enable eMMC for AVNET ZUBoard with AVNET eMMC module attached and running PYNQ?

ZUBoard PYNQ version and build

tjaekel — Wed, 10 Sep 2025 23:49:19 GMT

I am so confused. I try to build the official ZUBoard PYNQ image...
But: it results in errors!
When building the Overlay - it complains about axi_iic_1 (not available).

When I download, flash and boot the ZUBoard PYNQ image from official PYNQ web-site:
it says: "PYNQ Linux, based on Ubuntu 22.04"

But building the ZUBoard PYNQ via AVNET GitHub does not work on Ubuntu 22.04 (unless
you would modify all the build scripts checking for this 22.04 version).

So, it tells me this:

the AVNET ZUBoard GitHub repository is not the latest version
the official ZUBoard PYNQ image, published on PYNQ, is a newer version (Ubuntu 22.04, not 20.04!)
getting errors when building the AVNET ZUBoard PYNQ as described on GitHub - does not work beacuse
it seems to be an outdated repository

Where is the GitHub for the correct (working) and latest version?
Why AVNET does not update their GitHub?
Why ZUBoard PYNQ image does not enable the eMMC?
(the mmc@ff160000 = sd0 for eMMC module is set to "disabled" in device tree - WHY?)

Dear AVNET team:
Please, please, improve your support for your AVNET ZUBoard (actually an AVNET-TRIA board),
fix the GitHub, provide a working procedure to re-build this image... (e.g. the BDF seems to mismatch with the repository and
worth mentioning the BDF must be installed on AMD/Xilinx Vivado...)

Please, update ZUBoard PYNQ by adding YOUR! eMMC and SSD/M.2 cards.
Thank you.

ZUBoard PYNQ with eMMC device - how to build modified PYNQ repository?

tjaekel — Thu, 04 Sep 2025 03:47:50 GMT

My approach to "patch" the PYNQ image with image.ub (using a modified device_tree) does not work.
(almost all works, just using Interrupts in overlay bit file (AXI IntC), fails: it does not find OUI and the interrupt vector 121 needed for it)
Now I am building a complete PYNQ image for the ZUBoard, from scratch.

Why is it so 'painful'?
I have to check the build log, try to figure out what is missing, what is not set, even modifying the build scripts (e.g. xcst was not found) ...
It takes >10 hours just to setup the build environment (assume one entire day just to setup all properly for a clean build).

And when it was running once completely to the end - I want to change now just my device tree in 'system_user.dtsi', in order to add
a node for mmcblk1 (eMMC module, mmcblk0 is the SD card).

Why is the buildzu.sh loading, compiling, installing ... all the time "all" again?
It takes hours (a half day) just to make a small modification in just one device_tree file.
(few lines of text added to device tree and the build process takes hours again - WHY?)

What is the fastest way just to compile PYNQ for ZUBoard again?
(make should realize what is unchanged, but the script seems to run almost all again, "rrrrr"
and it seems to fetch a lot of stuff again from Internet, including to fetch/submit something from/to GitHub - what is this build process doing?)
(unless just wasting my time)

Please,
who does have or could generate a PYNQ SD card image:

which would see, support the eMMC module (or even the SSD M.2 module, alternatively)
as the PetaLinux does (but this PetaLinux image does not enable FPGA Manger or has Python (PYNQ) support integrated)
Please, please, ...
just merge the eMMC (and SSD M.2) module into a ZUBoard PYNQ image. THANK YOU!

How get a ZUBoard PYNQ image which would "see" (support) eMMC (and/or SSD M.2) module?

I'm trying to use IOBUF in Vivado on AVNET ZU1CG board, but I'm getting placement error.

Niru_10 — Thu, 21 Aug 2025 06:11:03 GMT

Hi,

I added IOBUFG component in the vivado and trying to connect the input to pin R1(from J1) and output to N4(From J6), during placement I'm facing error saying it can't be connected as there is no possibility to connect.
How can i drive the IOBUFG in vivado.

Below is my design.

My constraints are:

set_property PACKAGE_PIN N4 [get_ports BUFG_O_0]
set_property IOSTANDARD SSTL12 [get_ports BUFG_O_0]

set_property PACKAGE_PIN A8 [get_ports BUFG_I_0]
set_property IOSTANDARD LVCMOS18 [get_ports BUFG_I_0]

The error I'm facing is below:

[Place 30-675] Sub-optimal placement for a global clock-capable IO pin and BUFG pair.If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule. < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets BUFG_I_0_IBUF[0]_inst/O] > BUFG_I_0_IBUF[0]_inst/IBUFCTRL_INST (IBUFCTRL.O) is locked to IOB_X0Y32 design_1_i/util_ds_buf_0/U0/USE_BUFG.GEN_BUFG[0].BUFG_U (BUFGCE.I) is provisionally placed by clockplacer on BUFGCE_X0Y19 The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances. Clock Rule: rule_bufgce_bufg_conflict Status: PASS Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be used at the same time and design_1_i/util_ds_buf_0/U0/USE_BUFG.GEN_BUFG[0].BUFG_U (BUFGCE.O) is provisionally placed by clockplacer on BUFGCE_X0Y19

I would appreciate any suggestions.

Thanks,

Nirupama.T

ZUBoard PYNQ with eMMC and/or SSD extension?

tjaekel — Thu, 21 Aug 2025 02:10:03 GMT

My ZUBoard is working fine with the PYNQ SD card image.
Get it from here:

https://www.pynq.io/boards.html

The 'problem':
There are also an eMMC extension board (32GB eMMC, with option to boot from it) and
an extension board to use a M.2 SSD drive (but just as Gen3x2, max. 256GB, and not an option to boot from it,
the ZUBoard does not have a boot option for SSD):

https://www.tria-technologies.com/product/dp-emmc-high-speed-io-module/

https://www.avnet.com/americas/product/avnet-engineering-services/aes-acc-hsio-m2-g/evolve-64660440/

Both boards are working fine, even flashing the eMMC and booting from it works fine (with a PetaLinux image, not PYNQ!)
More details to find here:

https://www.hackster.io/tom-curran/zuboard-boot-linux-from-emmc-5d9447

https://www.hackster.io/tom-curran/zuboard-add-wifi-bluetooth-and-nvme-ssd-f90be2

So, all the HW is fine.
The 'problem' is:

The PYNQ SD card image for the ZUBoard does NOT support these optional and additional interfaces (it does not see it as devices),
such as mmcblk1 seen as the eMMC card or the nvme device for the M.2 SSD.
BTW: you have to buy an SSD M.2 module with a B+M key! (the B-key is needed, as Gen3x2, not M-key as
Gen4x4!

The only SSD module which works for me (sometimes referenced as SATA) is a KingSpec M.2 NVME, 256GB, able to order via:
https://www.amazon.com/dp/B08TTDQ5WH?ref_=ppx_hzod_title_dt_b_fed_asin_title_2_0&th=1

A larger one, e.g. 512GB or larger does not work: make sure your SSD module has a M.2 B-key (or B+M key, but larger as
256GB seems to fail, even it has B+M)

So, eMMC, M.2 SSD are working with a PetaLinux SD card image (as test Linux image):
Best references to replicate:
https://www.hackster.io/tom-curran/zuboard-boot-linux-from-emmc-5d9447
https://www.hackster.io/tom-curran/zuboard-add-wifi-bluetooth-and-nvme-ssd-f90be2

My needs:
I want to have a ZuBoard PYNQ SD card image which also 'sees' the eMMC module or the M.2 SDD module.
I need an additional fast memory device (not just the SD card or USB memory stick - works) to record fast
sensor data.

Is there anybody:

which has a PetaLinux setup for ZUBoard PYNQ image generation
where he could add support for eMMC and/or SSD
and publish this image
?

What is the fastest way to get ZUBoard PYNQ Linux image extended by eMMC (mmcblk1) or SSD (nvme)?
As I understand: it is necessary to get the PYNQ repository, to install and use PetaLinux and to modify the project, generate...

But not an easier way?, e.g. to extend the working PetaLinux (test) image with the PYNQ extension?
(as I understand: these PetaLinux images see the other boards and devices, but it does not have the PYNQ extension,
esp. not the FPGAManager integrated, and the image.ub file at the end does not enable these devices on PYNQ).

What happens if I 'mix' the PetaLinux with the PYNQ image (e.g. use the PYNQ image.ub file instead):
It works fine to boot, but loading an overlay does not work. Also: the PYNQ image.ub does not enable the
eMMC driver nor the M.2 SSD nvme driver. I cannot load a *.bit file (assuming in the PetaLinux image the FPGA manager
is not enabled).

So, it should be a small effort to add to ZUBoard PYNQ Linux image project to add and enable these devices.

If anybody has a ZUBoard PYNQ image supporting also the AVNET extensions board - I appreciate if you can share
the *.IMG file or help to setup the PetaLinux PYNQ project in order to add and modify. Thank you.

Dear AVNET team:
please, provide a ZUBoard PYNQ SD card image which would support your extensions boards. Thank you.

SSTL12 I/O standard compatible pins on Avnet ZUBoard 1CG

Niru_10 — Tue, 19 Aug 2025 06:13:18 GMT

Hi,

I am using AVNET ZUBoard 1CG and trying to figure out the pins compatible with I/O standard SSTL12 and i found J6 supports the standard, but when i try in vivado .xdc file making a pin SSTL12, its throwing error at bitstream.
Please help me to find out the proper IO that supports SSTL12.

Below is the command i used.

set_property PACKAGE_PIN N3 [ct_out_0]
set_property IOSTANDARD SSTL12 [ct_out_0]

Thanks,

Nirupama.T

Failed to create platform. Failed to generate bsp for application zynqmp_pmufw

Niru_10 — Tue, 22 Jul 2025 08:40:04 GMT

Hi,

I have tried one of the example designs on ZU board and during application creation, I'm getting the mentioned error.

Appreciate any suggestion!

Thanks,

Nirupama

DQ & DQS Signal Probing

Ravi_V — Mon, 21 Jul 2025 11:46:59 GMT

Hi,

I am measuring the DQ (AA9) and DQS signals (V3 and W3 pins off LPDDR4) of the S43LQ32256EA-062B2L using the default design. I am observing the following signals.

Are these signals expected? I am probing with the default design/application (QSPI image) of the board and with the continuous run mode at oscilloscope.

Please let me know if I am missing anything.

DDR example Design

Niru_10 — Mon, 21 Jul 2025 08:06:43 GMT

Hi,

I have the AVNET board and i tried the OOB example.

I need to work on DDR and i need an example DDR design which can do some read and write transactions.

Can anyone help me with this?