On Wed, Feb 10, 2021 at 05:08:01PM +0800, Bin Meng wrote: > On Tue, Feb 9, 2021 at 10:30 AM Bin Meng <bmeng...@gmail.com> wrote: > > > > Hi Edgar, > > > > On Mon, Feb 8, 2021 at 11:17 PM Edgar E. Iglesias > > <edgar.igles...@gmail.com> wrote: > > > > > > > > > > > > On Mon, Feb 8, 2021 at 3:45 PM Bin Meng <bmeng...@gmail.com> wrote: > > >> > > >> Hi Edgar, > > >> > > >> On Mon, Feb 8, 2021 at 10:34 PM Edgar E. Iglesias > > >> <edgar.igles...@gmail.com> wrote: > > >> > > > >> > > > >> > > > >> > On Mon, 8 Feb 2021, 15:10 Bin Meng, <bmeng...@gmail.com> wrote: > > >> >> > > >> >> 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. > > >> > > > >> > > > >> > Yes, it's a separate module. > > >> > > > >> >> > > >> >> > 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? > > >> > > > >> > > > >> > > > >> > Because it matches real hw and this particular dma exists in various > > >> > instances, not only in qspi. We don't want duplicate implementations > > >> > of the same dma. > > >> > > > >> > > >> Would you please share more details, like what other peripherals are > > >> using this same DMA model? > > >> > > > > > > It's used by the Crypto blocks (SHA, AES) and by the bitstream > > > programming blocks on the ZynqMP. > > > In Versal there's the same plus some additional uses of this DMA... > > > > Sigh, it's not obvious from the ZynqMP datasheet. Indeed the crypto > > blocks seem to be using the same IP that QSPI uses for its DMA mode. > > With that additional information, I agree modeling the DMA as a > > separate model makes sense. > > > > Will investigate the Xilinx fork, and report back. > > Unfortunately the Xilinx fork of QEMU does not boot VxWorks. It looks > like the fork has quite a lot of difference from the upstream QEMU. > For example, the fork has a new machine name for ZynqMP which does not > exist in the upstream. It seems quite a lot has not been upstreamed > yet, sigh. > > The CSU DMA model in the Xilinx fork seems to be quite complicated and > has lots of functionalities. However right now our goal is to > implement a minimum model that could be used to work with the GQSPI > model to make the QSPI DMA functionality work. > We implemented a basic CSU DMA model based on the Xilinx fork, and > will send it as v3 soon. >
We've prepared a patch with the QSPI DMA support using the complete DMA model. We'll send that out soon. It's better if you base your work on that. Cheers, Edgar
