At Fri, 28 May 2021 12:59:20 -0400 beagleboard@googlegroups.com wrote: > > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Bruce Chidester > <brucechidester-re5jqeeqqe8avxtiumw...@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.
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 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/20210528171520.B4112223267%40sharky4.deepsoft.com.
