Hello, This project is currently broken. The

broken,about bmartini/zynq-xdma

Comments (40)

bmartini commented on August 22, 2024

I've remove the top Makefile as I was not using it and as you said it, was not building everything. Each sub part now has to be compiled using the individual Makefiles.

The pointer conversion errors only happen for me when I'm not compiling the library on the Zedboard. I'm looking into getting it to work by cross compiling and will update when I do. As a work around you should compile and install the library from the Zedboard.

Once the library is installed the demos should then compile as the library and header will be in the linker PATH.

That the module will not load seems to me like it was compiled against a different version of the kernel then what you are running. To get information about the module use the following command on the module:

sudo modinfo xdma.ko

The version for my current running system is:

vermagic:       3.9.0-xilinx-dirty SMP preempt mod_unload modversions ARMv7 p2v8

Let me know if you need any more help getting it to run.

from zynq-xdma.

vanmierlo commented on August 22, 2024

So now one must enter the three directories by hand in the correct order and run make there?
This is more cumbersome and still doesn't work. I am indeed cross-compiling.

'Library installed' ? Where? In my host? I run make in lib/ and then in demo/ and it cannot find anything about the lib.

Due to the top Makefile not really making the dev/Makefile compile I accidently had an old xdma.ko for the wrong kernel. But... After a clean and renewed make insmod xdma.ko gives:

/ # insmod /nfs/xdma/xdma.ko
<xdma> init: registered
------------[ cut here ]------------
WARNING: CPU: 1 PID: 626 at mm/page_alloc.c:2484 __alloc_pages_nodemask+0x194/0x6e4()
Modules linked in: xdma(O+) axidmatest [last unloaded: axidmatest]
CPU: 1 PID: 626 Comm: insmod Tainted: G           O 3.12.0-xilinx-15330-g9e37fe7-dirty #1
[<c0014ef8>] (unwind_backtrace+0x0/0x11c) from [<c0011404>] (show_stack+0x10/0x14)
[<c0011404>] (show_stack+0x10/0x14) from [<c03ea1cc>] (dump_stack+0x84/0xc8)
[<c03ea1cc>] (dump_stack+0x84/0xc8) from [<c0021448>] (warn_slowpath_common+0x60/0x80)
[<c0021448>] (warn_slowpath_common+0x60/0x80) from [<c0021480>] (warn_slowpath_null+0x18/0x1c)
[<c0021480>] (warn_slowpath_null+0x18/0x1c) from [<c0080d38>] (__alloc_pages_nodemask+0x194/0x6e4)
[<c0080d38>] (__alloc_pages_nodemask+0x194/0x6e4) from [<c0018dfc>] (__dma_alloc_buffer.isra.17+0x2c/0x16c)
[<c0018dfc>] (__dma_alloc_buffer.isra.17+0x2c/0x16c) from [<c0018f50>] (__alloc_remap_buffer.isra.20+0x14/0xb0)
[<c0018f50>] (__alloc_remap_buffer.isra.20+0x14/0xb0) from [<c00191bc>] (__dma_alloc+0x1d0/0x238)
[<c00191bc>] (__dma_alloc+0x1d0/0x238) from [<c0019344>] (arm_dma_alloc+0x88/0x94)
[<c0019344>] (arm_dma_alloc+0x88/0x94) from [<bf0250fc>] (xdma_init+0xfc/0x14c [xdma])
[<bf0250fc>] (xdma_init+0xfc/0x14c [xdma]) from [<c0008794>] (do_one_initcall+0xc0/0x168)
[<c0008794>] (do_one_initcall+0xc0/0x168) from [<c006a6ac>] (load_module+0x1b20/0x1dd8)
[<c006a6ac>] (load_module+0x1b20/0x1dd8) from [<c006aa58>] (SyS_init_module+0xf4/0x100)
[<c006aa58>] (SyS_init_module+0xf4/0x100) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
---[ end trace 827d0e0ca4fe257f ]---
<xdma> Error: allocating dma memory failed
insmod: can't insert '/nfs/xdma/xdma.ko': Cannot allocate memory
/ #

Maarten

from zynq-xdma.

bmartini commented on August 22, 2024

The library runs on the zynq and so must be installed on the zynq. If you can compile on your zynq linux you can simply run the following command:

make install

or to install a already compiled library:

        sudo cp ${PWD}/libxdma.so /usr/lib
        sudo cp ${PWD}/libxdma.h /usr/include
        sudo chmod 0755 /usr/lib/libxdma.so
        sudo ldconfig

The last command 'ldconfig' updates the linker bindings and so will allow the demos to work.

The last issue is because of my lack of documentation, for which I'm very sorry. The Xilinx DMA requires contiguous memory allocations for it to work without a scatter gather engine. Contiguous memory needs to be set aside at boot using the device tree boot arguments. When editing your 'arch/arm/boot/dts/zynq-zed.dts' file include the following change:

        chosen {
-               bootargs = "console=ttyPS0,115200 root=/dev/ram rw earlyprintk";
+               bootargs = "cma=64M console=ttyPS0,115200 root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait devtmpfs.mount=0";
                linux,stdout-path = "/axi@0/serial@e0001000";
        } ;

Or a variation of it. The important thing is the 'cma=64M' which sets aside 64 Meg of ram for contiguous memory allocation.

from zynq-xdma.

vanmierlo commented on August 22, 2024

Sorry for the bad format in my previous answer. I've now updated it.

And building native on the zedboard really was outside my expectation. I doubt many others are doing that.

Anyway, now I have added the cma=64M to the bootargs, but it still fails:

/ # insmod /nfs/xdma/xdma.ko
<xdma> init: registered
------------[ cut here ]------------
WARNING: CPU: 1 PID: 585 at mm/page_alloc.c:2484 __alloc_pages_nodemask+0x194/0x6e4()
Modules linked in: xdma(O+)
CPU: 1 PID: 585 Comm: insmod Tainted: G           O 3.12.0-xilinx-15330-g9e37fe7-dirty #1
[<c0014ef8>] (unwind_backtrace+0x0/0x11c) from [<c0011404>] (show_stack+0x10/0x14)
[<c0011404>] (show_stack+0x10/0x14) from [<c03ea1cc>] (dump_stack+0x84/0xc8)
[<c03ea1cc>] (dump_stack+0x84/0xc8) from [<c0021448>] (warn_slowpath_common+0x60/0x80)
[<c0021448>] (warn_slowpath_common+0x60/0x80) from [<c0021480>] (warn_slowpath_null+0x18/0x1c)
[<c0021480>] (warn_slowpath_null+0x18/0x1c) from [<c0080d38>] (__alloc_pages_nodemask+0x194/0x6e4)
[<c0080d38>] (__alloc_pages_nodemask+0x194/0x6e4) from [<c0018dfc>] (__dma_alloc_buffer.isra.17+0x2c/0x16c)
[<c0018dfc>] (__dma_alloc_buffer.isra.17+0x2c/0x16c) from [<c0018f50>] (__alloc_remap_buffer.isra.20+0x14/0xb0)
[<c0018f50>] (__alloc_remap_buffer.isra.20+0x14/0xb0) from [<c00191bc>] (__dma_alloc+0x1d0/0x238)
[<c00191bc>] (__dma_alloc+0x1d0/0x238) from [<c0019344>] (arm_dma_alloc+0x88/0x94)
[<c0019344>] (arm_dma_alloc+0x88/0x94) from [<bf0030fc>] (xdma_init+0xfc/0x14c [xdma])
[<bf0030fc>] (xdma_init+0xfc/0x14c [xdma]) from [<c0008794>] (do_one_initcall+0xc0/0x168)
[<c0008794>] (do_one_initcall+0xc0/0x168) from [<c006a6ac>] (load_module+0x1b20/0x1dd8)
[<c006a6ac>] (load_module+0x1b20/0x1dd8) from [<c006aa58>] (SyS_init_module+0xf4/0x100)
[<c006aa58>] (SyS_init_module+0xf4/0x100) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
---[ end trace ea1421aac2a14a94 ]---
<xdma> Error: allocating dma memory failed
insmod: can't insert '/nfs/xdma/xdma.ko': Cannot allocate memory

/ # cat /proc/cmdline
console=ttyPS0,115200 root=/dev/ram rw ip=:::::eth0:dhcp earlyprintk cma=64M

Maarten

from zynq-xdma.

bmartini commented on August 22, 2024

Could you check to see if you are building the kernel with the Contiguous Memory Allocator (CMA) built in.

You can look in your .config file in the kernel repo and check the CMA entry is "CONFIG_CMA=y".

Or in 'make menuconfig' you can find it in 'Device Drivers -> Generic Driver Options' under 'Contiguous Memory Allocator'.

Also what kernel version are you building?

Thanks.

from zynq-xdma.

vanmierlo commented on August 22, 2024

Since I'm using a zedboard I also use xilinx_zynq_defconfig which has this enabled by default.
I also found CONFIG_DMA_CMA which was disabled. So I tried to enable that too. Alas, that didn't help much either. I no longer get errors, but instead:

/ # insmod /nfs/xdma/xdma.ko
<xdma> init: registered
<xdma> probe: number of devices found: 0

Do I need anything in the devicetree to get this thing going?

I'm building the master-next kernel from linux-xlnx (https://github.com/Xilinx/linux-xlnx)

/ # uname -r
3.12.0-xilinx-15330-g9e37fe7-dirty

Maarten

