I have found the child node names in fragment@2 must be P8_26_pinmux and P9_12_pinmux in order for config-pin to work with them. When I use these names and have the universal cape enabled, the corresponding gpio folders (gpio60 and gpio61) are present within /sys/class/gpio. If I don’t enable the universal cape, I have to export them manually.
During the boot sequence the pin is high, and I suspect it is operating as an input until Linux processes the overlays. Is this unavoidable, or is there some other configuration I can do to make the pin initialize as an output as the board comes online?
The direction file in sysfs always reads in after reboot despite the fact the pin is correctly muxed as an output. Is this just a bug in sysfs?
debian@beaglebone:~$ /opt/scripts/device/bone/show-pins.pl | grep P9.12
P9.12 30 U18 fast down 7 gpio 1.28 ocp/P9_12_pinmux (pinmux_tot_acp_P9_12)
debian@beaglebone:~$ cat /sys/class/gpio/gpio60/direction
I still haven’t resolved either of the 2 known issues. I did publish my article, regardless, so if anyone is inclined to purse a solution to the boot sequence pinmux or the sysfs direction mismatch my steps are fully documented as below.
Sadly, the reset state of the AM335x GPIO is in affect at power-on… You could also set the pin in u-boot to ensure it’s default state longer during boot… But sadly during linux initialization it’ll also return to reset. There is a devie-tree option to bypass this on boot, “gpio-hog” but sadly it’s not designed to be used as a toggle pin, it’s more of I ‘forgot’ a resistor pull-up, on a special pin.
For your example, i usually recommend user to use ‘gpio-led’ it supports startup states, and a single command to output high or low…
I definitely get more answers from this forum than I provide, so I’m happy to share what I can! Thanks for checking out the blog post, and please do let me know if you spot anything that can be improved.