Forum Discussion
14 Replies
- Altera_Forum
Honored Contributor
Hi Tomek,
I'm doing very similar thing as You do. My recommendation is definitely the mSGDMA. The source DMA is configured as "Memory-mapped to Streaming", the Sink DMA is configured as "Streaming to Memory Mapped". In between You implement your processing functions. I use standard ST-Packets to mark Image start and stop. I use also reserved memory which I define in device tree file and use for DMA transfers. This is because DMA needs physical address which is hard to get in Linux without implementing kernel modules. If you have reserved memory You can mmap this and access it from HPS ARM processor via virtual adress and give the physical adress in DMA descriptors. Enable "burst mode" to have higher performance. I'm not using IRQ based response channel in DMA, I'm counting symbols which are coming into sink DMA and read them out using Memory mapped PIO component. I also have compiled/ported some of the NIOS code of the software layer for creating the DMA descriptors for MSGDMA and schedule sync transfers. - Altera_Forum
Honored Contributor
Important question... I based my design on the DE1_SOC_Linux_FB demonstration. Should I generate and compile new preloader when i added two msgdmas and SDRAM controller?
- Altera_Forum
Honored Contributor
As a general rule of thumb any time the Qsys system changes I would get into a habit of regenerating the preloader. I don't think it'll make a difference here since the preloader doesn't know anything about FPGA DMAs but you don't want to face a hardware + software mismatch getting into a habit of using the same preloader across multiple generated Qsys systems.
- Altera_Forum
Honored Contributor
Hi Alex,
Can you show me how you connected signals in qsys? How to reserve memory? And how to start dma from c code?