Recent Posts

Pages: [1] 2 3 ... 10
Trenz Electronic FPGA Modules / Re: TEF1002 with TE0820 as PCIE endpoint
« Last post by paule on October 26, 2021, 02:34:02 PM »
Hi John,

I perhaps should not have used the word "support", what I mean is that there isn't currently a Xilinx provided Linux driver for a PS-PCIe endpoint, so as you say customers will need to write their own.

However, I have heard from another source that Xilinx have received a number of requests for such a driver and are hoping to target 2022.1 for this.



Hi,difference seems only RoHS conformity. XCF32PFS48C is not lead free.

Best Regards,Thorsten Trenz
I don't know. Flash manufacturer seems to be Xilinx.
We didn't use this flash. I would recommend you ask on Xilinx forum.
Trenz Electronic FPGA Modules / Re: TEF1002 with TE0820 as PCIE endpoint
« Last post by JH on October 26, 2021, 01:49:24 PM »
did I oversee something?
Xilinx didn't say it's not supported on AR70702:

Xilinx will not provide any drivers, but it doesn't means that's not supported. It  is very often the case that you have to write drivers by yourself or hire an external company.  Especially for complicated interfaces like pcie. Sometime they provide examples, but only fore there own evalboard. often they work also on other board with similar connection or with small modification.
I'm sorry but there is rarely a simple solution.

Open source hardware / Re: ZynqBerry SPI
« Last post by JH on October 26, 2021, 01:41:52 PM »
Hi, sorry, maybe I misunderstood something but that was just a statement and not a question, right?

UltraScale / Re: Can't program flash to QSPI
« Last post by JH on October 26, 2021, 01:39:56 PM »
Enclustra SoC  board? You know this forum is for Trenz  SoC and FPGA boards.  I don't get any money from Enclustra ;-)

From your log, Xilinx micro-Uboot has not get response from QSPI Flash. Either the flash is defective or I would imagine that you have incorrect settings for the FSBL. FSBL generation depends on your PS setup in your Vivado project (HDF/XSA export) and this setup depends on the PCB connection on the Enclustra Board.  You should check, if you use the correct setup for QSPI connection. Maybe Enclustra provide board files with basic PS configuration, if not than check schematics to setup PS IP correctly (QSPI MIO connections and DDR setup must fit as minimum setup).

I would recommend to ask enclustra support:
Maybe they have also some example designs available.

I bought a XCF32PFSG48C configuration memory after reading a detailed introduction article about this device, here's the link: XCF32PFSG48C datasheet. It gives me their comparison about specifications. But I can’t find that the difference between XCF32PFSG48C and XCF32PFS48C.
I have a question: can these two be used interchangeably?
UltraScale / Can't program flash to QSPI
« Last post by enclustra_xu5 on October 25, 2021, 02:34:14 PM »
Hi guys!   :D

I'm running the Enclustra XU5 module with a Xilinx Ultrascale+ MPSoC, and I'm trying to boot it up using QSPI32. There are three applications I want to boot up, one on the APU (A53_0) and two on the RPU (R5_0 and R5_1). The boot image I've created consists of my FSBL.elf (runs on the A53_0 core), my FPGA-generated bitstream, and the .elf files of all applications including one for the pmu (that runs on the PMU core, I've double checked), all in that order. Everything runs alright when I run the code using JTAG, but when I program flash it to QSPI, I get an error.

I've included the linker scripts of my three applications as attachments, and how I've ordered my partitions in my boot image. The blue covered lines are the applications for the A53_0, R5_0 and R5_1 cores.

Things I've tried - please don't suggest these things:

- turning the board off and on again

- Closing SDK and starting it up again

- cleaned everything and built it again

- I've double checked that I'm in the right configuration on the board with config pins

- generated the bitstream again

- tried to program flash to QSPI from Vivado, with no success


This is what my console looks like after trying to program flash:

Code: [Select]

cmd /C program_flash -f C:\MPSoC_Inverter\sw\bootstuff\BOOT.bin -offset 0 -flash_type \
qspi-x4-single -fsbl C:\MPSoC_Inverter\sw\fsbl\Debug\fsbl.elf -verify -cable type \
xilinx_tcf url TCP:
****** Xilinx Program Flash
****** Program Flash v2018.3 (64-bit)
  **** SW Build 2405991 on Thu Dec  6 23:38:27 MST 2018
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
Connected to hw_server @ TCP:
Available targets and devices:
Target 0 : jsn-JTAG-HS3-210299ABC3CA
Device 0: jsn-JTAG-HS3-210299ABC3CA-04721093-0
Retrieving Flash info...
Initialization done, programming the memory
===== mrd->addr=0xFF5E0204, data=0x00000222 =====
BOOT_MODE REG = 0x0222
WARNING: [Xicom 50-100] The current boot mode is QSPI32.
If flash programming fails, configure device for JTAG boot mode and try again.
Downloading FSBL...
Running FSBL...
Finished running FSBL.
U-Boot 2018.01-00073-g63efa8c-dirty (Oct 04 2018 - 08:26:33 -0600)
Board: Xilinx ZynqMP
DRAM:  256 KiB
EL Level: EL3
Using default environment
In:    dcc
Out:   dcc
Err:   dcc
ZynqMP> sf probe 0 0 0

Trenz Electronic FPGA Modules / Re: TEF1002 with TE0820 as PCIE endpoint
« Last post by paule on October 25, 2021, 12:50:48 PM »
Dear John,

Thank you for your earlier reply.

Following up on this topic, and for the benefit of others, I would like to report the following:

It seems that Xilinx do not currently support a Linux PCIe endpoint on the PS side of an Ultrascale+ MPSoC device (AR 70702), so this will not be possible until kernel support is added.

I also considered an alternative approach using a hardware design on the PL side, however the PL side uses a different set of transceivers and these do not appear to be wired up on the TE0820. It seems therefore that this would not be possible using a  TEF1002/TE0820 combination as there is simply no route to the PCIe connector from the PL side? Please correct me if this is wrong and I missed something?


Open source hardware / Re: ZynqBerry SPI
« Last post by ChanceTran on October 22, 2021, 04:42:30 PM »
Hi....Comprehend the contrast between the MIO and EMIO choices found in the IO section. The MIO (Multiplexed IO) pins are a proper arrangement of devoted pins that specific fringe capacities can be appointed to. These are traded as a feature of the FIXED_IO port that Vivado made during the Block Automation prior. MIO's are simply associated with the PS and not to the PL.

In the event that a fringe is directed through EMIO (Extended Multiplexed IO), Vivado will make an extraordinary port for that fringe on the Zynq PS block that can be relegated like some other sign in the PL. EMIOs are basically wires from the PS to the PL.
Pages: [1] 2 3 ... 10