I have been struggling to find a way to map which gpio pins on the BBB map to the specific bit in the R30 & R31 registers. I am probably looking for the wrong thing, but I can’t find many references. If they are fixed, can’t be remapped, how do I find what pins are mapped?
Thanks
You have to configure the pinmux for the pin(s) you want. Remember to
enable the input driver, as well (also in the pinmux register).
You can do this with a custom device tree overlay or by using my
"universal" cape overlay (with kernel 3.8, partly supported for kernel
3.14) and the config-pin utility.
On a recent RCN Debian image, just (for instance):
config-pin P8.15 pruin
...to connect P8.15 to PRU 0, R31, bit 15.
You may also find the pinmux spreadsheet useful, if you don't want to
crawl through the TI data-sheet for the AM3358 and the BeagleBone SRM:
https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods
Thank you for your help, I do appreciate it. This is like drinking from a fire hose 
I have a couple of questions.
I read your spreadsheet and find the following
pru0 has for output bits [0 - 7] and 14, 15
pru0 has for input bits [0-7] and 14, 15, 16
pru1 has for outputs [0 - 15]
pru1 has for inputs [0 - 16]
I am currently using pru0 simply because it is before pru1. Is there a drawback to using pru1 over pru0.
my application will be focused on using about 12 input pins and the only other resource on the beaglebone is the ethernet port.
If I wanted all the pins for pru0 as are on the pru1 I would have to learn the pinmux utility. I will eventually figure this out, I’m just looking to make some progress before I have to move to the next step.
The two PRU cores are identical, other than the external pins they are
tied to for direct I/O. Choose the PRU core to use based on the pins
you want, or if you're not using direct I/O it doesn't matter which core
you choose.
After reading lots of stuff I have what I thought might work.
Segments from my .dts
exclusive-use =
“p9.25”; /* R30[7] */
fragment@0 {
target = <&am33xx_pinmux>;
overlay {
mygpio: pinmux_mygpio{
pinctrl-single,pins = <
0x1AC 0x25 /* P9.25 mode 5 pulldown output */
;
};
};
};
If I do nothing in my pru code this pin is always high even after I reboot the bbb.
I tried
CLR R30.T7
and the pin still remained high.
Is there something else I need to do.
Browse the live device tree (/proc/device-tree) and make sure it's what
you expect. Typically, you create a pinctrl-single,pin entry and refer
to that in some other device. When that device is loaded, the kernel
will implement the pinmux settings referred to.
Is there some reason you're not just using config-pin and loading one of
the universal overlays?
The trouble is, I don’t know what to expect. I will look and see whats there to see if I can make sense out of it.
I looked at the universal overlay when you sent the link to it and it seemed overwhelming because of the number of entries for each pin. Now that I have a little more experience with it I can go back and see if I can figure it out.
All I need to do is comment out the pins in exclusive-use section that I don’t want to use and comment out all of the entries for those pins in the fragment. Then comment out the sections for the modes I don’t want for the pins I do want?
If you use a "stripped down" version of the universal cape overlay,
you'll still have the pinmux helper in control of the pin multiplexing.
That means you'll need to either setup the proper pin choice using sysfs
after loading the overlay or make the desired PRU pinmux mode the
default (or both).
Alternately, you could add your desired pinmux settings to a custom PRU
overlay based off of one of the BB-BONE-PRU overlays provided with the
standard kernel. This would prevent any changes to the pinmux setting
after loading the overlay, which might be good or bad, depending on
exactly what you're attempting to do.
I can’t thank you enough for your help. Every response is at least another two day learning activity. I just wish I didn’t have to work to pay the bills.
I went back to see what I did and it turns out I misspelled the name of the dtbo file that I was using so there is no wonder it didn’t work.
Now I get an error that the file exists when I:
echo pru_enable > /sys/devices/bone_capemgr.8/slots
echo: write error: File exists
prussdrv_open open failed
so I guess I have more to learn 
What I am really trying to do is learn how to work with this device.
This activity is to learn to write to a set of 9 or 10 pins, 8 data and one enable or 2 handshake.
My next step is to read fro a set of 9 or 10 pins, 8 for data and one for write enable or 2 for a handshake.
So:
If I add your desired pinmux settings to a custom PRU overlay based off of one of the BB-BONE-PRU overlays provided with the standard kernel. What would be the limitations?
I figure I could work out the problems at a later time. after I see an led light up:)
Taking your suggestion I went out to /lib/firmware and found several dts files that used pins like I want to use them. The number of pins in the list I want are 1 to all Plus some. The one that used all the pins I want to use include lots of stuff in the ocp fragment. Is there a way to use a modified version of this one. It is
BB-BONE-PRU-04-00A0.dts
I also noticed in the exclusive-use list in the universal overlays you have “pru0”, “pru1”, “pruss” with no other reference. I don’t have them in mine? What are they for?
I found a problem that P9_31 conflicts with the HDMI Overlay so I will have to figure out if I try to eliminate it because it is not going to be used or if I can move the output to the pru1.
I can't thank you enough for your help. Every response is at least another
two day learning activity. I just wish I didn't have to work to pay the
bills.I went back to see what I did and it turns out I misspelled the name of the
dtbo file that I was using so there is no wonder it didn't work.
Now I get an error that the file exists when I:echo pru_enable > /sys/devices/bone_capemgr.8/slots
echo: write error: File exists
prussdrv_open open failedso I guess I have more to learn
The errors from capemgr are really cryptic. You'll typically see "File
exists" when something you're trying to add to the device tree is
already in use. There may be slightly more information in dmesg or the
kernel log.
Also note it is not really possible to unload a device-tree overlay, so
testing is a cycle of boot - test - shutdown. 
What I am really trying to do is learn how to work with this device.
This activity is to learn to write to a set of 9 or 10 pins, 8 data and one
enable or 2 handshake.My next step is to read fro a set of 9 or 10 pins, 8 for data and one for
write enable or 2 for a handshake.So:
If I add your desired pinmux settings to a custom PRU overlay based off of
one of the BB-BONE-PRU overlays provided with the standard kernel. What
would be the limitations?
If you make a custom overlay and "hard-code" the pins you want to the
desired mode, the limitation is from then on you won't be able to change
them (without rebooting to unload your custom overlay). If you use the
pinmux-helper as is done in the universal overlay, you can switch
between the available modes at run-time (via the generated sysfs entries).
Sure, just edit, compile with dtc [1], copy to /lib/firmware, and load.
...the same as you would do for any other device-tree overlay.
[1] dtc -O dtb -o file.dtbo -b 0 -@ file.dts
I haven't delved through the source for what looks at the exclusive-use
section, but it seems like a poor-man's "collision detection" for
loading device-tree overlays. My entries were basically copied from the
existing overlay files, which seemed to use an assortment of naming
conventions (thus there are several near-duplicates in my universal
overlay).