On 05/17/17 13:42, William Hermans wrote:
> On Tue, May 16, 2017 at 7:41 PM, <ercolano7...@gmail.com
> <mailto:ercolano7...@gmail.com>> wrote:
> I've been a C and assembly programmer since the 80's, but all of this
> with dtc is still pure greek to me. I'm assuming the original intent
> was to install the latest git version of the dtc compiler, though I'm
> not sure what implications the sed command has, so I'd defer to you or
> the OP's opinions.
>
> Well device tree overlay source files are not C, or assembly either.
> [..] I tend to view overlay source files more as something like xml,
> or some form of a markup language.
________________________________________________________________________________
Thanks -- I appreciate the XML analogy.
I did watch Jason Kridner's videos a few weeks ago which preped me
for learning the device tree file format; I was kinda ready for that
hurdle actually.
What I wasn't ready for was dealing with the internals of the
tools themselves. In the case of dtc, errors like "unit_address_vs_reg"
and things like uboot vs boot, and the language of the various tool
version numbers, what's mainline and what isn't..
Just couldn't grok, after only recently emerging from the wringer
of the last several days.
It's not just dtc I was encountering trouble with; it's been days
of hitting walls with other tools as well; my browser history tells
the sad tail of echo commands causing "kernel oops" errors, the pru
loader tossing up "prussdrv_open() failed" errors.. on and on.
The possible solutions to these issues led everywhere; get this
newer kernel, build this newer module, rebuild blobs, tweak boot flags..
it was supremely overwhelming and depressing.
What's wonderful about starting with the OP's disk image + script
is suddenly the sky cleared; having immediate success (minor bumps)
instead of walls of errors -- I could focus on the task at hand;
writing C code to run the PRUs.
Took hours to achieve success, instead of days achieving none.
BTW, this config-pin tool seems like maybe a way to avoid the
device tree stuff a bit; I see the LED flash example uses this.
Seems promising for my end use case where I just need to assign
GPIO pins to be in/out, and under PRU vs linux control. Its options
are kinda exactly what I need.
> C syntax highlighting in your text editor of choice to make your life easier.
Good idea -- I see there's a few vim syntax files for .dts files, e.g.
https://github.com/vim/vim/blob/master/runtime/syntax/dts.vim
In fact, with the OP's resulting disk image (and the one I posted),
using ':syntax on' in vim while viewing a .dts file seems to be
highlighting meaningfully, apparently due to this file:
/usr/share/vim/vim74/syntax/dts.vim
> Understanding the source files though just takes time, and knowledge
> of how pin-muxing, and several hardware aspect on this platform works.
Do you think the config-pin tool is a way around .dts?
If config-pin didn't exist, I'd probably write it just to avoid
having to manually derive hex codes from diagrams. (Huh, it's
a "dash" script.. cool. Was expecting python..!)
I see also someone made a web page that generates .dts,
using pulldown menus to select GPIO pins and in/out.
I like the promise of config-pin because it can be scripted;
end users could read/tweak its arguments, and a script could
check for errors and take alternative execution paths, and
print meaningful warnings on the user's console, instead of
mixed in with the voluminous output of dmesg and the syslog.
> How, I learned how the source files work, was to take one of the
> Universal IO overlay source files, and deleted everything in it
> except the main structure, and a single pin. At this point,
> you see all the different modes a pin can function as, and things
> become a bit clearer.
Cool -- if config-pin doesn't deliver for me, I'll do that!
Sounds like good advice to start with the dts file.. I take
it you mean the dts equivalent of the /lib/firmware/univ-all-00A0?
> It also helps to understand the hardware that you're trying to
> configure. Some of the simpler overlay source files such as for
> RTC, or 1-wire. Studying these should help one understand some
> things too. Such as how to load a driver from an overlay file,
> or how to configure an I2C device bus address from an overlay file.
> In the end it just takes time.
Interesting; I wasn't aware you can control the load of
device driver modules from dtc files.
I'm kinda used to using modprobe/insmod/rmmod commands
so that I can script them to check for errors. Kernel designers
have different design goals that industrial application devs.
I'll definitely need to learn .dts at some point though.
Perhaps this is as good a place to start as any:
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf
So I think my actual journey starts here.. the last several
days were all just getting a stable environment, which I'd
hoped the BBB image that shipped with the board would be..!
--
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/591D167A.9050109%40seriss.com.
For more options, visit https://groups.google.com/d/optout.
