02-03-2017 11:34 AM - edited 02-03-2017 11:50 AM
I am trying to explore the DMA Subsystem for PCI Express. I have built a dma system, programmed the board, built and installed the driver (AR #65444), and ran a successful test with the AXI memory mapped interface to DDR4. I would now like to change out the memory mapped interface for an axi stream interface. My first test was the AXI4-Stream Example Design, found here(DMA Product Guide). This test worked. I could write to the H2C device and read the data back on the C2H interface.
I now want to move past the loopback test. I have the H2C transfers working. I am having trouble with the C2H transfers. I have set up an ILA core to peek into the stream interface signals. I trigger on the TREADY signal. when i execute the read command, the ILA triggers and the waveform is below. The axi stream interface is broken out along with the dma status signals. I am tying the TVALID signal high and using a constant data pattern. I would expect to read this pattern repeatedly on any C2H transfers.
From the waveform, it looks like the DMA subsystem is accepting the data. I'm not sure what i need to do on the host side to read it.
The commands I am using to test the transfer of data are below:
dd if=/dev/zero of=/dev/xdma0_h2c_0 bs=1024 count=1
dd if=/dev/xdma0_c2h_0 of=/dev/null bs=1024 count=1
What happens is that the dd command hangs on a C2H transfer. An strace shows its getting stuck in the read. A dump of the processes stack from /proc/##/stack shows the driver stack trace as:
[<ffffffffc037db02>] char_sgdma_read+0x122/0x400 [xdma] [<ffffffff811ef148>] __vfs_read+0x18/0x50 [<ffffffff811ef206>] vfs_read+0x86/0x140 [<ffffffff811ef306>] SyS_read+0x46/0xb0 [<ffffffff817bdecd>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff
any help would be appreciated.
EDIT: I have hacked the 'reg_rw' program contained in (AR #65444) to dump the register space of the dma peripheral while the C2H transfer hangs. the register dump is attached.
02-12-2017 06:11 AM
It seems that Xilinx has just released a new version of their XDMA drivers for Vivado 2016.4 .
Perhaps it can solve the problems. Please, let me also know if it works.
10-05-2017 03:44 AM
I am also running into a similar issue where the data reading process in Linux hangs.. Apparently, this happens when the writing process writes a (too) great load of data on the device channel; even though I set the data reading process to read the same data size as the one written by the writing process, depending on the data size, the read process would block on the device channel read function (calling Xilinx's driver).
In short, assuming write_size = read_size = S,
if S <= threshold_size (to be determined), everything works perfectly
but if S > threshold_size, data read process hangs
Any idea? Anyone?