Device seems to reboot when using gpio-shutdown?

Product support
,
#1

Hi,

I’ve found another issue when trying to potentially use Balena for our product.

For some reason, the gpio-shutdown dtoverlay isn’t working as expected.

I have the following dtoverlay configured as the device configuration under HOST_CONFIG_dtoverlay

"spi1-3cs","gpio-shutdown,gpio_pin=26,active_low=1,gpio_pull=up","gpio-poweroff,gpiopin=25,active_low='y'"

This sets 3 overlays we require, SPI1 being enabled, GPIO shutdown triggered when a button on pin 26 is pulled low and a Power LED to indicate when the Compute Module 3 shuts down on GPIO25.

SPI works fine, and the Power LED also acts as expected, however GPIO Shutdown does not.

Upon pressing the button to shut down, the device does indeed shut down, but seems to striaght away power back up.

I’m 99% certain this isn’t a hardware issue as when testing on a native Raspberry Pi OS installation once it shuts down it stays in a halted state ready for the user to unplug the device.

Using balenaOS 2.65.0+rev1, supervisor 12.2.11 on balena-staging.

#7

Hi @Ryanteck,

Looks like gpio-poweroff is meant to be used with a mechanism that cuts power externally after the gpio was toggled but before timeout_ms expires, which by default is 3000, otherwise the kernel will trigger a warn and reboot. You can check this with panic=0 in the command line.

So you can either use the gpio-shutdown overlay only, which works fine, or add the necessary external mechanism.

See: https://github.com/raspberrypi/linux/issues/3372#issuecomment-562533582

#8

Hmm, it seems that partially applies but that doesn’t explain when I use proper Raspberry Pi OS that I don’t have this issue.

However I’ll have to resolve it another way instead. Likely run code in a container that will then trigger a shutdown of the host.

Thanks for the help.

#11

Hi @Ryanteck,

Pi OS I has reboot on panic disabled by default. I enabled it there and it then rebooted with the poweroff overlay too.

Desired behavior for remote devices is to reboot in case of a kernel panic, so that they stay accessible should there be an issue.

However, if you want to disable this behavior for your specific usecase, from your container that has ENV UDEV set you can do:

echo 0 > /proc/sys/kernel/panic

You just need to be aware that the board won’t reboot anymore in case of a potential kernel panic that has a different root cause.

#12

Aha excellent, thank you.