OpenWrt for Zyxel WSM20 (Multy M1) development discussion

That's the generation of the upgrade image, not the upgrade script. The upgrade script is on the file system in /lib/upgrade/platform.sh and is executed for installing the upgrade:

And especially for MSTC IODATA devices (this is what I meant before with similar to the IODATA devices):

What I like best is the following approach:

  • run zyxel_mstc_upgrade_prepare (yet to be developed), which then
    • checks the current active partition
    • if RAS2 is active, copy RAS1 to RAS2, effectively overwriting the current initramfs system
    • set RAS1 as active image
    • set bootmenu_delay=3 in U-Boot to be on the safe side
  • flash to RAS1
  • If RAS1 was currently active, RAS2 is kept as-is and flashing continues.

That way, we preserve any OEM image that was previously installed and subsequent OpenWrt upgrades boot from RAS1 anyway.

Makes sense that protocol.

I was wondering something because I have not tested this (I should):
If I flash through OG UI the inibooramfs image, it reboots into OWRT.

If I then plug off the device without any further operation, what happens exactly?
It may reboot into OWRT again?
It's rebooting into a initbootramfs, right? so theorically it doesn't have any persistence?

PS:
I would set bootmenu_delay=5. It's very hard to pick it sometimes even with 5.

Exactly. It's then OpenWrt but without persistence. That way, it doesn't matter which partition it is installed to as it does not have to look for a root file system.

Hard? I'm pretty sure that mine is set for 3 and it now has a countdown of 3 seconds. Any cursor key interrupts the timeout and moves to the next menu position. I was tempted to set it to 1 ...

Can you plug in the device with the USB TTL connected to PC?

In my case, if I have USB TTL connected, device doesn't boot.
To boot I have to

  1. Plugin in the device
  2. Quickly, put the USB on the USB port
  3. Open the serial terminal.

In 3 seconds, it's hard to achieve. In 1 second is completely impossible. In fact, I've been leaving the thing to boot into OG firmware failsafe mode and then reboot from there, to make it easier.

In Fedora I can leave the serial waiting for input but still I need to plug the USB TTL before I plugin the router. So in 3 seconds it's fairly easy to make it. But in Windows is a pain in the ass.

Yes, no problem, I have it connected all the time.
I'm experiencing the same behavior with another device (Xirrus AP), though.

I also had with some usb / ttl a blocking at startup
the one I have right now that works is a CP210x
try another if you have

I have > 10 different models !!!

  • a FDTI no problem
  • with a CH340 it blocks, the zyxel box does not even have the LEDs that light up

Oh so it's a problem of the TTL

Yes EXACTLY, mine is a CH340 the first usb serial I snapped on Amazon a while ago, and it works great with my Tasmota/ESPHome crappy devices :rofl:

And this is the reason it should be at 5 seconds for the boot time, otherwise it's almost impossible to get there on time (and still on 5 secs it's pretty tricky if I don't put the USB on time) :dizzy_face:

By the way @hecatae also reported this behavior a time ago for a similar router. He did a even more trickier stunt to fool the issue: he disconnected GND and plugged it back after powering the router. I found that just not plugin the USB was simpler. Now here you have the solution to the issue :slight_smile:

PS: Maybe I can snap a FT232RL that I find on Amazon relatively cheap also, may it work better?

I have an FT232R with this problem, but the CP210x works.

I forgot because I have more than ten adapters with CP210x

for the CH340 if you remove the led diodes from the adapter it no longer
blocks the start

the leds ( gadgets )with their "low value" 330R resistors interfere with the RX/TX line.

cut near the pinouts ( red lines )

1 Like

I started trying to mod the router and I ended modding the TTL? :rofl:

I've snatched a CP2102 slightly pricier but I hope it works better :slight_smile:

my CH340 run fine without the 3 leds

