Omega2 reboot
-
@cusackph
shutdown doesn't work either. How do we turn these things off?!
-
Hello,
I have the same problem. When I want to turn off my Omega2+ (firmware v0.1.8-b145), I use
halt(orpoweroff) command. But these commands do not work and reboot the Omega2+.
-
@Mikaël-PIRIO said in Omega2 reboot:
Hello,
I have the same problem. When I want to turn off my Omega2+ (firmware v0.1.8-b145), I use
halt(orpoweroff) command. But these commands do not work and reboot the Omega2+.I can confirm this :(.
-
@Brian-Robbins @SukkoPera @cusackph @Mikaël-PIRIO
The nature of the kernel patch to enable rebooting seems to have this side-effect... How essential are thehaltorpoweroffcommands for your workflows?Btw, I will be submitting a Pull Request to LEDE for the reboot kernel patch soon, will update you when it's in.
-
@Lazar-Demin
Not essential, as long as I can be assured that simply unplugging or switching the Omega2+ off has no risk of file corruption
-
@Brian-Robbins ya it should be safe to just switch it off. I usually just yank mine out of my laptop when I want to power it down.
If you're feeling extra paranoid, run the
synccommand and allow it to finish before unplugging it.
-
@Lazar-Demin said in Omega2 reboot:
I usually just yank mine out of my laptop when I want to power it down.
Lol!!! But that's not very good for a USB key or SD card still mounted. Linux is not that robust.
-
@Lazar-Demin so you're going to submit a broken patch? Please don't. You can't just fix one thing and break another. The previous behaviour was more acceptable than the current one, as you turn off the Omega more often than you reboot it, at least at the current stage. So please revert the patch and look into the proper fix before you submit anything upstream.
-
@Lazar-Demin Please, consider fixing the
poweroffandhaltissues before summiting the Pull Request.
-
I just picked up my Omega2 / revision R1 / Firmware 0.1.9 (b149) today and also noticed the reboot-instead-of-shutdown behaviour. Is there a solution for this issue yet?
-
Hello,
With firmware v0.1.9-b149,
halt(orpoweroff) always reboot my Omega2+
.
-
The issues with the reboot flash state and problems with some of the proposed fixes are pretty clear.
What is more a mystery is how a powerdown used to work. Was this an actual shutdown of the chip, or at least a drastic drop in power consumption by slowing a clock?
Or was it just a one-way trip to what looked like an "off" state with no file systems mounted, from which externally cutting power would be fully appropriate?
(Was a hypothetical trip to such a deadend state even a designed behavior, or just an emergent one of the chip trying and eternally failing to boot from a flash stuck in the wrong addressing mode?)
And was it done by the kernel, by rebooting to U-Boot with flags to trigger special behavior there, or did the other (radio-related) CPU in the chip have a role in it?
-
the question i have when using shutdown is, there is roughly a 3 second period on my omega2+ after the power light goes off and before it comes back on. so if i do a shutdown, wait for the power light to go off, then remove the power plug, does this qualify as a "shutdown" in a legit sense? is it possible that damage to the filesystem will take place.?
-
The best time to pull power would be while the system is sitting in U-Boot; that's easily determined from the serial port, and you can probably correlate it to the state of the LEDs.
In terms of fileystem corruption, this risk is already substantially lower than it would be on something like an SD card based raspberry pi.
-
The SPI NOR flash memory is used relatively bare; there's no hardware flash translation table that could mess up and scramble one part of the addressable space because another is being written to; if there are bugs, they are in visible, correctable software layers and the modes those configure the chip to. And unlike SD cars, the flash chips have real data sheets.
-
The critical storage - U-Boot, Linux, and the root filesystem are not normally operated in a writable fashion. This combined with the memory architecture should mean they are essentially always almost as safe from power loss as they would be on a system that has been shutdown in preparation for it.
-
The one thing that is writeable is the overalay partition, but this is a journaling file system that makes some degree of effort to make changes only in an interruption-safe manner. Still this is the weak point. However, fortunately the writable filesystem is a place you may be able to tolerate failure - safemode or a factory reset gets you a still bootable system, and you can reconfigure the network and transfer your backups of customizations to the board again.
So orderly shutdown is a good idea when possible, but the consequences of a disorderly one are lesser than they would be on a different architecture.
-
-
thanks, Chris. another question, if i enter a dmesg , sometimes, usually after i have used a build for a period of time, the last line will be a warning of ~" vfat, filesystem is corrupt, try using fsck". when i've seen it i've wondered if this business of hacking a shutdown somehow is responsible for the corrupt filesystem that is being reported. do you have any other ideas about how this issue comes about?
-
What vfat filesystem?
If you have a USB stick or an SD card added to the system, then you're potentially subject the all the various ways those can fail, unless your usage of it is optional enough that failure there is tolerable.
In essence, with either of these before power loss you need to sync and unmount, just as you'd need to do "safely remove hardware" or drag to the trash or eject or whatever on a larger computer.
The stock shutdown process (when it works) would hopefully include that, but it's worth being explicitly sure.
Or just not using comparatively delicate storage, if you can avoid it.
-
i do ocassionally use an sd card. i must have left it in during a shutdown . i guess this means the things i would expect to be handled by the operating sytem are not being done. i need to pay more attention to what i'm doing.
-
@Chris-Stratton said in Omega2 reboot:
What is more a mystery is how a powerdown used to work. Was this an actual shutdown of the chip, or at least a drastic drop in power consumption by slowing a clock?
It was neither. The fact that it used to work was actually a bug: the SoC actually does reboot even in the old firmwares, before this fix, but the flash-chip was left in a state that the SoC's bootrom-loader doesn't know how to handle and it got stuck in an internal bootloop. If you attach an oscilloscope to the SPI-pins when the Omega2 looks like it's powered-down you'll see that it's actually periodically trying to boot off of the SPI-flash as there is traffic on the SPI-pins. The drop in power-consumption is simply due to the fact that all the other internal peripherals are off and clocks are at their minimum -- they'd get turned on by u-boot, if the bootrom managed to load it.
-
I'm both surprised... and not. The "emergent" shutdown of being unable to boot due to a flash address mode was actually in my list of guesses, after seeing exactly that (and indeed, the ongoing SPI traffic with mis-positioned response bytes) on another board.
It might actually be possible to do better intentionally though, or at least put the system into an end state not determined only by a bug. There are mailbox registers that could be used for signaling intention if it ends up being easiest to pass the task to the bootloader.
On a related point, setting the flash address mode back before an intentional reboot is not a safe fix, as it doesn't handle the unintended reboot case. Effectively, whatever mode the chip needs to be in at boot, is the mode it can never safely leave, or the system will have times when reboot would leave it in a broken state from which only power cycling could recover.
-
@Chris-Stratton said in Omega2 reboot:
Effectively, whatever mode the chip needs to be in at boot, is the mode it can never safely leave
It has to, you can only address 16MB of the flash in the default-mode. That's why the mode is switched to the other mode, so that the whole 32MB on the Omega2+ can be addressed.
