Button shutdown not detecting a press

[W0KHZ]

I have tried my best to find an answer to this problem, but can't find it. I recently acquired a used G2 and upon arrival the microSD in the G2 appeared to be corrupted. Luckily inside of the unit was a backup microSD which does work but shutdown via the power button does not work. I ran the script manually that waits for the button state to change, but it has no effect. The previous owner had upgraded the pi to 5 and it's running the bookworm OS.

Also, the power button originally stayed white. I ran the script that fixes that, and that works. Now when the pi is running, it turns red and turns white when the pi has shutdown. Since the button is not shutting down the pi, I have been shutting it down using the shutdown command.

Any clues as to why the power button shutdown script doesn't work? It is running and waiting for a button state change that it never detects.

[Svante]

Had my Anan G"2,17 months now. Never change colour on first push Have to make 2 short push then it changes colour and I wait about 15 sek. then a longer push This is very irritating way to shut off a tranceiver. Have my Anan under a noise isolated table do to the noisy fan. So looking for a better shut off solution.
Remote howe do this people do ?
Svante sm6usu

[ct1iqi]

Had a look at the fix-LED-power-button.sh script and it seems to only address indeed the LED action, not the shutdown.
The original front-less G2 has defined in config.txt:
>>
dtoverlay=gpio-shutdown,gpio_pin=26
gpio=15=op,dh
<<
The script replaces the effect of the second line by a systemd service that makes this pin an output and high, such the the red LED is lit when the OS is active.
It also removes the second line from config.txt when found.
It doesn't cover shutdown, so the question is whether this shutdown detection got activated.

The gpio definitions in the device tree have the option to make the gpio state change trigger a kernel action, in this case shutdown.
The overlay is added to the basic device tree during the initial phases of a boot.
You can check whether the overlay is actually there in the OS image (boot/overlays) and getting activated properly.
The settings the kernel sees for gpio appear by
sudo cat /sys/kernel/debug/gpio
and there should be something there that is an input and causing an interrupt.
What could be in config.txt is something like
dtoverlay=gpio-shutdown,gpio_pin=26,active_low=1,gpio_pull=up

The source code of the actual device tree overlay you can see here:
https://github.com/raspberrypi/linux/bl ... verlay.dts
Where it says rpi-6.12.y, choose the kernel version that your OS has (uname -r).

Like the setting of the LED was brought to user space, one can also do this with the shutdown interrupt.
In case needed I can send you some example code. It's what I did in my G2 after an upgrade with a Radxa CM5.

[W0KHZ]

Thank you for your help on this. Just so you know, you are dealing with a novice here using Linux. I know enough to be dangerous and that's about it. This is way over my head.

Here are a few lines in /sys/kernel/debug/gpio that might be of interest...

gpio-553 (PWR_GPIO |pwr_button ) in hi ACTIVE LOW
gpio-562 (BT_ON |shutdown ) out hi

The kernel version of my OS is: 6.12.34+rpt-rpi-2712

The script I found that doesn't work has this:

sleep 20
gpioget --bias=pull-up gpiochip0 26
pinvalue=1
sleep 2
echo "waiting for shutdown to be triggered..."
while [ $pinvalue -eq 1 ]
do
# poll input every second, and wait for logic zero
pinvalue=$(gpioget --bias=pull-up gpiochip0 26)
sleep 1
done
echo "shutdown request detected"
shutdown 0

Thanks again for any assistance you can provide.

[ct1iqi]

what is in /boot/config.txt concerning this?

[W0KHZ]

The actual file is located under /boot/firmware/config.txt. I don't see anything in there of interest?

# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

#enable USB
dtoverlay=dwc2,dr_mode=host

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[cm5]
dtoverlay=dwc2,dr_mode=host

[all]

[ct1iqi]

Indeed nothing there that would support power-on LED or Shutdown.
The LED having been taken care of, this leaves the gpio to be set that, when pulled low, should trigger OS shutdown.
The two gpios that you earlier reported are the result of the script you ran to get the power-on LED, and the other is about Bluetooth, unrelated.
You can try the two approaches, letting the kernel do the shutdown, or do it in userspace.
The two concepts are mutually exclusive as giving a gpio pin some function in the device tree, makes it unreachable from user space for manipulation.
The concepts:
A. kernel sets up gpio shutdown monitoring, defined per device tree and its overlays.
B. make it happen after the kernel has booted from user space