from zynq-xdma.

bmartini commented on August 22, 2024

From the looks of it the driver is now inserting fine but now you do not have the device tree setup correctly.

Quoted below is the dts file that I'm currently using in my project. I've tested it to work with the Xilinx linux kernel up to and including commit fdf538fbc1c5. However, the next commit in sequence (f9256f86e06) introduces a bug that prevents the DMA channels from being recognised. I'm working to find out why and when I do I'll be submitting a bit bug report to the Xilinx kernel.

In the mean time I would suggest you checkout commit fdf538fbc1c5 in the xilinx linux repo. Build the kernel (making sure you have CMA selected). Copy the dts file below and paste it into 'arch/arm/boot/dts/zynq-zed.dts' in the linux tree. Edit it to suit your projects hardware and build your device tree binary.

If you have the PL in the zynq setup up as a loopback then the demos should work.

/*
 * Device Tree Generator version: 1.1
 *
 * (C) Copyright 2007-2013 Xilinx, Inc.
 * (C) Copyright 2007-2013 Michal Simek
 * (C) Copyright 2007-2012 PetaLogix Qld Pty Ltd
 *
 * Michal SIMEK <[email protected]>
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of
 * the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA 02111-1307 USA
 *
 * CAUTION: This file is automatically generated by libgen.
 * Version: Xilinx EDK 14.5 EDK_P.58f
 *
 */

