Recent Posts

1

Trenz Electronic FPGA Modules / Re: Boot issue with VxWorks on TE0715/TE0701

« Last post by dswiger22 on Today at 04:43:46 PM »

Thanks for the suggestion.  We have been compiling our VxWorks with a DTS file from the known working Linux build, but that hasn't worked for us.  We've even tried stripping down the working DTS file to a "bare minimum" with just the single uart0 and a few other items, with the thought that we have one item described in the DTS that is keeping the software from running or providing text to the console.  That didn't work either.

We'll give it a go with the petalinux boot to see if we can get that to work.  Interestingly, we have already downloaded that build environment and created a pseudo-working U-Boot instance from that. I say pseudo-working because it can boot our existing Linux image, but some of the apps that we run on that Linux image crash.  However, our VxWorks build does not run from the petalinux built U-Boot either.  I would assume that if we get the petalinux image to run, we should be able to use the DTS for that to build our VxWorks image and it should then run.  At least that is my hope.

Thanks again for the suggestion, I really appreciate it.

Dan

2

Trenz Electronic FPGA Modules / Re: Ethernet does not work correctly on QSPI flash program in TE0729

« Last post by JH on Today at 06:20:47 AM »

Hi,
no sorry. I've no experience with IwIP.
I've searched shortly on Xilinx forum, maybe one of these posts help you:
https://support.xilinx.com/s/global-search/sys-arch-unprotect?language=en_US
they speak also about protect/unprotect --> https://support.xilinx.com/s/question/0D52E00006ksXpjSAE/ethernet-interrupt-stops-working-after-a-while?language=en_US

br
John

3

Trenz Electronic FPGA Modules / Re: Inter-FPGA-Communication: write config flash of a second FGPA

« Last post by JH on Today at 06:14:12 AM »

Hi,
xapp1215 is possible(Ive done it one time, with some modification of the xilinx example code). In this case you use a Zynq as programmer. But in this case you save only the programmer with Xilinx license. JTAG goes over ETH in this case and you see the connected device in Vivado (instead of full version, use free Vivado Labtools (much smaller->> ~1GB)).

br
John

4

Trenz Electronic FPGA Modules / Re: Boot issue with VxWorks on TE0715/TE0701

« Last post by JH on Today at 06:01:26 AM »

Hi,
I think you must use the the device tree which describes your TE0715 setup. Otherwhise you has annother HW description. Zynq is a configurable system. Each changes on PS or PS-PL (AXI Addresses or CLKs) need mostly other devicetree or some changes on it.
Start for example with our reference design and generate petalinux with our template.
br
John

5

Trenz Electronic FPGA Modules / Re: TE0726 - Bare minimum application

« Last post by JH on Today at 05:53:59 AM »

