I’ve been trying to get my test hardware back up and running after corrupting node and bonescript, see my earlier post.
I’m trying to get up and running with an 8.6 image as I couldn’t get a 9.2 image to provide pru_rproc support
debian@beaglebone:~$ uname -r
4.4.54-ti-r93
I’m trying to get the eqep support working on P8_31,33 & 35 (it was working before)
debian@beaglebone:~$ sudo config-pin -l P8_31
default gpio gpio_pu gpio_pd uart qep
Looks like qep is a supported mode…
debian@beaglebone:~$ sudo config-pin P8_31 qep
[sudo] password for debian:
bash: line 0: echo: write error: No such device
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state
Any idea what is causing the above error? The important bits from uEnv.txt are:
##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
dtb=am335x-boneblack-overlay.dtb
cmdline=coherent_pool=1M net.ifnames=0 quiet cape-universal=enable
##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=cape-universala
Running:
sudo apt update ; sudo apt install bb-cape-overlays
Has fixed the eqep errors and the clash between p9_26 and p8_24 that I was seeing - however, pru_ecap has now gone as a mode for p9_42 - arggghhhhh!!!
Running:
sudo apt update ; sudo apt install bb-cape-overlays
Has fixed the eqep errors and the clash between p9_26 and p8_24 that I was seeing - however, pru_ecap has now gone as a mode for p9_42 - arggghhhhh!!!
I see from the most recent commit that this has been added back again as a mux option Robert, any idea when it will be pushed up and available through apt update?
Hi Hugh,
Yeah after your message yesterday, i went thru the overlays and
regenerated with *.dts/pinmux..
I'll have a full update for the kernel/config-pin/etc shortly
(plus gpio_input option will be available)..
Regards,
Top man, thanks for taking care of this. Let me know when it gets pushed up and i’ll re-run apt update
Okay all pushed out..
sudo apt update ; sudo apt upgrade bb-cape-overlays
sudo reboot
Please test it and let us know if those config-pin options work..
Regards,
debian@test-bbb-4:~$ config-pin -q P9.42
P9_42 Mode: default Direction: in Value: 0
debian@test-bbb-4:~$ config-pin -l P9.42
default gpio gpio_pu gpio_pd gpio_input spi_cs spi_sclk uart pwm pru_ecap
debian@test-bbb-4:~$ config-pin P9.42 pru_ecap
debian@test-bbb-4:~$ config-pin -q P9.42
P9_42 Mode: pru_ecap
Regards,
Thanks Robert, I won’t be back in front of my BBB till Monday now but I’ll be sure to test it first thing.
When I load a .dtbo though my uEnv.txt file (ie, uboot_overlay_addr4=/lib/firmware/bone_eqep2b-00A0.dtbo ) I no longer have access to config-pin’s ability to set up ANY pins. Is there some sort of exclusiveness built into the system such that if .dtbos are found, then you cannot manually configure pins after boot with the config-pin utility?
My system info:
[root@beaglebone]> uname -a
Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l GNU/Linux
Thanks in advance!
You basically have 2 options regarding pinmuxing on a bb.... the config-pin utility requires the universal cape to be loaded as the only dtbo, you then use configure-pin to setup the pins you want.
2nd option, specify the overlays for the actual hardware you want to use, e.g robotics cape, bone-eqep2 etc. You can’t load the specific overlays and the universal cape together, they conflict, and you can’t use confit-pin without the universal overlay being loaded.
Personally, given I’m using a ton of pins for various things, I use the universal overlay then have a script that runs from init.d to configure all the pins at boot time. I preferred the convenience of using the config-pin utility as apposed to writing my own device overlay for the pins I’m using.
Robert, everything is working nicely at this end with the new version of bb-cape-overlays. Thanks
Thanks!! Very helpful. One issue with just using the config-pin utility is that it doesn’t always give you access to all the configurations possible for a peripheral (not pin), for instance, setting a pin to eqep (qep), there are actually several modes of eqep. The dts file often includes all these options.
That is a very valid point and something I hadn’t considered. I was working around this by using my pru code to configure the required peripheral registers directly, which now I look at it seems a terrible way to do it when I could use the dts file…