/dts-v1/;
/ {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "xlnx,zynq-7000";
    model = "Xilinx Zynq";
    aliases {
        ethernet0 = &ps7_ethernet_0;
        serial0 = &ps7_uart_1;
        spi0 = &ps7_qspi_0;
    } ;
    chosen {
        bootargs = "cma=64M console=ttyPS0,115200 root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait devtmpfs.mount=1";
        linux,stdout-path = "/amba@0/serial@e0001000";
    } ;
    cpus {
        #address-cells = <1>;
        #size-cells = <0>;
        ps7_cortexa9_0: cpu@0 {
            bus-handle = <&ps7_axi_interconnect_0>;
            compatible = "arm,cortex-a9";
            d-cache-line-size = <0x20>;
            d-cache-size = <0x8000>;
            device_type = "cpu";
            i-cache-line-size = <0x20>;
            i-cache-size = <0x8000>;
            interrupt-handle = <&ps7_scugic_0>;
            reg = <0x0>;
        } ;
        ps7_cortexa9_1: cpu@1 {
            bus-handle = <&ps7_axi_interconnect_0>;
            compatible = "arm,cortex-a9";
            d-cache-line-size = <0x20>;
            d-cache-size = <0x8000>;
            device_type = "cpu";
            i-cache-line-size = <0x20>;
            i-cache-size = <0x8000>;
            interrupt-handle = <&ps7_scugic_0>;
            reg = <0x1>;
        } ;
    } ;
    pmu {
        compatible = "arm,cortex-a9-pmu";
        interrupt-parent = <&ps7_scugic_0>;
        interrupts = <0 5 4>, <0 6 4>;
        reg = <0xf8891000 0x1000>, <0xf8893000 0x1000>;
        reg-names = "cpu0", "cpu1";
    } ;
    ps7_ddr_0: memory@0 {
        device_type = "memory";
        reg = <0x0 0x20000000>;
    } ;
    ps7_axi_interconnect_0: amba@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "xlnx,ps7-axi-interconnect-1.00.a", "simple-bus";
        ranges ;
        axi_dma_0: axi-dma@40400000 {
            compatible = "xlnx,axi-dma", "xlnx,axi-dma-6.03.a", "xlnx,axi-dma-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = < 0 59 4 0 58 4 >;
            reg = < 0x40400000 0x10000 >;
            xlnx,dlytmr-resolution = <0x7d>;
            xlnx,enable-multi-channel = <0x0>;
            xlnx,generic = <0x1>;
            xlnx,include-mm2s = <0x1>;
            xlnx,include-mm2s-dre = <0x0>;
            xlnx,include-mm2s-sf = <0x1>;
            xlnx,include-s2mm = <0x1>;
            xlnx,include-s2mm-dre = <0x0>;
            xlnx,include-s2mm-sf = <0x1>;
            xlnx,include-sg = <0x0>;
            xlnx,instance = "axi_dma_0";
            xlnx,mm2s-burst-size = <0x10>;
            xlnx,num-mm2s-channels = <0x1>;
            xlnx,num-s2mm-channels = <0x1>;
            xlnx,prmry-is-aclk-async = <0x0>;
            xlnx,s2mm-burst-size = <0x10>;
            xlnx,sg-include-desc-queue = <0x0>;
            xlnx,sg-include-stscntrl-strm = <0x0>;
            xlnx,sg-length-width = <0x0>;
            xlnx,sg-use-stsapp-length = <0x0>;
            dma-channel@40400000 {
                compatible = "xlnx,axi-dma-mm2s-channel";
                interrupts = < 0 59 4 >;
            } ;
            dma-channel@40400030 {
                compatible = "xlnx,axi-dma-s2mm-channel";
                interrupts = < 0 58 4 >;
            } ;
        } ;
        axi_dma_1: axi-dma@40440000 {
            compatible = "xlnx,axi-dma", "xlnx,axi-dma-6.03.a", "xlnx,axi-dma-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = < 0 57 4 0 56 4 >;
            reg = < 0x40440000 0x10000 >;
            xlnx,dlytmr-resolution = <0x7d>;
            xlnx,enable-multi-channel = <0x0>;
            xlnx,generic = <0x1>;
            xlnx,include-mm2s = <0x1>;
            xlnx,include-mm2s-dre = <0x0>;
            xlnx,include-mm2s-sf = <0x1>;
            xlnx,include-s2mm = <0x1>;
            xlnx,include-s2mm-dre = <0x0>;
            xlnx,include-s2mm-sf = <0x1>;
            xlnx,include-sg = <0x0>;
            xlnx,instance = "axi_dma_1";
            xlnx,mm2s-burst-size = <0x10>;
            xlnx,num-mm2s-channels = <0x1>;
            xlnx,num-s2mm-channels = <0x1>;
            xlnx,prmry-is-aclk-async = <0x0>;
            xlnx,s2mm-burst-size = <0x10>;
            xlnx,sg-include-desc-queue = <0x0>;
            xlnx,sg-include-stscntrl-strm = <0x0>;
            xlnx,sg-length-width = <0x0>;
            xlnx,sg-use-stsapp-length = <0x0>;
            dma-channel@40440000 {
                compatible = "xlnx,axi-dma-mm2s-channel";
                interrupts = < 0 57 4 >;
            } ;
            dma-channel@40440030 {
                compatible = "xlnx,axi-dma-s2mm-channel";
                interrupts = < 0 56 4 >;
            } ;
        } ;
        axi_dma_2: axi-dma@40480000 {
            compatible = "xlnx,axi-dma", "xlnx,axi-dma-6.03.a", "xlnx,axi-dma-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = < 0 55 4 0 54 4 >;
            reg = < 0x40480000 0x10000 >;
            xlnx,dlytmr-resolution = <0x7d>;
            xlnx,enable-multi-channel = <0x0>;
            xlnx,generic = <0x1>;
            xlnx,include-mm2s = <0x1>;
            xlnx,include-mm2s-dre = <0x0>;
            xlnx,include-mm2s-sf = <0x1>;
            xlnx,include-s2mm = <0x1>;
            xlnx,include-s2mm-dre = <0x0>;
            xlnx,include-s2mm-sf = <0x1>;
            xlnx,include-sg = <0x0>;
            xlnx,instance = "axi_dma_2";
            xlnx,mm2s-burst-size = <0x10>;
            xlnx,num-mm2s-channels = <0x1>;
            xlnx,num-s2mm-channels = <0x1>;
            xlnx,prmry-is-aclk-async = <0x0>;
            xlnx,s2mm-burst-size = <0x10>;
            xlnx,sg-include-desc-queue = <0x0>;
            xlnx,sg-include-stscntrl-strm = <0x0>;
            xlnx,sg-length-width = <0x0>;
            xlnx,sg-use-stsapp-length = <0x0>;
            dma-channel@40480000 {
                compatible = "xlnx,axi-dma-mm2s-channel";
                interrupts = < 0 55 4 >;
            } ;
            dma-channel@40480030 {
                compatible = "xlnx,axi-dma-s2mm-channel";
                interrupts = < 0 54 4 >;
            } ;
        } ;
        ps7_afi_0: ps7-afi@f8008000 {
            compatible = "xlnx,ps7-afi-1.00.a";
            reg = <0xf8008000 0x1000>;
        } ;
        ps7_afi_1: ps7-afi@f8009000 {
            compatible = "xlnx,ps7-afi-1.00.a";
            reg = <0xf8009000 0x1000>;
        } ;
        ps7_afi_2: ps7-afi@f800a000 {
            compatible = "xlnx,ps7-afi-1.00.a";
            reg = <0xf800a000 0x1000>;
        } ;
        ps7_afi_3: ps7-afi@f800b000 {
            compatible = "xlnx,ps7-afi-1.00.a";
            reg = <0xf800b000 0x1000>;
        } ;
        ps7_ddrc_0: ps7-ddrc@f8006000 {
            compatible = "xlnx,ps7-ddrc-1.00.a", "xlnx,ps7-ddrc";
            reg = <0xf8006000 0x1000>;
            xlnx,has-ecc = <0x0>;
        } ;
        ps7_dev_cfg_0: ps7-dev-cfg@f8007000 {
            clock-names = "ref_clk", "fclk0", "fclk1", "fclk2", "fclk3";
            clocks = <&clkc 12>, <&clkc 15>, <&clkc 16>, <&clkc 17>, <&clkc 18>;
            compatible = "xlnx,ps7-dev-cfg-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 8 4>;
            reg = <0xf8007000 0x100>;
        } ;
        ps7_dma_s: ps7-dma@f8003000 {
            #dma-cells = <1>;
            #dma-channels = <8>;
            #dma-requests = <4>;
            arm,primecell-periphid = <0x41330>;
            clock-names = "apb_pclk";
            clocks = <&clkc 27>;
            compatible = "xlnx,ps7-dma-1.00.a", "arm,primecell", "arm,pl330";
            interrupt-names = "abort", "dma0", "dma1", "dma2", "dma3",
                "dma4", "dma5", "dma6", "dma7";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 13 4>, <0 14 4>, <0 15 4>, <0 16 4>, <0 17 4>, <0 40 4>, <0 41 4>, <0 42 4>, <0 43 4>;
            reg = <0xf8003000 0x1000>;
        } ;
        ps7_ethernet_0: ps7-ethernet@e000b000 {
            #address-cells = <1>;
            #size-cells = <0>;
            clock-names = "ref_clk", "aper_clk";
            clocks = <&clkc 13>, <&clkc 30>;
            compatible = "xlnx,ps7-ethernet-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 22 4>;
            local-mac-address = [00 0a 35 00 00 00];
            phy-handle = <&phy0>;
            phy-mode = "rgmii-id";
            reg = <0xe000b000 0x1000>;
            xlnx,enet-reset = <0xffffffff>;
            xlnx,eth-mode = <0x1>;
            xlnx,has-mdio = <0x1>;
            xlnx,ptp-enet-clock = <111111115>;
            mdio {
                #address-cells = <1>;
                #size-cells = <0>;
                phy0: phy@7 {
                    compatible = "marvell,88e1510";
                    device_type = "ethernet-phy";
                    reg = <0>;
                } ;
            } ;
        } ;
        ps7_gpio_0: ps7-gpio@e000a000 {
            #gpio-cells = <2>;
            clocks = <&clkc 42>;
            compatible = "xlnx,ps7-gpio-1.00.a";
            emio-gpio-width = <64>;
            gpio-controller ;
            gpio-mask-high = <0xc0000>;
            gpio-mask-low = <0xfe81>;
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 20 4>;
            reg = <0xe000a000 0x1000>;
        } ;
        ps7_iop_bus_config_0: ps7-iop-bus-config@e0200000 {
            compatible = "xlnx,ps7-iop-bus-config-1.00.a";
            reg = <0xe0200000 0x1000>;
        } ;
        ps7_pl310_0: ps7-pl310@f8f02000 {
            arm,data-latency = <3 2 2>;
            arm,tag-latency = <2 2 2>;
            cache-level = <2>;
            cache-unified ;
            compatible = "xlnx,ps7-pl310-1.00.a", "arm,pl310-cache";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 2 4>;
            reg = <0xf8f02000 0x1000>;
        } ;
        ps7_qspi_0: ps7-qspi@e000d000 {
            clock-names = "ref_clk", "aper_clk";
            clocks = <&clkc 10>, <&clkc 43>;
            compatible = "xlnx,ps7-qspi-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 19 4>;
            is-dual = <0>;
            num-chip-select = <1>;
            reg = <0xe000d000 0x1000>;
            xlnx,fb-clk = <0x1>;
            xlnx,qspi-mode = <0x0>;
            #address-cells = <1>;
            #size-cells = <0>;
            flash@0 {
                compatible = "n25q128";
                reg = <0x0>;
                spi-max-frequency = <50000000>;
                #address-cells = <1>;
                #size-cells = <1>;
                partition@qspi-fsbl-uboot {
                    label = "qspi-fsbl-uboot";
                    reg = <0x0 0x100000>;
                };
                partition@qspi-linux {
                    label = "qspi-linux";
                    reg = <0x100000 0x500000>;
                };
                partition@qspi-device-tree {
                    label = "qspi-device-tree";
                    reg = <0x600000 0x20000>;
                };
                partition@qspi-rootfs {
                    label = "qspi-rootfs";
                    reg = <0x620000 0x5E0000>;
                };
                partition@qspi-bitstream {
                    label = "qspi-bitstream";
                    reg = <0xC00000 0x400000>;
                };
            };

        } ;
        ps7_qspi_linear_0: ps7-qspi-linear@fc000000 {
            clock-names = "ref_clk", "aper_clk";
            clocks = <&clkc 10>, <&clkc 43>;
            compatible = "xlnx,ps7-qspi-linear-1.00.a";
            reg = <0xfc000000 0x1000000>;
        } ;
        ps7_ram_0: ps7-ram@0 {
            compatible = "xlnx,ps7-ram-1.00.a", "xlnx,ps7-ocm";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 3 4>;
            reg = <0xfffc0000 0x40000>;
        } ;
        ps7_scugic_0: ps7-scugic@f8f01000 {
            #address-cells = <2>;
            #interrupt-cells = <3>;
            #size-cells = <1>;
            compatible = "xlnx,ps7-scugic-1.00.a", "arm,cortex-a9-gic", "arm,gic";
            interrupt-controller ;
            num_cpus = <2>;
            num_interrupts = <96>;
            reg = <0xf8f01000 0x1000>, <0xf8f00100 0x100>;
        } ;
        ps7_scutimer_0: ps7-scutimer@f8f00600 {
            clocks = <&clkc 4>;
            compatible = "xlnx,ps7-scutimer-1.00.a", "arm,cortex-a9-twd-timer";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <1 13 0x301>;
            reg = <0xf8f00600 0x20>;
        } ;
        ps7_scuwdt_0: ps7-scuwdt@f8f00620 {
            clocks = <&clkc 4>;
            compatible = "xlnx,ps7-scuwdt-1.00.a";
            device_type = "watchdog";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <1 14 0x301>;
            reg = <0xf8f00620 0xe0>;
        } ;
        ps7_sd_0: ps7-sdio@e0100000 {
            clock-frequency = <50000000>;
            clock-names = "ref_clk", "aper_clk";
            clocks = <&clkc 21>, <&clkc 32>;
            compatible = "xlnx,ps7-sdio-1.00.a", "generic-sdhci", "arasan,sdhci";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 24 4>;
            reg = <0xe0100000 0x1000>;
            xlnx,has-cd = <0x1>;
            xlnx,has-power = <0x0>;
            xlnx,has-wp = <0x1>;
        } ;
        ps7_slcr_0: ps7-slcr@f8000000 {
            compatible = "xlnx,ps7-slcr-1.00.a", "xlnx,zynq-slcr";
            reg = <0xf8000000 0x1000>;
            clocks {
                #address-cells = <1>;
                #size-cells = <0>;
                clkc: clkc {
                    #clock-cells = <1>;
                    clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x",
                        "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci",
                        "lqspi", "smc", "pcap", "gem0", "gem1",
                        "fclk0", "fclk1", "fclk2", "fclk3", "can0",
                        "can1", "sdio0", "sdio1", "uart0", "uart1",
                        "spi0", "spi1", "dma", "usb0_aper", "usb1_aper",
                        "gem0_aper", "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper",
                        "spi1_aper", "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper",
                        "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper",
                        "swdt", "dbg_trc", "dbg_apb";
                    compatible = "xlnx,ps7-clkc";
                    fclk-enable = <0xf>;
                    ps-clk-frequency = <33333333>;
                } ;
            } ;
        } ;
        ps7_ttc_0: ps7-ttc@f8001000 {
            clocks = <&clkc 6>;
            compatible = "xlnx,ps7-ttc-1.00.a", "cdns,ttc";
            interrupt-names = "ttc0", "ttc1", "ttc2";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 10 4>, <0 11 4>, <0 12 4>;
            reg = <0xf8001000 0x1000>;
        } ;
        ps7_uart_1: serial@e0001000 {
            clock-names = "ref_clk", "aper_clk";
            clocks = <&clkc 24>, <&clkc 41>;
            compatible = "xlnx,ps7-uart-1.00.a", "xlnx,xuartps";
            current-speed = <115200>;
            device_type = "serial";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 50 4>;
            port-number = <0>;
            reg = <0xe0001000 0x1000>;
            xlnx,has-modem = <0x0>;
        } ;
        ps7_usb_0: ps7-usb@e0002000 {
            clocks = <&clkc 28>;
            compatible = "xlnx,ps7-usb-1.00.a";
            dr_mode = "host";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 21 4>;
            phy_type = "ulpi";
            reg = <0xe0002000 0x1000>;
            xlnx,usb-reset = <0xffffffff>;
        } ;
        ps7_xadc: ps7-xadc@f8007100 {
            clocks = <&clkc 12>;
            compatible = "xlnx,ps7-xadc-1.00.a";
            interrupt-parent = <&ps7_scugic_0>;
            interrupts = <0 7 4>;
            reg = <0xf8007100 0x20>;
        } ;
        accel_config: accel_config@80000000 {
            compatible = "xlnx,config-1.00.a";
            reg = < 0x80000000 0x10000 >;
            xlnx,num-mem = <0x1>;
            xlnx,num-reg = <0x20>;
            xlnx,s-axi-min-size = <0x1ff>;
            xlnx,slv-awidth = <0x20>;
            xlnx,slv-dwidth = <0x20>;
        } ;
    } ;
} ;

