Showing results for 
Search instead for 
Did you mean: 
Registered: ‎10-14-2018

Where is the tsn related Yocto SDK and How to run a TSN demo please?

Dear All,


    I was wandering where I can find the three Xilinx's TSN yocto SDK release package mentioned in the document "TSN IP SW Guide (Yocto version, UG(v1.3) Feb, 2018)"?

    1. SW_Packages-ThirdParty.tar.gz

    2. SW_Packages-Xilinx.tar.gz



    I wanna run a TSN demo on my zynq board, but I really don't where to find the resource above. What I have is the petalinux 2018.2 installed, and I noticed the installation log: yocto sdk installing... .So I guess the newest yocto sdk is integrated in the petalinux 2018.2, am I right? If it is, then where is the tsn resource in the petalinux installation, or project?

    waiting for your help if you are in tsn related working too.

1 Reply
Registered: ‎06-30-2014

Re: Where is the tsn related Yocto SDK and How to run a TSN demo please?

I'm currently working through this with 2018.2 as well.  The posted files in the lounge (including the hardware build) only work with ZC702 and ZCU102 with the specific FMC cards.  All of the posted software and patches seem to be "on rails" to do exactly that one build, and that is all.  For example, the IP installer within Vivado will misname the subsystem as tsn_etherne_0 or something like that, which will prevent device-tree-xlnx from finding the core and adding the hierarchy of peripherals.  This error exists in 2018.3 as well.

In 2018.3, they have added the ability to choose "internal" as the PHY type (vs. GMII or RGMII), which allows one to pick another core like the PCS/PMA and therefore not be married to using the FMC adapter in the example.  However this route has proven to be very high-friction in our case since it doesn't seem to add all appropriate device tree elements for using their 1/2.5G PCS/PMA.  The kernel will boot and emit several log messages about registering the PTP and finding the TSN module(s), interrupts, etc. but ultimately not register the ethernet device, which is required for running ptp4l, for example.  I've attempted to patch back in various device tree elements that one would get from the AXI Ethernet Subsystem (where the PCS/PMA is implemented), but this causes an MDIO probe "error" message (which is emitted as a warning-type message in the kernel) that ultimately allows the probe to continue.

I realize your original post is a few months old, but I wanted to at least chime in that you're not alone in trying to get this working.