Is poweroff supposed to shutdown voxl?
-
Hi,
Sorry for the burst of questions (I've been asked to tackle a few different issues at the same time)...
I just noticed that I can connect to VOXL using adb shell, but when in that shell I had been assuming that poweroff -f is essentially a shutdown (i.e. after which it is safe to remove power).
Anyway, earlier (from adb shell) I ran "poweroff -f" and it responded with "Powering off", and I also noticed that my ssh connection was dropped. So far, so good.
Then, I forgot to actually remove power from the unit and a few minutes later I found that I could use both adb shell and/or ssh to log back into the VOXL. Seems like it did a reboot instead of a poweroff.Is that correct? It seems VOXL did not actually power off.
(or I'm an idiot for doing something wrong)...
Thoughts? -
@Ed-Sutter There is no SW control to physically power-off.
Because of drone access to buttons being a no-go, we do not have a physical power button to turn the hardware ON like on a phone. Basically, once you apply power, we turn on and boot up.
So, when you do a software power-off, it immediately powers back on once the SW is done with it's effective "reset" in that case. -
@Vinny Ok, I understand not having SW control of the actual power, but AFAIK, the SW can still shutdown and enter a "halt" state so as to provide the "safe" state to remove power. Although that would only work if there wasn't some watchdog that would then trigger and restart things!
Anyway, referring to this text, you may want to suggest to the SW folks that they remove the poweroff command from their shell (probably busybox) for systems that essentially do a "reboot" when the poweroff command is issued.
Again...thanks for the quick response.
-
@Ed-Sutter There is more to it than on the surface, as our SW team has gone to great lengths to figure out how to prevent corruption, so I still think it's the correct thing to follow as per that link, but we do need to educate users on the differences.
Adding some type of hardware level button and "safe to remove" indicator has been in discussion for years, but the practical implementation of that (since for most use cases, we'd want it different than a smart phone) leads to a whole bunch of low-level work that may not actually succeed.
These chips "think" they are in a phone, no matter what we do, so we try to work around it the best we can.
I know the team still thinks about this... maybe we'll get a clean solution one of these days.
