Redirect user0 led to different pin

I want to redirect the heartbeat going to user0 led to a different pin. I think I’m beginning to understand the device tree, but a lot of stuff doesn’t make sense. I’ve turned the heartbeat off, but I’m not sure if I can redirect it.
There are 2 places in the devicetree that reference the user leds that I can see:
here—

pinmux@44e10800 {
compatible = “pinctrl-single”;
reg = <0x44e10800 0x238>;
#address-cells = <0x1>;
#size-cells = <0x0>;
pinctrl-single,register-width = <0x20>;
pinctrl-single,function-mask = <0x7f>;
pinctrl-names = “default”;
pinctrl-0 = <0x3>;
linux,phandle = <0x12>;
phandle = <0x12>

pinmux_userled_pins {
pinctrl-single,pins = <0x54 0x7 0x58 0x17 0x5c 0x7 0x60 0x17>;
linux,phandle = <0x3>;
phandle = <0x3>;
};

and here —

gpio-leds {
compatible = “gpio-leds”;
pinctrl-names = “default”;
pinctrl-0 = <0x3>;

led0 {
label = “beaglebone:green:usr0”;
gpios = <0x5 0x15 0x0>;
linux,default-trigger = “heartbeat”; /*<— I changed this to “none” to turn off the heartbeat */
default-state = “off”;
}; …

Questions:

  1. Why don’t the nodes “pinmux_userled_pins” and “led0” have “compatible” labels, I read all nodes should.
  2. How are the addresses for gpio-leds linked to the pinmux addresses
  3. Is there a driver called “gpio-leds”? Does it have documentation?

You are right. It can be done. You can't redirect it but you can create a new, or two, or any amount you want.
I'm doing it with the status led on the BeBoPr: Have a look at my overlay here: <https://github.com/modmaker/BeBoPr/wiki/Device-Tree-Overlay-and-devices>

-- Bas

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.

  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?

  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.

  3. is “exclusive-use =” a standard tag in device trees? I assume it prevents other process from accessing the peripherals you allocate.

It’s been a while… I used Google and the kernel source code. 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). 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 ! Good question, hopefully I did answer part of it above. Where do you get this from? 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. 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 :slight_smile: – Bas

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