News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

Recent posts

#1
Trenz Electronic FPGA Modules / Re: Blinking LED on TE0715-05 ...
Last post by JH - May 08, 2024, 02:38:32 PM
Hi,
you want to change MIO7 (Zynq PS IO) --> Green LED1 (Designator D2)?

This is connected to PS MIO, please check this example:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841744/Gpio-PS+standalone+driver
--> https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/gpiops

MIO GPIO are activated on the reference design.
You can import this examples over Vitis Platform Board Support Package for standalone applications.

br
John




br
John
#2
Trenz Electronic FPGA Modules / Re: Memory write error at 0xF8...
Last post by JH - May 08, 2024, 01:35:54 PM
Hi,
can you check if you see ARM and FPGA device when you open Vivado HW manager?
Can you try to boot prebuilt Hello Trenz Boot.bin from SD Card?
br
John
#3
UltraScale / Re: Vitis Unified IDE 2023.2: ...
Last post by JH - May 08, 2024, 01:32:21 PM
Hi,
you are right, new IDE, doesn't work with our script and documentation. At the moment we use still Vitis classic for our designs.
br
John
#4
UltraScale / Vitis Unified IDE 2023.2: Plat...
Last post by FraLenzi - May 06, 2024, 04:51:33 PM
Hello everyone,

I've encountered an issue while attempting to create a platform component using Vitis Unified IDE 2023.2, where the build fails consistently. However, when I follow the same steps using Vitis Classic 2023.2, the build succeeds without any issues (https://wiki.trenz-electronic.de/display/PD/Vitis). I'm puzzled by this inconsistency and would appreciate any insights or suggestions on what might be causing this issue.

I suspect the problem could be related to the compatibility of the toolchain or the configuration settings between Vitis Unified IDE and Vitis Classic.

The necessary files for the test board that I have downloaded are at the following link: https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/4x5/TE0820/Reference_Design/2023.2/test_board.

Any help or advice on resolving this issue would be greatly appreciated. Thank you in advance for your assistance.
#5
Trenz Electronic FPGA Modules / Re: TE0715 and USB RNDIS on pe...
Last post by Swiss222 - May 06, 2024, 11:40:40 AM
I solved it! As I explained here https://support.xilinx.com/s/question/0D54U00008HaZLOSA3/usb-rndis-zynq-7000-doesnt-work

the device tree was the problem if you follow the xilinx zynq usb tutorial, the usb part should just be:

&usb0 {
     status = "okay";
    dr_mode = "peripheral";
    usb-phy = <&usb_phy0>;
};

Then ulpi-phy works. I saw a lot of people struggle with this so I hope this helps
#6
Trenz Electronic FPGA Modules / Using OpenOcd to dump_image fr...
Last post by blipton - April 27, 2024, 06:16:45 AM
SoftConsole/Eclipse works fine to Flash the elf to the SMF2000 device..  but I need to read the NVM and save it to a file.

