Proper way to Mux PRU pin without Cape Manager

GoogleGroups
1

I am working with the PRU on the 3.14 series kernel.
There is no cape manager, and I want to employ the proper technique for muxing a PRU pin.

For example, the file “am335x-bone-common-pinmux.dtsi” contains this definition which
is the pin&mode that I want to activate:

P9_25_pruin_pin: pinmux_P9_25_pruin_pin {
pinctrl-single,pins = <0x1ac 0x26>; }; /* Mode 6, Pull-Down, RxActive */

How exactly would I make use of this?

( Guessing that I need to reference this in am335x-boneblack.dts somehow, just not
experienced enough with DT to know how to do it. )

Regards,
-J

2

If you're using RCN's kernels, the universal overlay should already be part of the default device tree, so you can just use the config-pin utility:

   config-pin P9.25 pruin

3

Hi Charles - this will be sweet when I get past the error.

My kernel it is from RCN.
Using Kernel 3.14.51-r1 which I built from:
https://github.com/RobertCNelson/ti-linux-kernel/tree/linux-3.14.y

When I run “config-pin P9.25 pruin” I get this error:

P9_25 pinmux file not found!
Please verify your device tree file

Regards,
-J

4

Why are you building your own kernel?

Have you tried using one of RCN's pre-built packages:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#3.14.x-ti

...I know those have the universal overlay stuff folded into the
default device-tree overlay.

5

Building the kernel because I have some custom modules.

BTW, This works for me:

echo pruin > /sys/devices/ocp/ocp:P9_25_pinmux/state

But “config-pin P9.25 pruin” gives me the previous error.

6

Hmm...there's likely a config-pin bug with the 3.14 kernels. I don't
personally run 3.14 yet, and will likely jump to 4.x next (skipping 3.14).

Patches and/or pull requests welcome!

7

Hi Charles,

No experience with how patches should be introduced, but below is a patch for config-pin on linux 3.14.51
Hope this helps someone.

md5sum of the original config pin: 74a71c0a84c46d2df4e14113dea4834a

The problem was related to changes in how the /sys/ files are named.
Tried 4.1.x a couple weeks back and it was rebooting spontaneously for me.
The 3.14 kernel has been stable for me so far.

Thanks,
-J

-----cut-----

— config-pin 2015-09-10 00:01:26.596656005 +0000
+++ config-pin.new 2015-09-10 00:01:49.636656007 +0000
@@ -1,7 +1,7 @@
#!/bin/dash

Some important directories for use later

-OCPDIR=/sys/devices/ocp.*
+OCPDIR=/sys/devices/ocp
GPIODIR=/sys/class/gpio
SLOTS=/sys/devices/bone_capemgr.*/slots

@@ -801,7 +801,7 @@
check_pin $PIN

Expand filename using shell globbing

  • for FILE in $OCPDIR/${PIN}_pinmux.*/state ; do
  • for FILE in “$OCPDIR/ocp:${PIN}_pinmux/state” ; do
    if [ -r $FILE ] ; then
    read MODE JUNK < $FILE
    else
    @@ -870,7 +870,7 @@

Check whether support for a specific pin is loaded or not

$1 pin to check

check_pin () {

  • if [ -e $OCPDIR/${PIN}_pinmux.* ] ; then
  • if [ -e “$OCPDIR/ocp:${PIN}_pinmux” ] ; then
    echo_dbg $1 pinmux file found
    else
    echo_err $1 pinmux file not found!
    @@ -1000,7 +1000,7 @@
    fi

Expand filename using shell globbing

  • for FILE in $OCPDIR/${PIN}_pinmux.*/state ; do
  • for FILE in “$OCPDIR/ocp:${PIN}_pinmux/state” ; do
    echo_dbg “echo $MODE > $FILE”
    sudo -A bash -c “echo $MODE > $FILE” || (echo_err “Cannot write pinmux file: $FILE” && exit 1)
    done

-----cut-----

8

Random reboots are now fixed on v4.1.x.

Regards

9

<snip code patch>

Thanks for the patch, I'm glad it was a simple fix for you.

The code provided may work for 3.14, but will break other kernel
versions. I'll see if I can fold in an update that will do the proper
thing based on detecting the kernel verison so the code won't break on
the 3.8 kernels still used by lots of folks (including me).

10

Hi Charles, RCN,

I’ve got the 4.1.10-armv7-rt-x5 kernel running on my bbb; switched over to this version to avoid the ethernet 0xfffffffb detection problem (and to monopolize the CPU for 7-10ms). Fixed, and capemgr seems installed properly per https://github.com/RobertCNelson/bb.org-overlays, but the pinmux state files are absent. Have they moved? Must the pinmuxes be programmed in some other way?

e.g.

ls /sys/devices/platform/ocp/ocp:P8_07_pinmux
driver_override modalias of_node power subsystem uevent

No ‘state’ file as needed by config-pin (which includes the recent patches). Should I move back to an older or different kernel?

appreciated,
Tim