cannot enable pru pins (uBoot/cape/pinmux mismatch issue?)

GoogleGroups
1

I’ve been building a prototype using the uio_pruss driver and one “test” pin (P9_27) which was easily allocated using config-pin.
I’m now trying to complete the prototype and need to enable a total of 8 PRU pins (pr1_pru0_pru_r30_[0-7]). I am unable to enable most of these pins:

debian@BBB:~$ uname -r
4.4.30-ti-r64

debian@BBB:~$ config-pin -a p9_29 pruout

P9_29 pinmux file not found!

P9_29 overlay not found

Loading cape-universala overlay

bash: line 0: echo: write error: File exists

Error loading device tree overlay file: cape-universala

After searching I found this: https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/43

recommending updating overlays (“things have changed”)…

So I went here: https://github.com/beagleboard/bb.org-overlays

and did this:

debian@BBB:~$ sudo apt update ; sudo apt install bb-cape-overlays

debian@BBB:~$ apt show bb-cape-overlays

Package: bb-cape-overlays

Version: 4.4.20171215.0-0rcnee1~jessie+20171215

Maintainer: Robert Nelson robertcnelson@gmail.com

Installed-Size: 2,003 kB

Depends: device-tree-compiler

Priority: extra

Section: misc

Download-Size: 59.5 kB

APT-Manual-Installed: yes

APT-Sources: http://repos.rcn-ee.com/debian/ jessie/main armhf Packages

Description: Device tree overlays for Beaglebone.

Device tree overlays for Beaglebone /lib/firmware/

But now have a new problem:

debian@BBB:~$ config-pin p9_29 pruout

bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or directory

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state

debian@BBBr0C0-1:~/node$ config-pin -a p9_29 pruout

bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or directory

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state

I did read about moving away from kernel overlays to uBoot overlays here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

but am no closer to a solution. I am now under time pressure and prefer to make minimal changes to my system. Can anyone help with suggestions to work around this?

2

The package "bb-cape-overlays" needs to stay in sync with the kernel.
(Since config-pin does not auto-generate the pin options.)

Your going to need to update the kernel:

4.4.30-ti-r64 -> 4.4.91-ti-r140

Switch to u-boot overlays, with these options in /boot/uEnv.txt

enable_uboot_overlays=1
disable_uboot_overlay_audio=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
enable_uboot_cape_universal=1

if you run into any issues with settting up ^

Just run:

sudo /opt/scripts/tools/version.sh

then we can debug it..

Regards,

3

Thank you Robert. In the long term I will certainly do as you suggest. Is there no way to “downgrade” or use an overlay for pin configuration that is in sync with my current (4.4.30) kernel version?

If that is not possible, will the 4.4.91 version you recommend support uio_pruss? I will have to review my notes, but my recollection is the remoteproc/uio driver debate was raging when I decided on this route, and it took some effort for me to figure out how to make it work.

Finally, if I must move to 4.4.91, would you kindly state how I can accomplish this with all pinmux/helper/config/overlay items also being synced without disrupting uio_pruss?
I presume this:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh
sudo reboot

will result in the latest kernel version (4.9.x??) which is not what I want…

4

Thank you Robert. In the long term I will certainly do as you suggest. Is
there no way to "downgrade" or use an overlay for pin configuration that is
in sync with my current (4.4.30) kernel version?

Yes, source is available:

If that is not possible, will the 4.4.91 version you recommend support
uio_pruss? I will have to review my notes, but my recollection is the
remoteproc/uio driver debate was raging when I decided on this route, and it
took some effort for me to figure out how to make it work.

You said you were using uio_pruss, so i gave you specific directions
for uio_pruss with v4.4.x-ti. :wink:

Finally, if I must move to 4.4.91, would you kindly state how I can
accomplish this with all pinmux/helper/config/overlay items also being
synced without disrupting uio_pruss?
I presume this:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh
sudo reboot

will result in the latest kernel version (4.9.x??) which is not what I
want...

Nope, if you have v4.4.x-ti installed, that ^ will install the latest
v4.4.x-ti..

Regards,

5

I’m back to working on getting all 10 pru0 pins working for my final design. Rather than loading a new version and hoping for the best, I’d like to use this as a learning opportunity for better understanding of how device trees, overlays, pin-config, uBoot all work together.

  • Is there a recommended (organized) source for this type of information? I find that currently I’m finding fragmented information requiring me to piece it together for a complete understanding (which I sometimes do incorrectly). I’d be very happy to be able to read and learn on my own rather than ask for help - questions which may be obvious or simple for those that have the complete picture.

  • on the elinux.org BeagleBone pages I read that “kernel overlays are going bye-bye” and “too many bugs, no dev interest…”. So does this mean that exactly one dtb is loaded at boot and is immutable? Or that a “base” dtb with additional overlays can be used, but all must be specified at boot time and cannot change thereafter? I thought there was a lot of excitement about (and promotion of) the concept of using a cape overlay system to change the system configuration. (Piecing together fragments here) was the final analysis that on-the-fly hardware configuration changes are not really frequent, so boot-time reconfiguration was a reasonable trade-off for simplifying the overall system?

  • I still don’t know why my current configuration only allows me to configure some pru pins using config-pin. (Example: I can configure P9-27 and P9-30 as pruout but not P9-25.) I’ve looked at the config-pin output, and the tables/information contained in the script itself, and all seem to show the pins properly defined as having a pruout mode - yet it doesn’t work. I’m using the reference by Derek Molloy compiled to a convenient table format (here: http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP9Header.pdf) which indicates each of these pins are allocated for use by mcasp_0.

  • I looked at the source RCN linked below (bb.org-overlays) but don’t know what I need to build: is it a new .dtb, or config-pin script? On my system I see that there is no “state” file for the pins I cannot configure for pruout. I see cape-universala (and cape-universaln and cape-universal) in /lib/firmware, but when I use config-pin attempting to load it that fails. It seems my system is incorrectly configured…

Note that I am using uio_pruss drivers and a workable solution must be compatible with this.