Looking for some assistance on finding an image that has a working pinmux driver set.

GoogleGroups
1

Having the hardest time with my beaglebone blue. first and foremost, i followed the instructions after firing the unit up the first time, and flashed the latest image. Since then, all i can attribute that to is lack of knowledge on my part.I purchased this board because it had the built in functionality of pwms, motor drivers, servo drivers and 2s Lipo charging etc.

At this point i am looking for a stable, functional image that will work with Python, and if possible node red. I have no history or knowledge of javascript or C++, so i am trying to work my way up starting here, and teach my kids the fun tht can be had. As I am finding though, there isn’t an overlay set up for the Blue, most of the pins aren’t exported, and as such, rcpy doesn’t want to work correctly. Even running the basic included functions yields issues like this:

can’t open: /sys/devices/platform/ocp/ocp:H18_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:C18_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_22_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_21_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_26_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_24_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_30_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_29_pinmux/state
Pinmux: No such file or directory
can’t open: /sys/devices/platform/ocp/ocp:P9_31_pinmux/state
Pinmux: No such file or directory
WARNING: missing PINMUX driver
You probbaly just need a newer kernel
ERROR: export failed for hrpwm1 channel A
ERROR: failed to initialize hrpwm1
WARNING: Failed to initialize motors
ERROR: pru-rproc driver missing

this of course persists across all of the included examples. and as such, i can’t even get the motors to operate. Blinking the LED’s is only useful to a point.

i’m running the 4.9 kernel that came with the 2018-03-05 image. If there’s a functioning image i should be using that’s up to date enough i’d be happy to reflash. at this point, i’m looking for something that just works and allows all of the functions and pins the board has to work correctly. I’ve been advised i can manually set pins with sudo and and use other libraries.

If i’m expecting too much, and there are some good resources i should look at to make this work correctly i’d be happy to delve deeper. im not afraid to learn, but i am afraid i wasted $80 on a board that did work 12 months ago, and got left behind as the rest of the world updated.

Any pointers, educational resources, or even projects would be appreciated, as my children may find these interesting as well.

2

universal-io should be installed on that image by default.

you can configure all pins the way you want like this

echo 2 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio2/direction

read up on it on this github

https://github.com/cdsteinkuehler/beaglebone-universal-io

I dont have a blue but i would assume there is a premade overlay for
that board that should configure
everything for you if the above does not work out for you

3

Thanks for responding!

It is indeed installed, but there is no overlay for the Blue i was able to find in the list of overlays. the github you linked goes heavily into the 3.x kernels which don’t apply to the device tree changes in the 4.9.x and above kernels. i was hoping an overlay would exist that would fix the fact that the /sys/devices/platform/ocp/ directory only has 8 pinmux entries, which is why none of the robotics cape functions actually work.

i tried the export method below, but i doesn’t add anything to the OCP directory listed above that the examples all need. this is even after i modified the uEnv.txt file to include even the cape-universalh-dtbo.

The lack of an overlay, my lack of understanding how to correctly make one, is inhibiting this. i found out that for some reason the push buttons on it are hard coded into the libroboticscape library, which is written in C, and even the rcpy library doesn’t work correctly, all because of the missing entires in the /ocr/ directory.

any additional inside is appreciated.

4

i’ll clarify what i am looking for.

The newest images available that everything says to update to, doesn’t appear to export the pins to the /ocp directory. As such, even the example code supplied doesn’t work. config-pin doesn’t work because it looks in the /ocr directory for *pinmux folders so it can do things. these don’t exist in the 9.x versions. all of the information on making capes refers to a device tree/cape-manager that doesn’t appear to exist as a result of updates going down the line. i’ve tried various overlays loading them, and yet, nothing appears in the /ocr directory. using the RoboticsCape-00A0.dtbo as an overlay actually breaks the OS and makes it unable to load at all. it literally get’s stuck with all 4 of the user lights being stuck on.

