basic PRU Questions I haven't found answers to

[Delbert Martin]

I'm having some issues with PRU documentation and information gathering, or maybe I'm just reading a lot of stuff wrong. 

Help me figure out where I am wrong. 

PRU(s) are little embedded processors in the AM335x core. 

bone_capemgr allows you to change pinmux functions of the core, to allow plug in capes to be detected and set up. and firmware loaded into the kernel.

there seems to be a handful of kernel modules relating to the PRUs, 

pruss ( pru sub system driver / Allows kernel to interact with PRU? )

pru_rproc ( PRU Remoteproc system )

rpmsg_pru ( remote proc message system w/ PRU ) ( this may also be used to pass buffers between PRU and kernel ?)

uio ( UIO allows the IO to be assigned to Device files ?)

uio_pdrv_genirq ( guessing a UIO/PRU IRQ generator )

Based on what I have read from various Google Searches, the PRUs must be enabled, possibly by an Overlay?

are there any overlays that allow you to just enable the PRU, SANS IO pins, just to see if it will run code?

FROM: http://mythopoeic.org/bbb-pru-minimal/

echo BB-BONE-PRU-01 >/sys/devices/bone_capemgr.9/slots

which I found is based on the older 3.8 kernels and bone_capemgr has moved to /sys/devices/platform/bone_capemgr

from the new https://github.com/beagleboard/bb.org-overlays/

it gives me a plethora of options in /lib/firmware which all appear to be Device Tree Overlays

based on names I cannot find one like BB-BONE-PRU-01 the closest I can find is uio-pruss-enable-00A0

which I guessed enabled the PRU but the code from am335x_pru package still gives me the prussdrv_open open failed

so I'm guessing they are still disabled, or not enabled in the way I was expecting.

Looks like the apploader allows you to select which pru you want to use with #PRU_NUM.

so a couple of assumptions:

which of the following are true?

1. PRU firmware must be loaded at boot from /lib/firmware? 

(unlikely based on documentation)

OR

2. kernel can jam a program into the PRUs whenever you feel like it

This one seems like the more likely candidate from the am335x_pru_package

however I keep getting a prussdrv_open open failed, which tells me I probably don't have the PRUs enabled

I'd really just like to write a program for the pru that looks for a clock signal and reads other pins on it. 

Also from what I have read the PRUs have their own "GPI/GPO" pins that have single cycle IO that are dedicated to particular pins which are used elsewhere on the BBB

Really sorry for brain dumping and being all over the place here, these are just questions that I havent seemed to find the correct google search string to find the info I'm looking for, 

there is so much stuff out there for the 3.8 kernels and I'm not sure how well all that stuff carries over to the new 4.1.18 kernel.  

[Robert Nelson]

uio-pruss-enable-00A0 is specific to the "4.1.x-bone" kernel's (uio)

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Mainline_.284.1.x_lts.29

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Delbert Martin]

 For simplicity's sake, Lets say I would like to run PRU_memAccessPRUDataRam from the am335x_pru_package example, 

I keep getting "prussdrv_open open failed", which I'm going to guess means something isn't enabled.  "guessing"

ok, so uio-pruss-enable-00A0 is an overlay for the device tree which enabled the PRU? 

enables the pru in UIO mode? does the code from am335x_pru_package use UIO to upload code to the pru?

I am using the 4.1 kernel, I flashed the https://rcn-ee.com/rootfs/bb.org/testing/2016-02-26/console/BBB-eMMC-flasher-debian-8.3-console-armhf-2016-02-26-2gb.img.xz to my BeagleBone Black RevB (2geMMC)?

installed the bb.org/overlays and the am335x_pru_package from their git repos, so they should be current. 

how does one "unload" an overlay? reboot?

[Robert Nelson]

On Fri, Mar 4, 2016 at 10:58 AM, Delbert Martin <bgh...@gmail.com> wrote:
>> For simplicity's sake, Lets say I would like to run
>> PRU_memAccessPRUDataRam from the am335x_pru_package example,
>
> I keep getting "prussdrv_open open failed", which I'm going to guess means
> something isn't enabled. "guessing"
>
> ok, so uio-pruss-enable-00A0 is an overlay for the device tree which enabled
> the PRU?
> enables the pru in UIO mode? does the code from am335x_pru_package use UIO
> to upload code to the pru?
>
> I am using the 4.1 kernel, I flashed the
> https://rcn-ee.com/rootfs/bb.org/testing/2016-02-26/console/BBB-eMMC-flasher-debian-8.3-console-armhf-2016-02-26-2gb.img.xz
> to my BeagleBone Black RevB (2geMMC)?

That's the "4.1-ti" kernel, it uses remoteproc_pruss

if you want uio_pruss switch to the bone

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --bone-rt-kernel --lts-4_1

[Delbert Martin]

whats the difference? 

I figured the UIO / remote proc were kind of trying to do the same thing. 

which one can I use the am335x_pru_package examples with?

ok, after some googling now I realize they are 2 different ways to interact with the PRUs, 

based on the src of the am335x_pru_package examples, they are using the PRUDRV (UIO?) method, where there is a 

new and upcoming method for using remoteproc, I think I understand now. 

Still updating to the bone kernel to get the UIO stuff, Will report back soon. 

Thanks for all of your help, while I bludgeon the internet with my stupidity.

[Delbert Martin]

OK the examples work now, Thanks for all your help.

[Robert Nelson]

On Fri, Mar 4, 2016 at 11:19 AM, Delbert Martin <bgh...@gmail.com> wrote:
> OK the examples work now, Thanks for all your help.

That's the difference..

uio_pruss works from 3.8 -> 4.1

remoteproc_pruss needs more examples..

[William Hermans]

whats the difference? 

I figured the UIO / remote proc were kind of trying to do the same thing. 

which one can I use the am335x_pru_package examples with?

ok, after some googling now I realize they are 2 different ways to interact with the PRUs, 

based on the src of the am335x_pru_package examples, they are using the PRUDRV (UIO?) method, where there is a 

new and upcoming method for using remoteproc, I think I understand now. 

Still updating to the bone kernel to get the UIO stuff, Will report back soon. 

Thanks for all of your help, while I bludgeon the internet with my stupidity.

Ok, so uio can also be used as an acronym for "user mode I/O". UIO is a thing in of it's self and it not necessarily related to the PRU's in any other way. Other than *someone* back in the era of the beaglebone white wrote a user mode driver using UIO for the PRU's.

Anyway, to truly understand what the deal is. I would recommend to you to search the web for anything / everything UIO, and just start reading. The funny thing is that UIO  was originally intended to help people create generic PCI card drivers . . . obviously its adapted since.

remoteproc ( and rpmsg, etc ) is newer technology, which again really has nothing to do specifically with the PRU. From my understanding of what I've read. remoteproc is really much better used in a situation where you have a generic multi core processor, cores that would normally run Linux. Instead however, remoteproc makes it possible to say run one or more of those cores bare metal. Which quite honestly is a very good thing ( depending ).

In my own personal. . . I think they're both great, but that uio is a much better place to be for the beaglebone PRU's. In the future, where teh Begleboard X15 is concerned. remoteproc may actually be the best place to be. Due to the fact that the X15 will have 4 different core types on the single die. Application cores, PRU's IPU's and DSP's . . .

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.