Zynq Seekable Interface Issue

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: Zynq Seekable Interface Issue

Re: Zynq Seekable Interface Issue

Post by Guest »

Thank you, it worked also for me.

Romel

Re: Zynq Seekable Interface Issue

Post by support »

Hello,

Yes, the patch helped. I was notified about that in private correspondence.

Regards,
Eli

Re: Zynq Seekable Interface Issue

Post by Guest »

Did anyone check if the patch helped? I have got the same problem, but it seems to be a Yocto problem (with the toolchain)

Regards
Romel

Re: Zynq Seekable Interface Issue

Post by support »

Hello,

Please apply this patch to the Linux driver: https://lkml.org/lkml/2016/2/24/145 (possibly by manual editing).

It seems like seekable streams is one of the scenarios affected by the bug it fixes.

Sorry for the trouble.

Regards,
Eli

Zynq Seekable Interface Issue

Post by Guest »

Hello,

I am exploring the Xillybus for a Zynq application and I have run into issue.

I have the Xillybus IP connected directly to the ACP port of the Zynq processor. I am running a 4.1.15 yocto Linux kernel and Vivado 2015.4 tool chain. I have a Xillybus core configured with a 32 bit addressable interface and several FPGA to host asynchronous streams. The FPGA to host streams appear to be working as expected. However, I am having a problem with the addressable interface. I essentially have this interface connected to a dual port RAM where I am attempting to read values out of this RAM. As a starting point, I have a very simple C program that attempts to open the interface and read from the same address several (5) times. The behavior I am seeing is that I am able to open the file interface in Linux and initially perform a lseek to the desired address. The initial read returns the value from RAM that I expect to see. Subsequent lseek and read calls do not return the expected value. It appears that the address pointer is still incrementing even though I am calling lseek prior to the read with a static address. The program ends with closing this interface. The behavior I have described is repeatable every time I execute the program.

I've also instrumented Chipscope so I could observe the signal behavior on this interface. With the program described above, I've noticed that the initial user space read call for a single address triggers multiple reads in the FPGA starting at the address specified with lseek. The following user space read calls do not appear to trigger reads in the FPGA. I assume this maybe due to some method of caching, but I am not sure if this is correct behavior.

Please let me know if you have ideas on how I could possibly troubleshoot this issue. I've used this interface with great success with PCIe Xillybus implementations on x86 Linux and Windows variations.

Thanks for your help.

Kevin

Top