Since adafruit_bbio, libroboticscape rcpy etc all rely on them to be there, and since they aren’t, nothing works with the updated images. i’ve google searched my eyes out, and all of the guides, information, etc, all appear to be non-functional due to kernel upgrades and changes in how everything is handled with regards to capes, slots, and overlays. I am hoping for a solution that would allow me to use the fixes in code or updated python libraries i’m more comfortable with than having to look instead to learning to write in another programming language and then rewriting/correcting the issues with the existing example code to simply make it work.

This isn’t meant to be a slight to anyone, as i appreciate the project and the authors. I’m just frustrated to find that for the most part, this board feels like it’s been left left in the dust as the rest of the beaglebone product line moves forward despite it’s amazing capabilities. Given it’s a Black with the capabilties of the robotics cape integrated into it, I figured it would have been easier than this. As i said before, that may be my fault for expecting the ease of use i’ve come to know with the Raspberry Pi and similiar other single board computers.

5

Till things catch up just flash an old working version.
sometimes upgrading things is not a good idea till you get everything
working.

pinmux will work on new kernels just fine i use it on 4.14
it should be loading in /boot/uEnv.txt you can go look there to see

grab the overlay source

git clone https://github.com/beagleboard/bb.org-overlays

and take a look at the source of the overlay for your board

something might stand out

I use blacks and greens - so i dont have one here to play with

6

therein lies part of the issue. There isn’t an overlay for the board itself from what i can tell. none of the overlay’s indicate they are for beaglebone blue by name itself, and none of them list “ti,beaglebone-blue” as compatible. the closest would be the roboticscape-00a0, except loading that actually stops the board from booting period.

7

send a copy of your /boot/uEnv.txt to see whats loading

8

debian@beaglebone:/opt/scripts$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[e307a944e0be0610ff5296e0abe4ad31a6e70daa]
eeprom:[A335BNLTBLA21722EL001255]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Image 2018-03-05]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.01-00002-ge9ff418fb8]:[location: dd MBR]
kernel:[4.14.25-bone13]
nodejs:[v6.13.1]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180307.0-0rcnee0~stretch+20180307]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 0.849752] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper

9

Hi Drew,

Have you had any luck with this so far? I’ve hit the same point (which is how I came across this post).

If it’s not possible to get the robotics cape, rcpy/pyctrl, node-roboticscape, etc. working with the “current” image, I’m happy running an older image. It might be helpful to have a warning in any Blue-specific documentation that the newer images should be avoided until things are better.

Any recommendations for an older image where things like the EduMIP robot examples will work?

Thanks!
Andy

10

Hi Andy!

Short answer. Only the 3/2017 image works correctly for Libroboticscape, RCPY, Jhonny5, and node-robotics cape. And even then with the node red, most of it doesn’t work at all. RCPY is just conversion of the libroboticscape, but most of the functions aren’t there from the libroboticscape. Newer 4.x kernels simply won’t work.

Long answer.

The folks who designed the board use it for a class in a class at a university. As such, Robert C Nelson has disabled overlays for the Blue board. He also as of this point hasn’t updated the code to pull out all of the pinmuxes in newer boards despite protests from several of us so far. again because he doesn’t want top break the code the school uses if the board is accidently updated. The BBBLue also pulls out some pinmuxes that aren’t standard on a normal beaglebone, and assigns them under a different nomenclature than a normal Beaglebone. This is important later.

The libroboticscape library uses some older coding and very specific coding to perform some back end wizardry to handle the 4th encoder & the servos. this eliminates the ability to use them without the library. the Analog pins are also handled via mmap, which means you can’t get to them from python. This library is also called for the battery checker. RCPY is another university class grade piece of code, and largely unmaintained as you’ll find. unfortunately, to use everything and use it easily/correctly, this library is required. In python especially, there is no way to use the Analog pins, or even read from them. using the “State” in RCPY and in any of even the “C” examples is blocking, meaning that you can’t run two instances with it, it’ll close the first so the second. with some kajigery i was able to get some things out of it, right or not. it’s working for me so far.

