On Thursday, May 18, 2017 at 3:58:03 PM UTC-7, William Hermans wrote:
>
> 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:
https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/pinctrl/omap.h
<goog_1749688536> ? (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
<http://www.embedded-things.com/bbb/beaglebone-black-pin-mux-spreadsheet/>
which references the AM335x Datasheet
<http://www.ti.com/lit/ds/sprs717f/sprs717f.pdf>, 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.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/57d986b6-a374-469a-b9f7-97228fa66d65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
