New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missign control for RED "Power LED" #1332

Closed
jgrulich opened this Issue Mar 9, 2016 · 47 comments

Comments

Projects
None yet
@jgrulich
Contributor

jgrulich commented Mar 9, 2016

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

This comment has been minimized.

Collaborator

popcornmix commented Mar 9, 2016

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

This comment has been minimized.

Contributor

jgrulich commented Mar 9, 2016

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 notifications@github.com
Komu: raspberrypi/linux linux@noreply.github.com
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

This comment has been minimized.

Collaborator

popcornmix commented Mar 9, 2016

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

This comment has been minimized.

Contributor

jgrulich commented Mar 9, 2016

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 notifications@github.com
Komu: raspberrypi/linux linux@noreply.github.com
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

This comment has been minimized.

Contributor

pelwell commented Mar 9, 2016

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

This comment has been minimized.

Contributor

jgrulich commented Mar 9, 2016

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 notifications@github.com
Komu: raspberrypi/linux linux@noreply.github.com
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

This comment has been minimized.

Contributor

pelwell commented Mar 9, 2016

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

This comment has been minimized.

Contributor

jgrulich commented Mar 10, 2016

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 notifications@github.com
Komu: raspberrypi/linux linux@noreply.github.com
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

This comment has been minimized.

Contributor

pelwell commented Mar 11, 2016

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

This comment has been minimized.

ionciubotaru commented May 16, 2016

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

This comment has been minimized.

mikerabat commented Jun 15, 2016

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?

lmarlow added a commit to lmarlow/nerves-examples that referenced this issue Jul 3, 2016

RPi3 no longer supports controlling the PWR LED.
Only `/sys/class/leds/led0` exists on the Raspberry Pi 3 and it controls the green LED. It seems access was removed to accommodate the new wifi/BT capabilities.

raspberrypi/linux#1332
http://raspberrypi.stackexchange.com/questions/44168/how-can-i-control-the-red-led-again

lmarlow added a commit to lmarlow/nerves-examples that referenced this issue Jul 5, 2016

RPi3 no longer supports controlling the PWR LED.
Only `/sys/class/leds/led0` exists on the Raspberry Pi 3 and it controls the green LED. It seems access was removed to accommodate the new wifi/BT capabilities.

raspberrypi/linux#1332
http://raspberrypi.stackexchange.com/questions/44168/how-can-i-control-the-red-led-again
@dblevins

This comment has been minimized.

dblevins commented Jul 10, 2016

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

This comment has been minimized.

Contributor

6by9 commented Jul 10, 2016

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

This comment has been minimized.

mikerabat commented Jul 11, 2016

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 notifications@github.com 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

This comment has been minimized.

Contributor

pelwell commented Jul 11, 2016

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

This comment has been minimized.

mikerabat commented Jul 11, 2016

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 notifications@github.com
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

This comment has been minimized.

Contributor

6by9 commented Jul 11, 2016

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

This comment has been minimized.

canol commented Aug 30, 2016

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

This comment has been minimized.

Contributor

6by9 commented Aug 30, 2016

@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

This comment has been minimized.

Contributor

6by9 commented Aug 30, 2016

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

This comment has been minimized.

rekcah1986 commented Dec 7, 2016

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

@6by9

This comment has been minimized.

Contributor

6by9 commented Dec 7, 2016

"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

This comment has been minimized.

rekcah1986 commented Dec 9, 2016

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

This comment has been minimized.

Contributor

pelwell commented Dec 9, 2016

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

This comment has been minimized.

Contributor

6by9 commented Dec 9, 2016

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

This comment has been minimized.

davidpfahler commented Dec 25, 2016

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

@6by9

This comment has been minimized.

Contributor

6by9 commented Dec 25, 2016

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

Read the whole thread as there already is a solution (even if not the nicest)- #1332 (comment)

@davidpfahler

This comment has been minimized.

davidpfahler commented Dec 25, 2016

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

This comment has been minimized.

Akko1 commented Jan 5, 2017

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

This comment has been minimized.

maxammann commented Jan 6, 2017

@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

This comment has been minimized.

Akko1 commented Jan 7, 2017

@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.

@zidler

This comment has been minimized.

zidler commented Jan 14, 2017

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

This comment has been minimized.

maxammann commented Jan 14, 2017

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

@zidler

This comment has been minimized.

zidler commented Jan 14, 2017

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

This comment has been minimized.

maxammann commented Jan 15, 2017

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

@zidler

This comment has been minimized.

zidler commented Jan 15, 2017

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

@zidler

This comment has been minimized.

zidler commented Jan 15, 2017

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

This comment has been minimized.

derbroti commented Jan 22, 2017

@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

This comment has been minimized.

wpwentzell commented Jan 23, 2017

@6by9 This solution worked beautifully. Thank YOU.

@zidler

This comment has been minimized.

zidler commented Jan 23, 2017

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

@roycie1282

This comment has been minimized.

roycie1282 commented Feb 11, 2017

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

This comment has been minimized.

derbroti commented Feb 11, 2017

@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

This comment has been minimized.

derbroti commented Feb 11, 2017

@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

This comment has been minimized.

Contributor

6by9 commented Feb 15, 2017

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

This comment has been minimized.

Contributor

pelwell commented Mar 2, 2017

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

This comment has been minimized.

Contributor

pelwell commented Mar 30, 2017

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?

@gbkelley gbkelley referenced this issue May 17, 2017

Closed

Power LED #6

@JamesH65

This comment has been minimized.

Contributor

JamesH65 commented May 18, 2017

Closing this issue as questions answered/resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment