Adding support for SERCOMM NA502S

I've got a new device I'm trying to add support for: The SERCOMM NA502S, also sold as the A1 Smart Home Premium Gateway in Austria or the Vera Secure Gateway (I've got the A1 version). It is related to the SERCOMM NA502, but there are quite some hardware differences (see Adding support for Sercomm's NA502 for the NA502).

Features:

  • MT7621S
  • 512MiB RAM
  • 128MiB NAND
  • 2.4G WiFi
  • 5G WiFi
  • BLE
  • ZWave
  • ZigBee
  • 3G
  • Microphone Input
  • Buzzer output

U-Boot can be easily accessed via the Serial Console and does boot a kernel.
I'll have to reconstruct the partition layout from a NAND dump, because the installed OS has only very limited console output. The primary firmware image performs an automatic recovery of the second firmware image. The second kernel is much more communicative! There are no open ports, the device can only be managed by a subscription with the ISP.

Current Status (WiP):

  • Kernel Boots
  • LAN working
  • WiFi working
  • ZigBee working
  • Z-Wave working
  • 3G Module visible - untested
  • All Buttons and LEDs working
  • Installation to NAND working
  • Buzzer working

Current Problems:

  • There are two i2c GPIO expanders. They are only initialized if a third fake expander is added first, since the first initialization fails.

Current development version:

1 Like

I'm a bit surprised that the interest on this device and the "regular" NA502 is so low. Here in Austria, used devices are really, really cheap to even free (!). For me, it was the cheapest solution to get a WiFi access point with a Z-Wave module.

Z-Wave works well, too. I run zwavejs2mqtt on my NAS and connect via ser2net to the Z-Wave module.

2 Likes

