Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using the driver with Petalinux #24

Closed
LucasKl opened this issue Oct 9, 2017 · 44 comments
Closed

Using the driver with Petalinux #24

LucasKl opened this issue Oct 9, 2017 · 44 comments
Labels

Comments

@LucasKl
Copy link

LucasKl commented Oct 9, 2017

I tried compiling the driver using the Makefile you provided, however it seems to me that the KBUILD_DIR parameter is not correct.

"make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm KBUILD_DIR=..../petalinux-test/zynq-3/build/tmp/work-shared/plnx_arm/kernel-source/ driver"

This gives me the following error:

"make: *** No rule to make target '/home/lklemmer/Documents/Studium/Bachelorarbeit/petalinux-test/zynq-3/kernel-source/Module.symvers', needed by 'driver/axidma.ko'. Stop."

I noticed that petalinux put the Module.symvers file in a seprate directory (kernel-build-artifacts/)
I tried copying the contents of this directory into the linux kernel-sources (kernel-sources/) but without success.

@bperez77
Copy link
Owner

bperez77 commented Oct 9, 2017

The problem comes from the fact that PetaLinux seems to be putting all the generated build files from compiling the kernel in a separate directory. This also means that you can't run an out of tree build (at least I havne't been able to), so you can't use the driver's build system.

Instead you must create a PetaLinux 'modules' project, copy the source code into the project, and then make some modifications to the Makefile. First, cd to your PetaLinux project directory, and run:

petalinux-create -t modules -n xilinx-axidma --enable

Next, copy all of the C source files and header files under the driver directory, and the header file include/axidma_ioctl.h to the driver source directory, and remove the auto-generated file there:

