D-Link DSP-W215 smart plug OpenWrt support

D-Link has announced End of Service on December 30, 2022, for a variety of devices (DCS-935LH, DCS-8200LH, DCS-5025L, DSP-W110, DSP-W215, DCH-S150, DCH-S160, DCH-G020, DCH-G020X, DCH-Z110, DCH-S220, DCH-Z120, DCH-Z310, DCS-935L and DCS-5010L).

If these devices would have OpenWrt support they could remain in service. Assuming that there are plenty of these devices available, this is an environmental and economical opportunity.

The DSP-W215 WiFi Smart Plug is one of these devices.
Some chip details:

  • qca9531-bl3a: Qualcomm QCA9531 Chipset | 2x2 802.11n Wi-Fi SoC

  • Winbond W9751G6KB-25: DRAM Chip DDR2 SDRAM 512M-Bit 32Mx16 1.8V 84-Pin WBGA

I am happy to provide more details. You can find photos of the device internals in this OneDrive folder.

Firmware should be available here: ftp.dlink.de/dsp/dsp-w215/archive/driver_software/

It would be good to have initial feedback if there are any blockers for OpenWrt support.
Many thanks!

it's a 8/64 device, not the best start of the openwrt journey, but who knows.

see if you can figure out where the serial console is (assuming there's one),
I see no obvious location, unless it's the J2 on the PCB with the capacitors,
but that wouldn't make any sense.

QCA MIPS is widely supported so unless the radios are quirky ones it should not be too difficult. But either you will need to port it, or some kind soul with the chops needed for it that you can convince.

As pointed out above the lifespan will be limited either way. Bootloader needs to be able to handle a big enough kernel, 8 MiB is the absolute minimum for a standard image from a supported OpenWrt release (21.02 and up).

An opportunity for whom, exactly? Are you a marketeer by day? :wink:

1 Like

On the local ebay website I saw many W215 devices being sold, I have not checked the 14 other devices that are listed. These will likely end up in thrash bins starting next year as no cloud service will support them from then on. OpenWrt support could prevent a share of these devices ending up in the thrash.
Next to this, current owners could potentially keep using their devices if OpenWrt would be supported. There would be no need to replace the devices.
Even if OpenWrt would be supported, buying these devices next year would likely not be costly.
Environmental and economical opportunities :wink:

J2 seems to be connected to the PL8331 chip (Single-Phase, Multifunction Energy Metering IC). Perhaps J2 or J1 could be used, it seems straightforward to connect something to these pins even if the PCB's are connected.

If the effort is low enough, the limited lifespan would not be a problem. I have no idea about the effort though.

I have no problem to ship my single W215 to anyone in Germany who is serious about creating OpenWrt support for this device.

Seems like it'd be pretty easy to add support for this, given how everything is easily accessible. The biggest problem would be adding support for the PL8331, since there's no saying what they've flashed it with and thus how the MPU and the PL8331 communicate.

Time to dig out the ol' multimeter and trace the pins, eh.

The PL8331 communicates using SPI (datasheet here, main vendor page here). Someone would need to write a driver for it, of course.

The W215 has a mx25l6406e 64MB flash IC in case this was not clear yet.

I did just that! Results:

  • J1: 3.0v, 0.02v, 3.0v, 3.0v, 3.0v, 2.6v, 0.06v, GND, 12.3v, 12.3v, GND, GND
  • J2: 3.0v (DC), 3.0v (DC), 1.9v (AC), 1.9v (AC), 1.9v (AC), GND
  • J3: 2.6v, 2.2v, 2.6v, 2.6v, 0.06v, GND, 12.3v, 12.3v, GND, GND

If it helps, J1 and J3 share pins on one side in this order: 2.6v, 0.06v, GND, 12.3v, 12.3v, GND, GND.
The resistance of the 12.3v pins is too low to be RX and/or TX.

My guess is that the three 3.0v pins on J1 could be the part of the serial console.
Their resistances are respectively: 9.7k, 54.4k, 7.6k, when I reverse the leads: 10.2k, 5.9M, 10.2k. Not sure why I see different resistance values depending in which order I connect the leads.

The MX25L6406EM2I-12G flash IC has a Serial Data Input and Serial Data Output pin.

There is a GND and VCC too. The Output pin has 3.3v, the Input pin has 0.006v.
The resistance is not in range.

Could this IC be the serial console?

No, that's MISO and MOSI, ie. used by the SPI-bus.

EDIT: to add some information on the terminology, "serial-bus" does not actually refer to UART; people tend to call it a serial-bus or serial-port, but in actual electronics terminology, I2C, SPI, UART and many others are serial-buses. It's rather a misnomer to call UART-port a serial-port.

Would the D-Link Recovery GUI work? The W215 should have one.

OpenWrt article about D-link Recovery GUI.

After a check it appears that the recovery GUI is available!
The firmware from the FTP server contains a BIN file so I assume that it is not encrypted.

It would be good to know if any developers are interested in creating support for the W215.

Unless you're willing to provide a device, you'll probably be the one adding the support.

You'll will need a working serial console, sooner or later.

I can provide my device, I will ship it to anyone in Europe (preferably Germany) who is serious about providing support for the device.

I will continue searching for a serial console / UART next week, it is hard to find. Could it be that the device has none?

Yes, it is of course possible. It looks like there's pins for JTAG on the PCB, so it could be that it was entirely programmed and tested over that. Still, there is almost always UART somewhere; just have to trace them. A signal analyzer could also be useful and even a cheap clone from China would work for UART-speeds.

Would a signal analyzer be the same as a logic analyzer?
I am looking forward to use such a device! :smiley:

Ah, yes, I actually meant logic analyzer. I...dunced out there! :weary:

Also, no, do not get the one you linked to! You want the 16-channel clone, not the 8-channel one. The 8-channel one is limited to just 24MHz bandwidth and it's just garbage overall, whereas the 16-channel model has 100MHz bandwidth and, at least the one I got, has worked like an absolute peach.

Finding the 16-channel one at a reasonable price can be a tad difficult, though; ever since COVID-19 hit, they've almost all vanished -- presumably because the chip they use is unobtainium at the moment -- and only the crapola 8-channel ones remain, but I very much would recommend spending some time to (try to) find one.

Alright, before I spend ~80 euro on a logic analyzer I first want to properly measure the sides of the PCB's that are hard to reach when they are attached. I am looking for m/f jumper cables that could extend the connectors so I can lay the boards flat on the table. It somehow is hard to find these cables for 0.4mm pins, most cables are too thick like e.g. cables for the Raspberry Pi GPIO pins which are 0.6mm.

J3 (female connector on one of the PCB's) is about 13mm wide for 10 pins, so the raster size should be 1.3mm (or 1.27mm?). What would be a regular size?
And how would such a cable be called? It does not seem to be a breadboard jumper cable.

Could it be that the board that contains the Winbond and Qualcomm chips was powered separately at the factory when the firmware was uploaded? In that case I could be unlikely that I will find pins with the right votages.

Great to see some interest in the devices, I started looking at DSP-W215 a while ago, but since then it's been in the backlog...

UART TX seems to pin on Pin3 of J3, RX on Pin2 (measured directly between SoC contacts for GPIO10 (TX) and GPIO9 (RX)). It seems they're using the UART here to communicate with the Power Metering chip, so hopefully the bootloader was not compiled to disable any output. I don't have much time / nerves for this at the moment, but you could start to see if you receive anything at 115200 baud on Pin3 on the connector (power the whole thing with 3.3V directly, especially in a country like Germany where AC outlets are not polarity-protected).

As far as I recall, some of these devices didn't even have web interfaces for firmware uploading, but just HNAP, so we would need to build a tool for firmware uploading... But DSP-W215 may be one of the older devices still having a Web Interface.

It would be awesome to have many of these devices supported in OpenWrt, I had started with DCH-G020 initially, which has been running here with OpenWrt and Domoticz for a while :slight_smile:
Also the devices with "Z" in the model name are regular, re-branded Z-Wave devices, so they would just work with any other Z-Wave Gateway (I'm still running the smoke detector here, for example, although the label says the sensor has already expired its lifespan :innocent: )

The firmware format seems to be similar to DAP-1330 and DCH-G020 (i.e. using the mkdapimg2 util), hopefully this could work for this one as well.

However, devices without ethernet can not be officially supported in OpenWrt at the moment; this has been a discussion over many years....

2 Likes

as expected, the UART only uses 115200 until the kernel starts loading, after that it seems to query the power metering chip at a lower baudrate.


U-Boot 1.1.4--LSDK-10.2-00082-4 (Sep 25 2014 - 18:27:43)

ap143 - Honey Bee 2.0

DRAM:  64 MB
Top of RAM usable for U-Boot at: 84000000
Reserving 137k for U-Boot at: 83fdc000
Reserving 192k for malloc() at: 83fac000
Reserving 44 Bytes for Board Info at: 83fabfd4
Reserving 36 Bytes for Global Data at: 83fabfb0
Reserving 128k for boot params() at: 83f8bfb0
Stack Pointer at: 83f8bf98
Now running in RAM - U-Boot at: 83fdc000
============================================
Date:Sep 25 2014  Time:18:27:43
Loader Version: v1.01 Build:1
Module Name: DSP-W215
============================================
Flash Manuf Id 0xc2, DeviceId0 0x20, DeviceId1 0x17
flash size 8MB, sector count = 128
Flash:  8 MB
* Scan for Linux kernel images ...
* Backup mode Linux kernel found at 9F050000
* Linux kernel found at 9F2B0000
* Scan completed.
!!! 1 Backup mode and 1 other Linux kernel images found.

Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ath_gmac_enet_initialize...
ath_gmac_enet_initialize: reset mask:c02200
Scorpion ---->S27 PHY*
S27 reg init
: cfg1 0x800c0000 cfg2 0x7114
eth0: 0d:00:00:00:00:00
athrs27_phy_setup ATHR_PHY_CONTROL 4 :1000
athrs27_phy_setup ATHR_PHY_SPEC_STAUS 4 :10
eth0 up
Honey Bee ---->  MAC 1 S27 PHY *
S27 reg init
ATHRS27: resetting s27
ATHRS27: s27 reset done
: cfg1 0x800c0000 cfg2 0x7214
eth1: 54:b8:0a:7c:28:88
athrs27_phy_setup ATHR_PHY_CONTROL 0 :1000
athrs27_phy_setup ATHR_PHY_SPEC_STAUS 0 :10
athrs27_phy_setup ATHR_PHY_CONTROL 1 :1000
athrs27_phy_setup ATHR_PHY_SPEC_STAUS 1 :10
athrs27_phy_setup ATHR_PHY_CONTROL 2 :1000
athrs27_phy_setup ATHR_PHY_SPEC_STAUS 2 :10
athrs27_phy_setup ATHR_PHY_CONTROL 3 :1000
athrs27_phy_setup ATHR_PHY_SPEC_STAUS 3 :10
eth1 up
eth0, eth1
Setting 0x181162c0 to 0x3061a100
Hit any key to stop autoboot:  0
## Booting image at 9f2b0000 ...
   Image Name:   Linux Kernel Image
   Created:      2016-02-03   9:17:37 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    894701 Bytes = 873.7 kB
   Load Address: 80002000
   Entry Point:  801ff6e0
   Verifying Checksum at 0x9f2b0040 ...OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 801ff6e0) ...
## Giving linux memsize in bytes, 67108864

Starting kernel ...

Booting QCA953x
▒▒▒▒▒▒▒▒▒

// edit: Unfortunately I could see no way yet to cancel this, pressing any key or holding any button during reset is not helping... ok, there is a recovery mode when pressing just reset (but not multiple buttons; since I did not know which one is reset on the removed PCB :joy: )

Recovery Linux has not full output either:

eth0, eth1
Setting 0x181162c0 to 0x3061a100
Entering Recovery Mode...
Hit any key to stop autoboot:  0
## Booting image at 9f050000 ...
   Image Name:   Linux Backup Mode Kernel Image
   Created:      2014-08-02  11:22:11 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    870808 Bytes = 850.4 kB
   Load Address: 80002000
   Entry Point:  801efa10
   Verifying Checksum at 0x9f050040 ...OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 801efa10) ...
## Giving linux memsize in bytes, 67108864

Starting kernel ...

Booting QCA953x

Also the partition layout means: OKLI needs to be used, and we probably have to sacrifice the recovery partition to fit a current OpenWrt in the first place...

Finally, some progress :slightly_smiling_face:

The most annoying part was... that there is a minimum length for the Wifi PSK, and Wifi would just not come up at all since the 6-digit Pin Code from the label was too short :joy:

So the PSK is now: SSID + Pin Code
e.g. DSP-XXXXnnnnnn, with X being the last two bytes of MAC address

openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-factory.bin
openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-sysupgrade.bin

The mydlink partition will be overwritten (for 512k more space available, and it's quite full already).
Since I've never used the cloud service myself, I don't know if this breaks the connection to the dlink cloud after flashing back to OEM firmware (but in 6 months the cloud will be gone anyway.... :innocent: )

Turning Power On:
   echo "1" > /sys/class/gpio/gpio:ac_output_enable/value

Turning Power Off:
   echo "0" > /sys/class/gpio/gpio:ac_output_enable/value

// edit: this commit is outdated, please scroll down a few posts!
https://github.com/s-2/openwrt/commit/c0dbc2c2f69b1712b9393dd5f40074bdbe7ac498

This is based on the branch of PR #4777 from @dangowrt.

It seems the outcome of that PR will decide whether devices without Ethernet can be supported officially :slightly_smiling_face:

By the way, has anyone ever seen an A1 revision of this device? According to wikidevi there was an A1 using the older AR93xx SoC, but here in Germany I could only find the B1 devices containing QCA9531, so this is currently for Revision B1 only.

todo:

  • figure out 19200 UART protocol for power metering
  • find temperature sensor connection (maybe i2c?)
2 Likes