I am currently trying to get started with the A1 Smart Home Edit: Premium Gateway.
I was able to boot the initframefs image from here. ( https://openwrt.org/toh/sercomm/na502 )
Unfortunatly after running the sysupgrade I was not able to boot openwrt image and it was always booting the provider firmware.
Is there a different firmware imaged needed or do these steps apply on this model?

did you read the Caveats section in your link ?

The other possibility is that it didn't succeed to create the UBI partition. That happened to me once, in this case issue in the initramfs image:

mtd unlock ubi
mtd erase ubi

The first flash then failed, but a subsequent try worked. This isn't in the Wiki yet, just in the commit message. In the meantime, I've flashed about five A1 Smart Home Gateways, some of them brand new, some used.

I don't like the Premium Gateway aka the 502S too much as it has a bunch of features that I simply don't use. This thread, by the way, is the 502S development thread. It would be better to create a separate thread.

Regarding the 502S: I haven't had the time to finalize the missing issues and create a PR, so it's still in the save development state.

I am using the premium gateway. Unfortunately I forgot to mention that in the post.

That was my mistake, I did try the na502 firmware. Now I compiled the na502s firmware and tried it with this.
Here is the outputlog from that. I also did try the mtd unlock ubi and mtd erase ubi bevor that.

root@OpenWrt:/tmp# sysupgrade -n openwrt-ramips-mt7621-sercomm_na502s-squashfs-s

ysupgrade.bin e[J
Thu Mar 25 22:18:38 UTC 2021 upgrade: Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=3
- watchdog -
killall: telnetd: no process killed
Thu Mar 25 22:18:38 UTC 2021 upgrade: Sending TERM to remaining processes ... logd hostapd wpa_supplicant netifd odhcpd ntpd dnsmasq ubusd urngdsh: S: out of range
sh: S: out of range

Thu Mar 25 22:18:41 UTC 2021 upgrade: Sending KILL to remaining processes ...sh: S: out of range
sh: S: out of range

[   78.736182] sh (2485): drop_caches: 3
Thu Mar 25 22:18:42 UTC 2021 upgrade: Switching to ramdisk...
Thu Mar 25 22:18:44 UTC 2021 upgrade: Performing system upgrade...
Unlocking kernel ...

Writing from <stdin> to kernel ...  [ ]   
[   82.652658] ubi0: attaching mtd5
[   82.742572] ubi0: scanning is finished
[   82.750045] ubi0: empty MTD device detected
[   82.786898] ubi0: attached mtd5 (name "ubi", size 16 MiB)
[   82.797700] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[   82.811418] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[   82.824948] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[   82.838815] ubi0: good PEBs: 128, bad PEBs: 0, corrupted PEBs: 0
[   82.850777] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
[   82.865172] ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 2624372606
[   82.883360] ubi0: available PEBs: 104, total reserved PEBs: 24, PEBs reserved for bad PEB handling: 20
[   82.901938] ubi0: background thread "ubi_bgt0d" started, PID 3071
UBI device number 0, total 128 LEBs (16252928 bytes, 15.5 MiB), available 104 LEBs (13205504 bytes, 12.5 MiB), LEB size 126976 bytes (124.0 KiB)
Volume ID 0, size 24 LEBs (3047424 bytes, 2.9 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs", alignment 1
Set volume size to 10158080
Volume ID 1, size 80 LEBs (10158080 bytes, 9.6 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs_data", alignment 1
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[   85.155723] reboot: Restarting system

After the reboot it did boot the old firmware again.

The premium gateway differs quite a bit in how GPIOs and serial ports are set up, so the "regular" firmware should boot, but not much devices will work.

The devices have dual firmware design. From my experience, it boots kernel 1 until it has successfully flashed the latest official firmware and then switches to kernel 2. It then boots from kernel 2 as long as the checksum is correct. For this reason, OpenWrt is flashed to kernel 2.

To fix your problem, I would try the following: Connect it to the Internet and wait about 30 minutes until it has updated to the latest firmware. Afterwards, flash OpenWrt again.

If that doesn't work, we need to have a look at the log output from U-Boot.

I connected it to the internet for an hour and did try it again. Unfortunatly it did not work.

Here is a part from the serial output.


===================================================================

     		MT7621   stage1 code done 

     		CPU=50000000 HZ BUS=16666666 HZ

===================================================================



U-Boot 1.1.3 (Feb  3 2017 - 19:16:36)


Board: Ralink APSoC DRAM:  256 MB

relocate_code Pointer at: 8ffac000


Config XHCI 40M PLL 

******************************

Software System Reset Occurred

******************************

Allocate 16 byte aligned buffer: 8ffe1130

Enable NFI Clock

# MTK NAND # : Use HW ECC

NAND ID [C8 D1 80 95 40]

Device not found, ID: c8d1

Not Support this Device! 

chip_mode=00000001

Support this Device in MTK table! c8d1 

select_chip

[NAND]select ecc bit:4, sparesize :64 spare_per_sector=16

Signature matched and data read!

load_fact_bbt success 1023

load fact bbt success

[mtk_nand] probe successfully!

mtd->writesize=2048 mtd->oobsize=64,	mtd->erasesize=131072  devinfo.iowidth=8

Env addr : 0x80000

..============================================ 

Ralink UBoot Version: 4.2.1.0

-------------------------------------------- 

ASIC MT7621AS (MAC to MT7530 Mode)

DRAM_CONF_FROM: Auto-Detection 

DRAM_TYPE: DDR3 

DRAM bus: 16 bit

Xtal Mode=3 OCP Ratio=1/3

Flash component: NAND Flash

Date:Feb  3 2017  Time:19:16:36

============================================ 

icache: sets:256, ways:4, linesz:32 ,total:32768

dcache: sets:256, ways:4, linesz:32 ,total:32768 


 ##### The CPU freq = 880 MHZ #### 

 estimate memory size =256 Mbytes


Reset switch ...

#Reset_MT7530


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. 

STANDALONE_LOAD_ADDR is 0xa1200000

..

e[31m******************************************

    Uboot StandAlone Entry

******************************************e[0m


 0 


e[31m******************************************

    Uboot StandAlone Entry

******************************************e[0m

Flash Sector Number : 522.




***************************************************


    Sercomm Boot Version 2.00.5




***************************************************


Entering Firmware : Everything is OK.



=================================================

Check image validation:

Image1 Header Magic Number --> OK

Image2 Header Magic Number --> OK

Image1 Header Checksum --> OK

Image2 Header Checksum --> OK

Image1 Data Checksum --> ........................OK

Image2 Data Checksum --> .....................................OK


Image1: OK Image2: OK


=================================================

..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...

done

   

3: System Boot system code via Flash.

## Booting image at bfd40000 ...

   Image Name:   OpenWrt Linux-3.10.14

   Image Type:   MIPS Linux Kernel Image (lzma compressed)

   Data Size:    1569650 Bytes =  1.5 MB

   Load Address: 82001000

   Entry Point:  82001000

........................   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

No initrd

## Transferring control to Linux (at address 82001000) ...

## Giving linux memsize in MB, 256


Starting kernel ...



LINUX started...

 THIS IS ASIC

SDK 5.0.S.0
[    0.000000] Linux version 3.10.14 (openwrt@07b241907b34) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 unknown) ) #2 SMP Thu Jun 3 12:28:56 UTC 2021
[    0.000000] 

Please tell me if you need more information.

Strange...you can see that the flash went fine because the two images have a different size:

Image1 Data Checksum --> ........................OK
Image2 Data Checksum --> .....................................OK

With the stock firmware, both have an equal number of dots. After some time, does it revert back to stock also on Image2 if it's connected to the Internet? This is what usually happens with my device.

I do have a second, brand new Premium Gateway lying around. And I've figured out how to force the boot loader to boot a specific image months ago, but I haven't had the time to finalize this bit and/or write down how it works.

Maybe I can come up with something over the weekend or next week. Stay tuned!

Reconfigure uboot?

I would agree, last time I tried it, it didn't work. Right now, I only have a device with broken image 2, but if you want to try it, this is the default env:

U-Boot 1.1.3 (May  2 2017 - 17:01:08)
SERCOMM # printenv
bootcmd=tftp
bootdelay=1
baudrate=57600
ethaddr="00:C0:02:12:35:88"
ipaddr=192.168.1.254
serverip=192.168.1.100
ipaddr_auto=192.168.2.10
serverip_auto=192.168.2.1
bootfile_auto="NA502S_auto_tftp.bin"
patnum=1
stdin=serial
stdout=serial
stderr=serial

Setting patnum to 2 might work, @JonasGhost if you would like to try it?

is probably wrong, in my world, it'd never attempt to boot the stuff stored in flash.

Reset switch ...
#Reset_MT7530

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.
STANDALONE_LOAD_ADDR is 0xa1200000
..
******************************************
    Uboot StandAlone Entry
******************************************


You choosed 4
                                                                                                                                                                         0


4: System Enter Boot Command Line Interface.

U-Boot 1.1.3 (Feb  3 2017 - 19:16:36)
SERCOMM # printenv
bootcmd=tftp
baudrate=57600
ethaddr="00:C0:02:12:35:88"
ipaddr_auto=192.168.2.10
serverip_auto=192.168.2.1
bootfile_auto="NA502S_auto_tftp.bin"
bootdelay=3
ipaddr=192.168.1.254
serverip=192.168.1.100
bootfile=kernel.bin
patnum=2
stdin=serial
stdout=serial
stderr=serial

Environment size: 280/4092 bytes
SERCOMM #

reboot

******************************************
    Uboot StandAlone Entry
******************************************
                                                                                                                                                                         0

******************************************
    Uboot StandAlone Entry
******************************************
Flash Sector Number : 522.

***************************************************
    Sercomm Boot Version 2.00.5

***************************************************
Entering Firmware : Everything is OK.

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image2 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image2 Header Checksum --> OK
Image1 Data Checksum --> ........................OK
Image2 Data Checksum --> .....................................OK

Image1: OK Image2: OK

=================================================
..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...
done


After the next boot:

******************************************
    Uboot StandAlone Entry
******************************************


You choosed 4
                                                                                                                                                                         0


4: System Enter Boot Command Line Interface.

U-Boot 1.1.3 (Feb  3 2017 - 19:16:36)
SERCOMM # printenv
bootcmd=tftp
baudrate=57600
ethaddr="00:C0:02:12:35:88"
ipaddr_auto=192.168.2.10
serverip_auto=192.168.2.1
bootfile_auto="NA502S_auto_tftp.bin"
bootdelay=3
ipaddr=192.168.1.254
serverip=192.168.1.100
bootfile=kernel.bin
patnum=1
stdin=serial
stdout=serial
stderr=serial

Environment size: 280/4092 bytes
SERCOMM #

So it looks like that the patnum 2 is changed back to patnum 1.

How should the boot command look like?

These are the options shown in the help menu

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.
STANDALONE_LOAD_ADDR is 0xa1200000
..
******************************************
    Uboot StandAlone Entry
******************************************


You choosed 4
                                                                              0


4: System Enter Boot Command Line Interface.

U-Boot 1.1.3 (Feb  3 2017 - 19:16:36)
SERCOMM # help
?       - alias for 'help'
bootm   - boot application image from memory
go      - start application at address 'addr'
help    - print online help
mm      - memory modify (auto-incrementing)
nand    - nand command
nm      - memory modify (constant address)
printenv- print environment variables
reset   - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
sc_btver    -SC: SC Show Bootloader Version(SC), and dump compile timestamp
sc_dl       -SC: upgrade option
sc_exp      -SC: Command for control expander
sc_fl_map   -SC: SC Defined Flash Map Dump
sc_gpio     -SC: sc debug command for gpio operations
sc_led      -SC: sc debug command for led & buttons
sc_lp       -SC: SC loopback sample command
sc_nand     -SC: sc nand flash
sc_ramtest  -SC: sc debug command for memory test
sc_tx  - send data out
setenv  - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor version
SERCOMM #

Yeah I know, my impression is that SERCOMM hardcoded the U-Boot defaults and that patnum is just a read-only flag to check which image is currently active.

I found and checked my old files from the time I tried to investigate that. Back then, I compared full partition dumps after the current image changed: mtd1 (containing the U-Boot env) changes at offset 0x0002 0000 from
0x01 00 00 00 00 00 00 00
to
0x05 00 00 00 06 00 00 00

However, according to my notes, the device still booted from image 2 when I manually changed the bytes at 0x0002 0000 as well as the patnum partition. I think that I quickly lost interest in it since it was never necessary to change the currently booted image on one of my devices.

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.

#Reset_MT7530

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.
STANDALONE_LOAD_ADDR is 0xa1200000
..
******************************************
    Uboot StandAlone Entry
******************************************


You choosed 5
                                                                                                                                                                                                                 0


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...
done
## Booting image at 80100000 ...
Bad Magic Number,24800008
....Done!

===================================================================
                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
                                                                                                                                                                                                                 0


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

 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


 ETH_STATE_ACTIVE!!
TFTP from server 192.168.1.100; our IP address is 192.168.1.254
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.

3 Likes