Adafruit BBIO uses a certain nomenclature when setting pinmuxes. this is in the format of “P8_8”, and it’s hard coded. This is because the underlying software for setting the pinmuxes to do things is also hard coded for this style that the Adafruit BBIO uses under everything. the non-standard nomenclature of some of the pinmuxes means you can’t access them via this python library.

The node-roboticscape is based on an even earlier piece of code that’s no longer supported by node-red. as such, most of it’s corresponding functions aren’t even available. Johnny5 looks for things exported to /sys/class/gpio, which aren’t there because the overlays pinmux things instead. You can export pins in this directly, but all PWM is handled via pinmuxing and the PRUs.

Between the 3/2017 and the newer versions of the kernal, the pru driver changed. so newer kernel functions for PRUs doesn’t work correctly. This includes encoder #4, and all servo pins.

Now, with all of the depressing things out of the way that inhibit the use of it on newer kernels, there is a newer version of libroboticscape in the works. how it will function is beyond me and the developer isn’t responding to inquiries so far after over a month. it does appear Robert C nelson is helping them at least.

I myself am not willing to give up on this thing just yet. I’m on the 3/2017 kernel.none of the others work, or provide complete functionality, including the debian and ROS images. i’m not fluent in C and i bought this thing to do some fun things with my daughter, which means python for me. i’ve done some things to get the functionality i want and use a variety silly things to get it, but i can at least get some of the things needed to make it all work. if any of it is of interest to let me know, and i’d be happy to share what i’ve done to get it going. there are likely easier ways, mostly tied to learning how to create a better, more complete version of RCPY, but it’s all well outside of what i know how to do on such a large scale.

Thanks!
Drew

11

Thanks for the quick response!

I saw that there’s a new branch on the Strawson library that’s being actively worked on, so that’s very encouraging.

I’m new to linux, so when I first starting playing with the BBB last year, it was quite a learning curve. What made things especially difficult was that many good resources (i.e. Derek Molloy’s book & website) were based on older images and many examples didn’t work. Although it was a frustrating experience, I definitely learned a lot and was able to successfully use the BBB for a couple of projects around the house (replaced the commercial sprinkler system controller, monitor/control garage door, etc).

My target for the blue is definitely robotics. I was a mentor for a couple of FIRST FLL (lego robotics) teams and some of these kids have expressed an interest in getting into “real” robotics & programming. The BB blue seems like a great platform for that especially if some of the low-level details can be abstracted away through these libraries. Most of the kids have been exposed to javascript & python in school.

I’ll try the image from 3/2017 and see how it goes.

12

Hi Drew,

What was the "last" v4.4.x-ti based kernel (uname -r) that fully
worked for you guys?

Regards,

13

The last one that fully worked is

4.4.52-ti-r91.

but it only worked with RCPY and the default Libroboticscape C library.

Not to rehash our previous conversations, but none of the versions including this version fully works with Adafruit bbio because it relies on config-pin to call pinsetting, and that’s hardcoded for the nomenclature of “Px_x” in the /sys/devices/platform/ocp directory. While the overlay does bring a few of them out(P9_11, P9_21-31) that can be used, config-pin can’t handle the “special” ones like C18, D13, H17-18, J15, or U16 because of the special nomenclature. Nothing anyone can do here with those. Add to that overlays were disabled for the blue due to the libroboticscape handling assignments, which hasn’t been updated to 0.4.0 yet so all of the other pins can’t be addressed. DTB-rebuilder is an option, but I don’t feel safe playing with it.

The prevailing concern for me and the the others who private messaged me asking if this was ever solved, is the ability to use python and the newer kernels. The websites still state the first thing that should be done is to update the kernels, and all of the newer kernels state compatibility for the blue. It’s the first thing we do. again, not much you can do about the python situation. It’s just Python unfriendly/incomplete.

14

The last one that fully worked is

4.4.52-ti-r91.

but it only worked with RCPY and the default Libroboticscape C library.

Thanks! I'll start with that version and get it working on the main
v4.4.x tree again.

