-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zynq UltraScale+ (ARM Cortex-A53) #5
Comments
Thank you for the issue. Unfortunately, at the moment, I do not have ARM 64 so I have not confirmed its behavior. However, there is another hope from other people that you want udmabuf to work on ARM 64. I would like to follow hope as much as possible. Please wait a little more. Also, if you have any information, please let me know. |
I attempted to fix the problem that dma_alloc_coherent () fails on the ARM64 architecture. Unfortunately, since I am not yet ready for Zynq UltraScale +, I can not confirm whether compilation and execution succeed. Please wait a little more. Maybe it will be successful if you build with it. please try it. The branch is arm64-develop. I have not merged to the master branch yet.
|
Thank you for spending time on this issue. I try to compile the code on the branch. For ARM32, it works correctly (I insmod the module without problems). For ARM64, it fails at compilation time: The function pgprot_dmacoherent is only for ARM: I will try to figure out what you are trying to do and see if I can complete the porting. If you have comments about the differences between ARM32 and ARM64 implementations, please let me know. Finally, if you like to try remotely an ARM64 (ZynqMP), please let me know. |
Thank you for trying. The compile error that reported me is my mistake. Although it is an urgent action, I pushed the modified source. I think that I must study more about this subject. In ARM and ARM64, the bus configuration and DMA mapping are different. It seems that it will take some more time to fundamentally solve. |
I saw your latest changes. In the meantime, given this post: http://permalink.gmane.org/gmane.linux.kernel.commits.head/433710, I locally modified your code as the following snippet and it worked (I have still to properly verify it).
|
On ARM64, I am trying to allocate a 16MB contiguous buffer, but I get the following error:
Please, notice that I am using the latest revision (9092aff). Am I doing anything wrong? That should be possible because I have enabled the CMA module in the kernel and I have reserved (16MB). At kernel boot time I have the following log:
|
Please, note also that the same code compiled for ARM32 works:
while on ARM64, has problems:
I really appreciate your effort. |
Thank you for trying. The CMA buffer area used by udmabuf is shared with other devices. If other embedded devices have already allocated buffers from the CMA, the capacity available for that udmabuf will decrease. If you want to reserve 16 Mbytes with udmabuf, you will have to increase the capacity of CMA. The capacity that can be secured by CMA can be specified by the parameter at the time of starting the kernel. For example, if devicetree is specified as follows, the maximum number of bytes of CMA buffer can be changed to 128 Mbytes
Alternatively, when specifying parameters with u-boot, specify the capacity of CMA as follows.
|
udmabuf succeeded in securing the first buffer, but the second failed? Thank you for valuable information. |
This closes #27, courtesy of @sploet. This is based on the fix provided by issue ikwzm/udmabuf#5, in the [udmabuf](ikwzm/udmabuf) repository. The issue is that for AARCH64, all of the DMA functions require a non-NULL device as input. Additionally, a call to `of_dma_configure` is required.
This closes #27, courtesy of @sploet. This is based on the fix provided by issue ikwzm/udmabuf#5. The issue is that for AARCH64, all of the DMA functions require a non-NULL device as input. Additionally, a call to `of_dma_configure` is required.
I have released udmabuf v0.9.0 corresponding to ARM64. I am confirmed to work with UltraZed Starter Kit. I hope I can be of any help to you. |
I have released udmabuf v0.9.0 corresponding to ARM64. |
Hello, When I load the module, got the same error in this thread, using the Zynq Ultrascale+ A53 and Kernel 4.14.5: insmod udmabuf.ko udmabuf0=1000 Am I missing something? |
Thank you for trying. Have you tried v1.1.0? I confirmed the operation of udmabuf in the following environment. If you have not tried it yet, please try it. |
Thanks for your answer. I made a try now: git clone --depth=1 -b v1.1.0 https://github.com/ikwzm/udmabuf Set ARCH and CROSS_COMPILE in Makefile and type make. The output was the following: Building modules, stage 2. Then when I tried to load the module, got the same error: insmod udmabuf.ko udmabuf0=1000 The kernel log has the following output: Mar 20 15:25:12 linaro-gnome kernel: [ 1613.567894] dma_set_mask(DMA_BIT_MASK(32)) failed |
uum... I can not understand... It may not work on Linux Kernel 4.14. It is running on Linux Kernel 4.9. Can you allocate buffers from udmabuf using the device tree? |
I am sorry to have kept you waiting. |
Just to let you know. The udmabuf v1.2.0-rc1 can work with Linux Kernel 4.14 + ZynqMP. But I see this warning in compile time: |
Thank you for your reply. |
This closes #27, courtesy of @sploet. This is based on the fix provided by issue ikwzm/udmabuf#5. The issue is that for AARCH64, all of the DMA functions require a non-NULL device as input. Additionally, a call to `of_dma_configure` is required.
On a Xilinx Zynq UltraScale+ (CPU ARM Cortex-A53), I am running the Linux kernel 4.9-xilinx-v2017.2.
I know that both OS and CPU are not listed as supported, but --- hopefully --- the porting is easy.
For cross-compiling, I modified the Makefile:
ARCH := arm64
CROSS_COMPILE ?= aarch64-linux-gnu-
When I insmod the kernel driver, I get the following error:
# insmod udmabuf.ko udmabuf0=1024
[ 8554.453499] dma_alloc_coherent() failed
[ 8554.457374] udmabuf: couldn't create udmabuf0 driver
Can I fix the problem?
The text was updated successfully, but these errors were encountered: