Home
Developer Resources
Technical Articles

QNX Technical Articles

QNX® Software Development Platform 7.0 Board Support Package for the Xilinx Zynq UltraScale+ MPSoC ZCU104 Evaluation Kit: Release Notes

Date of this edition: November 4, 2019

QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for ARM v7, ARM v8, x86, and x86_64 targets running the QNX Neutrino RTOS 7.0.

Board Support Packages (BSP) are available for various hardware platforms on QNX SDP 7.0. This is a release note for the Xilinx Zynq UltraScale+ MPSoC ZCU104 Evaluation Kit BSP.

Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed.


Note:

A QNX BSP may be made available as an Experimental, Validated, or General Availability (GA) release, depending on factors such as software maturity and terms of commercial availability.

You should check the location where you downloaded your BSP for information about the current type of release offered for your BSP.


Revision history

The following is a summary of the updates made to this BSP.

BuildID 8 (7.0.8.E201910041500)

  • This initial release of the BSP is experimental. Graphics isn't supported for this release.

Supported hardware

Our BSP supports the following boards:

  • Xilinx Zynq UltraScale+ MPSoC ZCU104 Evaluation Kit (Revision 1.0 boards)
  • This BSP is verified using the Xilinx SDK 2019.1 and the files from Zynq Software Version 2019.1. The Xilinx prebuilt binaries(bl31.elf, pmufw.elf, system.bit, zynqmp_fsbl.elf) under the BSP's images/ directory are downloaded from https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/135364615/Zynq+2019.1+Release and the BOOT.BIN is a QNX IPL version generated with the Xilinx BootGen Tool (bootgen).

 

Known issues