from zynq-xdma.

vanmierlo commented on August 22, 2024

Thanks. It was not obvious to me that this driver depended on the xilinx_axidma driver instead of replacing it. So to prevent address clashes I removed the axi_dma_0 entry from the devicetree. You really should document this. Just like all this CMA stuff.

Now that I've placed it back it says:

/ # insmod /nfs/xdma/xdma.ko
<xdma> init: registered
<xdma> probe: number of devices found: 1

Whoohoo! Finally something starts working.

The latest xilinx_axidma driver has progressed really as at least the bug of looking at the wrong devicetree entry for SG inclusion has been fixed. But it also needs some extra entries in the channel sections. Here's the relevant part in my devicetree.dts:

axi_dma_0: axi-dma@40400000 {
    axistream-connected = <&axi_dma_0>;
    axistream-control-connected = <&axi_dma_0>;
    compatible = "xlnx,axi-dma";
    interrupt-parent = <&ps7_scugic_0>;
    interrupts = < 0 59 4 0 58 4 >;
    reg = < 0x40400000 0x10000 >;
    xlnx,dlytmr-resolution = <0x7d>;
    xlnx,enable-multi-channel = <0x0>;
    xlnx,family = "zynq";
    xlnx,generic = <0x0>;
    xlnx,include-mm2s = <0x1>;
    xlnx,include-mm2s-dre = <0x0>;
    xlnx,include-mm2s-sf = <0x1>;
    xlnx,include-s2mm = <0x1>;
    xlnx,include-s2mm-dre = <0x0>;
    xlnx,include-s2mm-sf = <0x1>;
    xlnx,include-sg = <0x0>;
    xlnx,instance = "axi_dma_0";
    xlnx,mm2s-burst-size = <0x10>;
    xlnx,num-mm2s-channels = <0x1>;
    xlnx,num-s2mm-channels = <0x1>;
    xlnx,prmry-is-aclk-async = <0x0>;
    xlnx,s2mm-burst-size = <0x10>;
    xlnx,sg-include-desc-queue = <0x0>;
    xlnx,sg-include-stscntrl-strm = <0x0>;
    xlnx,sg-length-width = <0xe>;
    xlnx,sg-use-stsapp-length = <0x1>;
    dma-channel@40400000 {
        compatible = "xlnx,axi-dma-mm2s-channel";
        xlnx,include-dre = <0x0>;
        xlnx,datawidth = <0x20>;
        xlnx,device-id = <0x0>;
        interrupts = <0 59 4 >;
    };
    dma-channel@40400030 {
        compatible = "xlnx,axi-dma-s2mm-channel";
        xlnx,include-dre = <0x0>;
        xlnx,datawidth = <0x20>;
        xlnx,device-id = <0x1>;
        interrupts = <0 58 4 >;
    };
};

I do not claim to understand all these entries or know if they are all required. I just found most of it in the xilinx forum and added the three lines in the channels according to what I found in the xilinx_axidma.c source.

Now I can finally start looking at the demo how to put this driver to use.

Maarten

from zynq-xdma.

vanmierlo commented on August 22, 2024

Oh oh, here's the output of test when I compile and run it from the SDK:

<xdma> file: open()
<xdma> ioctl: XDMA_TEST_TRANSFER
<xdma> test: rx buffer before transmit:
Y       Y  Y Y  Y     Y Y     Y Y       Y
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = dae2c000
[00000000] *pgd=1ae0e831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#2] PREEMPT SMP ARM
Modules linked in: xdma(O)
CPU: 1 PID: 660 Comm: xdma_test.elf Tainted: G      D    O 3.12.0-xilinx-15330-g9e37fe7-dirty #3
task: dae340c0 ti: dae28000 task.ti: dae28000
PC is at xdma_prep_buffer+0x4c/0xdc [xdma]
LR is at sg_init_table+0x18/0x30
pc : [<bf0002f8>]    lr : [<c01c4f2c>]    psr: 40000013
sp : dae29dd0  ip : 00000000  fp : bef24d54
r10: 1b100000  r9 : dae28000  r8 : 00100000
r7 : 00000000  r6 : 00000002  r5 : d8061d00  r4 : dae29e28
r3 : bf000ccc  r2 : 00000000  r1 : 0000000b  r0 : 00000002
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5387d  Table: 1ae2c04a  DAC: 00000015
Process xdma_test.elf (pid: 660, stack limit = 0xdae28240)
Stack: (0xdae29dd0 to 0xdae2a000)
9dc0:                                     c001cc68 00010002 0000000a 00000002
9de0: 00000000 00100000 1b100000 00000001 00000003 00000000 00100000 bf00135c
9e00: 00000001 00000003 00000000 bf000574 000000cd 00000000 00000020 00000000
9e20: 00000001 c05aba70 00000000 d8061d00 00000000 00000000 00100000 00000001
9e40: 00000000 00000000 00000001 00000000 00000000 daecb934 00000000 00000001
9e60: 00000000 00000000 00000000 d806aa80 00005706 00000003 dae28000 00000000
9e80: bef24d54 c03e8f08 00001181 000b6023 00000000 dae29ea4 00000000 00000000
9ea0: 00000000 d806aa80 00005706 bf0009a8 dac2e150 da88d998 c0907740 c0907760
9ec0: 00000000 00000002 00000000 dae29f74 00000001 d8007000 ffffff9c c000e544
9ee0: dae28000 00000000 bef24d54 00000007 c05a7178 b6f1dc10 dae29fb0 b6f91000
9f00: 00000000 b6fe4000 bef24d54 d80780b0 00000000 c00bb158 00002000 c00bbc3c
9f20: 00000004 00000000 00000000 00000000 00000400 00000000 00000000 00000000
9f40: 00000002 00000003 d806aa80 d8007000 00000003 00000003 00000003 d806aa80
9f60: d8007000 d806aa80 00000000 00000000 00005706 00000003 dae28000 00000000
9f80: bef24d54 c00bbcbc 00000003 00000000 00009078 00000000 000000d8 00000036
9fa0: c000e544 c000e3c0 00009078 00000000 00000003 00005706 00000000 00000003
9fc0: 00009078 00000000 000000d8 00000036 b6f91000 00000000 b6fe4000 bef24d54
9fe0: 00000000 bef24d40 000090d4 b6f1dc1c 60000010 00000003 00000000 00000000
[<bf0002f8>] (xdma_prep_buffer+0x4c/0xdc [xdma]) from [<bf000574>] (xdma_test_transfer+0xf4/0x274 [xdma])
[<bf000574>] (xdma_test_transfer+0xf4/0x274 [xdma]) from [<bf0009a8>] (xdma_ioctl+0x2b4/0x2f0 [xdma])
[<bf0009a8>] (xdma_ioctl+0x2b4/0x2f0 [xdma]) from [<c00bb158>] (vfs_ioctl+0x24/0x40)
[<c00bb158>] (vfs_ioctl+0x24/0x40) from [<c00bbc3c>] (do_vfs_ioctl+0x53c/0x584)
[<c00bbc3c>] (do_vfs_ioctl+0x53c/0x584) from [<c00bbcbc>] (SyS_ioctl+0x38/0x54)
[<c00bbcbc>] (SyS_ioctl+0x38/0x54) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
Code: eb471309 e58da018 e58d8014 e3a0100b (e5973000)
---[ end trace 4d82deb1aed54dee ]---
<xdma> file: close()
Segmentation fault

And this is the output of demo:

