reset function

[Tinker-Bel]

is it possible to use the on/off shim also as a reset button (for example: press the button 5 seconds to initiate a reboot/reset?

[bablokb]

You could replace the software from Pimoroni with my project https://github.com/bablokb/gpio-poll-service. You gain two things:

• performance: the "poll"-service uses the poll-systemcall and does not consume any cpu-cycles while actually polling like clean-shutdown does

• an example script examples/gpio-reset/gpio-reset which does what you want: (very short press: ignored, short press: reboot, long press: shutdown). Note that in the script the actual reboot/halt commands are commented out, you will just find some messages in the system log until you change that.

Bernhard

[Gadgetoid]

As far as I can tell your software can't set the pull resistor on the button pin, so unfortunately it wouldn't work at all. The poll system call is interesting, though, and isn't something I've tinkered with before.

The rest idea is an interesting one, though, and we're looking into it.

[bablokb]

The state of the internal pullups/pulldown is saved in non-volatile memory. So this is only necessary once. Information on the issue is scarce, but if it is of an eeprom-type, you should not write it too often (so better move it to your setup script and remove it from the daemon-script).

Another hint:

if you use the standard gpio-poweroff driver (add the line dtoverlay=gpio-poweroff,gpiopin=4 to /boot/config.txt), you do not have to do that in your script either. The gpio-poweroff driver fires very late (all disks are unmounted), so it is much more robust.

[Gadgetoid]

Pull up/down states are not saved in non-volatile memory, but rather registers that retain their state during a low power mode. They are certainly not EEPROM; they're write-only and their values cannot be read back. This means that since OnOff SHIM (one of the products for which this code was written) cuts the power to the Pi, their states will certainly be reset.

Anyway. In almost all cases- unless you're writing a bare-metal application where the system is in a known state- you must explicitly set the pull up/down states to be sure they're actually set how you expect them to be.

You might be able to guarantee you don't meddle with pin states on your system, but we unfortunately can't make that assumption here.

We opted not to use the dtoverlay. We flash a notification LED shortly before power down, which necessitates a systemd script. Might as well trip the GPIO pin for shutdown here, too, rather than relying upon another factor. At this point the filesystem is mounted RO anyway, so the dtoverlay wont really net us anything. Thanks for the suggestion anyway.

[bablokb]

Hm, I read the documentation (Broadcom peripherals, p100) differently:

it is the users’ responsibility to ‘remember’ which pull-up/downs are active. The reason for this is that GPIO pull-ups are maintained even in power-down mode when the core is off, when all register contents is lost.

"power down" and "core is off" seems to be something else than "low power mode".

Anyhow, if you don't have an external resistor (which I just assumed you had) than it is definitely better to set the state yourself.

[Gadgetoid]

My reading of this was "sleep mode", but if anything's clear, it's that the datasheet is not. :D

[riccardolardi]

Any update on this? I'm also looking to extend this with reset functionality. Best case would be to replicate a standard desktop PC on/off button: long press = reset, short press = boot/shutdown

[Gadgetoid]

I think under the current setup trying to shoe-horn in a reset would overcomplicate the (already fairly spaghetti) bash script. Since long-press is already used for "shut down" to avoid accidental short presses shutting down the system (not sure that's really a problem, but I'm hesitant to change things now.)