04-26-2019 07:34 AM
I'm attempting to use ADMA2 with command 53 to transfer data between my Zynq-7000 and an SDIO device, but the memory is not accessed or changed by the ADMA. The data on the DAT lines can be seen to be correct using an oscilloscope and the status register indicates that the command and transaction both complete. The ADMA address register is incremented by 4, suggesting that the descriptor table has been read and no ADMA error flags are raised. My code is written to follow the procedure set out in TRM section 13.3.4 Using ADMA2 and I'm using the XSdPs_SetupADMA2DescTbl function to prepare the descriptor table.
The same hardware can be used to access an SD memory card using the default xsdps code and xilffs libraries, so it appears that the ADMA2 works correctly with command 24 and 25. If the transfer function is changed to follow the procedure in TRM section 13.3.2 Data Transfers Without DMA, then the Data Port register can be read or written to directly.
I've tried changing the alignment of both my tranfer descriptor table and target memory, and I've tried putting them both in both cached and uncached memory regions.
What might I have missed that is causing the ADMA2 to do everything apart from move the data?
05-03-2019 03:35 PM - edited 05-03-2019 03:36 PM
Hi, I too have the same exact issue going on. It is happening with 2018.2 PetaLinux running on a ZU3EG part trying to talk to a Microchip WILC3000 SDIO wifi card. I will update here if we make any progress. Please update as well if you figure it out.
05-21-2019 03:44 AM
No real progress for me, but I have managed to get a TI WL1837MODCOMBI card to work with 2018.3 PetaLinux on a Avnet MicroZed board. I've never done any Linux development before, so it has taken me quite some time to get to this point. I don't know whether this is truely representative of my target hardware, but it is fairly close, and it does demonstrate that the silicon is capable of doing it. I've not really learned as much from the exercise as I had hoped, because all of the peripheral access code is abstracted and hidden behind the ARM device tree layer and it's not easy to follow an execution path through the various layers of code.
I've attached the JTag debugger and inspected the content of the SD peripheral registers, and they match the register values generated by my bare-metal code, with some minor differences due to different CMD53 arguments. There may be a bit in one of the registers that I've missed, but I can see it.
The Transfer Descriptor List passed to the ADMA in the PetaLinux version is subtly different, but adding a NOP descriptor to mark the end has not fixed the problem.
05-24-2019 04:36 PM - edited 05-24-2019 04:37 PM
Hi, The issue for me was that the wifi driver was trying to share its memory (local stack variable) with another driver (arasan mmc/sdio driver). The way the mmu was setup with PetaLinux it would not allow it to work. The fix was to kmalloc the memory that needed to be shared. In this case the driver was not written to be compatible with the aarch64 2018.x version of PetaLinux.