So a lot of text there to “Wade” through so I’ll try to answer the questions you have in order. Without the “Sea of text” 
No walls of text; OK, will try to keep it shorter.
I think Universal IO, which includes the shell script config-pin is a really cool tool for getting started. Especially, when all you want to do is get down to writing code for the hardware. However, at the same time I strongly feel that it is not a permanent solution for configuring the hardware, especially for a production system. For many reasons, partly because there can be some glitches, and partly because now we have uboot overlays, that one can load through the second stage bootloader. Which also means, for a production system you can have your pins, and hardware configured exactly how it needs to be. Prior to Linux being up and running. If you script config-pin, this has to be done after Linux is running.
Definitely going to consider those concerns, and keep an eye out for them in my setup.
In my case I envisioned config-pin in /etc/rc.local to run once, and be able to run it in real time so field personnel can change/experiment. For instance to make a change for a pin to have a pull-up instead of without one.
I read dev tree files can only be loaded on boot (?), IIRC the binary is loaded ahead of the kernel in ram by the boot loader, so I think dev cycle for dev tree files is harder for the field person, as a recompile + reboot is needed each time. It’s hard enough getting field people to just edit config files.
I’d also like to avoid field people seeing two ways of doing things. During support calls, one could compete with the other in unpredictable ways… better to provide only one way to do something.
Let’s take this:
/* P8_07 (ZCZ ball R7 ) */
P8_07_default_pin: pinmux_P8_07_default_pin {
pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */
This is just part of configuring a pin. Obviously for P8_07. So for pins that can be operating in GPIO mode. This will be the first entry in any of the universal io overlay files. The first line after the comment is pretty much just a “#define”, or a “prototype” definition of the pin in question. Kind of like prototyping a function in C. The second line after the comment is the actual pin information. 0x090 being the pin, which is a kernel pin identifier I think. The second number 0x37 is the mux, and pullup mode( put simply ). You can read the TRM and get a much better explanation of the mux / pullup mode register.
I see – I’ll do some reading to try to figure out what actually parses this info on boot, as I like to understand what tool/driver is looking at the file I’m configuring, in case I need to RTSL to figure out what’s wrong when errors occur. If it’s a built in kernel driver (cape driver maybe?)
I did read petazzoni’s “Device Tree For Dummies” last night to try to determine the big picture, but it really lost me somewhere in the middle. Just too much… stuff… I didn’t want to know or track down. It assumes a knowledge of the modern kernel terminology that I just don’t have.
Anyway, check this out. https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/board/am335x-bbw-bbb-base.h#L17 The point here, if you #include Robert’s header file, you can use all the BONE_Px_xx #defines in place of the actual “kernel pin value”.
I see, so I take it these two lines would be equivalent, the lower one my construction:
pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive /
pinctrl-single,pins = <BONE_P8_07 0x37>; }; / Mode 7, Pull-Up, RxActive */
…yes, symbols would be better than hex.
Which can( does for me ) remove a lot of tedious work trying to memorize, or digging through documentation just to get a pin to work the way you want. Additionally, there is another header file, which #define mux, and other register modes. These two headers alone can take a lot of learning pressure off your shoulders. Then if like me, you do know C very well ( I’m assuming you do ), you can read through these source header files, along with the TRM, or whatever documentation that makes the most sense to you. Suddenly, that light at the end of the tunnel starts to appear. Pullup modes, you simply OR together ( FOO | BAR )
Yes, it’d be much easier on the eyes if 0x37 could be a few macros OR’ed together instead. Would those values be found in, just guessing: bb.org-overlays/include/dt-bindings/pinctrl/omap.h at master · beagleboard/bb.org-overlays · GitHub ? (Same project, different file)
I wouldn’t mind magic numbers if the reference table was in the same document (ascii art preferred to a link, as links go stale).
For fun, I tried to determine what 0x37 means. You referred to the “TRM”, which I take to mean the Sitara Tech Ref Manual (rev c)… that ~2300 page monster! Spent a bit of time in there, but was unable to figure out which table was relevant.
At first I thought maybe Table 1-236 “PINCTRLn Register Field Descriptions” and Table 1-237 “PINCTRLn Register Pin Multiplexing”, but the bits didn’t match up. I searched for “mux mode” but that only appeared in the HD video section, and searching for “RxActive” (from the .dts file’s comment) without any match at all.
I googled around and found this spreadsheet which references the AM335x Datasheet, but the link is dead. I found a working link, but was unable to find the table. The speadsheet seems to show some info, so from that I determined 0x37 means “an output with a pullup”, which matches the comment. The spreadsheet doesn’t say what the lower 3 mode bits are for though. Seems like they weren’t sure, as it was left blank.
Anyway, right now I am kind of busy with work related code. Bu maybe, sometime soon I can make a working device tree overlay, with an explanation of the file for one pin. Put it on my blog page, and link back to it. The problem with that, is it often takes more work to create a post, than it does to actually just write the code, and maybe explain it, if needed.
Sounds good – If you do, I do think comments and inline comment ascii-art tables would help folks. I spent an hour or two floundering around, still not 100% sure what I found.
I do see one of the TI datasheets referred to a windows utility to calculate the pin mux values… seems that should really be an html/javascript so it can run platform independent, and can be referenced with a link or included locally as an html/js pair. But mainly I don’t have a windows box handy ATM.
