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. 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/ls52bghfoffdbk52e1fjtlggc7l8qvq4e0%404ax.com.