Using the driver with Petalinux
LucasKl opened this issue · 44 comments
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.
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 --enableNext, 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.cThen, 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).oFinally, 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-axidmaThe 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.
Did that end up working for you?
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!
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,
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,
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.
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.
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:
-
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. -
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 ;
};
};
};
};
- 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)
-
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. -
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
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
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?
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.
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.
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?
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.
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.
Sorry, crossover. I will test your code and let you know.
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:~#
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.
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.
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
Awesome, great to know! And no problemo, I'm glad to hear that the issue has been resolved.
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?
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 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.
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!
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.
Thanks for the neat and clear set of instructions! Was a breeze to compile your module with petalinux, and use the user space library :)
No problem, glad to hear it was a smooth process for you.
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.
@18829212662 upload your dmesg log
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.
use a fifo loop to rewrite your pics data back to ps ddr
@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
@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.
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 {
...
};
};
...
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
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 :)
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?
@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
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.
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
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