I'm in the process of replacing the ancient Debian firmware on my My Book Live NAS with LEDE, including a much leaner port of the massively convoluted "monitorio.sh" that's responsible for idle spindown and LED control.
However, I encountered a real shortcoming: When I poweroff, it's basically just a reboot, the board comes up again. In the original Debian-based firmware it actually did power down and stayed off, so the necessary hardware capabilities must be in place.
My question would be: Is there a better method, or are there more "capable" alternatives to the stock poweroff?
Happened to me with a Router too... have you tried "halt" ?
Please let me know if it is worked for you, I have plans to install Lede on MyBookLive too.
Once I have to disable a usb device using Tplink Atheros Router with USB, I used a unbind USB... and it worked... I think there is a hdparm, sdparm, hd-idle feature that does this:
I consider this a bigger problem than just this device. I use travel routers frequently and have SD cards and USB devices attached. Every once and a while I get a "scan and fix" dialog box on Windows for the device. Linux OS' have dismount functions and shutdown tools.
I am by far no Linux expert, but I think in the days of your basic router with no peripherals this was OK, it's all in flash. Today I would like to be nicer to my data devices.
I would like to see the logoff button changed to a Shutdown menu with Logoff, Dismount USB devices, Reboot and Poweroff.
I'm the farthest you can imagine from an expert on this matter, but I believe it depends on the hardware and not all devices can power off. However, there are devices that most definitely are capable of powering off and staying off. And I'm thinking that a real poweroff has just never been implemented in OpenWrt/LEDE. CMIIW, please.
It may work or not, wget also point to busybox and do a very different thing, on a atheros SoC halt worked just fine for me.
Then if you had no success you will need to stop al /etc/init.d/ daemons, they are just a few.
and sync and unmount filesystems and spindown drive, you will have no problems at all doing it in that way.
Just to be clear: I'm not familiar with programming close to the hardware, but I'm quite confident in understanding how the system works, including daemons and what busybox provides.
The thing is, even if I find a GPIO that will shut down power to the drive, even if I shut all the processes, the drive will come back on immediately at reboot (of course it will, system boots from disk). So the problem stands, it would always be yanking the power from a running drive.
In the meantime I contacted @chunkeey who commited the apm821xx/MBL target, he might be able to shed some light on it. He mentioned that there is more to it than meets the eye, and I'm looking forward to his insight into the matter.
As far I understand your concern is about to manage in some way the box in order to put in a "halt" or "power off" mode to be able to remove / disconnect the HD from the board, am I correct?
If you sync, unmount and stop processes you should be able to do that safely.
There is no need to do a reboot (or poweroff halt since these three commands also does a reboot as you stated).
you just need to leave dropbear in order to come back using SSH when the HD is re-added / re-connected again in order to reverse the commands or just reboot the unit...
Maybe if you explain why are you in the need of this feature we could help better, are you trying to convert the box in a interchangeable drive box?
No. Again, I want the system -- mainly the disk -- to power down in a controlled manner before power can be physically removed.
This is not an issue with flash-based devices, they have nothing spinning. And supposedly it is not a problem with spinning disks either, with automatic head parking at power loss. However, I am not sure if I want to rely on it for disks that are supposed to reliably keep data for a long time.
This is possible, in fact encouraged by the original MBL firmware. It is currently not possible in LEDE.
I think that if you do so, the kernel will keep running (in some manner) on RAM, but will throw some kernel errors (test it using dmesg), will not be a "clean" way but I think if you pull out the power and later you put again the Drive and put again the power nothing wrong will happen... right? you could also try to force root to remount in readonly mode before.
I will try to install LEDE on my WD MBL tonight or this weekend, I will try it. Nothing to loose.
Exactly, this is what's going on here. The APM821xx does not really have a way to poweroff or even halt.
As you can see, the machine definitions lacks a "halt()" function.
Also, there is no driver that sets a pm_power_off, so all halt/poweroff/init 0 calls will end up in an infinite loop:
What gets the machine out of this loop is the booke watchdog. The watchdog used to be a module, so it was possible to not load it. Looking at the code, it is clear that this is a kind of watchdog that can't be disabled once it was activated and has a timeout time of max. 3 seconds (MAX_WDT_TIMEOUT).
Thanks a lot for the insight. That clears up a few things.
So if I understood that correctly, the (ancient) Debian-based firmware just put the system into never-ending nop after shutdown. Well, it's a way to achieve the goal, I guess.
Can something like this "infinite loop" behaviour be replicated/emulated on LEDE, possibly even from userspace as the very last action in rc.d?
WD uploaded the GPL code on their website. The WD's config is located in packages/kernel_2.6.32-11/arch/powerpc/configs/44x/apollo_3G_nas_defconfig. I did take a peek and the CONFIG_BOOKE_WDT option is not enabled. So, the watchdog isn't initialized and can never fire. The machine_power_off in this kernel looks like this:
void machine_power_off(void)
{
machine_shutdown();
if (ppc_md.power_off)
ppc_md.power_off();
#ifdef CONFIG_SMP
smp_send_stop();
#endif
printk(KERN_EMERG "System Halted, OK to turn off power\n");
local_irq_disable();
while (1) ;
}
So yes, it does just infinitely loop. If you want to confirm it, you could attach a serial cable to the MBL' s serial port and load up the original firmware and try to shutdown the system. You should see the "System Halted..." message (or parts of it) over the serial console.
There are several ways. Although some are idiotic or academical.
get rid of the watchdog.
(And make it a module again, that can be removed. so that on future (re-)boots the MBL will wait in the loops)
get procd not to enable the watchdog by default.
make machine_halt() and machine_power_off() to service the watchdog every now and then.
...
No, the booke_wdt is by design a NOWAYOUT watchdog. Once it was set, it can't be disabled by any software means. If you want, you can read about it in various booke-compatible CPUs Manuals.
The watchdog is explained in "3.8.1 Timer control register (TCR)" on page 79/1025:
Look for the WRC bits:
When a watchdog reset event occurs, the value programmed into WRC is reflected
on core_wrs and into TSR[WRS], but the WRC bits are reset to 00. At this point,
software can reprogram WRC. Although WRC can be set by software, it cannot be
cleared by software (except by a software-induced reset). Once written to a non-zero
value, WRC may no longer be altered by software.
00 No watchdog timer reset will occur. TCR[WRC] resets to 00; it can be set by
software, but cannot be cleared by software (except by a software-induced reset).
xx Other values: Force processor to be reset on second time-out of watchdog
timer. The exact function of any of these settings is implementationdependent.
Thank you again. So there's no practical way with LEDE. This is a minor problem. I wonder what would be the best way to get to a state where the drive can safely be powered down. Probably the state directly after (re)boot before the drive engages again. I'm just not really fond of a safe shutdown meaning "wait until LED is blue, then be super quick about it.".
@takimata,
I think this will work in a pinch. It basically allows for the system to go into a state were the harddrive is effectively powered off indefinitely and it's not doing anything.... All this while keeping the Booke Watchdog around.
While the GPIO_POWEROFF isn't available (as in: not selected in the kernel config and no LEDE-Module) in the standard LEDE installation, you can use the devicetree changes to power off the MBL with a standard Installation.
The downside is, you have to do some stuff with a script or by hand
replace the /boot/boot/apollo3g.dtb on your MBL with this apollo3g.dtb https://gist.github.com/chunkeey/c4212996c23c669e2504637fdec2b6ee
[sha256 fb2f91822c74e8b9f80f310c5cd7c8f64dfc67fc2eaf740ff8a342a312360df9 apollo3g.dtb]
[note: please verify the apollo3g.dtb before you overwrite the existing one, the sha256 sum has to match.]
reboot the MBL (this is necessary, to get the enable-button line reassigned/free)
(If there was support for DT Overlay, this could be done without rebooting)
run this script as root when you want to poweroff:
#!/bin/sh
echo 473 > /sys/class/gpio/export # This is GPIO1 on the GPIO-Controller at 0x4e0000000
echo out > /sys/class/gpio/gpio473/direction
echo 1 > /sys/class/gpio/gpio473/value # drive it high
poweroff
(Note: poweroff is still needed here so the HDD will be put into standby/idle... which causes it to spin down. If you use reboot, the device will still not come back, but the HDD will keep spinning ).