I just updated the PR and code to automatically take a backup of the firmware partition in case we would overwrite all copies of the stock firmware during installation. The installation is now simplified to flashing the -initramfs version from the stock GUI and once booted run sysupgrade with the -sysupgrade version. The rest is taken care of by the sysupgrade mechanism.

You put 3 seconds at last :rofl:

First of all thanks for the supporting this nice affordable new device. I flashed one device with the debug/sysupgrade page. The only hickup was to notice the renaming of the -initramfs-recovery.bin image. I'm using 802.11s and batman, no problems so far. What kind of speed can we expect ?

Consider that this device only supports VHT80 so expect, at most, around 600Mb/s. Don't have immense expectations. For $25-30 we cannot ask for anything better (almost 4 times more I spent some years ago on a DIR-882, and it's much worse).

Personally, I only saw this device interesting just because it almost cost me the same as a Low cost Wifi N device which was my first idea (I bought a pair of tl-wr841n thinking I could mod them to fulfill my needs but just 4/32 is not enough, and not even supported by main branches of OWRT). So basically this router is completely nuts, unbeatable in price (you have to get it on a budget though, like most routers recommended in this forum, like Belkin RT3200 and Dynalink WRX36, otherwise none of them are that awesome). I have two separate WiFi, one for IoT and one for regular and work use and this router is simply too much for this purpose. It's like 3 times more I would expect for that use.

But I would not use this router as a daily driver, unless I didn't have big requirements. Personally I would opt for Dynalink WRX36 or a Xiaomi AIOT AC3600 otherwise. Also we don't have to forget that this router is almost comparable to ASUS RT-AC53 which I was about to buy a couple, for double the price (so currently I would only have 3 units, instead of the 6 ZyXEL I have)

PS: I still have to run many tests, but suddenly, a ton of work has come to my life :dizzy_face: Let's see if some others start commenting back on their experience.

2 Likes

Thanks, I fixed the commit message to read -initramfs-kernel.bin.

Two first machines done succesfully. The third machine does not boot the flashed owrt sysupgrade but boot the oem fw instead. Are there some env parameters to be set before the sysupgrade ?

root@OpenWrt:~# fw_printenv
bootcmd=mtkautoboot
bootmenu_0=Startup system (Default)=mtkboardboot
bootmenu_1=Upgrade firmware=mtkupgrade fw
bootmenu_2=Upgrade bootloader=mtkupgrade bl
bootmenu_3=Upgrade bootloader (advanced mode)=mtkupgrade bladv
bootmenu_4=Load image=mtkload
bootmenu_5=Upgrade mtkfirmware=mtkupgrade mtkfw
fdtcontroladdr=8ffeb890
ipaddr=10.10.10.123
serverip=10.10.10.3
stdin=serial
stdout=serial
stderr=serial
serialnum=S220Y420894xx
countrycode=E1
ethaddr=D4:1A:D1:18:B0
wifiwpapsk=HV4KCNTKEF47
bootmenu_delay=3

Hm, interesting. The boot partition is not selected using env variables but by a flag set in the "persist" partition. A script inside the sysupgrade handler should take care of that (and it has already run, since bootmenu_delay is set to 3 (the default is 0).

Could you run the following command to check what it is currently set to:

hexdump -s 4 -n 1 -e '"%x"' /dev/mtdblock7

(I hope that /dev/mtdblock7 is the persist partition, I have no device at hand to verify that right now)

The -e format parameter does not provide output at all.

root@OpenWrt:~# hexdump -s 4 -n 1 /dev/mtdblock7
0000004 0002
0000005

Ah yeah, it could be the quotes, I copied it from the script.
That indicates that it's set to boot from partition 2, i.e. the initramfs firmware you are currently running- good.

Do you have the chance to attach serial console to the device?

It would be interesting to know what goes wrong during the flashing procedure - I assume that it succeeds in setting the partition to the first one as it reboots to stock but then fails to flash the OpenWrt image - or it fails to create the backup, that would have the same effect. Unfortunately, it disconnects the SSH session and shows these messages only on the UART console.