Hi, yf Yes, in some scenarios, we do not need the Remoteproc to manage the remote core lifecycle. (e.g, the remote core is startup automatically and we do not want to stop/restart remote core)
So we do not need the remoteproc, and the remoteproc in rptun may appear redundant. Actually, we are also working on a standalone Rpmsg Virtio transport in NuttX (new file in nuttx/drivers/rpmsg/rpmsg_virtio.c), we want this new rpmsg virtio transport only call the rpmsg virtio related API in OpenAMP (not be coupled with OpenAMP.RemoteProc), then we can achieve smaller footprint and maybe fater intialization speed. OpenAMP community has similar discussions: rpmsg without remoteproc? · OpenAMP/open-amp · Discussion #275 (github.com)<https://github.com/OpenAMP/open-amp/discussions/275> And Rpmsg-Lite is a lightweight implementation of the Remote Processor Messaging (RPMsg) protocol (No remoteproc): nxp-mcuxpresso/rpmsg-lite: RPMsg implementation for small MCUs (github.com)<https://github.com/nxp-mcuxpresso/rpmsg-lite> ________________________________ Bowen Wang, wangbow...@xiaomi.com From: yfliu2008<mailto:yfliu2...@qq.com.INVALID> Date: 2024-01-26 18:32 To: dev<mailto:dev@nuttx.apache.org> Subject: [External Mail]Re:Re: RPTUN and RPMSG [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈 Xiang and Bowen, Thank you both the prompt explantions. Though still need time to get familiar with both rptun and rpmsg drivers in NuttX, I see that refactoring is ongoing currently to make rpmsg more independent. Meanwhile, one should still use rptun as the AMP bridge by preparing core-specific hooks and call rptun_initialize() during boot to enable AMP, right? Suppose the master and remote cores both can run NuttX, can we simply put the remote NuttX binary in ROMFS of the master NuttX then prepare rptun hooks and then leave the lifecycle details to rptun/openamp? Regards, yf Original From:"汪博文"< wangbow...@xiaomi.com.INVALID >; Date:2024/1/26 14:38 To:"yfliu2008"< yfliu2...@qq.com.INVALID >; CC:"dev"< dev@nuttx.apache.org >; Subject:Re: [External Mail]RPTUN and RPMSG Hi, yf NuttX.RPTUN abstracts the OpenAMP.RemoteProc and the OpenAMP.RpmsgVirtio NuttX.Rpmsg wraps the OpenAMP.Rpmsg and add more rpmsg api. I guess you want to ask whether Rpmsg can support different transport layer such as SPI/UART/I2C. Acctually, Rpmsg was designed to be compatible with different transport layer, and VirtIO is a very common transport, we call it Rpmsg VirtIO. And we are implementing the Rpmsg SPI/Uart Transport Layer in NuttX, we divide it to serveral steps: 1. NuttX.Rpmsg wrapper the OpenAMP.Rpmsg but the coupling between NuttX.Rpmsg and NuttX.Rptun (the wrapper of OpenAMP Rpmsg VirtIO and Remoteproc) is severe, so we decoupled the NuttX.Rpmsg and Nuttx.Rptun, here are some PRs: decoupling rptun ping and rptun_virtio_device, rptun ping and rptun. by wyr8899 · Pull Request #11537 · apache/nuttx (github.com) decoupling rptun ping and rptun_virtio_device, rptun ping and rptun. by wyr8899 · Pull Request #11537 · apache/nuttx (github.com) rptun: Strip rpmsg and rptun. Extract common rpmsg api in rptun.c to rpmsg.c, rpmsg provide rpmsg_ops to each backend for specific implementation. by wyr8899 · Pull Request #11536 · apache/nuttx (github.com) rpmsgfs: decoupling rpmsgfs server and rpmsg virtio. by wyr8899 · Pull Request #11591 · apache/nuttx (github.com) 2. Implement the Rpmsg SPI/UART Transport in NuttX, we has implemented the Rpmsg UART transport and verified in STM32 board in our internal Git, and the design and coding of Rpmsg SPI transport has been finished, we will upstream when they have been fully verified in some projects. 3. Implement the Rpmsg SPI/UART Transport in Linux, then the NuttX can communicate with Linux via Rpmsg VirtIO, Rpmsg Uart, Rpmsg SPI. ________________________________ Bowen Wang, wangbow...@xiaomi.com From: yfliu2008 Date: 2024-01-26 13:00 To: dev Subject: [External Mail]RPTUN and RPMSG Dear experts, I am wondering where we can find high level introduction about the RPTUN and RPMSG concepts in NuttX? I can't find explanations of the two NuttX drivers and their relationship with the two OpenAMP components "RemoteProc" and "RPMsg". Can we simply take that the "NuttX.RPTUN" abstracts the "OpenAMP.RemoteProc" and the "NuttX.RPMSG" wraps the "OpenAMP.RPMsg"? Can we also take that RPMSG models the communication channel between master and a remote core, like other master/slave buses such as SPI/I2C, thus various proxy drivers (like block, uart, syslog etc) for remote to use can be built on top of the RPMSG bus? Regards, yf #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/# #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
