> On Dec 28, 2014, at 21:20 , Robert Nelson <[email protected]> wrote:
>
> On Sun, Dec 28, 2014 at 11:04 PM, Rick Mann <[email protected]> wrote:
>>
>> A) What does it mean for all those resulting .dtb files to be in the
>> /boot/... directory? Do they all get loaded? Does only the main one
>> ("am335x-boneblack")?
>
> Only one "*.dtb" will get loaded by u-boot from /boot/
>
> For most "capes" (that work in v3.14.x) i've created a single *.dtb
> file for them.
>
> am335x-boneblack-<cape>.dtb
>
> This is what the commented out "#dtb=" variable in /boot/uEnv.txt is for.
>
> Say if you have the "4dcape-70t" cape plugged in and you don't want to
> edit anything between kernel versions you'd set:
>
> dtb=am335x-boneblack-4dcape-70t.dtb
So, I should create something like "am335x-boneblack-podtique.dtb" and set that
in uEnv.txt. And to create that, I could follow the Argus example as per your
answer to question (F).
>> B) In the Argus example, all the &ocp/..._pinmux statuses are set to
>> "disabled." Wouldn't I want the pinmux to be enabled ("okay")? What does it
>> mean to disable the pinmux?
>
> So the *_pinmux status are for the cape-universal. If you'd like to
> use "pin-config" in userspace you'd have to define those to a default
> state. In our case with the Argus it's not fully converted over so we
> control the pin stage in the am33xx_pinmux instea.
The more I can do in user space, the happier I am, but I have to be able to do
it from C-code (preferably without exec-ing some other program). I don't know
anything about "pin-config", but vaguely recall that this is something you
mentioned will be ready in the next few days, hopefully? Sadly, that will be
too late for now, so I'm okay with just getting it right in the dtb.
>> E) What does "debug" and "shutdown" do?
>
> Which reference is that too?
https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-argus.dtsi#L66
>> F) I'm going to add version of each of these ampersand-nodes, and a root
>> node, just like the argus ones, replacing "argus_ups" with "podtique", and
>> adjusting the pins to what I need. Is that the right approach? That will
>> result in am335x-boneblack.dts having multiple root nodes, and multiple &ocp
>> and &am335x-pinmux nodes. Eventually, this suggests making a separate .dtsi
>> with all the stuff for my cape, and just including it into .dts, right?
>
> Yeap, that's the best way.. Just edit your own *.dtsi and include it.
>
> Btw, there's two ways of doing gpio's..
>
> Say if you have a key event, and you want something done look at gpio-keys:
>
> https://github.com/beagleboard/linux/blob/3.14/Documentation/devicetree/bindings/gpio/gpio_keys.txt
>
> rtc example, gpio to wake up with:
>
> https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-rtc-01-00a1.dtsi#L27
>
> There's a few other specially ways here:
>
> https://github.com/beagleboard/linux/tree/3.14/Documentation/devicetree/bindings/gpio
Hmm. Right now, my main thread loops at about 10 Hz, reading the state of the
ADCs and GPIOs, and passes those to an object that manages another thread of
execution. Each time through that second thread's loop, it uses the state that
was set to adjust its behavior. That works pretty well for me, as neither
thread is terribly busy. The one thing that would be nice eventually would be
to use one of the GPIOs to let the whole thing go into a low-power sleep mode,
and then wake on change. But for now, I can do without that.
>> G) What should my uEnv.txt look like? It currently looks like this:
>> http://pastebin.com/3fx5SDb9
>
> That looks fine. If we ever ship a new default image, that's exactly
> how the new default will look like.
Will the capemgr lines be there? It's not clear to me if capemgr is deprecated
or just temporarily broken and will be coming back.
Assuming it's gone, how do I disable HDMI? Just remove the #include lines that
reference it from "am335x-boneblack.dts"?
Thanks!
--
Rick Mann
[email protected]
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.