Hi Edgar, On Mon, Feb 8, 2021 at 8:44 PM Edgar E. Iglesias <edgar.igles...@gmail.com> wrote: > > On Mon, Feb 08, 2021 at 01:25:24PM +0800, Bin Meng wrote: > > From: Xuzhou Cheng <xuzhou.ch...@windriver.com> > > > > ZynqMP QSPI supports SPI transfer using DMA mode, but currently this > > is unimplemented. When QSPI is programmed to use DMA mode, QEMU will > > crash. This is observed when testing VxWorks 7. > > > > Add a basic implementation of QSPI DMA functionality. > > > > Signed-off-by: Xuzhou Cheng <xuzhou.ch...@windriver.com> > > Signed-off-by: Bin Meng <bin.m...@windriver.com> > > + Francisco > > Hi, > > Like Peter commented on the previous version, the DMA unit is actully > separate.
Is it really separate? In the Xilinx ZynqMP datasheet, it's an integrated DMA unit dedicated for QSPI usage. IIUC, other modules on the ZynqMP SoC cannot use it to do any DMA transfer. To me this is no different like a DMA engine in a ethernet controller. > This module is better modelled by pushing data through the Stream framework > into the DMA. The DMA model is not upstream but can be found here: > https://github.com/Xilinx/qemu/blob/master/hw/dma/csu_stream_dma.c > What's the benefit of modeling it using the stream framework? > Feel free to send a patch to upstream with that model (perhaps changing > the filename to something more suitable, e.g xlnx-csu-stream-dma.c). > You can use --author="Edgar E. Iglesias <edgar.igles...@xilinx.com>". > Please, upstream all work Xilinx has done on QEMU. If you think the DMA support should really be using the Xilinx one, please do the upstream work as we are not familiar with that implementation. Currently we are having a hard time testing the upstream QEMU Xilinx QSPI model with either U-Boot or Linux. We cannot boot anything with upstream QEMU with the Xilinx ZynqMP model with the limited information from the internet. Instructions are needed. I also suggested to Francisco in another thread that the QEMU target guide for ZynqMP should be added to provide such information. > The DMA should be mapped to 0xFF0F0800 and IRQ 15. > > CC:d Francisco, he's going to publish some smoke-tests for this. > Regards, Bin
