Hello bodhi,

I think that was the reason why I wrote my own script.
I had also wondered why I didn't just use “rtcwake”.
However, I've been using the script for 7-8 years and can't remember the details.

I have attached my script so you can test it by yourself.
At the top of the script you set the day and time for the next start.
The script calculates the next start time in seconds and set it via echo into “/sys/class/rtc/rtc0/wakealarm”.
After executing the script, I shut down the NAS with the “halt” command.
Thats all.

I hope that helps

Otto

Otto,

Quote

I think that was the reason why I wrote my own script.

Yes, I think it must have been. And I see you actually halted the NAS, not putting it in standby. So it dit not go through the path to mvebu suspend.

Thanks!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi, was this ever resolved?
I tried rtcwake myself before on NSA325v2 with 6.14.6-kirkwood-tld-1 before finding this thread but without luck. Same write errors and system cannot hibernate nor suspend as the ethernet seems to refuse to suspend.

Does the rtc alarm work? I tried the work around suggested by ottok setting the alarm directly to /sys/class/rtc/rtc0/wakealarm then tried both poweroff and halt but the box did not wake up. Then I did nothing after setting the rtc alarm and expected to see a rtc message in dmesg or journalctl, but nothing. Should there not be a message from the wakeup alarm?

/Jan

Jan,

> Hi, was this ever resolved?
> I tried rtcwake myself before on NSA325v2 with
> 6.14.6-kirkwood-tld-1 before finding this thread
> but without luck. Same write errors and system
> cannot hibernate nor suspend as the ethernet seems
> to refuse to suspend.

I've not tried to resolve this, other than looking in the code to verify that the capability is still there. This driver has not been updated for a few years.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Note that this DTB has not been tested.
>
> Please test this updated DTB for the ReadyNAS duo
> V2 . This needs to be used with kernel
> linux-6.10.11-kirkwood-tld-1 or later. The RTC
> driver for this box (rs5c372) is quite different
> from the Zyxel NSA325 (pcf8563). So don't know if
> this will work.
>
> I'd suggest that you back up your rootfs, and
> remove the HDD data drive before the test. There
> was no change in the latest kernel is in this
> driver (but there might be changes somewhere else
> in the RTC infrastructure). We need to take
> precaution, especially if you are going to
> hibernate or suspend the system.
>
> - Download the attached DTB
> - Rename the current DTB in /boot/dts.
> - Copy the new DTB to /boot/dts
>
> If you are running stock u-boot then recreate the
> uImage with this DTB before reboot.
>
> After login to Debian (as root), check the
> infrastructure
>

> ls -l /sys/class/wakeup/
> ls -l /sys/class/wakeup/wakeup3/
> ls -l /sys/class/rtc/rtc0/
> cat /sys/class/rtc/rtc0/wakealarm
>

>
>
> Now you can proceed with rtcwake.

Hello Bodhi,
sorry for the long absence, but I had no time to further work on this project until now. I have done the steps for testing the new DTB for Readynas duo v.2 , and these are the results:

