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.
