PRU Assumptions - True or False

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:

  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.

  2. When using RemoteProc you can send a remote message to the PRU and this solution does not work with UIO.

  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.

  5. When working with UIO, clpru generated binaries are no good and this forces you to write the PRU code in assembly and to use pasm.

It’s really not knowing which architecture some articles are talking about, or not knowing the limits of the architecture that makes the PRU stuff so frustrating.

I thank you in advance.

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,

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.

>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.

I’m confused because I thought the plan was Remote Proc going forward. Do you seem to say it is UIO going forward?

Mainline has been 'slowly' getting RemoteProc work done by TI..

Regards,

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/remoteproc/pru_rproc.c

Regards,

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:

Does the 5.x kernel support an interrupt from the PRU while also supporting the bi-directional messaging through rproc?

sorry, i completely missed these commits, so i have not personally
tested it... It got merged in v5.11.x and has been tweaked since..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3

it "should" be an extension of the pru code found in
v4.14.x-ti/v4.19.x-ti/v5.4.x-ti..

Regards,

I see lots of interrupt hints here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c

Regards,

irq driver for pru:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-pruss-intc.c

Regards,

Dumb question by a Debian Newb

I am following this now Debian: Getting Started with the BeagleBone Black

[

Debian: Getting Started with the BeagleBone Black

This is a page about TI’s Cortex-A8 based; BeagleBone Black. Availability Boards: BeagleBone Black at Digi-K…

](https://forum.digikey.com/t/debian-getting-started-with-the-beaglebone-black/12967)

To test this PRU stuff should I use Mainline or TI BSP? whats the difference?

As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 Branch . I had bad internet last night and I lost the building during resolve after downloading the entire kernel of mainline . Today Im trying TI BSP

cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src

Use the “am33x-v5.13” branch of: https://github.com/RobertCNelson/bb-kernel

There are “pre-builds” under apt…

But, I think we need to update the device tree…

Regards,

Thinking:

https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/7a960d2e3e04a5418772cddd51493ad8578eccf6

Regards,

And the interrupt controller…

https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/68aea0792284d7b3c58741c62738287762a5cc0c

Regards,

Thanks Robert

I love these instructions very well done

my goal is to be able to build something stable from scratch not drop binaries maybe modify kernel add drivers be self sufficient at building everything and manually updating SD card as opposed to using an upgrade/update on the BB black.

Not worried about having the most current linux wont ask any questions or need support just trying to learn building everything myself for scratch. I have NO capes no changes to .dts Im interested in the workings of this resource file and maybe getting the big shared RAM

Thanks wish I had found this link before did not know it existed

So I guess my question is which version will work as is for testing some PRU MSG examples as is?

Mark

Thanks Robert

I love these instructions very well done

my goal is to be able to build something stable from scratch not drop binaries maybe modify kernel add drivers be self sufficient at building everything and manually updating SD card as opposed to using an upgrade/update on the BB black.

Glad you like it, it’s’ my old eewiki page just updated and updated as users need help. :wink:

Not worried about having the most current linux wont ask any questions or need support just trying to learn building everything myself for scratch. I have NO capes no changes to .dts Im interested in the workings of this resource file and maybe getting the big shared RAM

Thanks wish I had found this link before did not know it existed

So I guess my question is which version will work as is for testing some PRU MSG examples as is?

“as-is”… Either the 4.14.x-ti or 4.19.x-ti with Mark’s pru cookbook:

https://markayoder.github.io/PRUCookbook/

v5.13.x: closer… just another bug:

ebian@beaglebone:~$ uname -r
5.13.0-rc3-bone2.1
debian@beaglebone:~$ dmesg | grep pru
[ 2.040720] pruss 4a300000.pruss: (null) is missing its ‘cfg’ node

Regards,

Thanks!!

Think of it as I’m validating the instructions I think having these is something good. Unfortunately my VM blew up just now.

I KNOW your adamant about not supporting VM.

So I’ll build a dedicated Debian 8 dev box.

Any hints tips lessons learned what you use be appreciated.

Have a great long weekend.

Regards

VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
failure point..

Regards,