Not to rehash our previous conversations, but none of the versions including
this version fully works with Adafruit bbio because it relies on config-pin
to call pinsetting, and that's hardcoded for the nomenclature of "Px_x" in
the /sys/devices/platform/ocp directory. While the overlay does bring a few
of them out(P9_11, P9_21-31) that can be used, config-pin can't handle the
"special" ones like C18, D13, H17-18, J15, or U16 because of the special
nomenclature. Nothing anyone can do here with those. Add to that overlays
were disabled for the blue due to the libroboticscape handling assignments,
which hasn't been updated to 0.4.0 yet so all of the other pins can't be
addressed. DTB-rebuilder is an option, but I don't feel safe playing with
it.

Let's work with Drew on that, (he's the maintainer of the python library)..

Do we have a list of which pins are we are trying to access thru that library?

(it annoys we chose the P8/P9 syntax for the blue)

If you look at the python the library, the PocketBeagle turned out much cleaner.

I'd really like to just re-do the blue pin labels...

The prevailing concern for me and the the others who private messaged me
asking if this was ever solved, is the ability to use python and the newer
kernels. The websites still state the first thing that should be done is to
update the kernels, and all of the newer kernels state compatibility for the
blue. It's the first thing we do. again, not much you can do about the
python situation. It's just Python unfriendly/incomplete.

Lack of testing really broke things. Personally i was just running
rc_balance and assumed that was enough to verify things worked.

Being swamped at day job hasn't helped either.

Regards,

15

Okay first pass:

https://github.com/RobertCNelson/dtb-rebuilder/commit/8a3a03cb905fdc1f280ab7dc3cb3591d54be89f1

for anyone that is running v4.4.x-ti on a blue, simply do:

:~$ cd /opt/source/dtb-4.4-ti/
:/opt/source/dtb-4.4-ti$ git pull
:/opt/source/dtb-4.4-ti$ make
:/opt/source/dtb-4.4-ti$ sudo make install

then in /boot/uEnv.txt

change:

=dtb= to:

dtb=am335x-boneblue-mmap.dtb

reboot and please re-test the Libroboticscape C library.

Regards,

16

Side note, it appears Thalaviar made mention of his way to correct the 4.14-ti kernel issues. his method was to :

git clone https:``//github``.com``/RobertCNelson/dtb-rebuilder``.git
git checkout 4.14-ti
git checkout origin``/4``.9-ti -- src``/arm/am335x-boneblue``.dts
git checkout origin``/4``.9-ti -- src``/arm/am335x-bone-common-universal-pins``.dtsi
make src``/arm/am335x-boneblue``.dtb

This corrected the pruout/pruin pins that were set as GPIOs. one of the files was missing to rebuild it straight(if memory serves me, it was am335x-boneblue.dts). Not sure if this helps.

The adafruit bbio library allows access to any of the pins, but does it with the defacto config-pin in jessie and stretch. meaning :

https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv

any of them COULD be accessed by knowing the header/pin number. In an ideal world, that’d be the pin list, with the references to the BB, BBBL “pin” and the actual ball on the SOC. for instance, as it stands right now, any of the Analog Ins, isn’t accessable at all. Being limited to check AIN5 and AIN6 only via a C program is a pain. RCPY doesn’t bring out the AINs at all. Show-pins shows nothing for them. they just don’t exist. It can only be done in C, and with Libroboticscape. The rest of the pins on that list that are tied to a function in libroboticscape show up in showpins with a few bizare caveats(like motor 2 direction pin B), but have no way of accessing them because they aren’t in any of the overlays. Libroboticsape does everything with them, setting them, and using them in low level programming. In a perfect world, the overlay would allow them to be brought out so we could use them with things other than LibRoboticsCape.

The caveat to this is your prior fears would be well founded though if a universal fix for them would break the use of libroboticscape(and the battery monitor that relies on it and it’s analog pin mmap-ing).

