Multi Switch Shutdown Script!

cyperghost

@Ashpool You should use a correct name to tag me ;)
Nevertheless, I don't own a ArgoneOne. But there is a small IC that is attached to I2C-bus on this housing. AFAIK it writes only two values to the flash, one for a reboot and one for shutdown. So the case "knows" how to enable/disable the power source.

So you are correct - by using the multi_switch call you can perform a save shutdown but the long press action with the sudden power cut is performed by the ARGON ONE hardware. No chance to change anything with a simple script.

You can take a look to BATOCERA - here the script was modified to perform some more actions. Take a look at the script here

Rion

@cyperghost is correct. Sadly without re flashing the IC there is nothing we can do.

I more in depth explanation can be found here by Spiros Papadimitriou.

Read under hardware protocol.

Maybe something can be learned from Spiros Papadimitriou rewrite of the script?

Ashpool

@cyperghost & @Rion
Thanks for the confirmation that the forced shutdown truly is "hardwired". And the GitHub Link to Spapadim was interesting to read (besides (sorry can't restrain myself here) that he is getting milliseconds wrong). Especially this part is something that I hadn't considered as a possibility so far:

After a "shutdown" request, the board will wait for a brief period of time and then cut off power anyway. Therefore, it is critical that the system shutdown command is issued ASAP. Unfortunately, it seems that this poweroff delay is hardcoded into the board's firmware.
If your shutdown sequence takes longer than 1-2sec (e.g., if you mount network drives that need to be flushed and umounted, for instance), it would be better to avoid using the case's power button to initiate a shutdown.

As I am, at the moment, away from home during the next week, i cannot check the time for multiswitch.sh shutdown on my setup & if maybe the only safe way to perform a shutdown via multiswitch.sh initiated by the argon1 script would be using the double tap call (Edit: At least that would take away the 21..22..23...(24.25)...counting fear)

P.S.: At least for my retroflag cases (Raspi3B(+)) multiswitch.sh is still in the "sliced bread"-(of usefulness)-league ;)

Idelacio

I've installed the script on the NESPi 4 case set up with Retropie on an SSD.

And they work... mostly. One issue though:

When switching off the device correctly shuts down the OS and then... stays on. Lights off etc but the fan is still spinning. I can;t switch it back on from this state either, have to unplug from the power and plug back in.

Something similar happens with the Retroflag scripts, only with those it will boot back up again immediately after shutting down the OS without me doing anything.

Now all this said I should point out that I'm running a 512GB SSD from the USB2 slot so that may be causing issues? Pi 4 just flat out won't boot anthing above a 256GB 2.5" SSD from USB3... I've had no issues through USB2 though.

Any solutions to this issue?

cyperghost

@idelacio you should tag people to get response. Nevertheless it's easy to fix. I have written a solution here. https://github.com/RetroFlag/retroflag-picase/issues/90#issuecomment-676587374

jamrom2

@cyperghost Hello. I have a question on a Mausberry shutdown script I'm hoping to get advice on before I go down the Support road from the manufacturer. I hear the support is not that good, so I'm throwing my last dart.

I converted an Intellivision Flashback unit into a Retropie, using a Mausberry for the shutdown. This is my 2nd unit I've built with no issues. The newest image of Retropie, whatever O/S it's built on, doesn't seem to like the Mausberry script and leaves the shutdown sequence hanging, never powering off.

I tested the Mausberry with and older SD card I had with the previous Retropie build (4.6.7)... works like a charm. The new Retropie image (4.7.1) fails.

Would you have any idea why I would be getting this issue based on your knowledge? I'm completely out of my league. I tried all the mechanical stuff, changing GPIO values in their script. Checking conections... etc. Nothing work. I've used a Mausberry in my other unit for over 5 years, and this one now about 9 months... everything was good until I moved up to the new image.

Regards,

JR

BTW.. I use your script on my 3rd Retropie unit that's built into a MegaPi case. Works like a charm! Thanks!

Here is the shutdown log... minus all the [OK...] statements.

Stopped Dispatch Password Requests to Console Directory Watch
Stopped Forward Password Requests to Wall Directory Watch
Stopping Network Time Synchronization... Stopping Update UTMP about System Boot/Shutdown...
Stopping Load/Save Random Seed...
Stopped Load Kernel Modules.
Stopped Load/Save Random Seed.
Stopped Update UTMP about System Boot/Shutdown.
Stopped Network Time Synchronization.
Stopped Create Volatile Files and Directories. Stopped target Local File Systems.

Unmounting /boot...
Unnounted /boot.

Reached target Unmount All Filesystems. System Check on /dev/disk/by-partuuid/97a6378b-01.
Removed slice system-systemd\x2dfsck.slice.
Stopped target Local File Systems (Pre).
Stopped Create Static Device Nodes in /dev
Stopped Create System Users.
Stopped Remount Root and Kernel File Systems.
Stopped File System Check on Root Device. Reached target Shutdown.
Reached target Final Step.
Started Power-off.
Reached target Power-Off.
Stopping Restore / save the current clock... 59.9899221 reboot: Power down

cyperghost

@jamrom2 looks like there is a overlay file loaded inside your /boot/config.txt

Take a look for a entry like
dtoverlay=gpio-poweroff
and remove this

jamrom2

@cyperghost You nailed it! It was at the bottom of my config.txt...

I had loaded both the Mausberry shutdown script and your script because this build I made will be for 3 different boxes I have. I just "#" it out as I will need it on my MegaPi Case.

Thank you very much, it was the last item on my list and has been troubling me for months.

Many kudos to you and Happy New Year!

JR

cnoto

@cyperghost I am using your generic script above for a shutdown with a momentary button on a pi3a and Im seeing the following message:

Kernel panic - not syncing attempting to kill init!

Any thoughts why im seeing this?

Many Thanks,

Idelacio

@cyperghost

Oops, sorry for the slow reply.

Yup! That worked perfectly. Thanks! <3

ExarKunIv

@cyperghost I have used this to shutdown my pi.
But i have come across a few posts saying that it can be used to shutdown a emulator or restart ES.

Can it be used to finishing killing xinit after exiting a game?

cyperghost

@exarkuniv as long as the call is

Runcommand.sh
Xinit
X Application
And all calls are children of the shell parent process then it is very likely that it will work. But never tested before

ExarKunIv

@cyperghost yes i have the command going through run command to lunch the game

here is my command that i have for my emulator.sh

dhewm3 = "XINIT:/opt/retropie/ports/dhewm3/dhewm3"
default = "dhewm3"

so i know that it calls it correctly. well i think it does

what do i need to do to set the shutdown script up. i have tried to follow your info as best as i could and i still get lost on it.

quicksilver

@exarkuniv there is an issue with dhewm3 that the x window does not close properly after exiting the game. I was going to report it on the github page but never got around to it. It's likely to be a raspberry pi related issue or it could be because we aren't running a full desktop environment. Not sure if the dev would/could help.

There is a setting you can turn on via raspi-config that allows you to kill an x session using cntrl+alt+backspace. That was my workaround when trying to close dhewm3.

ExarKunIv

@quicksilver thanks for the idea. i managed to get my kill script to work and map my hot keys with Xboxdrv to start it so now my game/ports now exit quickly. but ill remember that if i end up needing it down the road

vwgolfman

@cyperghost
Hello and thank you so much for all your hard work in creating the fantastic scripts that you do.

I have built a dual joystick controller with a Raspberry Pi 4 inside.
It is running Retropie 4.7.1
I have a button wired to pins 5 and 6 of the GPIO Header which shorts those pins when the button is pressed.

I would like to use this button as my safe shutdown button.

Please can you tell me whether your script will be good for this and if so should I install using...

wget -O - "https://raw.githubusercontent.com/crcerror/retroflag-picase/master/install.sh" | sudo bash

Many thanks once again for any help.

cyperghost

@vwgolfman You are using the "wrong" script for this. Please visit https://github.com/crcerror/ES-generic-shutdown

There is a dedicated command line option for a single GPIO button. The Retroflag script is just a small subset of the one linked above.

Edit:
Did forget, I wrote small walk-through already here: https://retropie.org.uk/forum/topic/17415/multi-switch-shutdown-script

Idelacio

On resetting games with the reset button I'm getting the following error:
/home/pi/RetroPie/scripts/multi_switch.sh: line 63: kill: (####) - No Such Process

Where #### is the process number.

It also producses the following message on closing the process:
Killed

As it looks messy having persistant messages like these show between screens is there a clean way to hide them?

I don't want to completely prevent error messages showing as sometimes I do screw up so just these ones specifically. If it's all or nothing though I'll just have to accept that.

vwgolfman

@cyperghost
Thank you so much, your coding is fantastic and I am now using your safe shutdown script successfully!

Could I please ask, is there a version which monitors the shutdown button continuously rather than polling it every second or so?

cnoto

@cyperghost I just used this script for a generic button on a zero 2 with no luck. Would anything be different about the pi zero 2?