Hello, I have been working on use of remoteproc and rmpsg for bootup and communication between A5 and M4 core on NXP Vybrid[1]. Currently we are using a hacked up rpmsg[2] implementation for Vybrid based on NXP's implementation in downstream kernel for iMX7. We also use remoteproc but currently only for booting the M4 core and would like to completely leverage remoteproc for booting and rpmsg communication instead of hacked up way, so we can also upstream this. For Vybrid, currently the internal On-chip RAM is being used for the vrings. Initially I tried with remoteproc, but Linux remoteproc allocates vrings in it's memory space with a call to dma_alloc_coherent. This does not work for Vybrid's case as even using RSC_VDEV, rproc_handle_vdev dynamically allocates using DMA API and completely ignores requested hardcoded addresses. On M4 side, we use FreeRTOS and openamp which has support for rpmsg and remoteproc. The comment with rproc_handle_vdev mentions to use RSC_DEVMEM to map the required da to physical address. Reading the comments along with fw_rsc_devmem and above, I am not clear on what the firmware resource table should be. If I want the known internal OCRAM addresses to be used, shall I specify da and pa same in firmware resource table while using RSC_DEVMEM? Am not exactly clear on how the vrings will be allocated and handled in this case. It seems to have calls to iommu while we have no iommu. There seems to have been patches for exactly this usecase of internal memories [3] using ioremap_nocache, but that seems to have never made it through? Thanks & Regards, Sanchayan. [1]. http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/vfxxx-controller/f-series/arm-cortex-a5-plus-cortex-m4-mpus-1.5-mb-sram-lcd-security-ethernet-l2-switch:VF6xx [2]. https://lkml.org/lkml/2016/1/6/182 [3]. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270534.html -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
