Missign control for RED "Power LED"

[jgrulich]

At the RPi3 B+ board there is missing the control folder for led1 in the ../soc:leds/leds/ folder.
How to control the function or this RED LED than?

[popcornmix]

The power LED is different on Pi3. It is controlled from GPU through a GPIO expander which is configured as an input. It may not be possible to drive it from the arm (certainly it is not currently).

[jgrulich]

What's the reason of this change?
I need to swap the LEDs to have the logical function as Green - power on and
Red - mmc0.

---------- Původní zpráva ----------
Od: popcornmix [email protected]
Komu: raspberrypi/linux [email protected]
Datum: 9. 3. 2016 14:54:12
Předmět: Re: [linux] Missign control for RED "Power LED" (#1332)

"

The power LED is different on Pi3. It is controlled from GPU through a GPU
expander which is configured as an input. It may not be possible to drive it
from the arm (certainly it is not currently).

—
Reply to this email directly or view it on GitHub
(#1332 (comment)).

"=

[popcornmix]

Pi3's BT/wifi support required a number of additional GPIOs compared to Pi2.
The ACT and PWR leds had to move to make that possible.

[jgrulich]

OK than, and is there some way how to switch the RED LED off?
And why is not working at least the "pwr_led_gpio" redirection to connect it
via GPIO?

---------- Původní zpráva ----------
Od: popcornmix [email protected]
Komu: raspberrypi/linux [email protected]
Datum: 9. 3. 2016 16:45:09
Předmět: Re: [linux] Missign control for RED "Power LED" (#1332)

"

Pi3's BT/wifi support required a number of additional GPIOs compared to Pi2.
The ACT and PWR leds had to move to make that possible.

—
Reply to this email directly or view it on GitHub
(#1332 (comment)).

"=

[pelwell]

The PWR LED on RPis since the B+ has doubled as an under-voltage indication. Since GPIOs are in short supply, as well as being an indicator it is also the under-voltage detector - there is some external circuitry that can detect the GPIO direction so that it is either an input with an automatic LED or an output. This circuitry is only present on the red LED. The ability to change the "PWR" LED pin to an output, as you must do to make it the ACT LED, bypasses the under-voltage detection, which is permitted but not recommended.

As @popcornmix says these LEDs are now on a GPIO expander, and controlled from the VPU. These GPIOs may never be available as fully featured GPIOs because they are too slow to use in many circumstances. There is a simple GPIO driver that can efficiently control the ACT LED, but more effort is needed to make it work with the PWR LED and change its direction to an output. This is something we may address, but it isn't high on the list of priorities at the moment.

[jgrulich]

Oops, that's too bad to have such a incompatibility with the previous
versions. Guess that it will be the same for the new A+ board.
It's not important that LEDs are mechanically moved, I don't use them.
But need the signals at the GPIO pins, because I need them at the expansion
cards.

---------- Původní zpráva ----------
Od: Phil Elwell [email protected]
Komu: raspberrypi/linux [email protected]
Datum: 9. 3. 2016 17:04:19
Předmět: Re: [linux] Missign control for RED "Power LED" (#1332)

"

The PWR LED on RPis since the B+ has doubled as an under-voltage and over-
temperature indication. Since GPIOs are in short supply, as well as being an
indicator it is also the under-voltage detector - there is some external
circuitry that can detect the GPIO direction so that it is either an input
with an automatic LED or an output. This circuitry is only present on the
red LED. The ability to change the "PWR" LED pin to an output, as you must
do to make it the ACT LED, bypasses the under-voltage detection, which is
permitted but not recommended.

As @popcornmix(https://github.com/popcornmix) says these LEDs are now on a
GPIO expander, and controlled from the VPU. These GPIOs may never be
available as fully featured GPIOs because they are too slow to use in many
circumstances. There is a simple GPIO driver that can efficiently control
the ACT LED, but more effort is needed to make it work with the PWR LED and
change its direction to an output. This is something we may address, but it
isn't high on the list of priorities at the moment.

—
Reply to this email directly or view it on GitHub
(#1332 (comment)).

"=

[pelwell]

What functionality do you want from a PWR LED on an arbitrary GPIO (wired to a HAT)? You can't get under-voltage detection, so it is basically just on or off under CPU control.

The reason the PWR LED definition was removed from the base DTB for the Pi3 is because (annoyingly) there is no easy way to declare the LED but not have it use a GPIO. However, if you tell me exactly how you want your LEDs to work - both the onboard ones and any on your HAT - then we might be able to come up with a scheme to support that.

[jgrulich]

It's much more complex.

1. On the applications, when used original housing, I'm using LEDs on board
   and than I need the correct colors, based on the technical standards. Means
   that the normal operation must be GREEN and error state is RED. Don't see
   any chance how to solve it.

2. In case of customized housing, or HAT board, I'm using the LEDs more
   likely the same way, only extended to front panel.
   In this case I may change the GPIO for GREEN one, but the RED one GPIO is
   missing.

3. or I use only the RED one, GREEN is off. In this case it's quite simple
   to solve with only changing the GPIO number I guess.

---------- Původní zpráva ----------
Od: Phil Elwell [email protected]
Komu: raspberrypi/linux [email protected]
Datum: 9. 3. 2016 18:02:39
Předmět: Re: [linux] Missign control for RED "Power LED" (#1332)

"

What functionality do you want from a PWR LED on an arbitrary GPIO (wired to
a HAT)? You can't get under-voltage detection, so it is basically just on or
off under CPU control.

The reason the PWR LED definition was removed from the base DTB for the Pi3
is because (annoyingly) there is no easy way to declare the LED but not have
it use a GPIO. However, if you tell me exactly how you want your LEDs to
work - both the onboard ones and any on your HAT - then we might be able to
come up with a scheme to support that.

—
Reply to this email directly or view it on GitHub
(#1332 (comment)).

"=

[pelwell]

Sorry for the slow response - I'm not at work.

For 1) if you are prorated to lose the under-voltage detection and display then we can swap the functions between the two pins - green for power, red for activity.

For the others, what the DT parameters are missing is a way to choose which GPIO controller to use. The best way to solve this is with a new overlay.

[ionciubotaru]

On raspberry pi 2 I read GPIO35 as un input to find out if raspberry is under-voltage.
How can I do this on raspberry pi 3 (I don't want to change pin behavior), all I need is to determine if rpi3 is under-voltage or not.

[mikerabat]

Too bad... I wanted to disable the power led since it should work as a sleeping monitoring device and it's not good to have any lights on. Beside removing the led is there any other way to just disable it?

[dblevins]

I'd also like to disable the PWR LED on the PI 3. Is there a "donate to get your feature" option :) Just purchased 169 PI3s for a project. Need the lights to be on/off configurable.

[6by9]

I know that dt-blob.bin is a pain from a maintenance perspective, but could those wanting to totally disable the power LED totally not amend the pins_3b2 section to have:

            pin@p135 { function = "output";  termination = "no_pulling"; }; // Power low
...
            pin_define@POWER_LOW {
               type = "absent";
            };

There is also the mailbox service that would allow userspace to fiddle with the outputs on the expander, but not set direction - see https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=109137&start=100#p990152 and https://github.com/6by9/rpi3-gpiovirtbuf

[mikerabat]

Hi!

Actually I'm quite a beginner in the raspberry world... So I guess the mail
box
service code seems to be the way to go.

Thank you for the link to the repository it seems a perfect fit :) the
problem is which
slots/ports are handling the pwr and act led?
Is 130 or 0 the act led?? - I don't wanna damage somthing on the Pi....

kind regards
Mike

On Sun, Jul 10, 2016 at 11:08 PM, 6by9 [email protected] wrote:

I know that dt-blob.bin is a pain from a maintenance perspective, but
could those wanting to totally disable the power LED totally not amend the
pins_3b2 section to have:

        pin@p135 { function = "output";  termination = "no_pulling"; }; // Power low

...
pin_define@POWER_LOW {
type = "absent";
};

There is also the mailbox service that would allow userspace to fiddle
with the outputs on the expander, but not set direction - see
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=109137&start=100#p990152
and https://github.com/6by9/rpi3-gpiovirtbuf

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1332 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AK_Pg7NFFebM_Xs4KmItbqq55BwkgN0cks5qUV9ZgaJpZM4Hsf52
.

[pelwell]

130 is the activity LED, so /opt/vc/bin/vcmailbox 0x00038041 8 8 130 1 will turn it on and /opt/vc/bin/vcmailbox 0x00038041 8 8 130 0 will turn it off. Be aware that any SD card activity will override the value you set, so if you really want programmatic control of that LED you should change the LED trigger:

sudo sh -c "echo none > /sys/class/leds/led0/trigger"        # Static LED off
sudo sh -c "echo default-on > /sys/class/leds/led0/trigger"   # Static LED on
sudo sh -c "echo mmc0 > /sys/class/leds/led0/trigger"        # The normal behaviour

Once the LED is in one of the static states you can control it using the vcmailbox commands above, or with @6by9's code utility or the API it uses. Alternatively just switch between the two different static states as above. Using the API from your own code will be the most efficient because it skips the overhead of process creation.

[mikerabat]

Wow thanks for the info!

Any chance to steer the pwr led in the same way on my raspberry 3?

kind regards
Mike

On Mon, Jul 11, 2016 at 3:14 PM, Phil Elwell [email protected]
wrote:

130 is the activity LED, so /opt/vc/bin/vcmailbox 0x00038041 8 8 130 1
will turn it on and /opt/vc/bin/vcmailbox 0x00038041 8 8 130 0 will turn
it off. Be aware that any SD card activity will override the value you set,
so if you really want programmatic control of that LED you should change
the LED trigger:

sudo sh -c "echo none > /sys/class/leds/led0/trigger" # Static LED off
sudo sh -c "echo default-on > /sys/class/leds/led0/trigger" # Static LED on
sudo sh -c "echo mmc0 > /sys/class/leds/led0/trigger" # The normal behaviour

Once the LED is in one of the static states you can control it using the
vcmailbox commands above, or with @6by9 https://github.com/6by9's code
utility or the API it uses. Alternatively just switch between the two
different static states as above. Using the API from your own code will be
the most efficient because it skips the overhead of process creation.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1332 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AK_Pg4OCM67-oh77KrH0OlJhFiiHeUWwks5qUkHHgaJpZM4Hsf52
.

[6by9]

For the complete list of GPIO allocations, look at the dt-blob.dts that configures the GPU side - https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts#L1175 Documentation is at https://www.raspberrypi.org/documentation/configuration/pin-configuration.md

AFAIK Direction can only be controlled via the blob at the moment - certainly that's the answer I got from popcornmix when I discussed it with him last. Adding a mailbox call to do that wouldn't be huge, but is just yet another job to be done.
Eric Anholt has already discussed adding a full driver for the GPIO expander using these mailbox calls - http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-June/004077.html

[canol]

Hello, we are using several Raspberry 3's in a controlled lighting environment. And several red LEDs certainly disturb our light measurements. We were able to turn all other LEDs other than the red LED off. Is there any way that we can turn the red LED off?

[6by9]

@canol Had you tried the dtblob changes I'd suggested in #1332 (comment) ?
If they don't work then I'll try to have a quick play tonight.

[6by9]

Just given it a whirl.

wget https://raw.githubusercontent.com/raspberrypi/firmware/master/extra/dt-blob.dts
nano dt-blob.dts

As above, make the changes:

@@ -1187,7 +1187,7 @@
             pin@p132 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Hotplug
             pin@p133 { function = "output"; termination = "no_pulling"; }; // Camera LED
             pin@p134 { function = "output"; termination = "no_pulling"; }; // Camera shutdown
-            pin@p135 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Power low
+            pin@p135 { function = "output";  termination = "pull_down"; startup_state = "inactive"; }; // Power low
          }; // pin_config

          pin_defines {
@@ -1236,8 +1236,7 @@
                type = "absent";
             };
             pin_define@POWER_LOW {
-               type = "external";
-               number = <7>;
+               type = "absent";
             };
             pin_define@LEDS_DISK_ACTIVITY {
                type = "external";

And
sudo dtc -I dts -O dtb -o /boot/dt-blob.bin dt-blob.dts
to compile and install it (sudo apt-get install device-tree-compiler if you haven't already got the compiler installed).

The red power LED then comes on as the Pi initially boots, but is very quickly turned off again. It does come back on when you do sudo halt, but not much can be done about that (I suspect it is the reset condition of the chip).

If you checkout https://github.com/6by9/rpi3-gpiovirtbuf, then now I've fixed a minor bug, using rpi3-gpiovirtbuf s 135 1 turns the LED off, and ending 0 turns it on again.

[rekcah1986]

"rpi3-gpiovirtbuf" No use for my pi3...

[6by9]

"rpi3-gpiovirtbuf" No use for my pi3...

??!
It's no use on your Pi because ....?
It's not present by default, you need to get the code and compile it yourself.

[rekcah1986]

pi@raspberrypi:/shells/rpi3-gpiovirtbuf $ ls
Makefile raspberrypi-firmware.h rpi3-gpiovirtbuf rpi3-gpiovirtbuf.c
pi@raspberrypi:/shells/rpi3-gpiovirtbuf $ make clean
rm -f rpi3-gpiovirtbuf
pi@raspberrypi:/shells/rpi3-gpiovirtbuf $ make
cc rpi3-gpiovirtbuf.c -o rpi3-gpiovirtbuf
pi@raspberrypi:/shells/rpi3-gpiovirtbuf $ ./rpi3-gpiovirtbuf s 135 1
Set state of 135 to 1

I'm sure it's my own. But the red led is still on. @6by9

[pelwell]

It will only work if you also generate a custom dt-blob.bin with the GPIO marked as an output, as described above. This is because the API to the firmware does not allow the pin direction to be changed.

@popcornmix What do you think about either adding an explicit direction property or making the existing get and set methods also change the direction appropriately?

[6by9]

My vote would be for a new direction property.
There's also the niggle that the GPIO expander doesn't allow reading back the state of an output, so the firmware driver probably needs to cache the value in those cases. Not difficult, just another job to find time for.

[davidpfahler]

It would be really useful to be able to shut off the power led, also. How can I contribute to make this feature possible?

[davidpfahler]

Update: Worked like a charm @6by9! Thank you.

---

@6by9 Thanks for your quick response and Merry Christmas. I did read the whole thread, but as far as I understand, the solution above requires some sort of recompilation. I'll try to make that work, but I was referring to a feature that can be toggled on / off with just one line or so. If that is not possible or easy to do, I understand, I just wanted to affirm the need for such a feature.

[Akko1]

I'm not sure if I'm performing something drastically wrong in getting the power LED to switch off but I have tried the dt-blob.dts process and then the rpi-gpiovirtbuff, i get the "Set state of 135 to 1" confirmation but the red LED remains on and persists even after attempted restarts. Thank you in advance.

[maxammann]

@Akko1 Maybe you are using an other revision of the PI 3. So you have to change it for the other revision:

@@ -1023,7 +1023,7 @@
             pin@p132 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Hotplug
             pin@p133 { function = "output"; termination = "no_pulling"; }; // Camera LED
             pin@p134 { function = "output"; termination = "no_pulling"; }; // Camera shutdown
-            pin@p135 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Power low
+            pin@p135 { function = "output";  termination = "pull_down"; startup_state = "inactive"; }; // Power low
          }; // pin_config
 
          pin_defines {
@@ -1072,8 +1072,7 @@
                type = "absent";
             };
             pin_define@POWER_LOW {
-               type = "external";
-               number = <7>;
+               type = "absent";
             };
             pin_define@LEDS_DISK_ACTIVITY {
                type = "internal";
@@ -1187,7 +1186,7 @@
             pin@p132 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Hotplug
             pin@p133 { function = "output"; termination = "no_pulling"; }; // Camera LED
             pin@p134 { function = "output"; termination = "no_pulling"; }; // Camera shutdown
-            pin@p135 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Power low
+            pin@p135 { function = "output";  termination = "pull_down"; startup_state = "inactive"; }; // Power low
          }; // pin_config
 
          pin_defines {
@@ -1236,8 +1235,7 @@
                type = "absent";
             };
             pin_define@POWER_LOW {
-               type = "external";
-               number = <7>;
+		type = "absent";
             };
             pin_define@LEDS_DISK_ACTIVITY {
                type = "external";

[Akko1]

@maxammann As you mentioned the revision I suddenly realised my error. I have been using a Pi2 the entire time with inbuilt PWR LED controls... Thank you for the awakening however and a swift response but the LED is now nice and peaceful.

[wansiedler]

Guys, this is a silly question, but still...
Is it possible to get the status of the Power Led on Raspberry Pi 3?
What should I do?
Should I modify the dt-blob.dts and use pi3-gpiovirtbuf g 135?
1 means off and 0 means on?

[maxammann]

@Zidler yes, but I think when I tested it it 1 meant on and 0 off.

[wansiedler]

All i get is this:
[pi@max2play][~]> rpi3-gpiovirtbuf g 135
Get state of 135 as 0

The Power LED is red. What am I doing wrong?

[maxammann]

@Zidler after you modified your dt-blob.dts the power led should be already off.

[wansiedler]

ok, but how can I keep it on and get the status of it?

[wansiedler]

I don't know why buy I changed
pin@p135 { function = "input"; termination = "no_pulling"; polarity = "active_low"; }; // Power low
to
pin@p135 { function = "output"; termination = "pull_down"; polarity = "active_low"; }; // Power low
and
[pi@max2play][~]> rpi3-gpiovirtbuf g 135 shows
Get state of 135 as 1

[derbroti]

@Zidler When you just want to get the status of the LED you do not need to change anything!

just run: ./rpi3-gpiovirtbuf g 135
and as you earlier stated correctly: getting a zero means the LED is ON.
The led is "active low" that means when the signal is low (=0) it is active e.g. the led is on.

The meaning of the LED itself is inverses again: LED on means "NO power low".
So in the end: getting a zero with the virtbuf tool means ok and getting a 1 means low-power.

-> I just double checked with a good and a dodgy usb cable.

[wpwentzell]

@6by9 This solution worked beautifully. Thank YOU.

[wansiedler]

@derbroti, could you please tell me, where I can read about signals and stuff? Couldn't find any sources.

[roycie1282]

I need a little help (not a pro pi'er). I'm setting up MotionEye on a rp3 and on my rp2 turning off LEDs was fairly easy, but having some issues with this one. I have followed @6by9's directions up to making the changes to the file. I am stuck at

And
sudo dtc -I dts -O dtb -o /boot/dt-blob.bin dt-blob.dts
to compile and install it (sudo apt-get install device-tree-compiler if you haven't already got the compiler installed).

The motioneyeos system doesn't allow sudo since u log in as admin which is sudo I guess. I have tried multiple ways to get this to work to no avail. I think it might be an issue with the motioneyeos, but I'm not positive. Any help is greatly appreciated.

I also added @maxammann revision to it just in case anyone was gonna ask about that as well.

[derbroti]

@roycie1282 Looking at the FAQ: https://github.com/ccrisan/motioneyeos/wiki/FAQ

Yes: admin is an alias for root; yes, you do not need any sudo command - so leave it out

Is the device-tree-compiler installed?
If not you have to build it from source, as (according to the FAQ: https://github.com/ccrisan/motioneyeos/wiki/FAQ#i-cant-seem-to-find-apt-get-or-any-other-package-manager-what-gives you do not have a package manager.

So either, again FAQ: install motionEye as a program on raspbian instead of the motioneyeOS and have a full featured os with apt and sudo ;) or build the DTC and it will work as well :)

[derbroti]

@Zidler Sorry, I don't have any "way to go" sources - but there are many digital electronics/signal processing sources on the web - search for those terms or try your local university library, they often have good books about it.

[6by9]

The latest rpi-update code includes a mailbox service update that allows setting up the GPIO expander direction, polartity, and termination.
rpi3-gpiovirtbuf app also updated.

If you wish to try this on a non-critical Pi, then

sudo rpi-update
sudo reboot
git clone https://github.com/6by9/rpi3-gpiovirtbuf.git
make
./rpi3-gpiovirtbuf c 135 1 0 0 0 0

Should leave you with the LED off. Once configured as an output then
./rpi3-gpiovirtbuf s 135 0 should turn the LED off, and ./rpi3-gpiovirtbuf s 135 1 should turn it on.

The gotcha is that this is the under-voltage monitoring is still active. If it reads high (after active_low compensation), then it will disable turbo mode and display the lightning bolt. The above commands set the line as active_high (default is active_low), so with the LED off you won't be throttled, but will if you turn the LED on.
Adding avoid_warnings=2 to /boot/config.txt should disable this but make sure you have a decent power supply first.

Next up: writing a kernel driver to talk over that mailbox interface.

[pelwell]

Last night's rpi-update release includes 6by9's new GPIO expander driver, and the DT mods required for the power LED to appear as /sys/class/leds/led1. The pwd_led_trigger dtparam also works, but pwr_led_gpio currently only lets you switch between pins on the expander - not particularly useful. This is because even though the system has a unified GPIO space, in DT you have to select a GPIO from a specific controller.

N.B. I advise you not to choose the "heartbeat" pattern on the PWR LED - it seems to lock up a Pi3.

[pelwell]

I found a bug in the leds_gpio module (one I put there long ago) that was causing timer- and interrupt-driven LED triggers to lock up. The kernel sources and the latest rpi-update firmware now include the fix for this, so feel free to put a heartbeat on your PWR LED.

Can we close this issue now?

[JamesH65]

Closing this issue as questions answered/resolved.