UIO generic drivers in ubuntu pre-compiled image for snickerdoodle Black

[Roy Stillwell]

Hi all -

I had question on the UIO drivers in the newest ubuntu image for the snickerdoodle black.  I noticed something in the devicetree.dtb file and I wonder how it works.  There are 16 uio generic 'devices' (uio0 to uio15) in the file (once i decompiled the file) , but they're mapped for the same whole memory space of the fpga 0x40000000 to 0x80000000, but with a different IRQ for each 'device.' 

Was the intention to use these as 'generic' such that I can just map one of the /dev/uioX device files w/ an offset to the memory mapped device on the PL? If so, does anyone have code around to do that?  And in this scenario, do I even need to modify the devicetree.dtb file at all when I include, say, an AXI GPIO device, or an AXI CDMA from Vivado?

In particular, does anyone have full example code (for linux) of how to do a CDMA transfer w/ the UIO framework?  I think if i had a solid example there, I could extend it to control any of the PL fabric. 

I've read a few posts on this, but I didnt see a CDMA example anywhere.  

Thanks!

Roy S.

[weath...@krtkl.com]

Hi Roy,

Yes you are correct in your observations with this.  Each of /dev/uio0-/dev/uio15 is mapped to the 16 PL->PS interrupts respectively and mapped to the entire AXI GP0/GP1 master address space.

The intention is to give a way for hardware oriented users to interface FPGA IP with the Linux userspace without having to reconfigure the Linux kernel/device tree/etc.

Also, the last 1/4 of DDR memory (256MB on the snickerdoodle black) is held aside from linux control (but cached) for physical mapping via /dev/mem (direct access via the AXI ACP slave port from PL).

We have tested the /dev/uioX interrupt performance and AXI GP0/GP1 interaction extensively and I will share some code from that attached here (to be published to Git later).

I've recently pushed a Vivado HLS project implementing a bespoke data mover/DMA intended in operate in a straightforward manner using the above mechanisms for high performance data transfers over the AXI ACP to that 256MB reserved memory area.

See here: https://github.com/krtkl/snickerdoodle-hls-data-mover

The linux user space side source for this I am in the process of testing this week and will push when it is ready.  It will show utilization of the default Linux image reserved memory, AXI ACP, AXI GP0, /dev/mem and /dev/uioX devices.

-Jamil

[weath...@krtkl.com]

FWIW, attached is the Vivado block diagram I was using to test interrupt performance.

Basically you have the 100MHz clock divided by 1526 which is approximated 2^16 clocks per second then you have a 16-bit counter with each bit of the count tied to a different interrupt pin.

That way I could statistically test the /dev/uioX interrupt performance across the 16 PL->PS interrupt channels to see where the limits are.  As I recall ~20us latency per interrupt is the reasonable limit but the uio-test.c code calculates mean and standard deviation on the interrupt timing from Linux userspace.

The other junk in the block diagram was for verifying the AXI interfaces from Linux userspace via the Xilinx integrated logic analyzer over a JTAG adapter.

-Jamil

On Monday, June 11, 2018 at 11:59:50 AM UTC-7, Roy Stillwell wrote:

[Roy Stillwell]

This is great Jamil, thanks!  I'll give this and hls data mover a look over and post if I have any other questions.

[Roy Stillwell]

One other quick related question.  In the previous snickerdoodle boot image, one could load a custom bitstream using the uEnv.txt argument:

bitstream_image=bitstream.bit

This doesn't seem to work in the new image.  What's the right setup now w/ the newer uEnv.txt setup? 

My uEnv.txt file looks like the following:

bootargs=console=ttyPS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait earlyprink uio_pdrv_genirq.of_id=krtkl,generic-uio,ui_pdrv
bitstream_image=bitstream.bit
script_image=uboot.scr
script_load_address=0x4000000
uenvcmd=if test -e mmc 0 ${script_image}; then load mmc 0 ${script_load_address} ${script_image} && source ${script_load_address}; fi

Thanks!

RS

On Monday, June 11, 2018 at 3:33:59 PM UTC-4, weath...@krtkl.com wrote:

[Bush]

The uboot.scr loads the bitstream file from the BOOT (FAT32) partition. If the file does not exist in that file system, you should see a boot message "No bitstream present. Bitstream will not be loaded."

Can you confirm you have a file named "bitstream.bit" in your BOOT partition and what U-Boot messages you get after a restart?

[Roy Stillwell]

It looks like the problem was a corrupted .bit file.  Generated a new one and all was good.  Thanks guys.