NAS326 - Set wakealarm at shutdown fails - on reboot fine

Fusel

I want to start my NAS every day at 08:00.
When i set the wakealarm for rtc on reboot it works fine.
I use the script below to set wakealarm

START_TIME="08:00"
START_TIME=$(date -d "$(date "+%Y-%m-%d") $START_TIME:00" "+%s")

sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
sh -c "echo $START_TIME > /sys/class/rtc/rtc0/wakealarm"

On shutdown i check some parameters and sometimes i want to wakeup the NAS before 08:00.
When i use the script above to wakeup e.g. at 03:00, i set START_TIME to "03:00" and run it the same way like on reboot. But this doesn't work.
(I also prefer to set the next default start time at shutdown instead of reboot, but even this fails.)

On shutdown i tried to save the wakealarm file and it contains the right wakeup timestamp. But the NAS doesn't start.

Short: On reboot works, on shutdown doesn't.

Why?

#NAS_Mar_2019

Mijzelf

I think your script interferes with the firmware timed wakeup implementation. At reboot it's not necessary to set the rtc, so in that case your script has 'the last word', but at shutdown the firmware sneaks in and overwrites your action.

Having said that, I have no idea how the firmware sneaks in. /etc/init.d/rc.shutdown doesn't seem to do anything significant in this respect, and AFAIK 'poweroff' and 'reboot' don't call any firmware scripts, just cause init to shutdown/reboot.

Maybe you can disable the possibility of the firmware to access the rtc. Try to delete /sbin/i2cset. (Don't worry, it's in the initramfs, and will be back on reboot). A possible problem here is that /etc/init.d/rc.shutdown also calls i2cset. I 'think' to tell the MCU what to do on power loss.

If that doesn't help, you can remove the rtc from the /sys/class/ tree. On my 520 that is done with

<div>echo c2k-rtc >/sys/bus/platform/drivers/c2k-rtc/unbind</div><div></div>

BTW, how do you know your scripts works at reboot? Just pull the plug?

Fusel

Thanks a lot for your answer!

I forgot some details...
I wanted to install Tvheadend, so i installed ffp using your package.
On ffp you can use the /ffp/start/ directory to call scripts after start ffp - my autorun on reboot
In this script i set the wakeup (i rather prefer on shutdown instead) and add a script-call to /etc/init.d/rc.shutdown on first position.
This script is running on shutdown/reboot (checking by buzzerc -t 2).

Wakeup at defined time works well but setting different wakeup by using shutdown-call fails.
Copy wakealarm to hdd using my shutdown-script shows the right time, but wake on initial wakeup and not on the wakeup defined in my shutdown-script.

Setting wakeup at shutdown instead of reboot also fails.
So i think you are right, "default" firmware overrides my changes with my previous setting.
But only at shutdown/reboot.

When i delete i2cset, wakealarm still runing?
When i unbind rtc, wakealarm still possible?

Mijzelf

When i delete i2cset, wakealarm still runing?
When i unbind rtc, wakealarm still possible?

The RTC is an independent chip which is connected to the SoC by the I2C bus. And it has a copper line to some logic which is able to powerup the bus. By progamming a wakeup time you actually tell the clock to pulse that copper line at a certain time.

Deleting i2cset or unbinding the rtc has the same purpose, virtually cutting the i2c wire. If you do that after programming the chip, it should prevent the firmware (and you) from accessing the chip, but the chip itself is autonomous, and doesn't care.

So yes, wakealarm should still occur.

But if the firmware programs the rtc using another way (a direct link to libi2c) it doesn't help.

Fusel

I think it's an other problem.
When i use

ST=1553675595 // (e.g.)
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $ST > /sys/class/rtc/rtc0/wakealarm

it work.

When using

ST=$(date -d '+ 2 minutes' +%s)
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $ST > /sys/class/rtc/rtc0/wakealarm

it fails.

Maybe an problem with the date-function and/or the result of it and not with the rtc himself

Mijzelf

I suppose you have looked at the output of

date -d '+ 2 minutes' +%s

But did you also look at

/bin/date -d '+ 2 minutes' +%s

When using FFP, by default /ffp/bin/date is used, which is much more powerful than the firmware busybox applet.

/etc/init.d/rc-shutdown runs in a different environment, and so it will default to /bin/date. I don't think you can use /ffp/bin/date here, as FFP is already cleaned up.

Fusel

</code>/bin/date -d '+ 2 minutes' +%s</pre>Fails - invalid date '+ 2 minutes'<br><br><pre class="CodeBlock"><code>ST=$(/bin/date +%s)

ST=$(($ST + 180))

works