Hi,
I give you the full name of your TE0726, when you send the the serial number of the module (it's on the small sticker with QR code).

I know different assembly option makes it sometimes not easy to find the own configuration, but the lifetime of the Xilinx SoC is much bigger than on other components, so we must change it from time to time.

br
John

6

Trenz Electronic FPGA Modules / Re: TE0726 - Bare minimum application

« Last post by Plotti on January 27, 2022, 10:42:09 PM »

Just in case somebody is googling the same issue:

Somehow I got mixed up with the 11 different versions of the TE0726, so I selected the wrong DDR Timings and DDR size in the Zynq configuration.
After selecting "MT41J256M16 RE-125" with low voltage (the last entry in the list) for my TE0726-03-41C64-A , each application is now working as intended. Now I hope I'll get my own petalinux up and running soon...

Best regards,
Dirk

7

Trenz Electronic FPGA Modules / Re: Boot issue with VxWorks on TE0715/TE0701

« Last post by dswiger22 on January 26, 2022, 03:21:05 AM »

Sorry to post 2 years later, but I'm having a similar problem as Chris12... I hope you're still around to provide more details.  To summarize my problem, I've got a "known working Trenz board" (TE0706-03 baseboard and TE0715 module) that we've been booting Linux on for several years.  I'm trying to do a VxWorks build with the latest VxWorks tools (VxWorks 7, version 21.11) and am having no luck getting anything out of the console after U-Boot identifies the VxWorks kernel and DTB.  In my past experience (with VxWorks running on other processors), I usually see a large list of initializations ending with the VxWorks ASCII-Art logo, and a '->' prompt.  However, here's all I get with the current setup (the files are read from SD card to memory, then a "bootm" command, pointing at the two memory areas):

Code: [Select]

Zynq> boot
reading uVxWorks
12420356 bytes read in 657 ms (18 MiB/s)
reading zynq-zc706.dtb
4930 bytes read in 16 ms (300.8 KiB/s)
## Booting kernel from Legacy Image at 00300000 ...
   Image Name:   vxworks
   Image Type:   ARM VxWorks Kernel Image (uncompressed)
   Data Size:    12420292 Bytes = 11.8 MiB
   Load Address: 00200000
   Entry Point:  00200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 00100000
   Booting using the fdt blob at 0x100000
   Loading Kernel Image ... OK
   Loading Device Tree to 1f314000, end 1f318341 ... OK
## Starting vxWorks at 0x00200000, device tree at 0x1f314000 ...
<nothing more>
If you're still around Chris12 and can share what your boot log looked like after you fixed the UART issue, that might be very helpful.  Also a clue as to what you changed your UART configuration to might be helpful.

For our problem, I've tried several modifications of the WindRiver provided DTS files to no avail (note above I used a zynq-zc706.dts file, but I also tried zynq-zc702.dts).  I've also tried to  use the exact same DTS files we're currently using for our Linux build.  While VxWorks tools complain a little (provide tool warnings about the DTS files) they don't indicate that the image should not run.  I feel like this is a UART configuration issue, but haven't landed on the change to make yet.

Thanks for any help!

8

Trenz Electronic FPGA Modules / Re: Ethernet does not work correctly on QSPI flash program in TE0729

« Last post by david.sakharov on January 25, 2022, 04:40:56 PM »

hi jonh
i run some test and i track down my application to find out whats going on.
in lwip library source in emacliteif.c file in function named "low-level-output"
the function use 2 macros when it want send out the data."sys-arch-protect(lev)" and "sys-arch-unprotect(lev)"
when the application reach "sys-arch-unprotect(lev)" it goes on halt and did not go further.
for some reason my xilinx account is block so i can't ask xilinxs to help .
meanwhile when i comment "sys-arch-unprotect(lev)" it go on the application but it stack on next outgoing packet
i do some search and learn about those macros but i dont know what exactly they do.
i have this question,do you know what do those macros do?

9

Trenz Electronic FPGA Modules / Re: TE0712: Using MGT as general purpose IOs

« Last post by JH on January 25, 2022, 09:10:52 AM »

Hi,
no MGT pins are dedicated pin which has only CML IO standard. And you need special IP on your design to get access.

br
John

10

Trenz Electronic FPGA Modules / Re: Ethernet does not work correctly on QSPI flash program in TE0729

« Last post by JH on January 25, 2022, 09:08:47 AM »

Hi,

thats my question do you think would it be the problem?
meanwhile i change the fsbl to run ps7_post_config  before application,it didnt work.

Maybe, I don't now.

What you can to maybe is to force ETH PHY reset on your IwIP application before IwIP initilise everything (one reset is connected to MIO and 2 resets are connected to PL, see schematics). Maybe this helps. Or/and check whats happens when you start initialisation of IwIP twice....I think it's try and error to find solution. You can also try following:
1. Put your Boot.bin with your IwIP app build as debug on SD card and set boot mode to SD.
2. Start debugger in SDK and set a breakpoint.
3.force module reboot.
With a little bit luck it will stop on this break point and you can step during your code which was executed from SD. Maybe it helps to debug it better?

br
John