While we can’t expect you to test everything, I can give you a few very specific examples where it completely breaks down using adafruit’s BBIO library in either tyhe 4.14 or 4.4 kernels. Give the ADC or PWM sample code in the read me a try.

17

Side note, it appears Thalaviar made mention of his way to correct the
4.14-ti kernel issues. his method was to :

git clone https://github.com/RobertCNelson/dtb-rebuilder.git
git checkout 4.14-ti
git checkout origin/4.9-ti -- src/arm/am335x-boneblue.dts
git checkout origin/4.9-ti -- src/arm/am335x-bone-common-universal-pins.dtsi
make src/arm/am335x-boneblue.dtb

This corrected the pruout/pruin pins that were set as GPIOs. one of the
files was missing to rebuild it straight(if memory serves me, it was
am335x-boneblue.dts). Not sure if this helps.

The adafruit bbio library allows access to any of the pins, but does it with
the defacto config-pin in jessie and stretch. meaning :

https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv

any of them COULD be accessed by knowing the header/pin number. In an ideal
world, that'd be the pin list, with the references to the BB, BBBL "pin" and
the actual ball on the SOC. for instance, as it stands right now, any of the
Analog Ins, isn't accessable at all. Being limited to check AIN5 and AIN6
only via a C program is a pain. RCPY doesn't bring out the AINs at all.
Show-pins shows nothing for them. they just don't exist. It can only be done
in C, and with Libroboticscape. The rest of the pins on that list that are
tied to a function in libroboticscape show up in showpins with a few bizare
caveats(like motor 2 direction pin B), but have no way of accessing them
because they aren't in any of the overlays. Libroboticsape does everything
with them, setting them, and using them in low level programming. In a
perfect world, the overlay would allow them to be brought out so we could
use them with things other than LibRoboticsCape.

