NSA325v2 (kirkwood) autopower-on /wakeup

Hello.

I recently installed latest uboot and debian (last rootfs and kernel from bodhi) on sata disk sucessfully. Now I want to schedule the power-on and power-off. I thought It was a hidden function of the box so I have been searching on fw binary following this thread.
I have found interesting things starting from a javascript file that has taken me to the same file on this thread but with no result... by now...
Anyway searching for any clue I have found some other threads on this forum talking about the possibility of use rtcwake...

I think the way of work of rtcwake could be slightly different from the way the stock fw has for scheduling power-on and off, but probably the rtcwake functionality it's enough for me and it's seems far easier.

So I have tried rtcwake with this result:

root@debian:~# rtcwake -s 60
rtcwake: /dev/rtc0 not enabled for wakeup events

Any solution?
Any clue?

Hi erkeye,

> I think the way of work of rtcwake could be
> slightly different from the way the stock fw has
> for scheduling power-on and off, but probably the
> rtcwake functionality it's enough for me and it's
> seems far easier.
>
> So I have tried rtcwake with this result:
>

> root@debian:~# rtcwake -s 60
> rtcwake: /dev/rtc0 not enabled for wakeup events
> 
>

This was a topic I forgot! (browser tab was inadvertenly closed). The last report that I recalled was rtcwake is missing in these Zyxel boxes (NSA3xx), and I've confirmed myself that there is a problem. I planned to investigate this issue further. IIRC, my kernel build did not include this config option.

Will let you know in a few days.

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

Hi erkeye,

rtwake is not possible on this box. The RTC driver does not have hooks for triggering the RTC framework for that.

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

OK. Thanks for the info. Then I'll try the RE way...

I have found some clues to follow, but all of them refer to files that I can't found on filesystem extracted from firmware.
I would like to boot with sotck rootfs as you suggest in the thread I mentioned before:

Quote
UART booting (kwboot through serial console) the stock u-boot (mtd0) and that most likely will boot into stock OS (the stock envs were untouched when you installed new u-boot). This is not something permanent, each time you want to boot stock, you would have to kwboot it.

and even do a complete (stock) system install to watch any related process working..

But... I don't know how. And maybe it's out of topic...

I don't know what kwboot is?, Is it just the way of booting from uboot prompt (nboot command or similar)? Is it possible to do that kind of boot by nc or just by serial console?

I flashed the latest Uboot, but I didn't touch the rest of mtd0. And I even did a backup following your instructions in the Uboot flash thread.

Can you help me with next steps, bodhi?

Thank you in advance

erkeye,

> I would like to boot with sotck rootfs as you
> suggest in the thread I mentioned before:
>

Quote
UART booting (kwboot through serial
> console) the stock u-boot (mtd0) and that most
> likely will boot into stock OS (the stock envs
> were untouched when you installed new u-boot).
> This is not something permanent, each time you
> want to boot stock, you would have to kwboot
> it.
>
>

>
> and even do a complete (stock) system install to
> watch any related process working..
>
> But... I don't know how. And maybe it's out of
> topic...
>
> I don't know what kwboot is?,

kwboot is the command that's used in UART booting (all latest Debian-based distros, such as Ubuntu, have this command avaliable). Basically, with serial console connected, you can load a u-boot image over serial line using kwboot. And the box will boot that u-boot version, instead of the one flashed to NAND.

It was mentioned in my u-boot installation instruction:

Quote

UART Booting: If possible, try to test this boot image with UART booting before flashing to NAND. See davygravy's UART booting using kwboot instruction here in this thread. The latest u-boot image released here should be used for UART booting, if your box is the type that supports it (these do not: Dockstar, Pogo E02, iConnect).

> Is it just the way
> of booting from uboot prompt (nboot command or
> similar)? Is it possible to do that kind of boot
> by nc or just by serial console?
>
> I flashed the latest Uboot, but I didn't touch the
> rest of mtd0. And I even did a backup following
> your instructions in the Uboot flash thread.

Instruction by davygravy mentioned above explains the details. Here is an example:

https://forum.doozan.com/read.php?3,51739,51919#msg-51919

So instead of using my latest u-boot image for this box (uboot.2017.07-tld-1.nsa325.mtd0.kwb), you would use the mtd0 backup. Recall this step during u-boot installation:

Quote

3. Be sure to save your current uBoot image in mtd0, or have a backup image saved somewhere as precaution. And save your current u-boot envs with fw_printenv, or just copy/paste the listing into a text file. Note the nanddump command below allows future restoration to the same box you're backing up, and also can be used to restore a differrent box's mtd0 if needed.

Dumping NAND mtd0:
nanddump --noecc --omitoob -l 0x80000 -f mtd0 /dev/mtd0

Therefore:

kwboot  -t -B 115200 /dev/ttyUSB0 -b mtd0  -p

That will boot the stock FW on NAND. And you can login to browse around to find the scripts. Afer that, just reboot without running kwboot will boot back to your current Debian roots.

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

Ah!! Ok, I had misunderstood the behaivour of kwboot. I thought it was a way of custom booting but directly from the box...uboot console or similar...But now I understand the concept: the box listen the serial port for someone sending a bootloader image, if nothing come, then find the bootloader on flash. So we need someone "talking" in the other side: kwboot.

Thank you very much for your clarification. I'll work on this.