<xdma> file: open()
<xdma> file: mmap()
<xdma> file: memory size reserved: 33554432, mmap size requested: 4096
test: rx buffer before transmit:
65      65 65   65    65 65   65        65      65      65
<xdma> ioctl: XDMA_GET_NUM_DEVICES
Number of devices: 1
<xdma> ioctl: XDMA_GET_DEV_INFO
devices tx chan: daecb934, tx cmp:d8061a80, rx chan: 0, rx cmp: <xdma> ioctl: XDMA_DEVICE_CONTROL
d8061d00
config rx chans
<xdma> ioctl: XDMA_DEVICE_CONTROL
config tx chans
<xdma> ioctl: XDMA_PREP_BUF
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = df49c000
[00000000] *pgd=1805c831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#4] PREEMPT SMP ARM
Modules linked in: xdma(O)
CPU: 1 PID: 668 Comm: xdma_demo.elf Tainted: G      D    O 3.12.0-xilinx-15330-g9e37fe7-dirty #3
task: dad77080 ti: d807a000 task.ti: d807a000
PC is at xdma_prep_buffer+0x4c/0xdc [xdma]
LR is at sg_init_table+0x18/0x30
pc : [<bf0002f8>]    lr : [<c01c4f2c>]    psr: 40000013
sp : d807be70  ip : 00000000  fp : befbbd54
r10: 1b100000  r9 : d807a000  r8 : 00000400
r7 : 00000000  r6 : 00000002  r5 : d8061d00  r4 : d807beb0
r3 : bf000ccc  r2 : 00000000  r1 : 0000000b  r0 : 00000002
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5387d  Table: 1f49c04a  DAC: 00000015
Process xdma_demo.elf (pid: 668, stack limit = 0xd807a240)
Stack: (0xd807be70 to 0xd807c000)
be60:                                     00005703 00000003 d807a000 00000002
be80: 00000000 00000400 1b100000 d807a000 dac98bc0 befbbce8 d807a000 dac98bc0
bea0: 00005703 00000003 00000000 bf0008a8 00000000 d8061d00 00000000 00000000
bec0: 00000400 00000001 c05fd1ec c0218180 da39f600 00000000 00000000 da39f778
bee0: 20000013 00000001 00000001 00000004 00000010 00000010 dad1cc30 c00deb3c
bf00: 00000004 da39f600 00000010 d80780b0 befbbce8 c00bb158 00002000 c00bbc3c
bf20: df45d140 00000000 00000000 00000000 00000010 d8090900 00000010 d8090908
bf40: 00000002 dad1cc30 00000000 00000000 befbbd54 c00ad634 00000000 00000000
bf60: 00000010 dac98bc0 00000000 befbbce8 00005703 00000003 d807a000 00000000
bf80: befbbd54 c00bbcbc 00000003 00000000 00008700 00000000 000000d8 00000036
bfa0: c000e544 c000e3c0 00008700 00000000 00000003 00005703 befbbce8 befbbce8
bfc0: 00008700 00000000 000000d8 00000036 b6f16000 00000000 b6f69000 befbbd54
bfe0: 00000000 befbbca0 00008a98 b6ea2c1c 60000010 00000003 00000000 00000000
[<bf0002f8>] (xdma_prep_buffer+0x4c/0xdc [xdma]) from [<bf0008a8>] (xdma_ioctl+0x1b4/0x2f0 [xdma])
[<bf0008a8>] (xdma_ioctl+0x1b4/0x2f0 [xdma]) from [<c00bb158>] (vfs_ioctl+0x24/0x40)
[<c00bb158>] (vfs_ioctl+0x24/0x40) from [<c00bbc3c>] (do_vfs_ioctl+0x53c/0x584)
[<c00bbc3c>] (do_vfs_ioctl+0x53c/0x584) from [<c00bbcbc>] (SyS_ioctl+0x38/0x54)
[<c00bbcbc>] (SyS_ioctl+0x38/0x54) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
Code: eb471309 e58da018 e58d8014 e3a0100b (e5973000)
---[ end trace 4d82deb1aed54df0 ]---
<xdma> file: close()
Segmentation fault

And finally app:

<xdma> file: open()
<xdma> file: mmap()
<xdma> file: memory size reserved: 33554432, mmap size requested: 33554432
<xdma> ioctl: XDMA_GET_NUM_DEVICES
<xdma> ioctl: XDMA_GET_DEV_INFO
<xdma> ioctl: XDMA_DEVICE_CONTROL
<xdma> ioctl: XDMA_DEVICE_CONTROL
test: dst buffer before transmit:
65      65 65   65    65 65   65        65      65      65
<xdma> ioctl: XDMA_GET_NUM_DEVICES
<xdma> ioctl: XDMA_PREP_BUF
<xdma> ioctl: XDMA_PREP_BUF
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = d8050000
[00000000] *pgd=18005831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#7] PREEMPT SMP ARM
Modules linked in: xdma(O)
CPU: 1 PID: 677 Comm: xdma_app.elf Tainted: G      D    O 3.12.0-xilinx-15330-g9e37fe7-dirty #3
task: dae3b480 ti: dae2c000 task.ti: dae2c000
PC is at xdma_prep_buffer+0x4c/0xdc [xdma]
LR is at sg_init_table+0x18/0x30
pc : [<bf0002f8>]    lr : [<c01c4f2c>]    psr: 40000013
sp : dae2de70  ip : 00000000  fp : bef38d2c
r10: 1b100000  r9 : dae2c000  r8 : 00001004
r7 : 00000000  r6 : 00000002  r5 : d8061d00  r4 : dae2deb0
r3 : bf000ccc  r2 : 00000000  r1 : 0000000b  r0 : 00000002
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5387d  Table: 1805004a  DAC: 00000015
Process xdma_app.elf (pid: 677, stack limit = 0xdae2c240)
Stack: (0xdae2de70 to 0xdae2e000)
de60:                                     00005703 00000003 dae2c000 00000002
de80: 00000000 00001004 1b100000 dae2c000 d806a0c0 bef38d08 dae2c000 d806a0c0
dea0: 00005703 00000003 00000000 bf0008a8 00000000 d8061d00 00000000 00000000
dec0: 00001004 00000001 c05fd1ec c0218180 da39f600 00000000 00000000 da39f778
dee0: 20000013 00000001 00000001 00000004 0000001f 0000001f dad1cc30 c00deb3c
df00: 00000001 da39f600 0000001f d80780b0 bef38d08 c00bb158 00002000 c00bbc3c
df20: df45d140 00000000 00000000 00000000 0000001f d8090900 0000001f d8090908
df40: 00000002 dad1cc30 00000000 00000000 bef38d54 c00ad634 00000000 00000000
df60: 0000001f d806a0c0 00000000 bef38d08 00005703 00000003 dae2c000 00000000
df80: bef38d2c c00bbcbc 00000003 00000000 000090dc 00000000 000000d8 00000036
dfa0: c000e544 c000e3c0 000090dc 00000000 00000003 00005703 bef38d08 bef38d08
dfc0: 000090dc 00000000 000000d8 00000036 b6ec0000 00000000 b6f13000 bef38d2c
dfe0: 00000000 bef38cc0 00008f14 b6e4cc1c 20000010 00000003 00000000 00000000
[<bf0002f8>] (xdma_prep_buffer+0x4c/0xdc [xdma]) from [<bf0008a8>] (xdma_ioctl+0x1b4/0x2f0 [xdma])
[<bf0008a8>] (xdma_ioctl+0x1b4/0x2f0 [xdma]) from [<c00bb158>] (vfs_ioctl+0x24/0x40)
[<c00bb158>] (vfs_ioctl+0x24/0x40) from [<c00bbc3c>] (do_vfs_ioctl+0x53c/0x584)
[<c00bbc3c>] (do_vfs_ioctl+0x53c/0x584) from [<c00bbcbc>] (SyS_ioctl+0x38/0x54)
[<c00bbcbc>] (SyS_ioctl+0x38/0x54) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
Code: eb471309 e58da018 e58d8014 e3a0100b (e5973000)
---[ end trace 4d82deb1aed54df3 ]---
<xdma> file: close()
Segmentation fault

Hints and comments are still welcome,
Maarten

from zynq-xdma.

bmartini commented on August 22, 2024

Thanks for the feed back. I'm going to integrate your device tree updates into my project and try to get it working with the latest kernel.

I'm in the process of writing some documentation and will be putting them up soon. But please note the project README does clearly explains in the first paragraph that this project is a wrapper driver for the Xilinx "xilinx_axidma.c" low level driver.

from zynq-xdma.

bmartini commented on August 22, 2024

In your device trees 2nd channel node you have:

xlnx,device-id = <0x1>;

If you change it to:

xlnx,device-id = <0x0>;

the demos should work.

from zynq-xdma.

bmartini commented on August 22, 2024

After a bit more testing the above change only stops the error, it does not get the demos to work.

So my earlier advice still stands; if you want it to work right now checkout (fdf538fbc1c5) and use the devicetree I quoted above. Or, if you really need to use a newer kernel you can try and fix the devicetree to work with the latest kernel. I'm working on that myself, but I don't know how long it will take.

from zynq-xdma.

bmartini commented on August 22, 2024

In order to get the device tree that I quoted in one of my earlier comments working with the latest master (efc27505715) and the latest master-next (7cfa11705d13e) I had to change the axi_dma device tree node to the following:

axi_dma_0: axi-dma@40400000 {
    compatible = "xlnx,axi-dma", "xlnx,axi-dma-6.03.a", "xlnx,axi-dma-1.00.a";
    interrupt-parent = <&ps7_scugic_0>;
    interrupts = < 0 59 4 0 58 4 >;
    reg = < 0x40400000 0x10000 >;
    xlnx,dlytmr-resolution = <0x7d>;
    xlnx,enable-multi-channel = <0x0>;
    xlnx,generic = <0x1>;
    xlnx,include-mm2s = <0x1>;
    xlnx,include-mm2s-dre = <0x0>;
    xlnx,include-mm2s-sf = <0x1>;
    xlnx,include-s2mm = <0x1>;
    xlnx,include-s2mm-dre = <0x0>;
    xlnx,include-s2mm-sf = <0x1>;
    xlnx,instance = "axi_dma_0";
    xlnx,mm2s-burst-size = <0x10>;
    xlnx,num-mm2s-channels = <0x1>;
    xlnx,num-s2mm-channels = <0x1>;
    xlnx,prmry-is-aclk-async = <0x0>;
    xlnx,s2mm-burst-size = <0x10>;
    xlnx,sg-include-desc-queue = <0x0>;
    xlnx,sg-length-width = <0x0>;
    xlnx,sg-use-stsapp-length = <0x0>;
    dma-channel@40400000 {
        compatible = "xlnx,axi-dma-mm2s-channel";
        interrupts = < 0 59 4 >;
        xlnx,datawidth = <0x20>;
        xlnx,device-id = <0x0>;
    } ;
    dma-channel@40400030 {
        compatible = "xlnx,axi-dma-s2mm-channel";
        interrupts = < 0 58 4 >;
        xlnx,datawidth = <0x20>;
        xlnx,device-id = <0x0>;
    } ;
} ;