cp -a driver/*.c driver/*.h include/axidma_ioctl.h <path/to/PetaLinux/project>/project-spec/meta-user/recipes-modules/xilinx-axidma/files
rm <path/to/PetaLinux/project>/project-spec/meta-user/recipes-modules/xilinx-axidma/files/xilinx-axidma.c

Then, replace the first line of the Makefile at <path/to/PetaLinux/project>/project-spec/meta-user/recipes-modules/xilinx-axidma/files/Makefile with the following:

DRIVER_NAME = xilinx-axidma
$(DRIVER_NAME)-objs = axi_dma.o axidma_chrdev.o axidma_dma.o axidma_of.o
obj-m := $(DRIVER_NAME).o

Finally, you can build the module normally with the petalinux-build command, or you can build just the module with the following command:

petalinux-build -c rootfs/xilinx-axidma

The module should be packaged with your filesystem image, and you can find the kernel object file under /lib/modules//extra/xilinx-axidma.ko. Alternately, you can find it in your PetaLinux project directory under <path/to/PetaLinux/project>/build/tmp/sysroots/plnx_arm/lib/modules//extra/xilinx-axidma.ko.

bperez77 added a commit that referenced this issue Oct 9, 2017
This was brought about by issue #24, and the README now contains a reference to the issue to point people on how to use the driver with PetaLinux.
@bperez77
Copy link
Owner

Did that end up working for you?

@LucasKl
Copy link
Author

LucasKl commented Oct 12, 2017

To make it work i had to append all C and Header Files to the SRC_URI List in the xilinx-axidma.bb file.

SRC_URI = "file://Makefile \ 
           file://xilinx-axidma.c \ 
           file://axi_dma.c \
           file://axidma_chrdev.c \
           file://axidma_dma.c \
           file://axidma_of.c \
           file://axidma.h \
           file://axidma_ioctl.h \
           file://COPYING \
          "

I'm using petalinux 2016.4.

Thank you a lot for make this driver compatible with Petalinux!

@LucasKl LucasKl closed this as completed Oct 12, 2017
@bperez77
Copy link
Owner

No problem! Ahh got it, those steps worked for me, but we might have been using different versions of PetaLinux. Thanks for posting your solution, it should be useful to everyone else who runs into this issue,

@fpgaioc
Copy link

fpgaioc commented Oct 18, 2017

Hi Brandon and Jared,

Thank you guys VERY much for sharing all the great work. I am very happy to find your
project after being frustrated with this AXI DMA for quite some time. With your clear instructions,
I managed to include your driver into my PetaLinux 2016.2 project with very little trouble.

Now my modified version of your test program (axidma_transfer.c) is also running -- RX forever,
but with the same buffer. Now I got a question, or rather, another favor, to ask of you:

How to set up the ring of buffers/descriptors like with the bare metal? And then how to receive
the interrupt, get one filled buffer from a filled-buffer-queue, use it, then return it to the ring?
Do you have another example for this, or could you please give us some instructions?

This way we can reduce the chance of loosing data to practically ZERO if we have a large number
of buffers in the ring.

Thank you very much again, best regards,

@bperez77
Copy link
Owner

The best way to do this would be to use AXI VDMA, as it supports this continuous transfer mode. Unfortunately, the driver at the moment has the code to support VDMA, but it does not work.

However, this is still possible to emulate with AXI DMA. The best way to setup the ring of buffers is to use axidma_malloc during the initialization phase of your application. You can allocate as many buffers as you need or can fit. You can increase the available region of memory that you can use by changing the cma=<size> parameter on the kernel command line. Then, you can use whatever internal data structure you prefer for ring buffer.

To initiate a continuous transfer, you can use the signal support that is part of the AXI DMA library. You can use the library function axidma_set_callback. This function will be invoked anytime a transfer from any AXI DMA/VDMA device completes. This also utilizes a real-time signal, so the signal should be delivered soon after the interrupt occurs. The function takes in the ID of the channel whose transfer completed, and a generic piece of data that you set with axidma_set_callback.

With those two functions, that should be sufficient to setup a continuous RX transfer. The signal handler can advance the buffer in the ring that you're sending, and set a flag that indicates for your application to initiate the next transfer.

@fpgaioc
Copy link

fpgaioc commented Oct 20, 2017 via email

bperez77 added a commit that referenced this issue Oct 21, 2017
This was brought about by issue #24, and the README now contains a reference to the issue to point people on how to use the driver with PetaLinux.
@bperez77
Copy link
Owner

Sorry for the late reply, I missed this notification. Ah yes, that's a good question. So you can think of my driver purely as a "bridge" between userspace and Xilinx's AXI (V)DMA driver. The Xilinx AXI (V)DMA driver can only used by other drivers or code in kernel space, and cannot be used by userspace code.

The Xilinx AXI DMA handles all of what would be traditionally considered what a "driver" does, such as setting up the interrupts, handling low-level writes to MMIO registers, allocating DMA buffer descriptors, etc. My driver, on the other hand, handles setting up some basic data structures, and exposing DMA functionalities to userspace through IOCTL's. Of course, there's also a userspace library that sits between my driver and the end user application to further simplify the use of the driver.

In terms of your question about the descriptors, it's probably unnecessary to increase the number of them, unless the size of data you're transferring is larger than 8 MB * 255 (8 MB is the max size for any one transfer). Your second point should work, though you'll likely need to handle that in Xilinx's driver.

@Westwood68
Copy link

Hi Brandon,

I am trying to install your driver for using with VDMA on petalinux 2017.2 and run into some problems.
Generally it seems, that things are a bit different in the 2017 versions.
Here is what I have done:

  1. There are no CONFIG_XILINX_AXIDMA and CONFIG_XILINX_AXIVDMA symbols in the kernel
    config any more. The DMA drivers seem to be enabled with CONFIG_XILINX_DMAENGINES=y.

  2. A device tree entry for VDMA is generated automatically by the petalinux tools in
    components/plnx_workspace/device-tree-generation/pl.dtsi, in my case:

  / {
	amba_pl: amba_pl {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "simple-bus";
		ranges ;
		axi_vdma_0: dma@43000000 {
			#dma-cells = <1>;
			clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk", "m_axi_s2mm_aclk";
			clocks = <&clkc 15>, <&clkc 15>, <&clkc 15>, <&clkc 15>, <&clkc 15>;
			compatible = "xlnx,axi-vdma-1.00.a";
			interrupt-parent = <&intc>;
			interrupts = <0 29 4 0 30 4>;
			reg = <0x43000000 0x10000>;
			xlnx,addrwidth = <0x20>;
			xlnx,flush-fsync = <0x1>;
			xlnx,num-fstores = <0x3>;
			dma-channel@43000000 {
				compatible = "xlnx,axi-vdma-mm2s-channel";
				interrupts = <0 29 4>;
				xlnx,datawidth = <0x20>;
				xlnx,device-id = <0x0>;
				xlnx,genlock-mode ;
			};
			dma-channel@43000030 {
				compatible = "xlnx,axi-vdma-s2mm-channel";
				interrupts = <0 30 4>;
				xlnx,datawidth = <0x20>;
				xlnx,device-id = <0x0>;
				xlnx,genlock-mode ;
			};
		};
	};
};
  1. The additonal manual device tree entry in project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi
    must contain only the chrdev device:
    axidma_chrdev: axidma_chrdev@0 {
    compatible = "xlnx,axidma-chrdev";
    dmas = <&axi_vdma_0 0 &axi_vdma_0 1>;
    dma-names = "tx_channel", "rx_channel";
};

(Actually, there are some more entries for my platform here, but they are not related to DMA)

  1. I followed the Instructions given above for creating the kernel module. I also have to include all
    source files in xilinx-axidma.bb as described above, except for xilinx-axidma.c which is
    deleted.

  2. After building and booting the new system, I get the following on the target platform:

# dmesg |grep dma
[...]
xilinx-vdma 43000000.dma: Xilinx AXI VDMA Engine Driver Probed!!

So it seems the Xilinx DMA stuff is initialized correctly. But then:

# cd /lib/modules/4.9.0-xilinx-v2017.2/extra/
# insmod ./xilinx_axidma.ko 

xilinx_axidma: loading out-of-tree module taints kernel.
axidma: axidma_of.c: axidma_check_unique_ids: 138: Channels 0 and 1 in the 'dmas' list have the same channel id
axidma: probe of axidma_chrdev@0 failed with error -38

According to device tree entry:

    dmas = <&axi_vdma_0 0 &axi_vdma_0 1>;

I would expect the channel IDs being 0 and 1.

Do you have an idea about what is going wrong here?

Thanks a lot

@Westwood68
Copy link

Hi again,

sometimes it helps to describe the problem for finding the solution. Obviously petalinux assigns device id 0 to both dma channels, no idea why. I made a copy of the petalinux-generated device tree entry into system-user.dtsi and manually set the rx channel to device id 1. After compiling, the driver loads fine.

Bests, Westwood68

@bperez77
Copy link
Owner

bperez77 commented Dec 1, 2017

Ok, got it thanks for the heads up. Yeah that's annoying that PetaLinux does that. I'm guessing that implies that the device-id field may be deprecated soon, which may be an issue. I'll need to update my README about the different config option. I think Xilinx merged the AXI DMA and AXI VDMA drivers in the newer versions of the kernel.

So no other problems then? The driver works fine with AXI VDMA?

@Westwood68
Copy link

Yes, all DMA modes (dma, cdma, vdma) are handled by a single low level driver in the new kernels.

My idea was to to start with a VDMA loopback test, same as the Xilinx vdmatest kernel module does.
But unfortunately, I found that your driver does not support VDMA read operation (i.e., from PL to PS), and that is exactly what I need (getting a camera stream into the memory). Is there a special reason why this is not implemented? Would it be complicated?

There is also a userspace bridge driver for VDMA from Xilinx (vdma_wrapper), which is still included in the kernel tree but seems outdated and even does not compile.

So I am a bit at a loss what to do now.

@bperez77
Copy link
Owner

bperez77 commented Dec 1, 2017

Actually, I'm literally writing that support into the driver as we speak, see issue #31. At the moment, the driver does support VDMA transactions, but only one at a time. It doesn't have a loop mode for cameras like it does for displays.

Interesting, glad to see they finally tried to add a userspace bridge driver; after all, I had to write this because they lacked one. It's actually not too complicated to add, I never did simply because I didn't need it for any of my projects.

@bperez77
Copy link
Owner

bperez77 commented Dec 1, 2017

Ok, I added support for this with c3181d8.

Unfortunately, I don't have a setup right now to test my changes (and I won't for a while), so I only check that the changes compiled against the most recent version of the Xilinx kernel. Could you take the code for a spin and let me know if it works?

@Westwood68
Copy link

At the moment, the driver does support VDMA transactions, but only one at a time.

Ok... does this mean, each vdma read operation must be requested explicitly by the software? This would be sufficient for the moment. How can I do this? I should read the issue #31 comments.

Interesting, glad to see they finally tried to add a userspace bridge driver;

Well, it is in the staging tree, and it seems Xilinx forgot it there. No idea if this was ever operational. It depends on another C source file which has changed, and so compiling the kernel fails with this wrapper enabled.

Btw, I tried to do loopback test from kernel space. Xilinx provides a kernel module for that (config_vdma_test=y), and it reports vdma working. So I can verify my hardware being ok. However, for this test, all f_sync options in the vdma IP must be turned off, otherwise I get a timeout.

@bperez77
Copy link
Owner

bperez77 commented Dec 1, 2017

Ok... does this mean, each vdma read operation must be requested explicitly by the software? This would be sufficient for the moment. How can I do this? I should read the issue #31 comments.

It doesn't need to be explicitly requested by your userspace application. In either of the library functions, axidma_oneway_transfer and axidma_twoway_transfer, you specify a channel ID. Based on that, the library and driver can handle whatever type of channel corresponds to the ID.

Well, it is in the staging tree, and it seems Xilinx forgot it there. No idea if this was ever operational. It depends on another C source file which has changed, and so compiling the kernel fails with this wrapper enabled.

That's just classic Xilinx there.

Btw, I tried to do loopback test from kernel space. Xilinx provides a kernel module for that (config_vdma_test=y), and it reports vdma working. So I can verify my hardware being ok. However, for this test, all f_sync options in the vdma IP must be turned off, otherwise I get a timeout.

Got it. I've never tested my driver with the f_sync options, so I have no idea what its behavior would be. There's actaully an equivalent program in the repository, axidma_benchmark.c.

The commit I just pushed enables cyclic/loop transfer for VDMA reads. It's untested, but I have verified that it successfully compiles.

@Westwood68
Copy link

Sorry, crossover. I will test your code and let you know.

@Westwood68
Copy link

I did just a short test, but get a read timeout, see below. Do I need to change the example code somehow?

root@te0715_linux:~# modprobe xilinx_axidma
xilinx_axidma: loading out-of-tree module taints kernel.
axidma: axidma_dma.c: axidma_dma_init: 706: DMA: Found 0 transmit channels and 0 receive channels.
axidma: axidma_dma.c: axidma_dma_init: 708: VDMA: Found 1 transmit channels and 1 receive channels.
root@te0715_linux:~# ./axidma_benchmark -v -n 100
AXI DMA Benchmark Parameters:
        Transmit Buffer Size: 7.91 Mb
        Receive Buffer Size: 7.91 Mb
        Number of DMA Transfers: 100 transfers

Using transmit channel 0 and receive channel 1.
xilinx-vdma 43000000.dma: Frame Store Configuration is not enabled at the
xilinx-vdma 43000000.dma: H/w level enable Debug info 13 or 6 at the h/w level
xilinx-vdma 43000000.dma: OR Submit the frames upto h/w Capable

xilinx-vdma 43000000.dma: Frame Store Configuration is not enabled at the
xilinx-vdma 43000000.dma: H/w level enable Debug info 13 or 6 at the h/w level
xilinx-vdma 43000000.dma: OR Submit the frames upto h/w Capable

axidma: axidma_dma.c: axidma_start_transfer: 298: VDMA receive transaction timed out.
Failed to perform the AXI DMA read-write transfer: Timer expired
root@te0715_linux:~# 

@Westwood68
Copy link

Ok, seems it works now. The timeout problem is obviously caused from the "Frame Store Configuration is not enabled..." thing, see previous posting. This occurs when the number of frame buffers configured in the vdma ip core is higher than 1, which cannot be handled by the xilinx dma engine driver. According to Xilinx this should already be fixed , but maybe in newer versions of Petalinux (I am on 2017.2). So I configured the core and the device tree for a single frame buffer, and now the benchmark passes:

XI DMA Benchmark Parameters:
        Transmit Buffer Size: 7.91 Mb
        Receive Buffer Size: 7.91 Mb
        Number of DMA Transfers: 1000 transfers

Using transmit channel 0 and receive channel 1.
Single transfer test successfully completed!
Beginning performance analysis of the DMA engine.

random: fast init done
DMA Timing Statistics:
        Elapsed Time: 41.64 s
        Transmit Throughput: 189.97 Mb/s
        Receive Throughput: 189.97 Mb/s
        Total Throughput: 379.94 Mb/s

Next I will try to get it working with multiple buffers.

@bperez77
Copy link
Owner

bperez77 commented Dec 2, 2017

Ok, got it. Yeah that makes sense, but a shame that they haven't backported the changes to earlier versions. Let me know if you're able to get multiple frame buffers working.

@Westwood68
Copy link

Hi Brandon,

I have upgraded to Petalinux 2017.3 and Vivado 2017.3. Now your axidma bridge benchmark works also with multiple frame buffers (tested with 3 buffers). I have tried this on a Digilent Zybo board:

root@zybo_linux:~# ./axidma_benchmark -v
AXI DMA Benchmark Parameters:
Transmit Buffer Size: 7.91 Mb
Receive Buffer Size: 7.91 Mb
Number of DMA Transfers: 1000 transfers

Using transmit channel 0 and receive channel 1.
Single transfer test successfully completed!
Beginning performance analysis of the DMA engine.

DMA Timing Statistics:
Elapsed Time: 20.86 s
Transmit Throughput: 379.26 Mb/s
Receive Throughput: 379.26 Mb/s
Total Throughput: 758.52 Mb/s

Thanks a lot for your support!

Regards

@bperez77
Copy link
Owner

Awesome, great to know! And no problemo, I'm glad to hear that the issue has been resolved.

@rdb9879
Copy link

rdb9879 commented May 11, 2018

Greetings. I am trying to replicate these steps for Petalinux 2017.4. I got to the point where I perform the command petalinux-build -c rootfs/xilinx-axidma, but this is returning an error: "ERROR: Nothing PROVIDES 'rootfs/xilinx-axidma'. Close matches: xilinx-axidma". I tried following LucasKl's additional step of modifying the SRC_URI line of xilinx-axidma.bb. I noticed in the listed procedure, it does instruct to delete the xilinx-axidma.c file, but it still exists in the SRC_URI line?

@bperez77
Copy link
Owner

I'm not sure. I would try deleting the file as described and also removing it from the SRC_URI line.

@Westwood68 did you run into a similar issue?

@Westwood68
Copy link

Westwood68 commented May 21, 2018 via email

@bperez77
Copy link
Owner

@Westwood68 Do you happen to remember/have the settings for the AXI VDMA IP you used to get the VDMA test to work in the kernel? I'm trying to get it up an running now, but I can't seem to find the right configuration.

@tbesemer
Copy link

Where can I find the Bitbake recipe <xilinx-axidma.bb> for this? I am not working in Petalinux, just working in straight Yocto with meta-xilinx, and can't seem to find the recipe.

Thanks!

@bperez77
Copy link
Owner

I haven't worked much with Yocto unfortunately, but the xilinx-axidma.bb was generated by PetaLinux is the steps described above. You could try going that route to get the file. I unfortunately don't have those files anymore, since it was a while ago.

@schegde
Copy link

schegde commented Nov 2, 2018

Thanks for the neat and clear set of instructions! Was a breeze to compile your module with petalinux, and use the user space library :)

@bperez77
Copy link
Owner

No problem, glad to hear it was a smooth process for you.

@18829212662
Copy link

Hi , I am testing axi-dma in zcu106 board with your driver , I have compiled the driver code with petalinux under your guidence above , and I have modified my device-tree as follows in system-user.dtsi . However , after insmod my driver.ko in zcu106 board , I cannot see anything ,it seems like that the code is stuck in this function "platform_driver_register(&axidma_driver);" in axi_dma.c , and there is nothing shown on the screen , and there is no device registered in the kernel , I cannot see the driver under "/dev/", my system-user.dtsi is as follows
/include/ "system-conf.dtsi"
/
{
axidma_chrdev: axidma_chrdev@0 {
compatible = "xlnx,axidma-chrdev";
dmas = <&axi_dma_0 0 &axi_dma_0 1>;
dma-names = "tx_channel", "rx_channel";
};
amba_pl: amba_pl@0 {
#address-cells = <2>;
#size-cells = <2>;
compatible = "simple-bus";
ranges ;
axi_dma_0: dma@a0000000 {
#dma-cells = <1>;
clock-names = "s_axi_lite_aclk", "m_axi_sg_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk";
clocks = <&clk 71>, <&clk 71>, <&clk 71>, <&clk 71>;
compatible = "xlnx,axi-dma-1.00.a";
interrupt-names = "mm2s_introut", "s2mm_introut";
interrupt-parent = <&gic>;
interrupts = <0 104 4 0 105 4>;
reg = <0x0 0xa0000000 0x0 0x1000>;
xlnx,addrwidth = <0x20>;
xlnx,include-sg ;
xlnx,sg-length-width = <0x1a>;
dma-channel@a0000000 {
compatible = "xlnx,axi-dma-mm2s-channel";
dma-channels = <0x1>;
interrupts = <0 104 4>;
xlnx,datawidth = <0x20>;
xlnx,device-id = <0x0>;
};
dma-channel@a0000030 {
compatible = "xlnx,axi-dma-s2mm-channel";
dma-channels = <0x1>;
interrupts = <0 105 4>;
xlnx,datawidth = <0x20>;
xlnx,device-id = <0x0>;
};
};
psu_ctrl_ipi: PERIPHERAL@ff380000 {
compatible = "xlnx,PERIPHERAL-1.0";
reg = <0x0 0xff380000 0x0 0x80000>;
};
psu_message_buffers: PERIPHERAL@ff990000 {
compatible = "xlnx,PERIPHERAL-1.0";
reg = <0x0 0xff990000 0x0 0x10000>;
};
};
};

Any idea?Thanks.

@eleICoto
Copy link

eleICoto commented May 8, 2019

@18829212662 upload your dmesg log

@suikammd
Copy link

Hey, I wrote code to get camera pics and I did some modifications to those pics. After that, I use your driver to send pics to pl. How do I know I successfully transfered pics?
I use petalinux 2018.2 and zcu104.

@eleICoto
Copy link

use a fifo loop to rewrite your pics data back to ps ddr

@eleICoto
Copy link

@suikammd or add ila to your block design. When you start your pics transfer vivado monitor interface will get the data waveform in axi bus, so you can check whether the data is well tranfered

@guerricmeurice
Copy link

@suikammd If you really worry about verifying that your data transfer happened reliably, I would suggest the use of checksum like CRC32. It can be computed very efficiently both in PS and PL and you only need to send a single checksum word from PL to PS to perform your verification.

@egaznep
Copy link

egaznep commented May 27, 2019

To make it work i had to append all C and Header Files to the SRC_URI List in the xilinx-axidma.bb file.

SRC_URI = "file://Makefile \ 
           file://xilinx-axidma.c \ 
           file://axi_dma.c \
           file://axidma_chrdev.c \
           file://axidma_dma.c \
           file://axidma_of.c \
           file://axidma.h \
           file://axidma_ioctl.h \
           file://COPYING \
          "

I'm using petalinux 2016.4.

Thank you a lot for make this driver compatible with Petalinux!

This is required for Petalinux 2018.2 as well. Huge thanks to you and @bperez77!

Edit: The steps described above in (#24 (comment)) are also required. Whilst copying the contents of pl.dtsi to system-user.dtsi, I had to get it from the amba_pl bus section, as described below:

/include/ "system-conf.dtsi"
/ {
    axidma_chrdev: axidma_chrdev@0 {
    compatible = "xlnx,axidma-chrdev";
    dmas = <&axi_dma_0 0 &axi_dma_0 1>;
    dma-names = "tx_channel", "rx_channel";
};

amba_pl: amba_pl@0 {
		...
		axi_dma_0: dma@80000000 {
			...
                         dma-channel@80000000 {
				...
			};
			dma-channel@80000030 {
                                ...
			};
		};

... 

@benpaodewali
Copy link

hey,Thank you VERY much for sharing all the great work.
I am testing axi-dma in z7035 board with your driver,it work fine for axidma_tranfer.c ,but failed when it comes to axidma_benchmark.c , I checked dmesg , it show that the function dmaengine_prep_slave_sg return NULL ,but if i change the IMAGE_SIZE of axidma_benchmark.c to about 3.9M,it works fine again , i had changed cma to 60M , but it still return NULL
I use petalinux 2018.3 ,thank you

@benpaodewali
Copy link

hey,Thank you VERY much for sharing all the great work.
I am testing axi-dma in z7035 board with your driver,it work fine for axidma_tranfer.c ,but failed when it comes to axidma_benchmark.c , I checked dmesg , it show that the function dmaengine_prep_slave_sg return NULL ,but if i change the IMAGE_SIZE of axidma_benchmark.c to about 3.9M,it works fine again , i had changed cma to 60M , but it still return NULL
I use petalinux 2018.3 ,thank you

The problem lies in the width of buffer length register , it's 14 by default ,when the buffer size was larger than 4M , it will goes wrong ,final I change it to 23,which works,thanks again :)

@honorpeter
Copy link

Hi again,

sometimes it helps to describe the problem for finding the solution. Obviously petalinux assigns device id 0 to both dma channels, no idea why. I made a copy of the petalinux-generated device tree entry into system-user.dtsi and manually set the rx channel to device id 1. After compiling, the driver loads fine.

Bests, Westwood68

I get this error too.

root@xdmatest:/lib/modules/4.14.0-xilinx-v2018.2/extra# insmod xilinx-axidma.ko
[ 105.911767] axidma: axidma_of.c: axidma_check_unique_ids: 144: Channels 0 an.
[ 105.922935] axidma: probe of axidma_chrdev@0 failed with error -38

But one dma two channel, is it ok?

@honorpeter
Copy link

@18829212662 upload your dmesg log
I do like @18829212662 and got this error . and I change like @Westwood68 , but it dosn't work.

always error:

root@xdmatest:/lib/modules/4.14.0-xilinx-v2018.2/extra# insmod xilinx-axidma.ko
[ 105.911767] axidma: axidma_of.c: axidma_check_unique_ids: 144: Channels 0 an.
[ 105.922935] axidma: probe of axidma_chrdev@0 failed with error -38

@whnwhn
Copy link

whnwhn commented Dec 21, 2019

help~~
Does anybody have met the problem about : Test failed! The receive buffer was not updated.
Besides, an vdma error inserts the normal test prints.

@whnwhn
Copy link

whnwhn commented Dec 21, 2019

this is the error:

./axidma_benchmark -t 0 -r 1 -b 1500 -s 1500-n 300
AXI DMA Benchmark Parameters:
Transmit Buffer Size: 0.00 MiB
Receivxilinx-vdma 40400000.dma: Channel ef3b9010 has errors 40, cdr 0 tdr 0
e Buffer Size: 0.00 MiB
Number of DMA Transfers: 1000 transfers

Using transmit channel 0 and receive channel 1.
axidma: axidma_dma.c: axidma_start_transfer: 301: DMA receive transaction timed out.
Failed to perform the AXI DMA read-write transfer: Timer expired

@Jcrash29
Copy link

Jcrash29 commented Jul 1, 2021

Greetings. I am trying to replicate these steps for Petalinux 2017.4. I got to the point where I perform the command petalinux-build -c rootfs/xilinx-axidma, but this is returning an error: "ERROR: Nothing PROVIDES 'rootfs/xilinx-axidma'. Close matches: xilinx-axidma". I tried following LucasKl's additional step of modifying the SRC_URI line of xilinx-axidma.bb. I noticed in the listed procedure, it does instruct to delete the xilinx-axidma.c file, but it still exists in the SRC_URI line?

Instead of running petalinux-build -c rootfs/xilinx-axidma run petalinux-build -c xilinx-axidma
removing xilinx-axidma.c from SRC_URI is required.

Note that for 2019.2 I was required to change 2 *.c files as seen here: ISSUE-123

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests