At Fri, 28 May 2021 10:21:11 -0700 (PDT) [email protected] wrote:
> > I'm confused because I thought the plan was Remote Proc going forward. Do > you seem to say it is UIO going forward? Only that the *stock* mainline kernels don't have Remote Proc support. I guess TI has not gotten around to porting things yet or the kernel builder devs have not built the 5.x kernels with Remote Proc: from /boot/config-4.19.94-ti-r42: # # Rpmsg drivers # CONFIG_RPMSG=y # CONFIG_RPMSG_CHAR is not set # CONFIG_RPMSG_QCOM_GLINK_RPM is not set CONFIG_RPMSG_VIRTIO=m CONFIG_RPMSG_RPC=m CONFIG_RPMSG_PRU=m # # Rpmsg virtual device drivers # CONFIG_RPMSG_KDRV=y CONFIG_RPMSG_KDRV_DISPLAY=y CONFIG_RPMSG_KDRV_ETH_SWITCH=m from /boot/config-5.4.102-bone45: # # Rpmsg drivers # CONFIG_RPMSG=m CONFIG_RPMSG_CHAR=m # CONFIG_RPMSG_QCOM_GLINK_RPM is not set CONFIG_RPMSG_VIRTIO=m # end of Rpmsg drivers > > On Friday, May 28, 2021 at 12:15:34 PM UTC-5 [email protected] wrote: > > > At Fri, 28 May 2021 12:59:20 -0400 [email protected] wrote: > > > > > > > > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in > > > gmane.comp.hardware.beagleboard.user Bruce Chidester > > > <[email protected]> wrote: > > > > > > >I am using BBB Revision C > > > > > > > >Please help me get clarity on my assumptions that I believe I have > > learned > > > >so far and tell me where I am incorrect: > > > > > > Can't confirm for everything, but... > > > > > > > >1. There are 2 architectures to interact with the PRU's. They are *UIO* > > and > > > >*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt > > file. > > > >You cannot run both at the same time. > > > > > > TRUE -- but maybe not "easily"; there are some dependencies upon the > > > kernel version loaded. > > > > YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc. > > > > > > > > TI has deprecated UIO and considers RemoteProc to be the route for > > > future usage (it is not tied to just the PRUs, it should work with the > > DSP > > > chips on the BB AI, et al.). > > > > I think the mainline kernels don't have the RemoteProc kernel code. At > > least > > by default. > > > > > > > > > > > > >2. When using RemoteProc you can *send* a remote message to the PRU and > > > >this solution *does not work* with UIO. > > > > > > RPMsg supports sending message in both directions > > > > > https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html > > > """ > > > There are two vrings provided per PRU core, one vring is used for > > messages > > > passed to the ARM and the other vring is used for messages received from > > > the ARM. System level mailboxes are used to notify cores (ARM or PRU) > > when > > > new messages are waiting in the shared buffers. > > > """ > > > > > > > > > > >3. When using UIO the PRU can *send* an Interrupt to the host code but > > > >RemoteProc *cannot*. > > > > > > > >4. When using UIO, you *cannot* send an interrupt to the PRU, you need > > to > > > >create some other solution maybe through shared memory. > > > > > > > > > > As the PRUs do not have what I would call true interrupts (they have a > > > set of "interrupt bits" but do NOT interrupt the processor, the bits have > > > to be polled, and appropriate handlers called) any talk of interrupts is > > > vague. > > > > > > However, for RPMsg, the "mailbox" provides, I believe, some form of > > > blocked wait or maybe use of a select() call to test for mailbox data. I > > > don't really know what a "Kick" entails in: > > > """ > > > ARM Host Steps > > > Step 1a: Allocate a new buffer -or- > > > Step 1b: Get a Used buffer from the slave Vring > > > Step 2: Copy data to be transferred into the buffer from Step 1 > > > Step 3: Add the newly filled buffer to the Available list in the > > > slave Vring > > > Step 4: Kick the slave Vring by writing its index (1) into a > > > message in Mailbox 2 > > > PRU Steps > > > Step 5: A Kick is discovered in Mailbox 2 with the index of the > > > Kicked Vring (1). This indicates to the PRU that data is available for > > > receive > > > Step 6: Get the Available buffer from the slave Vring > > > Step 7: Copy data to be received out of the buffer from Step 2 > > > Step 8: Add the now empty buffer to the Used list in the slave > > > Vring > > > Step 9: Kick the slave Vring by writing its index (1) into a > > > message in Mailbox 3 > > > """ > > > Step five appears to be a polling loop on the mailbox. > > > > > > > > > > > > > > > > -- > > Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 > > <(978)%20633-5364> > > Deepwoods Software -- Custom Software Services > > http://www.deepsoft.com/ -- Linux Administration Services > > [email protected] -- Webhosting Services > > > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services [email protected] -- Webhosting Services -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/20210528173739.9BC31223D67%40sharky4.deepsoft.com.
