More pimux woes

[Hugh Frater]

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

[Hugh Frater]

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!!!!

[Hugh Frater]

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?

 

[Robert Nelson]

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,

--
Robert Nelson
https://rcn-ee.com/

[Hugh Frater]

Top man, thanks for taking care of this. Let me know when it gets pushed up and i'll re-run apt update

[Robert Nelson]

On Fri, Jan 19, 2018 at 10:25 AM, Hugh Frater <hugh....@gmail.com> wrote:
> 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..

[Robert Nelson]

On Fri, Jan 19, 2018 at 2:25 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Fri, Jan 19, 2018 at 10:25 AM, Hugh Frater <hugh....@gmail.com> wrote:
>> 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..

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

[Hugh Frater]

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.

[lgil...@tethers.com]

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!

[Hugh Frater]

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.

[Hugh Frater]

Robert, everything is working nicely at this end with the new version of bb-cape-overlays. Thanks

[lgil...@tethers.com]

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.  

[Hugh Frater]

On Monday, 22 January 2018 17:42:03 UTC, lgil...@tethers.com wrote:

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...