Adding support for SERCOMM NA502S

I tried it with the non premium gateway, did unfortunately also not work.

Today I did experiment a bit with the premium device and the i noticed, that it is broadcasting a wifi network named disabled with the password disabled.
Inside the Network, the devices has port 53 and 22 open. SSH only with public key authentication.

And I have noticed there is a option 5 within the bootload.


Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   9: Load Boot Loader code then write to Flash via TFTP.
    Uboot StandAlone Entry

You choosed 5

System Boot Linux via Flash.

    Uboot StandAlone Entry
Flash Sector Number : 522.

    Sercomm Boot Version 2.00.5

Entering Firmware : Everything is OK.
kernel addr :0xbfd40000
kernel addr :0xbfd40000

flash base: 0xbfc00000, kernel addr :0xbfd40000, bootloader size: 0x80000, config size 0x80000, fac size : 0x40000
..Erasing NAND Flash...
.Writing to NAND Flash...
## Booting image at 80100000 ...
Bad Magic Number,24800008

                MT7621   stage1 code 13:15:05 (ASIC)
                CPU=50000000 HZ BUS=16666666 HZ

the it restarts.

And option 8:

    Uboot StandAlone Entry

You choosed 8

8: System Load UBoot to SDRAM via TFTP.
 Please Input new ones /or Ctrl-C to discard
        Input device IP ( ==:
        Input server IP ( ==:
        Input Uboot filename (kernel.bin) ==:kernel.bin
..Erasing NAND Flash...
.Writing to NAND Flash...

 netboot_common, argc= 3

 NetTxPacket = 0x8FFE50C0

 KSEG1ADDR(NetTxPacket) = 0xAFFE50C0

 NetLoop,call eth_halt !

 NetLoop,call eth_init !
Trying Eth0 (10/100-M)

 Waitting for RX_DMA_BUSY status Start... done

TFTP from server; our IP address is
Filename 'kernel.bin'.

 TIMEOUT_COUNT=10,Load address: 0x80200000
Loading: *

I'm not sure if entering "5" had any effect: The output corresponds to the default, booting Linux from Flash.
Unfortunately, I still haven't had the time to check how my second, brand-new gateway behaves. The other four non-premium gateways that I have all worked flawlessly with the installation instructions posted in the Wiki.

Do you get the same problem with the "standard" gateway, i.e. it reverts back to the default firmware?

The standard gateway also reverts back to the default firmware, but it did not send out the "disabled" wifi.

Thought I would chime in and report I'm having the same issue as JonasGhost. Following the suggestions provider I was able to replicate the same results: Image1 overwrites Image2 upon bootup. Patnam=2 dosent persist between reboots. Both Images report OK with valid magic number...

The device I'm working with is a "Scout" branded NA502S sold in the US. It's running a later version bootloader: 3.00.1....

Appricieate everyone's efforts thus far and more than happy to test any suggestions and report back with results!

Well, we could easily overwrite Image 1 with OpenWrt - but then there is no way back to the stock firmware that I am aware of - at least, I was unable to find a recovery image from A1.

I still have a brand new NA502S (also A1 branded), but I haven't had the time to investigate this further.

OK, I think I figured it out. I tried it on a brand new NA502S that had Image 1 OK and Image 2 Error. I left it connected to the Internet for some time and, contrary to my previous experience, it stayed in a reboot loop. Similar to your experience, OpenWrt would never boot from flash.

Please be careful following the next instructions, you can permanently brick your device if you write to the wrong NAND location.

I compared NAND dumps of different boot configurations. The partition "config" (represented as /dev/mtd1 in OpenWrt) contains the boot flags at offset 0x20000 / 0x20004. It is possible to read/write to the NAND in U-Boot, the following instructions are for the U-Boot command line. Please be aware that the partition /dev/mtd1 is at offset 0x80000, so the location 0x20000 becomes 0xa0000 in U-Boot.

First, examine the current configuration:
sc_nand r 0xa0000
This gives a lot of output, of interest are just the first few bytes:

03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00

This configuration 0x03 / 0x02 loads kernel 1 on my device. In older dumps, I found the combinations 0x01 / 0x00, 0x01 / 0x02 and 0x05 / 0x06, so I tried them all. The following are my observations:

0x01 0x00 => Kernel 1 (stock configuration before flashing firmware)
0x01 0x01 => Bad Magic Number (reset loop, Linux is not booted)
0x03 0x02 => Kernel 1
0x01 0x02 => Kernel 2
0x05 0x06 => Kernel 2

So on my machine, I issued the following commands to switch to Kernel 2 (OpenWrt):

sc_nand w 0xa0000 0x01
sc_nand w 0xa0004 0x02

Switch back to Kernel 1 (Stock Recovery):

sc_nand w 0xa0000 0x03
sc_nand w 0xa0004 0x02

Obviously, it's not necessary to write to 0xa0004 every time if the value is already 0x02.

It should be possible to set the boot configuration from within OpenWrt as well - I'll figure this out next. I'm quite positive this will also work on the NA502 (i.e. without the "S"), let's see.

EDIT: It might be something like a boot count. I also tried 0x07 / 0x06 and it boots kernel 1. I assume that it just compares the two offsets, if the first one is higher than the second one, Kernel 1 is booted, otherwise Kernel 2. If both are equal, it fails with "Bad Magic Number". 0x00 / 0x01 also loads kernel 2.

EDIT2: Currently, it doesn't work from within OpenWrt as the partition is marked read-only. If I have some free time during the next days, I'll sync my fork with the latest OpenWrt code and remove the flag.


Would help?

1 Like

Yes, probably. In the meantime, I was a bit adventurous: I got hold of a recovery image of a Vera secure. If you keep the reset button pressed while booting, it enters a recovery mode. Using this recovery image can be flashed to a NA502S gateway. However, MiOS is not properly registered and thus doesn't fully work.

Going back didn't work and I bricked the device (killed U-Boot, although I don't know how).

I have used sercomm-recovery with a secomm-device before. It worked but I had to create an image from a flash dump like detailed in here:

Since this post @csharper2005 and @MaxS0niX came up with a more suitable solution to create the file with correct OOB data (I used BBE to just pad 00's since they are discarded by the tool before flashing).

Also when you press the reset button (at least on our devices) you should get a log about what is going to be flashed and what is going to be kept, this means the flash dump has to be complete (at least till the kernel and rootfs that needs to be booted) but the bootloader and config as well as the OOB will be discarded and not changed.

I am not sure I am making sense here but I haven't played with the sercomm device for a few months but I am sure @MaxS0niX and @csharper2005 will be able to help more in regards to the tool

Yeah, I flashed the Vera firmware with sercomm-recovery and tried to go back by flashing my backup using nandwrite from within the Vera firmware. I still don't know what went bad, but since U-Boot is gone, the recovery mode is gone as well.

The Vera recovery image definitely changed the bootloader.

The only solution that I'm aware of to revive my device is to flash the NAND directly. I don't have the necessary tools, so this gateway is dead. Since they sell for as low as €10,- used, it's not a big deal.

first post and immediately a question :grimacing:

I got one of the NA502s from my parents, because they had no use for it and was very happy to find your efforts to make it work with OpenWRT.
I managed to get the firmware booting with your informations here (had to do only the sc_nand w 0xa0000 0x01 part).
Also i was able to compile the 21.02.3 tagged source, which i cloned from the official GitHub and patched your changes in there.
The image works and i can control the LED's and the 502 seems to work fine.
The only thing i can't get to work is the ser2net part for ZigBee and ZWave. It seems like the devices aren't even listening / reacting on /dev/ttyS1 or ttyS2.

Do you have any hints, what i maybe have missed?
Do i have to enable the ZigBee or ZWave device on the 502 first somehow?

What i've done so far is:

  • install the ser2net and ser2net-app package via opkg
  • configured one port via the Lucia app
    • Port 5000, Protocol Raw, /dev/ttyS1, 115200 8N1
  • at my OpenHAB instance on another server i used socat to connect to the 502
    • it connects, but then nothing more happens
  • tried cat /dev/ttyS1 and screen /dev/ttyS1 115200 8N1 from a root shell at the 502
    • here i also get nothing, no output, no reactions on keypresses

ZWave is at /dev/ttyS1 115200 baud, ZigBee is at /dev/ttyXRUSB1 57600 baud.

The modules might be in reset state, please check the zwave_reset and zigbee_reset GPIOs.

Thanks for the hint, i don't see a ttyXRUSB1.

root@openwrt87:/# ll /dev/tty*
crw-rw-rw-    1 root     root        5,   0 Jan  1  1970 /dev/tty
crw-rw----    1 root     dialout     4,  64 Apr 21 18:11 /dev/ttyS0
crw-rw----    1 root     dialout     4,  65 Jan  1  1970 /dev/ttyS1
crw-rw----    1 root     dialout     4,  66 Jan  1  1970 /dev/ttyS2

I'm focusing on ZWave now, to try to get one thing working before trying another.
What i can see is that the modules seem to be in reset state.
I'm looking at /sys/class/gpio/zwave_reset:
cat /sys/class/gpio/zwave_reset/active_low is 1
cat /sys/class/gpio/zwave_reset/value is 0
If i understand that right, the pin is in a low state and therefore the module in reset (because active_low == 1).
If i do an echo 1 > /sys/class/gpio/zwave_reset/value it puts a 1 in there, but nothing more happens.
I can do the same things with leds or the buzzer, that works and the buzzer is awfully loud :smiley:

Maybe i'm missing a kernel module in my build config or something similar.
Do you have a diff config for the 502s somewhere or does it make no sense to do that?

So i just checked on my box: the GPIO has active_low=1 and value=0 for the module to function properly. active_low == 1 means that the GPIO is in low state if the value is 1 and it is in a high state if the value is 0. That makes sense, the module is in reset for as long as the GPIO is pulled low.

My /etc/config/ser2net config file looks like this:

config ser2net 'global'
	option enabled '1'

config controlport
	option enabled '0'
	option host 'localhost'
	option port '2000'

config default
	option speed '115200'
	option databits '8'
	option parity 'none'
	option stopbits '1'
	option rtscts 'false'
	option local 'false'
	option remctl 'true'

config proxy
	option port '5000'
	option timeout '0'
	option baudrate '115200'
	option databits '8'
	option parity 'none'
	option stopbits '1'
	option xonxoff 'false'
	option enabled '1'
	option protocol 'raw'
	option device '/dev/ttyS1'

The kernel version is 5.4.105, so if you forward-ported it to the current OpenWrt code, you might have hit some problem with a newer kernel version. For the /dev/ttyXRUSB0 and /dev/ttyXRUSB1 nodes to show up, you need kmod-usb-serial-xr_usb_serial_common installed and loaded.


Oh wow that did it! Thank you so much for your help :partying_face:
I think your ser2net config was the central thing, mine was missing all the rtscts, remctl and xonxoff lines.
Maybe they are default on if nothing is in the config file and so it was somehow waiting for the signals on those lines.
But now i have a happy "Online" badge at my OpenHAB instance. I'm using the Z-Wave Serial Bridge.
I still have to test ZigBee and the devices that were provided with the 502s package (window open sensor, temperature sensor and so on) but now i am a huge step further.
Oh and i never mentioned the exact build i'm on:

. .
Firmware Version OpenWrt 21.02-SNAPSHOT r16577-75cbd8de00 / LuCI openwrt-21.02 branch git-22.099.58713-fe09ab9
Kernel Version 5.4.188

The provided devices where ZWave, both a temperature/luminance sensor and a window open sensor are working great!

I'm glad you got it working. I've got all kinds of ZWave devices running with this gateway and zwavejs/Home Assistant on the other end while providing a nice WiFi AP as an added benefit.

Once some remaining issues are ironed out (most notably the fake sx1509 in the dts), I can create a PR for this device too.

If somebody wants to figure out how a recovery image is built, we might not even need to disassemble the device for the initial installation.

1 Like

Just a short fyi: I've updated my branch and I've created a PR:


I was able to find the version of the Zigbee Firmware of the Zigbee chip:

2022/05/04 19:28:28 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2022/05/04 19:28:28 Elelabs_EzspFwUtility:   Firmware: 6.4.0-129
2022/05/04 19:28:28 Elelabs_EzspFwUtility:   EZSP v7

The chip is a EM357, i tried upgrading it to a newer version, but did not had success.
I tried it over ser2net with an WSL Ubuntu System as other endpoint. I used this tool:

fyi: The PR for the NA502S has just been accepted, so it's now in Snapshot! Official release will follow with the next release cycle.

1 Like

Andreas - Just wanted to thank you for the time and effort spent on this device. Very much appreciated. Thanks again!