Forum Discussion
Hi,
You may find the answers below:
A1:
Yes, you can check the mgrnonsecure, the default value should be secure state.
A2:
Yes, to be exact permodrst.dma.
A3:
Based on the ARM doc, the DMASEV is not related to the interrupts request signals.
By default the value should be in secure mode, so no, only if you need to test a non secure then you might need to set to bit to 1.
A4:
Yes they are.
A5:
Yes you are correct, issuing the DMAWFP is needed as you mentioned.
Hello,
thank you for your answers, but I need a more specific help now.
I tried Test_DMA_PL330_LKM - the code for building DMA programs and starting transactions works fine even from Linux userpace together with u-dma-buf kernel driver for allocating DMAble buffers.
This DMA program for reading 128B (= 16x 64bit) chunks of data from on-chip RAM works as expected:
DMAMOV SAR <source physical 32b address>
DMAMOV DAR <destination physical 32b address>
DMAMOV CCR SB16 SS64 DB16 DS64 ES64
DMALP <num_loops_of_128B_trans>
DMALD
DMAST
DMALPEND
DMAEND
But the interrupts still don't work.
I am clearing all 8 bits in the RSTMGR-PER2MODRST register during boot to enable FPGA request interfaces using this line in u-boot script:
mw.b 0xFFD05018 0x00
I don't know how to use the DMAWFP instruction properly. When I use this program, the channel gets stuck in the WFP state (ALT_DMA_CHANNEL_STATE_WFP) no matter how I toggle the f2h_dma_req0_req (burst) port in the fabric:
DMAMOV SAR <source physical 32b address>
DMAMOV DAR <destination physical 32b address>
DMAMOV CCR SB16 SS64 DB16 DS64 ES64
DMAFLUSHP P0
DMAWFP P0 burst
DMALP <num_loops_of_128B_trans - 1>
DMALDB
DMASTB
DMALPENDB
DMALDB
DMASTPB P0
DMAEND
(Here I understand P0 as the ALT_DMA_PERIPH_FPGA_0 ie. f2h_dma_req0 request.)
Thanks for any help.