On 10/03/16 13:43, Matthijs van Duin wrote:
> On 3 October 2016 at 12:08, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote:
>> What happens if you set ACNT to 2?
>
> content of dma descriptor after edma transfer for various combinations
> of destination offset and length (ACNT):
> 10 11 12 13 ff ff ff ff ff ff ff ff ff ff ff ff (off=0, len=1..4)
> 10 11 12 13 14 15 16 17 ff ff ff ff ff ff ff ff (off=0, len=5..8)
> 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f (off=0, len=9..16)
> 00 00 00 10 ff ff ff ff ff ff ff ff ff ff ff ff (off=3, len=1)
I bet that with off=2, len=2:
00 00 10 11 ff ff ff ff ff ff ff ff ff ff ff ff
> 00 00 00 10 11 12 13 10 ff ff ff ff ff ff ff ff (off=3, len=2..4)
^^
This is interesting
> 00 00 00 10 11 12 13 14 ff ff ff ff ff ff ff ff (off=3, len=5)
> 00 00 00 10 11 12 13 14 15 16 17 10 11 12 13 14 (off=3, len=6..8)
^^
This is also interesting
> 00 00 00 10 11 12 13 14 15 16 17 18 19 1a 1b 1c (off=3, len=9..13)
> ff ff ff ff 00 00 00 10 ff ff ff ff ff ff ff ff (off=7, len=1)
> 00 00 00 00 00 00 00 10 11 12 13 10 11 12 13 10 (off=7, len=2)
Thanks.
What happens of you do the copy from RAM to RAM? Does the data correct in that
case?
I guess if you change the offset in src it is behaving correctly?
But based on this nice table the access to the CPPI TX/RX buffer descriptor
memory via eDMA is only valid with 32bit aligned 32bit word access. All other
cases will corrupt data it should not touch.
>> There is no alignment restriction in eDMA.
>
> Yes and no. It supports arbitrary alignment, but the way in which it
> implemented this is not compatible with all targets. This is mostly
> something to beware of since a transfer may seem aligned if you
> consider only the target and not edma.
I checked again several eDMA3 documents and there is no word about alignment
restriction. I think it is up to the slave NIU how it is interpreting the
request 'to write 3 bytes to this address'. Probably the DDR2/3 NUI does it
right, but the CPPI descriptor memory translation is not?
>> There might be restriction on the L3/L4 boundary for the ethernet
>
> Nope, L3 error logs show the transfers already have these sizes when
> they traverse the L3. It might be possible that it's due to the
> interfacing of edma to the L3, I can't really make that distinction.
What is the error you see in logs?
>> How did you set up the DMA to do this? Can you paste the relevant code
>> snippets which does the request of the DMA channel, set up for the transfer, etc?
>
> Not easily. I use an old DM814x-based prototype board which is running
> a baremetal forth system I wrote which includes an edma-based memcpy
> command. It's extremely convenient for experimenting directly with
> hardware, which is why I still use it for such purposes even though we
> abandoned the DM814x.
Can you print out the paRAM used for the memcopy? Probably two examples so I
can see what are you changing between different runs.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