These are the known issues with this BSP:

  • The clock-xzynq driver returns frequency values that are incorrect if your target uses a PSS_REF_CLK frequency that isn't 33 MHz or if a PLL uses a reference clock other than the PSS_REF_CLK. (Ref# J2784527, J2786972)

    Workarounds: If your target uses a PSS_REF_CLK frequency that isn’t 33 MHz, you can modify the value of MPSOC_PSS_REF_CLOCK in the $BSP_ROOT_DIR/src/hardware/startup/lib/public/arm/mpsoc.h file and XZYNQ_PS_CLOCK in the $BSP_ROOT_DIR/src/hardware/startup/lib/public/arm/xzynq.h file, and then rebuild all the binaries in the BSP. Reference clocks other than PSS_REF_CLK aren't supported with the clock-xzynq driver at this time so there's no workaround for this portion of the issue. Note that this BSP has been tested with a PSS_REF_CLK of 33 MHz; other values may lead to unexpected behavior.

  • If you configure the SRCSEL bits of a module reference clock to a non-zero value, the DCMD_CLOCK_SET_FREQ command won't set the frequency correctly. (Ref# J2643699)

    Workaround: Keep the SRCSEL bits set to zero.

  • If a client application uses the data types listed in the DCMD definitions for DCMD_CLOCK_INFO, DCMD_CLOCK_GET_PLL_FREQ or DCMD_CLOCK_SET_PLL_FREQ, the clock-xzynq resource manager won't parse or return data as expected. There is also a potential issue that the clock-xzynq resource manager may write to memory outside of the data structure passed in by the client which will cause undefined behavior. (Ref# J2795816)

    Workarounds: In your client, do the following:

    • pass in a data structure of type clk_info_t instead of type ctrl_id_t if you use DCMD_CLOCK_INFO
    • pass in a data structure of type pll_freq_t instead of pll_id_t if you use DCMD_CLOCK_GET_PLL_FREQ or DCMD_CLOCK_SET_PLL_FREQ
  • The clock-xzynq driver doesn't return errors properly from some devctl() DCMDs. This may cause the following issues:
    • The DCMD_CLOCK_DISABLE, DCMD_CLOCK_ENABLE, DCMD_CLOCK_GET_FREQ, DCMD_CLOCK_GET_PLL_FREQ, and DCMD_CLOCK_INFO DCMDs may fail silently.
    • Unsupported DCMDs that you specify may cause devctl() calls to fail silently.
    (Ref# J2795823)

    Workarounds: The workarounds depend on the DCMDs as follows:

    • For DCMD_CLOCK_DISABLE, DCMD_CLOCK_ENABLE: After using these DCMDs, run a DCMD_CLOCK_INFO devctl() call and see if the enabled field is set or cleared as expected. Alternatively, check the clock ctrl register manually to see if the CLKACT bit is set or cleared as expected.
    • DCMD_CLOCK_GET_FREQ, DCMD_CLOCK_GET_PLL_FREQ: Check to see if the returned freq value is equal to 0xffffffff. If it is equal to 0xffffffff, the devctl() call was unsuccessful.
    • DCMD_CLOCK_INFO: Before calling DCMD_CLOCK_INFO, set the client’s clk_info_t freq field to 0. If the returned freq field value is still equal to 0 after the devctl() call, the devctl() call has failed.
    • There is no workaround to detect an unsupported DCMD. Verify that you are using a valid DCMD command from $BSP_ROOT_DIR/src/hardwre/support/xzynq/clock/public/hw/xzynq_clk.h file.
  • The buildfile (zcu104.build) for this BSP incorrectly includes i2c-xzynq-axi binary. The i2c-xzynq-axi driver isn't part of this BSP. (Ref# J2780743)
  • This BSP incorrectly includes a graphics variant of the buildfile (zcu104-graphics.build). Graphics isn't currently supported in this BSP. (Ref# J2793767)
  • In this release, the SD driver filesystem supports only read-only access. (Ref# J2780007)

    Workaround: None.

  • You aren't able to flash the board with the BOOT.BIN using the provided $BSP_ROOT_DIR/prebuilt/scripts/reflash-ipl.sh script because the size of the BOOT.BIN files is 20-30M; however the reflash-ipl.sh script reserves only 12M for the BOOT.BIN file. (Ref# J2780344)

    Workaround: Modify $BSP_ROOT_DIR/prebuilt/scripts/reflash-ipl.sh to increase the reserved size to accommodate the size of BOOT.BIN. For example, make the following change in the $BSP_ROOT_DIR/prebuilt/scripts/reflash-ipl.sh file to increase the size to 30M:

    From:

    echo "flashctl -vvv -p $DEVF_DEVICE -e -o 0 -l 12M"
    flashctl -vvv -p $DEVF_DEVICE -e -o 0 -l 12M

    To:

    echo "flashctl -vvv -p $DEVF_DEVICE -e -o 0 -l 30M"
    flashctl -vvv -p $DEVF_DEVICE -e -o 0 -l 30M
  • When you run the shutdown command, the console connection drops, but the board doesn't reboot. (Ref# J2746186)

    Workaround: By default, the vendor didn't enable the watchdog which is required to execute the shutdown command. To resolve this, you must make changes to the code and rebuild the pmufw.elf file using these steps:

    1. In Command Prompt (Windows) or a terminal (Linux, macOS), create a zcu104_source (e.g., ZCU104) directory on your host computer, and navigate to it.
    2. Using Git, clone https://github.com/Xilinx/embeddedsw:
      git clone https://github.com/Xilinx/embeddedsw.git
    3. Navigate to the source code you've cloned locally:
      cd zcu104_source/embeddedsw/lib/sw_apps/zynqmp_pmufw/src/
    4. Modify the zcu104_source/embeddedsw/lib/sw_apps/zynqmp_pmufw/src/xpfw_mod_em.c file and add #define ENABLE_EM before the line #ifdef ENABLE_EM and save your changes.
    5. Clean and rebuild your changes to create the required ELF file, (called executable.elf):
      make clean
      make
    6. Copy executable.elf to the $BSP_ROOT_DIR/images directory in step 3 as described in the "Rebuild the BOOT.BIN file" section and rebuild the BOOT.BIN file.
      copy executable.elf $BSP_ROOT_DIR/images/pmufw.elf

Getting started with this BSP

Each BSP has a user's guide that describes what's in the BSP and how to install and work with it. In a browser, after you log in with your myQNX account, you can download the latest revision of the user's guide from the QNX SDP 7.0 Board Support Documentation page.

We recommend that you read the Building Embedded Systems guide, which contains common information about working with all BSPs from QNX Software Systems. This guide is also available on the QNX Software Development Platform 7.0 documentation website.


Note:

To ensure that you pick up the same components from your development environment, we recommend that you rebuild the IFS image on your host system.

Included in this BSP are prebuilt IFS images that are provided as convenience for you to quickly get QNX Neutrino running on your board, however these prebuilt images might not have the same components from your development environment.


Technical support

To obtain technical support for any QNX product, visit the Support area on our website (www.qnx.com). You'll find a wide range of support options, including community forums.