Hey @gomer , I never knew about the -i argument for the config-pin utility. Thank you again…
thanks to your initial question, we both learned much.
gomer
1 Like
No. P8.15 => Ball U13 => GPMC_AD15 => conf_gpmc_ad15 => offset 0x83c - 0x800 => 0x3c.
There’s your value!
As Robert has iterated many many times, config-pin is going away, so forget about it.
1 Like
OUCH! … lucky for me, I don’t chase the new kernels… why is it going away?
Right about config-pin. I noticed it gone on many images. I just grabbed the last Buster image to test with some older source called beagleg.
Supposedly, this source can handle pushing up to about six motors or seven I guess.
On my image, config-pin is still around and I think I need it for setting up pins but maybe not.
Maybe I just need to account for the pins in a DTS file and compile it, load it, and then reboot. Either/and/or, I cannot get the communication down pat just yet.
Also, like you stated, gpmc is a thing and that thing is listed under config-pin when querying the pin, i.e. P8.15. I have gpio, gpio_pu, and pruin, pruout, and etc…
If you say forget it, I will forget it. Hopefully, there is another way around the image to try to install this source and use it. I am still new to it. So, learning about it just recently is giving me cyclic methodologies for now.
Seth
P.S. Left-right-left, halt. And, then repeat. Argh…
And thank you for clarifying 0x3c and/or 0x03c is the hex value for the build. I thought that was it. I just had to make sure.
My guess is because its unnecessary and fragile. I fact it’s already breaking - the original -a option core dumps so it’s just been removed in the versions that (used to) ship with bbb and friends.
Anything you need to do with config-pin can be achieved in other ways. For example config-pin P9.22 gpio simply does:
echo gpio > /sys/devices/platform/ocp/ocp:P9_22_pinmux/state
If you want to know how do something that used to be handled by config-pin, just grab the source:
https://raw.githubusercontent.com/beagleboard/bb.org-overlays/master/tools/pmunts_muntsos/config-pin.c
1 Like
and right…
But writing the entire source over again may be counterintuitive for me, i.e. if you know me.
I only can handle so much! But yes sir about the echo command. And thank you for the source…
I found pmunts_muntsos on the BBB image I currently have now (Buster). It is an older image that I thought would provide some type of older technology to handle this library for promoting motor movement with PRU(s).
I think since the conception of this library, the other PRU was not used for wakeup but is used for wakeup now.
update
Oh. You were discussing things with gomer. Sorry…I just saw that snippet.
on my systems it is a ‘dash’ script… with the details mostly hard coded … so not too informative:
debian@bbb21:/dev/shm$ file /usr/bin/config-pin
/usr/bin/config-pin: a /bin/dash script, ASCII text executable
debian@bbb21:/dev/shm$
I thought at one time that its’ study would answer all the questions… no such luck
gomer
There’s a note at the top of config-pin.c that says it’s compatible with the shell script, so these presumably are the same, just written in different languages.
All the info you need is in these source files. Here’s what I distilled from the .c source:
list modes (-l option):
Read the file /sys/firmware/devicetree/base/ocp/P[x]_[y]_pinmux/pinctrl-names
query current mode (-q option):
Read the file /sys/devices/platform/ocp/ocp:P[x]_[y]_pinmux/state
set the mode:
Write the mode to /sys/devices/platform/ocp/ocp:P[x]_[y]_pinmux/state
then, if mode is gpio, use gpioinfo and gpiofind to get the gpio number and write the direction to /sys/class/gpio/gpio[n]/direction
The paths given above are for the BBB, see the source file itself for the paths for the BeagleY.
I agree that just using the utility itself is far more convienient but I wonder whether time spent maintaining it for the different platforms is time that RCN would much rather devote to more valuable tasks.
where is the ‘-i’ mode, which shows the egpio bit and which pru the pin is attached to? …
answer: it is hardcoded in the tool, not detailed in /sys nor the device tree… true?
gomer
There is no -i mode in the official version I have on my BBB nor in the source file I referenced. I dont know what version you have …
debian@bbb21:/dev/shm$ uname -r
4.14.71-ti-r80
debian@bbb21:/dev/shm$ config-pin -i P8_15
Pin name: P8_15
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin
Function information: gpio1_15 default gpio1_15 gpio1_15 gpio1_15 gpio1_15 eqep2_strobe pru_ecap pru0_in15
Kernel GPIO id: 47
PRU GPIO id: 79
debian@bbb21:/dev/shm$
That’s fairly old, I’m on 4.19.94-ti-r42. It seems the -i option has been removed some time in between.
I know it’s old … but it does everything I need… also still compiles code from Doctor Bernsteins’ https://cr.yp.to/ …
what do new kernels do that I need? IDK.
gomer
Well, in this case newer version do less than what you need.
If you need to engage in a frustration filled and an utterly ridiculous time waste event, the newer kernels are just fine.
It is past the point of ridiculous any more, it seems like the 6.x is nothing but a huge pile of crap. So much stuff does not work. Problem is its key stuff like gpu drivers, networking drivers. That stuff is not a simple fix by any one.