Open DrFuzzy opened 6 years ago
Given that the AXI DMA test driver is also failing, I would guess that the issue lies in your custom HLS IP. It could also be an issue with the block diagram connections or the device tree configuration, but those both look good to me. Also, I'm guessing the reason that it works fine in the baremetal application is that you're polling the AXI DMA IP, rather than relying on the interrupt, so the behavior being tested is different.
Without knowing any specifics about your custom IP, it's hard to say exactly what the issue is. However, the most likely culprit is that you're not correctly asserting the TLAST
signal for the AXIS protocol. If this signal is not asserted, then no interrupt will be generated from the AXI DMA IP core.
Hi Brandon,
First off, thank you for taking the time to answer. I have now checked all of your suggestions and unfortunately none of them applies. Specifically, the baremetal application transfers packets in interrupt mode with the AXI DMA core configured in SG Mode.
To the best of my understanding, I am simply asserting the TLAST signal to 1 at the last 64-bit packet of the IP output stream (see attached HLS simulation screenshot) unless I am missing something here and there is more to it.
Please let me know if Ι can provide more design resources to help you identify the problem.
Yeah all of your signals look fine, and the reset of your configuration is correct. The only other guess I have would be the Linux version you're using, but since you're using PetaLinux, this shouldn't be a problem.
Hi ,DrFuzzy! I have the same problem. Did you find a solution?
I have the same problem but my SG is not enabled , the IRQ is mapped but never triggers. I changed a bit the device tree based on the automatic device tree created by petalinux : axi_dma_0: axidma@40400000 {
clock-names = "s_axi_lite_aclk", "m_axi_sg_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk";
clocks = <&clkc 15>, <&clkc 15>, <&clkc 15>, <&clkc 15>;
compatible = "xlnx,axi-dma", "xlnx,axi-dma-6.03.a", "xlnx,axi-dma-1.00.a";
interrupt-names = "mm2s_introut", "s2mm_introut";
interrupt-parent = <&intc>;
interrupts = <0 29 4 0 30 4>;
reg = <0x40400000 0x10000>;
xlnx,addrwidth = <0x40>;
//xlnx,sg-length-width = <0xe>;
dma-channel@40400000 {
compatible = "xlnx,axi-dma-mm2s-channel";
dma-channels = <0x1>;
interrupts = <0 29 4>;
xlnx,datawidth = <0x40>;
xlnx,device-id = <0x0>;
};
dma-channel@40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
dma-channels = <0x1>;
interrupts = <0 30 4>;
xlnx,datawidth = <0x40>;
xlnx,device-id = <0x1>;
};
};
Hi @DrFuzzy
I had the same issues wiith the axidmatest.ko driver and after lot's of effort I found these settings worked for me inside vivado with a simple loopback.
Summary of axidma settings (axi_dma_0)
Enable scatter Gather Engine Disable Micro DMA Disable Multi Channel Support Width of buffer length Register: 23 bits Address Width: 64 bits Enable Read channel number of channels: 1 Memory Map data width: 32 Stream data width: 32 Max burst size: 256 Allow Unaligned Transfers Enable Write channel number of channels: 1 Memory Map data width: 32 Stream data width: 32 Max burst size: 256 Allow Unaligned Transfers
Hi @DrFuzzy
Hi Brandon,
First off, thank you for taking the time to answer. I have now checked all of your suggestions and unfortunately none of them applies. Specifically, the baremetal application transfers packets in interrupt mode with the AXI DMA core configured in SG Mode.
To the best of my understanding, I am simply asserting the TLAST signal to 1 at the last 64-bit packet of the IP output stream (see attached HLS simulation screenshot) unless I am missing something here and there is more to it.
Please let me know if Ι can provide more design resources to help you identify the problem.
I had the same issues AXI DMA core configured in SG Mode.
root@xdmatest:/usr/bin# ./axidma-benchmark AXI DMA Benchmark Parameters: Transmit Buffer Size: 7.91 MiB Receive Buffer Size: 7.91 MiB Number of DMA Transfers: 1000 transfers
Using transmit channel 0 and receive channel 1. [ 254.437088] axidma: axidma_dma.c: axidma_start_transfer: 301: DMA receive transaction timed out. [ 255.445821] xilinx-vdma a0001000.dma: Cannot stop channel ffffffc87af62a18: 10008 Failed to perform the AXI DMA read-write transfer: Timer expired
Hi Brandon,
First off, thank you for taking the time to answer. I have now checked all of your suggestions and unfortunately none of them applies. Specifically, the baremetal application transfers packets in interrupt mode with the AXI DMA core configured in SG Mode.
To the best of my understanding, I am simply asserting the TLAST signal to 1 at the last 64-bit packet of the IP output stream (see attached HLS simulation screenshot) unless I am missing something here and there is more to it.
Please let me know if Ι can provide more design resources to help you identify the problem.
I had the same issues AXI DMA core configured in non SG Mode, and the tlast is just the same with the picture. Have you solved this problem?
你发给我的邮件已收到! ——王振华
Hi, I have same problem like this: axidma: axidma_dma.c: axidma_start_transfer: 305: DMA transmit transaction timed out.
this issue is a about mapping between devicetree node (dma) property and zynq interrupt number (IRQ_F2P[15:0])
for example when you connect mm2s_introut -> IRQ_F2P[0] and s2mm_introut -> IRQ_F2P[1] your devcietree node property should be like this:
IRQ_F2P[0] = 61 --> 61-32 = 29 = 0x1d IRQ_F2P[1] = 62 --> 62-32 = 30 = 0x1e
so: &dma_ps2pl {
dma-channel@40400000 {
xlnx,device-id = <0x0>;
interrupts = <0x00 0x1d 0x04>;
};
dma-channel@40400030 {
xlnx,device-id = <0x1>;
interrupts = <0x00 0x1e 0x04>;
};
};
When running axidma_transfer (or the benchmark example) on PetaLinux 2017.2, I am getting "axidma: axidma_dma.c: axidma_start_transfer: 305: DMA receive transaction timed out". My Vivado 2017.2 design (SG enabled) uses a custom HLS IP and has been verified with a baremetal application already.
Below is the Vivado block diagram:
with the following AXI DMA settings:
the system-user.dtsi:
and the output dmesg after running axidma_transfer:
and again same story with AXI DMA Test driver:
Do you have any idea what might be wrong with this setup or any suggestions to try?