root@mintvm:~# ssh root@192.9.200.125 -p 222
root@192.9.200.125's password: 
Linux nas-backup 6.10.11-kirkwood-tld-1 #1 PREEMPT Sun Sep 22 15:40:38 PDT 2024 armv5tel

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jan  4 19:54:05 2025 from 192.9.200.25
nas-backup
192.9.200.125
NETGEAR ReadyNAS Duo v2
Linux version 6.10.11-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 PREEMPT Sun Sep 22 15:40:38 PDT 2024
Debian 12.6
Fri Dec 19 17:31:35 CET 2025 up 8 minutes
root@nas-backup:~# ls -l /sys/class/wakeup/
total 0
drwxr-xr-x  2 root root 0 Jan  1  1970 .
drwxr-xr-x 53 root root 0 Jan  1  1970 ..
lrwxrwxrwx  1 root root 0 Jan  1  1970 wakeup1 -> ../../devices/platform/mbus@f1000000/mbus@f1000000:pcie@82000000/pci0000:00/0000:00:01.0/0000:01:00.0/wakeup/wakeup1
lrwxrwxrwx  1 root root 0 Dec 19 17:25 wakeup2 -> ../../devices/platform/ocp@f1000000/f1011000.i2c/i2c-0/0-0032/wakeup/wakeup2
lrwxrwxrwx  1 root root 0 Dec 19 17:25 wakeup3 -> ../../devices/platform/ocp@f1000000/f1011000.i2c/i2c-0/0-0032/rtc/rtc0/alarmtimer.0.auto/wakeup/wakeup3
root@nas-backup:~# ls -l /sys/class/wakeup/wakeup3/
total 0
drwxr-xr-x 2 root root    0 Dec 19 17:22 .
drwxr-xr-x 3 root root    0 Dec 19 17:22 ..
-r--r--r-- 1 root root 4096 Dec 19 17:32 active_count
-r--r--r-- 1 root root 4096 Dec 19 17:32 active_time_ms
lrwxrwxrwx 1 root root    0 Dec 19 17:32 device -> ../../../alarmtimer.0.auto
-r--r--r-- 1 root root 4096 Dec 19 17:32 event_count
-r--r--r-- 1 root root 4096 Dec 19 17:32 expire_count
-r--r--r-- 1 root root 4096 Dec 19 17:32 last_change_ms
-r--r--r-- 1 root root 4096 Dec 19 17:32 max_time_ms
-r--r--r-- 1 root root 4096 Dec 19 17:32 name
-r--r--r-- 1 root root 4096 Dec 19 17:32 prevent_suspend_time_ms
lrwxrwxrwx 1 root root    0 Dec 19 17:25 subsystem -> ../../../../../../../../../../../class/wakeup
-r--r--r-- 1 root root 4096 Dec 19 17:32 total_time_ms
-rw-r--r-- 1 root root 4096 Dec 19 17:22 uevent
-r--r--r-- 1 root root 4096 Dec 19 17:32 wakeup_count
root@nas-backup:~# ls -l /sys/class/rtc/rtc0/
total 0
drwxr-xr-x 4 root root    0 Dec 19 17:22 .
drwxr-xr-x 3 root root    0 Dec 19 17:22 ..
drwxr-xr-x 4 root root    0 Dec 19 17:22 alarmtimer.0.auto
-r--r--r-- 1 root root 4096 Dec 19 17:32 date
-r--r--r-- 1 root root 4096 Dec 19 17:32 dev
lrwxrwxrwx 1 root root    0 Dec 19 17:32 device -> ../../../0-0032
-r--r--r-- 1 root root 4096 Dec 19 17:22 hctosys
-rw-r--r-- 1 root root 4096 Dec 19 17:32 max_user_freq
-r--r--r-- 1 root root 4096 Dec 19 17:32 name
-rw-r--r-- 1 root root 4096 Dec 19 17:32 offset
drwxr-xr-x 2 root root    0 Dec 19 17:32 power
-r--r--r-- 1 root root 4096 Dec 19 17:32 since_epoch
lrwxrwxrwx 1 root root    0 Dec 19 17:22 subsystem -> ../../../../../../../../class/rtc
-r--r--r-- 1 root root 4096 Dec 19 17:32 time
-rw-r--r-- 1 root root 4096 Dec 19 17:22 uevent
-rw-r--r-- 1 root root 4096 Dec 19 17:32 wakealarm
root@nas-backup:~# cat /sys/class/rtc/rtc0/wakealarm
root@nas-backup:~# date
Fri Dec 19 17:33:57 CET 2025
root@nas-backup:~# rtcwake -s 180
rtcwake: set rtc wake alarm failed: Invalid argument
root@nas-backup:~# rtcwake -s 30
rtcwake: set rtc wake alarm failed: Invalid argument

It seems as the rtc wake did not work, can I try some other way on making the nas to wake up on a weekly time schedule ?
Thank You !

AndreaCipcino,

Have you tried what Otto did above?

https://forum.doozan.com/read.php?2,137911,138165#msg-138165

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi, hi AndreaCipcino,

unfortunately, the WakeUp script no longer working since some kernel updates.
I starts the WOL from a Raspi via cron now.

Otto

Otto

> unfortunately, the WakeUp script no longer working
> since some kernel updates.

> I starts the WOL from a Raspi via cron now.

Yes, it's a good way to get around this rtc_wake problem.

Last time I looked at the driver, mvebu suspend code seems to have a problem. Not sure if I want to try fixing it (not a simple task).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)