Dennis, Thanks for your response.
When developing with the UIO architecture, they use the term "interrupt", so I assume they meant it somehow, but not willing to die on that hill. I could not get any form of "what they called interrupt" to work the remote proc architecture. I tried, and tried, and tried. If that solution exists I would greatly appreciate it. The bi-directional note is correct about messaging, I was trying to emphasize that UIO cannot do messaging. Your willingness to get in the mud with my issues is appreciated. On Friday, May 28, 2021 at 11:59:35 AM UTC-5 Dennis Bieber wrote: > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Bruce Chidester > <brucechidester-re5...@public.gmane.org> 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. > > 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.). > > > > >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. > > > > > -- > Dennis L Bieber > > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2ee64ff3-f998-443f-9b44-0e06b371abb5n%40googlegroups.com.