The difference in the dma device node is the removal of the "xlnx,include-sg" and "xlnx,sg-include-stscntrl-strm" fields. In the dma channel node it is the inclusion of the "xlnx,datawidth" and "xlnx,device-id" fields.

With these changes to the device tree the demos can now work.

from zynq-xdma.

vanmierlo commented on August 22, 2024

Hello again,

I've tried again with your latest modifications and the axi_dma_0 shown above in the devicetree. I also reverted to the master branch of linux-xlnx. I also have enabled CMA and added cma=64M again. This time the test no longer generates a segmentation fault, but it does generate a timeout:

<xdma> file: open()
<xdma> ioctl: XDMA_TEST_TRANSFER
<xdma> test: rx buffer before transmit:
Y      Y        Y       Y Y     Y       Y   Y   Y       Y
<xdma> test: xdma_start_transfer rx
<xdma> test: xdma_start_transfer tx
<xdma> test: time to prepare DMA channels [us]: 6432
<xdma> Error: transfer timed out
<xdma> test: DMA transfer time [us]: -6322
<xdma> test: DMA bytes sent: 1048576
<xdma> test: DMA speed in Mbytes/s: -165
<xdma> test: rx buffer after transmit:
Y      Y        Y       Y Y     Y       Y   Y   Y       Y
ran driver test transition: use 'dmesg' to view results
<xdma> file: close()

This is my diagram in Vivado. I have the two streams connected directly to each other in VHDL. Do I have anything wrong? Should I use ACP instead of HP0?

Any help is still very much appreciated.
Maarten

from zynq-xdma.

bmartini commented on August 22, 2024

I don't use Vivado or VHDL in my projects but instead planAhead and Verilog, thus I don't think I would do very well with debugging your project. However, to give you a bit of help I created a simple loopback peripheral that can be used by the xdma driver on the Zedboard.

https://github.com/bmartini/zedboard-simple-loopback

Using this and the included device tree source (you might need to tweak the bootargs) you should be able to get the demos working.

Let me know how it goes.

from zynq-xdma.

vanmierlo commented on August 22, 2024

Thank you very much. I had to download and install PlanAhead 14.7 first, but now I finally managed to get the test application to run without timeout. I'm still not sure what my Vivado design is doing differently.

I noticed you used a custom IP called loopback. Is there a special reason why you did not just connect M_AXIS_MM2S to S_AXIS_S2MM in XPS? Inside loopback.v you simply assign the outputs to the inputs as did I in my VHDL.

Did you manually change anything in the generated system_stub.v wrapper? I'm guessing you didn't.

But I'm really glad that I finally saw this thing working in linux.

from zynq-xdma.

bmartini commented on August 22, 2024

You could probably migrate (import) the planAhead project into a Vivado project and then compare to two.

I made a custom IP because I thought it would be easier to modify if someone wanted to add custom logic to the project. That project was (is) going to be part of some tutorials I'm writing. I'm sure it would work just fine if the ports were connected directly.

The system_stub.v file has a small modification from what the Xilinx tools generated. The commits for that project will tell you what I did.

Glad that its working for you now. Feel free to point others to this project, the more people that start using it the better it will get. I've added a public email address to my github profile so you can email me with any general question.

from zynq-xdma.

vanmierlo commented on August 22, 2024

I tested without the loopback IP and a direct connection in XPS and that works as well. Then I regenerated the system_stub.v wrapper and found no differences. So the project is now virtually without verilog for me as it only contains generated code.

Digging into the settings in XPS I found that the Length Register has a width of 23 bits, where the default in Vivado is 14 which I had not changed. Now that I have, your driver also starts to work with my Vivado generated bit-file and no more timeouts. Is this also why you need 64M CMA?

Now I can finally push forward and start using it in my own applications.

One more question, though: How do you ensure cache coherency? Should the AXI-DMA not be connected to the ACP for that? Or does your driver or the xilinx_axidma driver fix that in software?

from zynq-xdma.

vanmierlo commented on August 22, 2024

Now I have another question about the xdma library. Is there a way to timeout on receiving data? Or is there a way to guess how many data is available in the stream? I think not. But then I don't want to wait indefinitely until a full buffer has arrived. And how can my software see how many data was actually received? I expected the return value of xdma_perform_transaction to indicate this, but it can only return 0 or -1.

from zynq-xdma.

bmartini commented on August 22, 2024

Line 198 of xdma.c

unsigned long tmo = msecs_to_jiffies(3000);

sets the time out. Its hard coded but I guess I could make it a variable that gets passed in if there is a need. However, a time out is considered an error and it only matters if you are waiting/blocking on a transfer. I'm thinking that there might be a better way around your problem then generating errors.

DMA has to work with a known buffer size as you have to prep the buffer before the transaction. I believe the hardware can terminate the tx transaction early by using the TLAST signal in the stream bus. Knowing the size of the stream might then be a matter of having the stream NULL terminated or similar. Or having Linux read the size from a AXI Lite register which is separate from the DMA stuff. Terminating the rx transaction early can be done using the xdma_stop_transfer function.

For my project I setup a lot of DMA transfers on a number of different DMA channels at the same time. I don't block on the transfers because I want to set them up to run at the same time. I then probe a AXI Lite register which reads a counter in hardware to know how much data has been transferred by the DMA channels. When the DMA transfer is complete I then move on to do more transactions.

If you want you can read the Xilinx low level DMA driver to find out if they have a way of knowing the amount of data that was transferred by the DMA hardware. If they do, feel free to tell me and I'll add that functionality to the xdma driver. However, I don't think they do.

from zynq-xdma.

vanmierlo commented on August 22, 2024

Yes, I had seen the timeout. However the application is never notified of the timeout since xdma_start_transfer() does not return an error code. So even when nothing is received from the S2MM pipe the application thinks it got a full block. I've modified xdma.c so xdma_start_transfer() returns an int and let it return -1 in the two error cases and 0 otherwise. This way xdma_ioctl() can return -EFAULT when it fails. I hope this describes it enough because I don't really know how to use git to send it to you.

It is also a bit unclear how the XDMA_WAIT_SRC and XDMA_WAIT_DST work. Or rather their inverse. If you don't wait for the transfer to end, how will the application know it has ended? It seems to me that the xilinx_axidma driver will add a new transfer to a pending list if it is still busy. So you can issue several. But in your demo application you do not wait, yet immediately after the transfer you start reading the map[]. Are you assuming the printf's to take enough time?

I cannot find in the xilinx_axidma driver either where it reads back the transfer length allthough the hardware manual (PG021) clearly states it updates the LENGTH register. So the IOC interrupt handler could certainly get it. I've opened an issue about it here: https://github.com/Xilinx/linux-xlnx/issues/20 Let's see where that ends.

In general I would prefer to see the AXI-Streams as linux character devices. Then you can write to them and see how much was actually written. And you can read into an allocated block and see how much you actually received.

from zynq-xdma.

bmartini commented on August 22, 2024

I'll see about integrating a return for the xdma_start_transfer. However, it will most likely be after Christmas as I'm about to go on holiday.

If you use XDMA_WAIT_NONE in the transaction the function call will be non-blocking while all others are blocking. In the demo I don't bother waiting because, as you guessed, the print statements slow down the reading so much that the transfer will be done before I finish reading the map.

As I explained in my last comment, in my project I use the XDMA_WAIT_NONE and then a AXI Lite register (which I poll) to check to see if the transfer is done. That lets me start up a number of transactions on different DMA Devices which can then run in parallel. I then move on when one or all the transfers are done, as indicated by the AXI Lite register.

Having the AXI-Streams as character devices defeats the purpose of DMA, the point of which is to move data into and out of the PL without getting the ARM/Linux involved, except to initiate the transfer. Writing to a character device is the exact opposite of DMA. If you want to use a char dev to move data into and out of the PL it can be done using the AXI Lite or AXI Burst ports. It will, however, be much, much slower then DMA.

from zynq-xdma.

vanmierlo commented on August 22, 2024

I will also be on holidays the coming weeks, so no worry there.

I find it weird to check the completion of the DMA transfer on a different interface from the one starting it. I think the driver is missing a function to check for the completion.

I also don't quite see how a character device defeats the purpose of the DMA. I understand that it requires contiguous memory and that this must remain allocated after the call to start the transfer when not waiting for completion. But IMHO the DMA is very useful as a way to make a much faster transfer whilst releasing CPU resources for other threads. I've tried the AXI-Lite and AXI-Burst ports and I find their throughput lacking to say the least. But what I was mainly saying was I prefer the behaviour of file write and read as I was describing.

from zynq-xdma.

bmartini commented on August 22, 2024

What you must remember is that this because this driver is for an FPGA it
would be impossible to implement an interface that handles ever conceivable
use case because every user of the DMA is different. As such the interface
this driver provides is simple but still provides great flexibly. This
makes it easy to integrate into a larger whole; a whole which will most
likely have over drivers for accessing the other components.

If you want to make a library that has 'read' and 'write' and uses a DMA
'file discripter' it would be fairly easy. But a char device that you can
'cat' or 'echo' to would require the kernel to copy data into kernel space
which is not what you want when you do DMA.
On Dec 15, 2013 4:13 AM, "vanmierlo" [email protected] wrote:

I will also be on holidays the coming weeks, so no worry there.

I find it weird to check the completion of the DMA transfer on a different
interface from the one starting it. I think the driver is missing a
function to check for the completion.