The caveat to this is your prior fears would be well founded though if a
universal fix for them would break the use of libroboticscape(and the
battery monitor that relies on it and it's analog pin mmap-ing).

last i looked at 0.4.0 i think the battery/adc has been moved to iio..
that's why the adc was disabled by default for us. now that u-boot
overlays work for the blue, the adc can be turned on..

While we can't expect you to test everything, I can give you a few very
specific examples where it completely breaks down using adafruit's BBIO
library in either tyhe 4.14 or 4.4 kernels. Give the ADC or PWM sample code
in the read me a try.

ADC and PWM are the fun one right now..

For the ADC, as long as you have a recent u-boot (v2018+)

sudo /opt/scripts/tools/version.sh

The adc can be turned off and on via an overlay:

enable_uboot_overlays=1

#enables adc
#disable_uboot_overlay_adc=1

#disables adc
disable_uboot_overlay_adc=1

the pru options are also available on the blue:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

PWM:

lib_robotics assumes the old non-udev-rule-able location.. i need to
fix that.. (it's just a different directory).. This is what breaks
v4.11.x+ (a few v4.9.x kernels when i backported the pwm rule)

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/7cc72b902fc64deab5a54f58414cb65a595ef1d3

Regards,

18

Rebooted, library still works. I ran down all of the functions just in case one at a time.

19

ADC and PWM are the fun one right now…

For the ADC, as long as you have a recent u-boot (v2018+)

sudo /opt/scripts/tools/version.sh

Bootloader is 2018.03+

The adc can be turned off and on via an overlay:

enable_uboot_overlays=1

#enables adc
#disable_uboot_overlay_adc=1

#disables adc
disable_uboot_overlay_adc=1

With the Blue MMAP dtb mentioned previously still in uEnv.txt

The above doesn’t seem to work with the python examples from adafruit.

with uboot overlays enabled, disabling it or enabling it still returns:

RuntimeError: Unable to setup ADC system. Possible causes are:

  • A cape with a conflicting pin mapping is loaded
  • A device tree object is loaded that uses the same name for a fragment: helper

ADC Enabled or disabled, rc_test_adc still works.

20

This may help make things clearer:

#show-pins | sort
P8.03 / eMMC d6 6 fast rx up 1 mmc 1 d6 mmc@481d8000 (pinmux_emmc_pins)
P8.04 / eMMC d7 7 fast rx up 1 mmc 1 d7 mmc@481d8000 (pinmux_emmc_pins)
P8.05 / eMMC d2 2 fast rx up 1 mmc 1 d2 mmc@481d8000 (pinmux_emmc_pins)
P8.06 / eMMC d3 3 fast rx up 1 mmc 1 d3 mmc@481d8000 (pinmux_emmc_pins)
P8.07 36 fast 7 gpio 2.02 lo >> leds (pinmux_led_pins)
P8.08 37 fast 7 gpio 2.03 lo >> leds (pinmux_led_pins)
P8.09 39 fast rx up 7 gpio 2.05 << hi sysfs (pins)
P8.10 38 fast rx up 7 gpio 2.04 << hi sysfs (pins)
P8.11 13 fast rx up 4 qep 2 in B ocp/helper (pins)
P8.12 12 fast rx up 4 qep 2 in A ocp/helper (pins)
P8.13 9 fast down 4 pwm 2 out B ocp/helper (pins)
P8.14 10 fast 7 gpio 0.26 lo >> leds (pinmux_led_pins)
P8.15 15 fast rx up 6 pru 0 in 15 ocp/helper (pins)
P8.16 14 fast rx up 6 pru 0 in 14 ocp/helper (pins)
P8.17 11 fast 7 gpio 0.27 lo >> leds (pinmux_led_pins)
P8.18 35 fast 7 gpio 2.01 ocp/helper (pins)
P8.19 8 fast down 4 pwm 2 out A ocp/helper (pins)
P8.20 / eMMC cmd 33 fast rx up 2 mmc 1 cmd mmc@481d8000 (pinmux_emmc_pins)
P8.21 / eMMC clk 32 fast rx up 2 mmc 1 clk mmc@481d8000 (pinmux_emmc_pins)
P8.22 / eMMC d5 5 fast rx up 1 mmc 1 d5 mmc@481d8000 (pinmux_emmc_pins)
P8.23 / eMMC d4 4 fast rx up 1 mmc 1 d4 mmc@481d8000 (pinmux_emmc_pins)
P8.24 / eMMC d1 1 fast rx up 1 mmc 1 d1 mmc@481d8000 (pinmux_emmc_pins)
P8.25 / eMMC d0 0 fast rx up 1 mmc 1 d0 mmc@481d8000 (pinmux_emmc_pins)
P8.26 31 fast 7 gpio 1.29 lo >> leds (pinmux_led_pins)
P8.27 / hdmi 56 fast down 5 pru 1 out 8 ocp/helper (pins)
P8.28 / hdmi 58 fast down 5 pru 1 out 10 ocp/helper (pins)
P8.29 / hdmi 57 fast down 5 pru 1 out 9 ocp/helper (pins)
P8.30 / hdmi 59 fast down 5 pru 1 out 11 ocp/helper (pins)
P8.31 / hdmi / sysboot 14 54 fast 7 gpio 0.10 lo >> sysfs (pins)
P8.32 / hdmi / sysboot 15 55 fast 7 gpio 0.11 lo >> leds (pinmux_led_pins)
P8.33 / hdmi / sysboot 13 53 fast rx up 2 qep 1 in B ocp/helper (pins)
P8.34 / hdmi / sysboot 11 51 fast rx 7 gpio 2.17
P8.35 / hdmi / sysboot 12 52 fast rx up 2 qep 1 in A ocp/helper (pins)
P8.36 / hdmi / sysboot 10 50 fast 7 gpio 2.16 lo >> sysfs (pins)
P8.37 / hdmi / sysboot 8 48 fast 4 uart 5 txd ocp/helper (pins)
P8.38 / hdmi / sysboot 9 49 fast rx 4 uart 5 rxd ocp/helper (pins)
P8.39 / hdmi / sysboot 6 46 fast down 5 pru 1 out 6 ocp/helper (pins)
P8.40 / hdmi / sysboot 7 47 fast down 5 pru 1 out 7 ocp/helper (pins)
P8.41 / hdmi / sysboot 4 44 fast down 5 pru 1 out 4 ocp/helper (pins)
P8.42 / hdmi / sysboot 5 45 fast down 5 pru 1 out 5 ocp/helper (pins)
P8.43 / hdmi / sysboot 2 42 fast 7 gpio 2.08 lo >> sysfs (pins)
P8.44 / hdmi / sysboot 3 43 fast 7 gpio 2.09 lo >> sysfs (pins)
P8.45 / hdmi / sysboot 0 40 fast 7 gpio 2.06 lo >> sysfs (pins)
P8.46 / hdmi / sysboot 1 41 fast 7 gpio 2.07 lo >> sysfs (pins)
P9.11 28 fast rx up 6 uart 4 rxd ocp/P9_11_pinmux (pinmux_P9_11_uart_pin)
P9.12 30 fast 7 gpio 1.28 ocp/helper (pins)
P9.13 29 fast 7 gpio 0.31 lo >> sysfs (pins)
P9.14 18 fast down 6 pwm 1 out A ocp/helper (pins)
P9.15 16 fast 7 gpio 1.16 lo >> sysfs (pins)
P9.15 34 fast 7 gpio 2.00 lo >> sysfs (pins)
P9.16 19 fast down 6 pwm 1 out B ocp/helper (pins)
P9.17 / spi boot cs 87 fast rx up 2 i²c 1 scl ocp/helper (pins)
P9.18 / spi boot out 86 fast rx up 2 i²c 1 sda ocp/helper (pins)
P9.19 / cape i²c scl 95 slow rx up 3 i²c 2 scl ocp/helper (pins)
P9.20 / cape i²c sda 94 slow rx up 3 i²c 2 sda ocp/helper (pins)
P9.21 / spi boot in 85 fast rx up 1 uart 2 txd ocp/P9_21_pinmux (pinmux_P9_21_uart_pin)
P9.22 / spi boot clk 84 fast rx up 1 uart 2 rxd ocp/P9_22_pinmux (pinmux_P9_22_uart_pin)
P9.23 17 fast rx up 7 gpio 1.17 ocp/P9_23_pinmux (pinmux_P9_23_gpio_pu_pin)
P9.24 97 fast rx up 0 uart 1 txd ocp/P9_24_pinmux (pinmux_P9_24_uart_pin)
P9.25 / audio osc 107 fast rx up 7 gpio 3.21 << lo sysfs (pins)
P9.26 96 fast rx up 0 uart 1 rxd ocp/P9_26_pinmux (pinmux_P9_26_uart_pin)
P9.27 105 fast rx up 1 qep 0 in B ocp/helper (pins)
P9.28 / hdmi audio data 103 fast rx up 7 gpio 3.17 << hi sysfs (pinmux_P9_28_gpio_pu_pin)
P9.29 / hdmi audio fs 101 fast rx down 3 spi 1 d0 miso ocp/P9_29_pinmux (pinmux_P9_29_spi_pin)
P9.30 102 fast rx down 3 spi 1 d1 mosi ocp/P9_30_pinmux (pinmux_P9_30_spi_pin)
P9.31 / hdmi audio clk 100 fast rx down 3 spi 1 clk ocp/P9_31_pinmux (pinmux_P9_31_spi_pin)
P9.41 106 fast rx up 7 gpio 3.20 ocp/D13_pinmux (pinmux_D13_gpio_pu_pin)
P9.41 / jtag emu3 109 fast 7 gpio 0.20 lo >> sysfs (pins)
P9.42 104 fast rx up 1 qep 0 in A ocp/helper (pins)
P9.42 89 fast 2 spi 1 cs 1 ocp/C18_pinmux (pinmux_C18_spi_pin)

Instead of:

ocp/helper (pins) or sysfs (pins)

it’s expecting something akin to:

ocp/P8_45_pinmux (pinmux_P8_45_xxxxx)