Sonoff NSPanel Pro Notes

This is my notes on the Sonoff NSPanel Pro.

I bought this device after reading about it on blakadder’s blog and thought an open ADB with root shell sounds like a fun project and might make a cool wall switch.

I of course made the mistake of not reading the V1.3.2 changes, so I booted, and no ADB for me.

Since I had it open, I’ll try a different approach.

Dump firmware:

Follow instructions on how to open the device on blakadder’s site, and connect a micro-USB cable to the OTG.

While holding the button “BOOT”, connect cable to the computer.

Instead of showing up as MTP device, it will now show up as Rockchip USB download gadget [2207:330d].

Now it is ready for rkdeveloptool:

Read out flash info: rkdeveloptool rfi

Flash Info:
        Manufacturer: SAMSUNG, value=00
        Flash Size: 7456 MB
        Flash Size: 15269888 Sectors
        Block Size: 512 KB
        Page Size: 2 KB
        ECC Bits: 0
        Access Time: 40
        Flash CS: Flash<0> 

Now that we know the size, dump the whole flash using rkdeveloptool:

# syntax:
# rkdeveloptool rl <start> <end> <output file>

rkdeveloptool rl 0 15269888 emmc.img

This will take a while. On my machine it took 10 minutes 8 sec at 12.6047 MiB/sec. This is a limitation of USB 2.0.

Show partition info:

rkdeveloptool ppt

Partition Info(GPT) NO LBA Name
00 00004000 uboot 01 00006000 trust 02 00008000 misc 03 0000A000 resource 04 00012000 kernel 05 00022000 boot 06 00032000 recovery 07 00052000 backup 08 0008A000 security 09 0008C000 cache 10 0014C000 system 11 0044C000 metadata 12 00454000 vendor 13 00514000 oem 14 00594000 frp 15 00594400 smatek 16 0059C400 keypart 17 0059C600 STSN 18 0059C800 stback 19 0079C800 userdata

The emmc is partitioned with GPT. My gdisk tool mentioned the backup partition table was corrupt, but the primary was OK. This partition table matches perfectly the output from rkdeveloptool ppt.

gdisk -l emmc.img

Number  Start (sector)    End (sector)  Size       Code  Name
   1           16384           24575   4.0 MiB     FFFF  uboot
   2           24576           32767   4.0 MiB     FFFF  trust
   3           32768           40959   4.0 MiB     FFFF  misc
   4           40960           73727   16.0 MiB    FFFF  resource
   5           73728          139263   32.0 MiB    FFFF  kernel
   6          139264          204799   32.0 MiB    FFFF  boot
   7          204800          335871   64.0 MiB    FFFF  recovery
   8          335872          565247   112.0 MiB   FFFF  backup
   9          565248          573439   4.0 MiB     FFFF  security
  10          573440         1359871   384.0 MiB   FFFF  cache
  11         1359872         4505599   1.5 GiB     FFFF  system
  12         4505600         4538367   16.0 MiB    FFFF  metadata
  13         4538368         5324799   384.0 MiB   FFFF  vendor
  14         5324800         5849087   256.0 MiB   FFFF  oem
  15         5849088         5850111   512.0 KiB   FFFF  frp
  16         5850112         5882879   16.0 MiB    FFFF  smatek
  17         5882880         5883391   256.0 KiB   FFFF  keypart
  18         5883392         5883903   256.0 KiB   FFFF  STSN
  19         5883904         7981055   1024.0 MiB  FFFF  stback
  20         7981056        15269854   3.5 GiB     FFFF  userdata

Output from file -s