I also don't quite see how a character device defeats the purpose of the
DMA. I understand that it requires contiguous memory and that this must
remain allocated after the call to start the transfer when not waiting for
completion. But IMHO the DMA is very useful as a way to make a much faster
transfer whilst releasing CPU resources for other threads. I've tried the
AXI-Lite and AXI-Burst ports and I find their throughput lacking to say the
least. But what I was mainly saying was I prefer the behaviour of file
write and read as I was describing.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-30601564
.

from zynq-xdma.

vanmierlo commented on August 22, 2024

Hello again,

First my best wishes for this year.

I am back to trying to get the DMA stream working and I'm looking into getting the actual received length to the user.

While examining the code I wondered about the variable cookie in xdma_prep_buffer() in xdma.c. It is located on stack yet at the end of the function its address is taken and returned in buf_info. Isn't that a dangerous thing to do? Even if the pointer is never dereferenced it does not guarantee uniqueness either. Is this a bug waiting to be triggered?

Maarten

from zynq-xdma.

bmartini commented on August 22, 2024

Thanks for catching that as it was a bug. I've fixed it and pushed it so if you want to look it over to make sure its right it would be much appreciated.

Berin

from zynq-xdma.

trevdawg122 commented on August 22, 2024

Hi. I'm trying to use the zynq-xdma driver and I'm having one of the problems described above. When I try to load the xdma.ko module using insmod, I get the following error:
Error: allocating dma memory failed
I’ve included the libxdma.h/so files, added cma=64M to the device tree bootargs, and added CONFIG_CMA=y and CONFIG_CMA_DEBUG=y to the kernel config file, but the failure persists. We're using linux-xlnx kernel version (tag) xilinx-v2014.4-trd and the latest zynq-xdma driver commit c869423 on Feb 12, 2015. Below is our device tree dma node:

axi_dma_0: dma@40400000 {
compatible = "xlnx,axi-dma";
interrupt-parent = <&intc>;
interrupts = <0 30 4>;
reg = <0x40400000 0x1000>;
xlnx,include-sg ;
dma-channel@40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
interrupts = <0 30 4>;
xlnx,datawidth = <0x40>;
xlnx,device-id = <0x0>;
};
};

Thanks,
Trevor

from zynq-xdma.

hussein-alasadi commented on August 22, 2024

Hi there,

Most probably CMA is still not enabled.

Not sure what the CONFIG_ variables are called, however in kconfig (console menu) the options to enable are:

Kernel Features -> Contiguous Memory Allocator
Device Drivers -> Generic Driver Options -> DMA contiguous Memory Allocator

Regards

From: trevdawg122 [mailto:[email protected]]
Sent: Tuesday, March 22, 2016 9:41 PM
To: bmartini/zynq-xdma [email protected]
Subject: Re: [zynq-xdma] broken (#1)

Hi. I'm trying to use the zynq-xdma driver and I'm having one of the problems described above. When I try to load the xdma.ko module using insmod, I get the following error:
Error: allocating dma memory failed
I’ve included the libxdma.h/so files, added cma=64M to the device tree bootargs, and added CONFIG_CMA=y and CONFIG_CMA_DEBUG=y to the kernel config file, but the failure persists. We're using linux-xlnx kernel version (tag) xilinx-v2014.4-trd and the latest zynq-xdma driver commit c869423c869423 on Feb 12, 2015. Below is our device tree dma node:

axi_dma_0: dma@4040000https://github.com/dma/zynq-xdma/commit/40400000 {
compatible = "xlnx,axi-dma";
interrupt-parent = <&intc>;
interrupts = <0 30 4>;
reg = <0x40400000 0x1000>;
xlnx,include-sg ;
dma-channel@4040003https://github.com/dma-channel/zynq-xdma/commit/40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
interrupts = <0 30 4>;
xlnx,datawidth = <0x40>;
xlnx,device-id = <0x0>;
};
};

Thanks,
Trevor

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-200013761

from zynq-xdma.

trevdawg122 commented on August 22, 2024

I did see that earlier in this discussion. CMA is enabled in the kernel configuration so that is not a problem.

from zynq-xdma.

hussein-alasadi commented on August 22, 2024

Are you sure its enabled in both places?

Unfortunately I don’t have my .config file now to give you the exact options. However from the menu structure it needs to be ticked in two separate entries. See earlier post.