I have tried with to differents USB2TTL adapters with no luck. I spend more than 3 hours, trying an retrying, with all combinations I came up with...(disconnecting 3.3v, disconecting gnd, powering the box first, conecting the adapter first...)
First of the adapters detected response from the box for just 2 times, but failing the process at the very begining(0%).
Then I tried with the second one. It was able to start the image transfer...but it failed at 18%-19% every single attempt...

I don't now why. I have used the first adapter before for flashing an OpenWrt firmware to a router before. The second one wasn't used until yesterday.

Now I'm thinking in flashing the nand dump back. Anyway, I'll try to find another adapter to make a last attempt before.

erkeye,

> First of the adapters detected response from the
> box for just 2 times, but failing the process at
> the very begining(0%).
> Then I tried with the second one. It was able to
> start the image transfer...but it failed at
> 18%-19% every single attempt...
>
> I don't now why. I have used the first adapter
> before for flashing an OpenWrt firmware to a
> router before. The second one wasn't used until
> yesterday.

Sorry, my bad. I forgot about this stock u-boot behavior (it's been quite a long time). This box has a hardware watchdog, and in the new u-boot I have disabled it. What you saw was the watchdog barking at 30 seconds after kwboot started transfering the image! Stock uboot does not disable the watchdog.


> Now I'm thinking in flashing the nand dump back.
> Anyway, I'll try to find another adapter to make a
> last attempt before.

No, you don't need new adapter. You can try kwboot the latest NSA325 u-boot image and confirm that it has no problem.

Yeah, I think the easiest way to find the scripts in stock FW is to flash the original mtd0 back.

But make sure you can kwboot successfully before you do that. And try kwboot an older version of the NSA325 u-boot. This is so that you can see that it is actually another u-boot image is running, and not the one on NAND.

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

erkeye,

Try this to see if it works.

- Boot up normally all the way into Debian.

- On serial console server, start kwboot with the mtd0 dump. So kwboot will wait for the handshake.

- Reboot the box (don't shutdown)

shutdown -r now

And se if kwboot will complete the xfer and stock uboot will start.

I hope the box will not overwrite the watchdog disable bit that was set in a normal boot (a reboot should not clear that bit).

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

I'm a little bit lost. I think I don't undertand the uboot loading process and the watchdog behavior...

> No, you don't need new adapter. You can try kwboot the latest
> NSA325 u-boot image and confirm that it has no problem.

I have tried this and sucess!!!. But I don't know how or why... The only diference is the image file...so.. What's happening? Is the last uboot being sucessfull (kwboot-)loaded before the first bark? That's all?
I mean. We need the watchdog disabled before the one who disable it (uboot) is loaded....so every attempt should fail except the images with lower size...


> I hope the box will not overwrite the watchdog disable bit
> that was set in a normal boot (a reboot should not clear that bit).

I haven't been able to do that yet (S.O. in hd but box disassembled...) but I tried reset command in uboot prompt with no success. Maybe it reboot too fast...or maybe this way reset that bit...
I'll try what you say later, but I think I won't be able to try until friday.

Thanks bodhi.

erkeye,

> I'm a little bit lost. I think I don't undertand
> the uboot loading process and the watchdog
> behavior...
>
> > No, you don't need new adapter. You can try
> kwboot the latest
> > NSA325 u-boot image and confirm that it has no
> problem.
>
> I have tried this and sucess!!!. But I don't know
> how or why... The only diference is the image
> file...so.. What's happening? Is the last uboot
> being sucessfull (kwboot-)loaded before the first
> bark? That's all?
> I mean. We need the watchdog disabled before the
> one who disable it (uboot) is loaded....so every
> attempt should fail except the images with lower
> size...

It is a bit subtle. If the image is large, the watchdog kicks in during the transfer, so the box is reset. If the image is small, the transfer completes. However, the watchdog is still alive so it will reset the box a bit later.

kwboot loading u-boot image over serial works in 2 steps, like this in general (there are more complicate details, but I've simplified it):

- The image header is transfered first. And inside the header, there are commands to set RAM size, registers, GPIO,.... The commands in the header are executed by the BootROM (IOW, without the RAM, there is no place for the image body to be loaded to).
- The image body is then transfered. When it is complete, the BootROM executes (i.e. jumps to) the address of the image in RAM.

So for this NSA325box, what we did was putting a command that set the GPIO 14 to kill the watchdog inside the header. So immediately right after the header was executed by the BootROM, the watchdog is gone. The image body is then transfered without interruption. The key point is the header is quite small, so it take only a few seconds to send, and be executed.

It would also work if the image is small enough, and there is a few lines of code to set that GPIO 14 right at the start (this was the approach I used during initial testing).


> > I hope the box will not overwrite the watchdog
> disable bit
> > that was set in a normal boot (a reboot should
> not clear that bit).
>
> I haven't been able to do that yet (S.O. in hd but
> box disassembled...) but I tried reset command in
> uboot prompt with no success. Maybe it reboot too
> fast...or maybe this way reset that bit...
> I'll try what you say later, but I think I won't
> be able to try until friday.

IIRC, the reboot worked in the past, but too long ago so I'm not certain.

===
EDITED: typos

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



Edited 2 time(s). Last edit at 12/14/2021 07:20PM by bodhi.

> The image header is transfered first.
> what we did was putting a command that set the GPIO 14 to kill the watchdog inside the header

Now everything makes sense. Thanks for the explanation.