And while a dump_image seems to exist for OpenOcd 0.10 
( https://riverloopsecurity.com/blog/2021/07/hw-101-jtag-part3/ )

Telnetting to port 4444 doesn't work, but 3334 does.. which makes me think that the only way to get to openocd is thru 'fpserver'?

Any suggestions?
#7
Trenz Electronic FPGA Modules / Re: JFFS2 errors, QSPI data do...
Last post by neels - April 25, 2024, 04:21:33 PM
Thanks @M kirberg for your suggestion.
Updating the spi bus width, frequency and compatible device fixed the jffs2 errors.
I can also confirm that the data in QSPI persists after reboots.
It will be great if the petalinux kickstart page can be updated with your suggestion, so that it might benefit other users when they try to do similar things.

Thanks.
#8
Hello. I am new to the Xilinx platform and I'm getting started using a TE0715-04-73E33-A board plugged into a  TE0701-05 carrier card.

The first thing I did was run 'Hello World' by loading the prebuilt hardware definition (test_board_04_30_3e_1gb.xsa) in Vitis 2022.2 and loading the hello world example. This worked fine and was able to output to Tera Term with no issues.

Next, I want to do a blinking LED using the code (below) but it doesn't work because 'XPAR_GPIO0_BASEADDR' is not defined.

Do I need to create my own hardware definition in Vivardo and add the axi_gpio_0 block? If so which board interfaces am I supposed to set? The board interfaces are: asio, p1a, p1b, p2a, p2b, p2c, p3 but I can't find where these are defined.

I really appreciate the help. Thank you.

#include <stdio.h>
#include <xstatus.h>
#include "platform.h"
#include "xil_printf.h"
#include "xgpiops.h"
#include "xparameters.h"
#include "sleep.h"

XGpioPs gpio;

void gpio_init()
{
    XGpioPs_Config *gpioConfig;
    gpioConfig = XGpioPs_LookupConfig(XPS_GPIO_BASEADDR);  //XPAR_GPIO0_BASEADDR
    if(gpioConfig==NULL) xil_printf("GPIO Config Error...");
    int status =XGpioPs_CfgInitialize(&gpio, gpioConfig, gpioConfig->BaseAddr);
    if (status==XST_SUCCESS) xil_printf("GPIO initialization Successful...\r\n");
    XGpioPs_SetDirectionPin(&gpio, 7, 1);
    XGpioPs_SetOutputEnablePin(&gpio, 7, 1);
}

int main()
{
init_platform();
    gpio_init();
    while(1)
    {
        XGpioPs_WritePin(&gpio, 7, 1);
        sleep(1);
        XGpioPs_WritePin(&gpio, 7, 0);
        sleep(1);
    }
    return 0;
}
#9
Trenz Electronic FPGA Modules / Re: JFFS2 errors, QSPI data do...
Last post by M Kirberg - April 25, 2024, 08:51:19 AM
Hi,

normally the problem with QSPI access is the QuadMode/QuadEnable fiddling of FSBL/Uboot/Linux.
I assume this can also be the case for you if you Boot via QSPI.

Linux changed the underlying devicetree configuration quite a bit in recent versions.
So please check if you are correct here.

Normally a good place to look for the correct bits in recent versions is the Uboot Devicetrees that Vivado uses internally:

So for 2021.2 please have a look at:
https://github.com/u-boot/u-boot/blob/v2021.01/arch/arm/dts/zynq-cse-qspi.dtsi#L65-L66

Most important are the highlighted Lines.

br
#10
Trenz Electronic FPGA Modules / JFFS2 errors, QSPI data doesn'...
Last post by neels - April 22, 2024, 05:10:32 PM
Hi All,

I have a TE0720 module. I have a design that was running on a old Vivado toolchain (2016.2). I am currently updating the design to use Vivado 2021.2 toolchain. Much of the tool migration has gone as expected. But I have had a few issues with the QSPI on 2021.2 toolchain. I have the following patch that changes the QSPI from the default to my custom config.
 
--- project-spec/configs/config 2024-04-22 14:46:11.193697828 +0100
@@ -35,7 +35,7 @@
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_SELECT=y
 # CONFIG_SUBSYSTEM_MEMORY_MANUAL_SELECT is not set
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_BASEADDR=0x0
-CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_SIZE=0x10000000
+CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_SIZE=0x0e000000
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_KERNEL_BASEADDR=0x0
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_U__BOOT_TEXTBASE_OFFSET=0x400000
 CONFIG_SUBSYSTEM_MEMORY_IP_NAME="PS7_DDR_0"
@@ -43,12 +43,12 @@
 #
 # Serial Settings
 #
-# CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_0_SELECT is not set
-CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_1_SELECT=y
+CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_0_SELECT=y
+# CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_1_SELECT is not set
 # CONFIG_SUBSYSTEM_FSBL_SERIAL_AXI_UART16550_0_SELECT is not set
 # CONFIG_SUBSYSTEM_FSBL_SERIAL_MANUAL_SELECT is not set
-# CONFIG_SUBSYSTEM_SERIAL_PS7_UART_0_SELECT is not set
-CONFIG_SUBSYSTEM_SERIAL_PS7_UART_1_SELECT=y
+CONFIG_SUBSYSTEM_SERIAL_PS7_UART_0_SELECT=y
+# CONFIG_SUBSYSTEM_SERIAL_PS7_UART_1_SELECT is not set
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_SELECT is not set
 # CONFIG_SUBSYSTEM_SERIAL_MANUAL_SELECT is not set
 # CONFIG_SUBSYSTEM_SERIAL_PS7_UART_0_BAUDRATE_600 is not set
@@ -72,8 +72,8 @@
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_BAUDRATE_230400 is not set
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_BAUDRATE_460800 is not set
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_BAUDRATE_921600 is not set
-CONFIG_SUBSYSTEM_SERIAL_FSBL_IP_NAME="ps7_uart_1"
-CONFIG_SUBSYSTEM_SERIAL_IP_NAME="ps7_uart_1"
+CONFIG_SUBSYSTEM_SERIAL_FSBL_IP_NAME="ps7_uart_0"
+CONFIG_SUBSYSTEM_SERIAL_IP_NAME="ps7_uart_0"

 #
 # Ethernet Settings


The above patch used to work fine in the 2016.2 version (jffs2 had no errors, QSPI data used to persist after reboots). But on the 2021.2 version I am have noticed a lot of jffs2 errors in the boot log (as shown below) and the QSPI doesn't persist data after reboots.

Run /init as init process
INIT: version 2.97 booting
random: fast init done
jffs2: jffs2_scan_dirent_node(): Node CRC failed on node at 0x001d00f0: Read 0x5c97f158, calculated 0xbd247889
jffs2: jffs2_scan_dirent_node(): Node CRC failed on node at 0x001d10cc: Read 0x385250f9, calculated 0x99a1e049
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0000: 0x19ff instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0004: 0x000c instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0008: 0xb0b1 instead
jffs2: notice: (66) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2ccc. {19ff,e001,00000034,755c292f}
jffs2: notice: (66) jffs2_get_inode_nodes: Node header CRC failed at 0x1d295c. {196b,e001,00000034,755c292f}
jffs2: notice: (66) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2604. {1973,e001,00000032,503776f3}
Starting udev
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2ba4. {1954,e002,00000044,98f7fb1d}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2b48. {19be,e002,0000005a,2831dbb1}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2b04. {1916,e002,00000044,98f7fb1d}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2aa8. {19bd,e002,0000005a,2831dbb1}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d271c. {1916,e002,00000044,98f7fb1d}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d26cc. {1900,e002,0000004f,4ff67c1c}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2688. {190b,e002,00000044,98f7fb1d}
udevd[79]: starting version 3.2.9
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2638. {1900,e002,0000004f,4ff67c1c}
random: udevd: uninitialized urandom read (16 bytes read)
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d25c0. {193e,e002,00000044,98f7fb1d}
random: udevd: uninitialized urandom read (16 bytes read)
jffs2: warning: (68) jffs2_do_read_inode_internal: no data nodes found for ino #66
jffs2: Returned error for crccheck of ino #66. Expect badness...
random: udevd: uninitialized urandom read (16 bytes read)
udevd[80]: starting eudev-3.2.9
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2904. {193e,e002,00000057,da5b036c}
jffs2: warning: (68) jffs2_do_read_inode_internal: no data nodes found for ino #70
jffs2: Returned error for crccheck of ino #70. Expect badness...
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2c74. {1913,e002,00000057,da5b036c}
jffs2: warning: (68) jffs2_do_read_inode_internal: no data nodes found for ino #74
jffs2: Returned error for crccheck of ino #74. Expect badness...
FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

From the log it can be seen that the MTD device is detected and the patches are taking effect. But the data on QSPI doesn't persist after the reboot.

spi-nor spi0.0: s25fl256s1 (32768 Kbytes)
2 fixed-partitions partitions found on MTD device spi0.0
Creating 2 MTD partitions on "spi0.0":
0x000000000000-0x000000e00000 : "qspi-boot"
0x000000e00000-0x000001000000 : "qspi-user"

I have attached a full log if it is of interest. Any pointers to fix the issue is greatly appreciated.