Regards
From: trevdawg122 [mailto:[email protected]]
Sent: Tuesday, March 22, 2016 11:55 PM
To: bmartini/zynq-xdma [email protected]
Cc: Hussein Alasadi [email protected]
Subject: Re: [zynq-xdma] broken (#1)

I did see that earlier in this discussion. CMA is enabled in the kernel configuration so that is not a problem.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-200068737

from zynq-xdma.

trevdawg122 commented on August 22, 2024

I ensured both were enabled and I still get the same error:
Error: allocating dma memory failed

from zynq-xdma.

trevdawg122 commented on August 22, 2024

Update: I found that the device tree bootargs were being overwritten by u-boot. Adding cma=64MB to the u-boot arguments allowed us to insmod the xdma driver successfully. Thanks for the help.

from zynq-xdma.

elmohandis commented on August 22, 2024

I didn't reply further since I was quite sure it just wasn’t enabled. Didn't think of the bootargs though. Good catch.

from zynq-xdma.

luntik2012 commented on August 22, 2024

Hi, I have a similar issue:

#file libxdma.so 
libxdma.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=2dad92d666eca23693d6fc1e62810708c1189b5d, not stripped

root@zc702-zynq7:~# insmod /lib/modules/3.19.0-xilinx/kernel/drivers/dma/xilinx/
xilinx_axidma.ko 
[  109.383614] xilinx-dma 40400000.ps7-axidma: Probing xilinx axi dma engine...Successful
root@zc702-zynq7:~# insmod /lib/modules/3.19.0-xilinx/extra/xdma.ko 
[  124.815731] Hello World!
[  124.818457] <xdma> Error: allocating dma memory failed
insmod: can't insert '/lib/modules/3.19.0-xilinx/extra/xdma.ko': Cannot allocate memory
root@zc702-zynq7:~# insmod /lib/modules/3.19.0-xilinx/extra/xdma.ko 
[  127.461327] Hello World!
[  127.463810] ------------[ cut here ]------------
[  127.468453] WARNING: CPU: 1 PID: 785 at /media/nick/garbage/opoky/poky/build/tmp/work-shared/zc702-zynq7/kernel-source/fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x70()
[  127.482986] sysfs: cannot create duplicate filename '/class/xdma'
[  127.489066] Modules linked in: xdma(O+) xilinx_axidma
[  127.494086] CPU: 1 PID: 785 Comm: insmod Tainted: G           O   3.19.0-xilinx #2
[  127.501657] Hardware name: Xilinx Zynq Platform
[  127.506187] [<c0014c08>] (unwind_backtrace) from [<c0011878>] (show_stack+0x10/0x14)
[  127.513887] [<c0011878>] (show_stack) from [<c043dbf4>] (dump_stack+0x88/0xc8)
[  127.521129] [<c043dbf4>] (dump_stack) from [<c00229cc>] (warn_slowpath_common+0x80/0xb0)
[  127.529173] [<c00229cc>] (warn_slowpath_common) from [<c0022a2c>] (warn_slowpath_fmt+0x30/0x40)
[  127.537867] [<c0022a2c>] (warn_slowpath_fmt) from [<c01333e4>] (sysfs_warn_dup+0x60/0x70)
[  127.546018] [<c01333e4>] (sysfs_warn_dup) from [<c013347c>] (sysfs_create_dir_ns+0x88/0x98)
[  127.554331] [<c013347c>] (sysfs_create_dir_ns) from [<c02124bc>] (kobject_add_internal+0xa0/0x2f8)
[  127.563300] [<c02124bc>] (kobject_add_internal) from [<c0212858>] (kset_register+0x50/0x7c)
[  127.571622] [<c0212858>] (kset_register) from [<c02718f0>] (__class_register+0xc8/0x1bc)
[  127.579701] [<c02718f0>] (__class_register) from [<c0271a2c>] (__class_create+0x48/0x74)
[  127.587769] [<c0271a2c>] (__class_create) from [<bf00ab94>] (init_module+0x6c/0x29c [xdma])
[  127.596116] [<bf00ab94>] (init_module [xdma]) from [<c00088f0>] (do_one_initcall+0x8c/0x1d4)
[  127.604503] [<c00088f0>] (do_one_initcall) from [<c00822c0>] (load_module+0x1a7c/0x20e4)
[  127.612600] [<c00822c0>] (load_module) from [<c0082a20>] (SyS_init_module+0xf8/0x104)
[  127.620398] [<c0082a20>] (SyS_init_module) from [<c000e5e0>] (ret_fast_syscall+0x0/0x34)
[  127.628467] ---[ end trace c6c8013d52113977 ]---
[  127.633047] ------------[ cut here ]------------
[  127.637678] WARNING: CPU: 1 PID: 785 at /media/nick/garbage/opoky/poky/build/tmp/work-shared/zc702-zynq7/kernel-source/lib/kobject.c:240 kobject_add_internal+0x280/0x2f8()
[  127.652940] kobject_add_internal failed for xdma with -EEXIST, don't try to register things with the same name in the same directory.
[  127.664919] Modules linked in: xdma(O+) xilinx_axidma
[  127.669942] CPU: 1 PID: 785 Comm: insmod Tainted: G        W  O   3.19.0-xilinx #2
[  127.677507] Hardware name: Xilinx Zynq Platform
[  127.682019] [<c0014c08>] (unwind_backtrace) from [<c0011878>] (show_stack+0x10/0x14)
[  127.689764] [<c0011878>] (show_stack) from [<c043dbf4>] (dump_stack+0x88/0xc8)
[  127.696962] [<c043dbf4>] (dump_stack) from [<c00229cc>] (warn_slowpath_common+0x80/0xb0)
[  127.705035] [<c00229cc>] (warn_slowpath_common) from [<c0022a2c>] (warn_slowpath_fmt+0x30/0x40)
[  127.713694] [<c0022a2c>] (warn_slowpath_fmt) from [<c021269c>] (kobject_add_internal+0x280/0x2f8)
[  127.722566] [<c021269c>] (kobject_add_internal) from [<c0212858>] (kset_register+0x50/0x7c)
[  127.730903] [<c0212858>] (kset_register) from [<c02718f0>] (__class_register+0xc8/0x1bc)
[  127.738974] [<c02718f0>] (__class_register) from [<c0271a2c>] (__class_create+0x48/0x74)
[  127.747050] [<c0271a2c>] (__class_create) from [<bf00ab94>] (init_module+0x6c/0x29c [xdma])
[  127.755393] [<bf00ab94>] (init_module [xdma]) from [<c00088f0>] (do_one_initcall+0x8c/0x1d4)
[  127.763778] [<c00088f0>] (do_one_initcall) from [<c00822c0>] (load_module+0x1a7c/0x20e4)
[  127.771877] [<c00822c0>] (load_module) from [<c0082a20>] (SyS_init_module+0xf8/0x104)
[  127.779679] [<c0082a20>] (SyS_init_module) from [<c000e5e0>] (ret_fast_syscall+0x0/0x34)
[  127.787748] ---[ end trace c6c8013d52113978 ]---
[  127.792334] <xdma> Error: allocating dma memory failed
insmod: can't insert '/lib/modules/3.19.0-xilinx/extra/xdma.ko': Cannot allocate memory

Parts from my kernel config:

CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
CONFIG_CMA_AREAS=7
...
CONFIG_DMA_CMA=y

#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=16
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8

from zynq-xdma.

vanmierlo commented on August 22, 2024

CONFIG_CMA_SIZE_MBYTES=16

Did you change the DMA_LENGTH as well?

xdma.h:
#define DMA_LENGTH (3210241024)

from zynq-xdma.

luntik2012 commented on August 22, 2024

I've recompiled kernel with CONFIG_CMA_SIZE_MBYTES=32 and recompiled xdma driver.
I still have the same error.

My .dts part:

axi_dma_0: axi-dma@40400000 {
                    axistream-connected = <&axi_dma_0>;
                    axistream-control-connected = <&axi_dma_0>;
                    compatible = "xlnx,axi-dma";
                    interrupt-parent = <&ps7_scugic_0>;
                    //interrupts = < 0 59 4 0 58 4 >;
                    interrupts = < 0 58 4 >;
                    reg = < 0x40400000 0x10000 >;
                    xlnx,dlytmr-resolution = <0x7d>;
                    xlnx,enable-multi-channel = <0x0>;
                    xlnx,family = "zynq";
                    xlnx,generic = <0x0>;
                    xlnx,include-s2mm = <0x1>;
                    xlnx,include-s2mm-dre = <0x0>;
                    xlnx,include-s2mm-sf = <0x1>;
                    xlnx,include-sg = <0x0>;
                    xlnx,instance = "axi_dma_0";
                    xlnx,num-s2mm-channels = <0x1>;
                    xlnx,prmry-is-aclk-async = <0x0>;
                    xlnx,s2mm-burst-size = <0x10>;
                    xlnx,sg-include-desc-queue = <0x0>;
                    xlnx,sg-include-stscntrl-strm = <0x0>;
                    xlnx,sg-length-width = <0xe>;
                    xlnx,sg-use-stsapp-length = <0x1>;
                    dma-channel@40400030 {
                        compatible = "xlnx,axi-dma-s2mm-channel";
                        xlnx,include-dre = <0x0>;
                        xlnx,datawidth = <0x20>;
                        xlnx,device-id = <0x1>;
                        interrupts = <0 58 4 >;
                    };
                };

I have no mm2s parts because I've one direction s2mm device on fpga
dmesg says

[    0.000000] cma: dma_contiguous_reserve(limit ffffffff)
[    0.000000] cma: dma_contiguous_reserve: reserving 32 MiB for global area
[    0.000000] cma: cma_declare_contiguous(size 0x02000000, base 0x00000000, limit 0xffffffff alignment 0x00000000)
[    0.000000] cma: Reserved 32 MiB at 0x3e000000
[    0.000000] Memory: 1000104K/1048576K available (4457K kernel code, 235K rwdata, 1404K rodata, 224K init, 199K bss, 15704K reserved, 32768K cma-reserved, 237568K highmem)
...
[    0.247590] cma: cma_alloc(cma c065477c, count 64, align 6)
[    0.248379] cma: cma_alloc(): returned ef7b8000
[    0.249417] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    2.150699] cma: cma_alloc(cma c065477c, count 1, align 0)
[    2.150745] cma: cma_alloc(): returned ef7b8820
[    2.150789] cma: cma_alloc(cma c065477c, count 1, align 0)
[    2.150815] cma: cma_alloc(): returned ef7b8840
[    2.150851] cma: cma_alloc(cma c065477c, count 1, align 0)
[    2.150875] cma: cma_alloc(): returned ef7b8860
...
[   23.066648] cma: cma_alloc(cma c065477c, count 1, align 0)
[   23.066810] cma: cma_alloc(): returned ef7b88a0
[   23.066853] cma: cma_alloc(cma c065477c, count 1, align 0)
[   23.066882] cma: cma_alloc(): returned ef7b88c0
[   61.852643] xilinx-dma 40400000.axi-dma: Probing xilinx axi dma engine...Successful
[   73.826246] random: nonblocking pool is initialized
[   76.682066] Hello World!
[   76.684526] <xdma> init: registered
[   76.684802] cma: cma_alloc(cma c065477c, count 8192, align 8)
[   76.684817] cma: cma_alloc(): returned   (null)
[   76.684827] <xdma> Error: allocating dma memory failed

from zynq-xdma.

vanmierlo commented on August 22, 2024

Maybe there are other drivers that use CMA? Maybe you cannot allocate exactly as much as is reserved for CMA? It is very well possible that the allocator needs some space in there as well for administrative purposes.

from zynq-xdma.

luntik2012 commented on August 22, 2024

I've set CONFIG_CMA_SIZE_MBYTES=128 and #define DMA_LENGTH (128_1024_1024)

dmesg says the same except

[    0.000000] cma: dma_contiguous_reserve: reserving 128 MiB for global area
[    0.000000] cma: cma_declare_contiguous(size 0x08000000, base 0x00000000, limit 0xffffffff alignment 0x00000000)
[    0.000000] cma: Reserved 128 MiB at 0x38000000
[    0.000000] Memory: 901816K/1048576K available (4445K kernel code, 234K rwdata, 1400K rodata, 224K init, 199K bss, 15688K reserved, 131072K cma-reserved, 139264K highmem)
[    0.252148] cma: cma_alloc(cma c06506fc, count 64, align 6)
[    0.252936] cma: cma_alloc(): returned ef6f8000
[    2.140635] cma: cma_alloc(cma c06506fc, count 1, align 0)
[    2.140741] cma: cma_alloc(): returned ef6f8800
...

I also cannot find in my kernel config, modules.buitin or somewhere else modules that can use CMA. I think I've disabled everything unnecessary. I have 1GB RAM so I can try set CMA size 512, but I think there is enough memory

from zynq-xdma.

luntik2012 commented on August 22, 2024

Ok. It seems I cannot allocate size defined in CONFIG_CMA_SIZE_MBYTES.
I've set it to 128 and successfully allocated 32MB of memory.

from zynq-xdma.

luntik2012 commented on August 22, 2024

Now I have this. Buffer is the same as before transfer, no data from my fpga axidma device.
No errors at all.
BTW I've commented out all TX part, so only RX(s2mm) code exists.

Any suggestions?

# dmesg
[  304.041300] <xdma> file: open()
[  304.041328] <xdma> ioctl: XDMA_TEST_TRANSFER
[  304.041832] <xdma> test: rx buffer before transmit:
[  304.041839] Y        Y       Y       Y       Y       Y       Y       Y       Y       Y
[  304.059748] <xdma> test: xdma_start_transfer rx
[  304.059759] <xdma> test: time to prepare DMA channels [us]: 11854
[  304.059773] <xdma> test: DMA transfer time [us]: 6
[  304.059782] <xdma> test: DMA bytes sent: 1048576
[  304.059790] <xdma> test: DMA speed in Mbytes/s: 174762
[  304.059797] <xdma> test: rx buffer after transmit:
[  304.059804] Y        Y       Y       Y       Y       Y       Y       Y       Y       Y
[  304.063138] <xdma> file: close()

# cat /proc/interrupts | grep dma
176:          0          0       GIC  61  xilinx-dma-controller

from zynq-xdma.

broken about zynq-xdma HOT 40 CLOSED

Comments (40)

Related Issues (10)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent