On Mon, Jan 29, 2024 at 2:13 PM yfliu2008 <yfliu2...@qq.com.invalid> wrote:
> Bowen & Xiang, > > > > > I am considering to use RPTUN on K230 target, initally between the two > RISC-V cores. NuttX can run on both RISC-V cores with the help of U-Boot. I > browsed the "nrf53_rptun.c" and "sim_rptun.c" in NuttX repository, however > I can only run "sim_rptun" on Linux. > > > I still have a few questions as a RPTUN user: > > > > > Does RPTUN only support nodes running NuttX? we can't use RPTUN on a DSP > if it can't run NuttX, right? > Yes, RPTUN can't be used outside of NuttX. Please use OpenAMP or rpmsg-lite directly if you run other OS. > > Can a RPTUN master manage a baremetal remote? is there any existing > samples in the repo now for this case? > > You need reference OpenAMP, there are many examples. > > Can we use RPTUN without inter-processor-interruptions? I am wondering if > a minimum RPTUN implemtation can basically work without IPI, and can work > better when IPI us added? > You need an interrupt to trigger the remote core either through IPI, mailbox or doorbell, otherwise you have to poll the ring buffer periodically like sim, but it is very inefficient. > > Does RPTUN support loading of remote NuttX firmware? I didn't find how > "nrf5340-dk/rptun_cpuapp" manages the firmware of "rptun_cpunet" yet. But I > saw "sim/rpserver" can spawn the remote node as a host process. If there is > an existing RPTUN sample that shows loading remote firmware, please teach. > > Yes, RPTUN can support loading ELF to the remote core, we use this feature in some products, but no upstreaming project enables this feature yet. > Does RPTUN support NuttX in Kernel/Protected modes? If so, we can manage a > Flat remote from a Kernel master. It could be. Eero Nurkkala may use this configuration on risc-v/mpfs, but we haven't tried this configuration yet. > > > > > > Regards, > yf > > > > > > > > > Original > > > > From:"汪博文"< wangbow...@xiaomi.com.INVALID >; > > Date:2024/1/26 19:04 > > To:"yfliu2008"< yfliu2...@qq.com.INVALID >; > > CC:"dev"< dev@nuttx.apache.org >; > > Subject:Re: [External Mail]Re:Re: RPTUN and RPMSG > > > 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) > > 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 > ) > > ________________________________ > Bowen Wang, wangbow...@xiaomi.com > > From: yfliu2008 > Date: 2024-01-26 18:32 > To: dev > 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!******/#
