Re: Re:Re:Re: RPTUN and RPMSG
On Mon, Jan 29, 2024 at 2:13 PM yfliu2008 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 transpo
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)<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 con
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)<https://github.com/apache/nuttx/pull/11537> decoupling rptun ping and rptun_virtio_device, rptun ping and rptun. by wyr8899 · Pull Request #11537 · apache/nuttx (github.com)<https://github.com/apache/nuttx/pull/11537> 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)<https://github.com/apache/nuttx/pull/11536> rpmsgfs: decoupling rpmsgfs server and rpmsg virtio. by wyr8899 · Pull Request #11591 · apache/nuttx (github.com)<https://github.com/apache/nuttx/pull/11591> 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<mailto:yfliu2...@qq.com.INVALID> Date: 2024-01-26 13:00 To: dev<mailto:dev@nuttx.apache.org> 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!**/#
Re: RPTUN and RPMSG
On Fri, Jan 26, 2024 at 1:01 PM yfliu2008 wrote: > Dear experts, > > > > > I am wondering where we can find high level introduction about the RPTUN > and RPMSG concepts in NuttX? > > > 2022 online workshop has a introduction presentation: https://www.youtube.com/watch?v=6uehz3WQ0vU=211s > > > 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"? > > Yes, NuttX.RPTUN equals OpenAMP.RemoteProc, which implements many OpenAMP required functions, and defines a bunch of callbacks for customization. > > 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? > > Yes, we are working on this area to: 1. Decouple rpmsg from virtio 2. Implement new rpmsg transport(e.g. SPI, UART) Part of this work upstream recently, more will come soon: https://github.com/apache/nuttx/pulls?q=is%3Apr+author%3Awyr8899+ After we finish all work, all high level rpmsg driver/service(e.g. rpmsg syslog/uart/usrsock/fs...) will work for shared memory and spi/uart. > > > Regards, > yf
