I’m making my own amp with rPI 3. I’m using I-SABRE V4 from audiophonics (ES9023) as DAC (which use hifiberry-dac-overlay) and Hypex UCD180HG amp. I would like customize the led’s behaviors from the DAC and to do that i need to use a customized firmware for attiny45/85.
Sir Unhold provide a great firmware and an “HOW TO” to run on VOLUMIO and/or OSMC http://forum.audiophonics.fr/viewtopic.php?p=8766#p8766
Unfortunatly i’m stuck with the latest version (Oct 2018) of OSMC. I can run/start OSMC by pushing the button, but i can’t shutdown osmc. RaspDAC blinking, but it seem’s that OSMC ignore the signal on gpio 17 (pin 11).
/boot/config.txt was modified as Unhold said, but i’have also see in the README of overlays that command should be
but anyway, it doesn’t work. Also rules not be mandatory for this current version of OSMC.
Then, if any body have idea, I wiil really appreciate ! thanks all
I’ve reinstall osmc (November 2018) and followed your instructions, so my rPi is running osmc version 4.14.78-4.
Unfortunately, after set the dtoverlay (gpio-shutdown), i’m not able to shutdown as expected the rPi. (GPIO3 & GPIO5 as default => do nothing, GPIO5 & GPIO17 as wished => nothing). I haven’t enough knowledge , but I continue to investigate
If you have any idea or informations, let’s me know many thanks in advance
This will be very difficult for us to debug from a distance.
I think your next step should be to install Raspbian, ideally on a separate SD card if you have one, and see if you can get it to work. If it works, it will at least prove that the firmware you flashed onto the DAC is working and that your hardware is generally ok.
I’ve successfully installed the latest version of Rasbian (lite & desktop) and do nothing else except adding these lines to /boot/config.txt & reboot :
The firmware flashed is working as expected, this confirm that issue is NOT caused by the firmware.
As I said, this is very difficult to debug from a distance, since I/we have no easy way to replicate your set-up. Nevertheless, I’ll see if I can find anything that might be missing or configured differently in OSMC.
I understand. If you have a rPI 3 and if you can initiate a shutdown with the regular gpio 5&3 (shunt these pins with a push button and a resistor, no need DAC) then you will probably solve the issue. Else I wish you a lot of courage to compare the both OS :). I really apreciate your helps @dillthedog and @sam_nazarko
I do have a Pi3 that I use as a sandbox but won’t have physical access to it until the weekend – and then very little free time . I also don’t have any jumper wires to attach to the GPIO pins (though I guess it’s about time I bought some!)
So unless there’s any way I can emulate over SSH what you’re proposing, I’m afraid physically reproducing it is not going to be possible for a while.
I’m afraid that i’ve made a mistake when namming gpio pin. It’s NOT gpio pin 3 & 5, sorry for that, but it’s gpio pin 5 (BCM 3) and gpio pin 6 (GND) that’s the default behavior for shutdown:
Info: Initiates a shutdown when GPIO pin changes. The given GPIO pin
is configured as an input key that generates KEY_POWER events.
This event is handled by systemd-logind by initiating a
shutdown. Systemd versions older than 225 need an udev rule
enable listening to the input device:
ACTION!="REMOVE", SUBSYSTEM=="input", KERNEL=="event*", \
SUBSYSTEMS=="platform", DRIVERS=="gpio-keys", \
This overlay only handles shutdown. After shutdown, the system
can be powered up again by driving GPIO3 low. The default
configuration uses GPIO3 with a pullup, so if you connect a
button between GPIO3 and GND (pin 5 and 6 on the 40-pin header),
you get a shutdown and power-up button.
Params: gpio_pin GPIO pin to trigger on (default 3)
active_low When this is 1 (active low), a falling
edge generates a key down event and a
rising edge generates a key up event.
When this is 0 (active high), this is
reversed. The default is 1 (active low).
gpio_pull Desired pull-up/down state (off, down, up)
Default is "up".
Note that the default pin (GPIO3) has an
Note, in my case i need to replace BCM3 by BCM17 but doesn’t matter for this test
Using WiringPI, with dtoverlay=gpio-shutdown set in /boot/config.txt, I found that I was able to shutdown Raspbian (4.14.90-v7+) using the command gpio -g mode 3 out. Without the dtoverlay, it has no effect.
Moving to OSMC (4.14.78-2), I was able to reproduce the same behaviour as above.
With dtoverlay=gpio-shutdown,gpio_pin=17, running gpio -g mode 3 out has no effect, but shutdown does work with gpio -g mode 17 out, so it all appears to work as expected.
Finally, with dtoverlay=gpio-shutdown,gpio_pin=17,active_low=0, running gpio -g mode 17 out no longer works, so the active_low=0 part has disabled the shutdown.
So my first suggestion is to see if it works with only dtoverlay=gpio-shutdown,gpio_pin=17. If not, I’ll investigate further.
I assume that it detects a change in the state of the pin. It’s not crashing the system, since this appears in the log when I run the command:
Dec 27 16:44:31 osmc systemd-logind: Power key pressed.
Dec 27 16:44:31 osmc systemd-logind: Powering Off...
Dec 27 16:44:31 osmc systemd-logind: System is powering down.
You haven’t said whether removing active_low=0 or using active_low=1 makes a difference.
As I mentioned, I don’t have any jump wires right now, so can’t test by physically shorting pins. You’ll have to do that yourself to confirm that it works. I’d suggest that you start with the default (BCM 3 → GND) and work up from there.
Hope you enjoy what’s left of the festive holiday!
I had previously (before the systemd update) had GPIO shutdown working, but since rebuilding the system, and rc.local not working any more under systemd, I find I’m now stuck as to how to re-engineer it.
My application is a Raspberry Pi Zero (not W) with HiFiBerry DAC installed in a car. To configure it it over ssh I use an Ethernet to USB adaptor.
I have made some analogue circuitry to pull down a GPIO pin about 1 minute after the ignition key is removed (to cater for stalling / re starting the engine). Then a second timer turns off the 5V power supply after 4 minutes to save the car battery, but allowing plenty of time for the Pi to shut down after the first 1 minute timer. (I found this circuitry a lot more straightforward to figure out than the software minefield!)
We have a very long car journey coming up soon, the OSMC install really makes this possible by entertaining the kids, for parts of the journey, but I can’t see that I’m going to succeed in time for this trip. (I jut purchased a new OSMC remote for this as my eldest lost the last OSMC remote on our last trip to France… grrr…)
ANY help is really really appreciated… I really hope I can get this working in time…