A.
under [CM5] add the line
dtoverlay=gpio-shutdown,gpio_pin=26
(do check that it is actually that pin that 'sees' the power button; saw some comments via Google that perhaps this script does not work well with the CM5; unchartered territory)

B.
1. create a systemd service that will activate the gpio pin monitoring upon boot:
create /etc/systemd/system/power-button.service with content (>>> <<< only here to mark beginning and end, not in code):
>>>
[Unit]
Description=Anan G2 power button short press monitor
After=systemd-user-sessions.service

[Service]
ExecStart=/etc/Saturn/wait_shutdown.py

[Install]
WantedBy=multi-user.target
<<<

2. create a folder to put home made Saturn specific stuff
mkdir -p /etc/Saturn

3. create the Python3 script /etc/Saturn/wait_shutdown.py that will do the gpio settings:
>>>
#!/usr/bin/env python3

import gpiod
import subprocess

gpiochip="0"
chip_pin=23

with gpiod.Chip(gpiochip, gpiod.Chip.OPEN_BY_NUMBER) as chip:
line = chip.get_line(chip_pin)
line.request(consumer='root', type=gpiod.LINE_REQ_EV_BOTH_EDGES)
event = line.event_read()

# this sets the pin to output high
with gpiod.Chip(gpiochip, gpiod.Chip.OPEN_BY_NUMBER) as chip:
line = chip.get_line(chip_pin)
line.request(consumer='root', type=gpiod.LINE_REQ_DIR_OUT, default_val=1)

output = subprocess.call(['/usr/sbin/shutdown now'])
<<<
4. In the above script actually set the proper gpio line. The 'chip_pin=23' is what I used for the Radxca CM5. Perhaps this has to be 26 with you.
You'll have to see which 2x20 pin is actually connected in your G2 to the power button and check the Rpi CM5 docs to see what gpio number that pin has.
Make the script executable: sudo chmod 755 /etc/Saturn/wait_shutdown.py

5. make the service known to the OS and enable it:
sudo systemctl daemon-reload
sudo systemctl enable power-button.service

The Python3 script actually in the first 'with' statement will halt until a transition occurs on the gpio line. So this is interrupt based and won't miss a short press.
While waiting, the script won't stop the OS from other action. I added the second 'with' to make the output high after the interrupt, in an attempt for that pin not to start mimicking a long press itself.
In the end I needed to add a diode in the wiring to this gpio pin in the case of using a Radxa CM5. The Rpi CM5 I have no experience with and may not need the diode.
The power button is both watched by the gpio and by the power circuitry which acts as a solid state relay and will cut all powering when the press is long.
So under no circumstance the CM5 circuitry should draw current from there. It only has to monitor state.

[W0KHZ]

I really do appreciate the time you took to work with me on this but I have resolved the problem without having to build a script. Your instructions led me to find out what was causing the problem -- thank you!!! As I mentioned, I bought this used and the previous owner installed a new quieter Noctua fan. It was installed with these strange looking rubber legs and not adequately installed to the top case. During shipment, the fan came loose. Upon inspection, everything seemed ok.

But when you mentioned to check what gpio pins were used on the 40-pin header, I found that some of the pins were bent from the fan banging around during shipment. They didn't appear to be touching but they were very close together. The cable for the button was attached to gpio 26 which is correct. After straightening out the pins and making sure there were no shorts, the script found in the Saturn directory now works and all is good.

Consider this resolved. Thanks again.

[ct1iqi]

Great that you found the problem! Without the proper wiring nothing would work.
It also means everything regarding the power button is done in user space and that there is probably another service installed, besides the one you got from the Saturn repo, that starts the script you showed.
That script has i.m.h.o. the shortcoming that it polls every second and then takes a snap shot, potentially missing a press that is shorter than a second.
The Python script that I gave you would do better in using the gpiod library and its option to make a press transition at any time cause action.
You could adapt the button-press service and make it start the Python script.
After editing do apply a systemctl daemon-reload and restart of the service to have effect.