1:  data
2:  data
3:  data
4:  data
5:  data
6:  Android bootimg, kernel (0x10008000), ramdisk (0x11000000), second stage (0x10f00000), page size: 2048, cmdline (buildvariant=userdebug)
7:  Android bootimg, kernel (0x10008000), ramdisk (0x11000000), second stage (0x10f00000), page size: 2048, cmdline (buildvariant=userdebug)
8:  data
9:  data
10: Linux rev 1.0 ext4 filesystem data, UUID=62e645e9-1bc9-4f08-a9a6-ed985e12a6cb (needs journal recovery) (extents) (64bit) (large files) (huge files)
11: Linux rev 1.0 ext4 filesystem data, UUID=f50ec315-cfa8-5fcb-bda3-36f000715f1e, volume name "system" (extents) (64bit) (large files) (huge files)
12: Linux rev 1.0 ext4 filesystem data, UUID=5299a141-32fc-4721-9505-25a1eb874003 (needs journal recovery) (extents) (64bit) (large files) (huge files)
13: Linux rev 1.0 ext4 filesystem data, UUID=0f14c177-d71b-554d-943a-f9800abc8a57, volume name "vendor" (extents) (64bit) (large files) (huge files)
14: Linux rev 1.0 ext4 filesystem data, UUID=e9a0a8d3-52a4-5a52-bdbb-a5bda861f1a7, volume name "oem" (needs journal recovery) (extents) (64bit) (large files) (huge files)
15: data
16: data
17: data
18: data
19: Linux rev 1.0 ext4 filesystem data, UUID=da594c53-9beb-f85c-85c5-cedf76546f7a, volume name "system" (extents) (large files)
20: Linux rev 1.0 ext4 filesystem data, UUID=5df6b771-ed65-4537-ba00-26b836bf2fb9 (needs journal recovery) (extents) (64bit) (large files) (huge files)

This seems to be a good beginning for making a custom ROM, or a postmarketOS port. I want to make a postmarketOS port.

Some intensive googling reveals the kernel sources at https://github.com/itead/NSPro_Kernel, which disappointingly contains exactly 1 commit, and is kernel version 4.4.138.

There isn’t any obvious kernel config.

Comparing this kernel tree against the rockchip at 4.4 shows a lot of changes, a lot of which are probaby not related to our device.

Let’s dig for a device tree. I look at the bootimg at partition 6. This is an android bootimg and extract-dtb pulls out a dtb file for dtc to reconstitute.

This reveals the DTS in use to be px30-evb-ddr3-v10.dts

There is a 1G and a 2G RAM version, so they probably have a different device tree.

Booting the device and poking around with ADB

The zigbee gateway (with mosquitto server) is contained in /vendor/bin/siliconlabs_host, and everything seems to be started by run.sh script in that directory.

lsof reveals that the zgateway binary opens /dev/ttyS5 for direct communication with the zigbee gateway. I want to replace this with zigbee2mqtt.

pkg install python pip install -r requirements.txt

$ python3 Elelabs_EzspFwUtility.py probe -p /dev/ttyS5
2023/01/08 12:45:16 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2023/01/08 12:45:16 Elelabs_EzspFwUtility:   Firmware: 6.10.1-216
2023/01/08 12:45:16 Elelabs_EzspFwUtility:   EZSP v8

$ python3 Elelabs_EzspFwUtility.py flash -f ../efr32mg13p-v8-6910-115200.gbl -p /dev/ttyS5
2023/01/08 12:46:13 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2023/01/08 12:46:13 Elelabs_EzspFwUtility:   Firmware: 6.10.1-216
2023/01/08 12:46:13 Elelabs_EzspFwUtility:   EZSP v8
2023/01/08 12:46:13 Elelabs_EzspFwUtility:   Launch in bootloader mode
2023/01/08 12:46:23 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2023/01/08 12:46:23 Elelabs_EzspFwUtility:   Gecko Bootloader v1.12.00
2023/01/08 12:46:24 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
..
2023/01/08 12:47:00 Elelabs_EzspFwUtility:   Firmware upload complete
2023/01/08 12:47:00 Elelabs_EzspFwUtility:   Rebooting NCP...
2023/01/08 12:47:15 Elelabs_EzspFwUtility:   Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode

This is as far as I got this weekend. To be continued another weekend.