Hi Bas,
I know it has been a while since you've talked about this topic, but I came
across it while searching for a solution for my problem. (beaglebone black
with Debian wheezy kernel 3.8.13)
I also want to drive some pins with the "heartbeat" and "cpu0" events, and
I succeeded, however, by changing the Data Tree Blob (
/boot/uboot/dts/am335x-boneblack.dtb ); converting to .dts, modifying and
converting back to .dtb. But I wanted to create a Overlay that so I could
load and unload at my taste.
I've created the overlay as follows in file
/lib/firmware/activityOnPins-00A0.dts:
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* identification */
part-number = "activityOnPins";
version = "V1";
exclusive-use =
"P9.14",
"P9.16",
"ehrpwm1a",
"ehrpwm1b";
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
act_leds: pin_mux_act_leds_pins {
pinctrl-single,pins = <
0x48 0x7
0x4c 0x7
>;
};
};
};
fragment@1 {
target = <&ocp>;
__overlay__ {
activity_leds {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&act_leds>;
actled_heartbeat {
label =
"beaglebone:actled:heartbeat";
gpios = <&gpio1 18 0>;
linux,default-trigger = "heartbeat";
default-state = "off";
};
actled_cpu {
label = "beaglebone:actled:cpu";
gpios = <&gpio1 19 0>;
linux,default-trigger = "cpu0";
default-state = "off";
};
};
};
};
};
I compile it with:
root@beaglebone:/lib/firmware# dtc -O dtb -o activityOnPins-00A0.dtbo -b 0
-@ activityOnPins-00A0.dts
without any problems; then I load it with:
root@beaglebone:/lib/firmware# echo activityOnPins >
/sys/devices/bone_capemgr.9/slots
And I can confirm it it appears on the slot. However checking dmesg I get:
[ 165.034412] bone-capemgr bone_capemgr.9: part_number 'activityOnPins',
version 'N/A'
[ 165.034605] bone-capemgr bone_capemgr.9: slot #8: generic override
[ 165.034657] bone-capemgr bone_capemgr.9: bone: Using override eeprom
data at slot 8
[ 165.034709] bone-capemgr bone_capemgr.9: slot #8: 'Override Board
Name,00A0,Override Manuf,activityOnPins'
[ 165.037350] bone-capemgr bone_capemgr.9: slot #8: Requesting part
number/version based 'activityOnPins-00A0.dtbo
[ 165.037418] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware
'activityOnPins-00A0.dtbo' for board-name 'Override Board Name', version
'00A0'
[ 165.043234] bone-capemgr bone_capemgr.9: slot #8: dtbo
'activityOnPins-00A0.dtbo' loaded; converting to live tree
[ 165.044391] bone-capemgr bone_capemgr.9: slot #8: #2 overlays
[ 165.053464] of_get_named_gpio_flags exited with status 19
[ 165.053518] of_get_named_gpio_flags exited with status 18
[ 165.053561] of_get_named_gpio_flags exited with status 19
[ 165.054122] of_get_named_gpio_flags exited with status 18
[ 165.059018] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.
is it normal? I also see that the directories
/sys/class/leds/beaglebone:actled:cpu and
/sys/class/leds/beaglebone:actled:heartbeat are created.
*My problem is*, after loading the dtbo the pins don't start indicating the
CPU's and Heartbeat, and I can't even control them manually by writing to
"brightness" file. Do you know where I'm doing the mistake?
I hope you can help me. Thank you a lot.
cumps,
JCBastos Portela
On Tuesday, July 9, 2013 at 9:31:03 PM UTC+3, Bas Laarhoven wrote:
>
> On 9-7-2013 19:13, mron wrote:
>
> Bas,
> Thanks for your reply. I looked at your overlay file. It looks like you
> know what you're doing so I'd like to ask some questions to clear up some
> confusion I have about device trees. If you can refer me to reference
> pages, I'd appreciate it.
>
>
> It's been a while... I used Google and the kernel source code.
>
>
> 1) I see where you assign a "heartbeat" to a pin under the /*--- LED
> ----*/ section. Why do you have 2 fragments, one targeting <&am33xx_pinmux>
> and another targeting <&ocp> ? I see this pattern frequently in overlay
> examples. In other cases you target the resource directly i.e.
> fragment@22 {
> target = <&pruss>
> What determines how you target?
>
>
> In fact, there are 3 sections for each pin:
>
> The first in the exclusive-use section. Here you specify the used
> resource. It seems like a bunch of text strings that can be used to
> determine conflicts,
> I'm not sure if these are really used and whether conflicts are detected.
> AFAIK you can put any string in the list.
>
> Second, you must let the pinmux driver know how to configure the pin. By
> this you're connecting the (hardware) pin to an internal device.
>
> Third, you'll often want to initialize a some driver to connect to a
> single or set of pins.
>
> How does this map to your LED:
>
> You'll find the LED output in the exclusive-use section:
>
> "P8.25"; /* gpio1.0 LED */
>
> The pinmux setting is done in fragment51 of the example:
>
> pinctrl-single,pins = <
> 0x000 0x07 /* P8-25 GPIO1_0 gpmc_ad0
> .gpio1[0] */
>
> And finally, the pin is being driven by the gpio-leds driver as determined
> in fragment52:
>
> bebopr_leds {
> compatible = "gpio-leds";
> pinctrl-names = "default";
> pinctrl-0 = <&bebopr_led_pins>;
>
> status_led {
> label = "bebopr:status_led";
> gpios = <&gpio2 0 0>;
> linux,default-trigger = "heartbeat";
> default-state = "off";
> };
>
> If you look in /sys/devices/ocp.2, you'll find a 'bebopr_leds.*' directory
> with a
> 'leds/bebopr:status_led/trigger' file. If you cat that file, you'll see
> the options
> that can be set (like some other - software - level of pinmuxing).
> "heatbeat"
> is one of these options. IIRC you can also configure the output as normal
> gpio.
>
> With the PWM signals I'm playing some tricks so that I can configure the
> pinmux
> setting from userspace without having to load a new overlay. Each of the 3
> PWM
> outputs has 3 (one has only 2 but I'll ignore that for now) possible
> sources: Each
> pin can either been driven by a GPIO pin driver, a PRUSS output or a
> EHRPWM output.
>
> The pinmux-helper driver exports these to the sysfs and initializes the
> pinmux to the
> 'default' setting. But you can override this by writing a value string
> ("default", "pruss"
> or "gpio") to the 'state' file in the corresponding pinmux directory (e.g.
> bebopr_pwm_J2_pinmux.11).
>
>
> 2) It looks like you use many drivers in your system. Which ones are
> openly available? Where do you find docs for them? For instance, "
> bone-pinmux-helper" and "gpio-leds" are used in many examples, but I
> can't find their usage described.
>
>
> I've found little documentation on all these features. As you'll often
> hear with Linux:
> the source is the documentation. Search, discover and try !
>
> 3) is "exclusive-use =" a standard tag in device trees? I assume it
> prevents other process from accessing the peripherals you allocate.
>
>
> Good question, hopefully I did answer part of it above.
>
>
>> Questions:
>> 1) Why don't the nodes "pinmux_userled_pins" and "led0" have "compatible"
>> labels, I read all nodes should.
>>
>
> Where do you get this from?
>
> 2) How are the addresses for gpio-leds linked to the pinmux addresses
>>
>
> The silly thing with this naming or addressing scheme is that there's no
> architect
> who controls the namespaces. For each pin there are too many ways to name
> that pin. I spend quite some time looking up names/ pins/ offsets. With
> the overlays.
> If you look in the above example: gpio1[0], gpio32, P8.25, gpmc_ad0,
> '&gpio2 0' (yes,
> this is not a typo!) and offset 0x000 are all referring to the same
> resouce. And this
> list is not even complete.
>
> 3) Is there a driver called "gpio-leds"? Does it have documentation?
>>
>
> See above
>
> I hope to have answered some of your questions. I'm not a DT expert, just
> someone
> who doesn't give up easily :-)
>
> -- Bas
>
> --
> 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] <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
--
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.
