ramips: mt7621: add support for Wodesys WD-R1802U

[raenye]

This commit adds support for a dual-band AX1800 wall plug manufactured by Shenzhen Century Xinyang Tech Co., Ltd.

• CPU: Mediatek MT7621A (2 cores, 4 threads)
• RAM: 256 MiB DDR3 (Samsung K4B2G1646F-BCNB)
• ROM: 16 MiB SPI NOR (Winbond W25Q128JVPQ)
• Wired: one gigabit RJ45 port (with green/yellow non-GPIO LEDs)
• WiFi: Mediatek MT7905DAN + MT7975DN (DBDC 2x 2T2R)
• Ant.: four 2 dBi external antennas (two 2.4GHz, two 5 GHz)
• GPIO:
  • tri-color status LED (GPIO 13, 14, 16);
  • reset button (GPIO 18)
• Power:
  • 12V 2-pin JST-XH on main PCB
  • 110/220V AC to 12V1A DC on auxiliary PCB
• UART:
  • 115200 8n1, SMD pads available on the PCB as J4
  • pinout is [3v3] (Rx) (Tx) (Gnd)
• MAC: 1C:BF:CE:xx:xx:xx (2.4 GHz, label) 1C:BF:CE:xx:xx:xx + 1 (ethernet [^1]) 1C:BF:CE:xx:xx:xx + 2 (5 GHz)

Original firmware is LEDE Reboot 17.01-SNAPSHOT (kernel 4.4.198) with a few custom packages and a non-LuCI web interface. Telnet and SSH are enabled, requiring an unknown root password [^2]. Root password is also needed to access the router via UART console, but passwordless telnet can be enabled via a trivial web exploit [^3] and then the root password can be removed by editing /etc/shadow.

Installation: uploading sysupgrade binary via web interface at http://192.168.188.1/settings.shtml doesn't work since original firmware uses swconfig and recent versions of OpenWrt use DSA; nevertheless, the sysupgrade file is uploaded correctly and stored at /tmp/upgrade.bin, so a forced sysupgrade can be attempted via the web exploit [^4]. TODO: verify it actually works. Alternatively, use u-boot menu to load image via TFTP.

Notes:

• Device model in LEDE is "MediaTek MT7621 RFB (802.11ax,SNOR)".
• It is sold under several names, among them are Wodesys WD-R1802U, Fenvi F-AX1802U, and EDUP EP-2971; the Wodesys brand was selected since it is referenced in /etc/banner and /etc/hosts, and the PCB is marked "WD518A V1.0".
• Instead of a standard ethernet transformer, the PCB has a few tiny SMD coils.

[^1] Original firmware sets ethernet MAC to 1C:BF:CE:E7:62:1D based on offset 0x3fff4 in the Factory partition; since this is the same MAC for all units, whereas WiFi MACs stored at offsets 0x6 and 0xc are unique, it was decided to use <label MAC + 1> for ethernet. [^2] root:$1$7rmMiPJj$91iv9LWhfkZE/t7aCBdo.0:18388:0:99999:7::: [^3] curl -X POST http://192.168.188.1/cgi-bin/adm.cgi -d page=Lang -d langType="en;killall telnetd;telnetd -l /bin/sh" [^4] curl -X POST http://192.168.188.1/cgi-bin/adm.cgi -d page=Lang -d langType="en;sysupgrade -n -F /tmp/upgrade.bin"

[raenye]

sysupgrade -F doesn't work, I need to connect UART to figure out why; besides that everything works. Should I get it out of draft status, or wait until I fix the installation instructions? (which most likely won't require code changes)

EDIT: mtd write works fine for installation; I updated the instructions.

[hauke]

Is sysupgrade from the vendor firmware to OpenWrt not working? Please post the error message if you get one.

If the user should sysupgrade from the vendor firmware please add SUPPORTED_DEVICES to the image definition to allow upgrade from the vendor firmware without -F. Make sure the DEVICE_COMPAT_VERSION is different from the vendor firmware to force a configuration reset.

I am not sure if this will really work, maybe the vendor hacked around in the scripts or lede 17.01 is too old.

[raenye]

Thanks @hauke.

Is sysupgrade from the vendor firmware to OpenWrt not working? Please post the error message if you get one.

At first it didn't work because the model name was different. I added the relevant model to SUPPORTED_DEVICES and then it didn't work because of swconfig vs DSA. Forced upgrade did not work in either case. I still have one unit on vendor firmware; I'll try sysupgrade and post the error messages here (not planning to open it up and solder UART headers, so I'll copy the error messages from /tmp/sysupgrade.meta).

If the user should sysupgrade from the vendor firmware please add SUPPORTED_DEVICES to the image definition to allow upgrade from the vendor firmware without -F. Make sure the DEVICE_COMPAT_VERSION is different from the vendor firmware to force a configuration reset.

Thanks for the suggestions, but I couldn't make it work (this is why I initially submitted the PR in draft mode).

I am not sure if this will really work, maybe the vendor hacked around in the scripts or lede 17.01 is too old.

Is mtd -r write problematic (for installation only, later upgrades via sysupgrade work fine)?

[hauke]

I am not sure if this will really work, maybe the vendor hacked around in the scripts or lede 17.01 is too old.

Is mtd -r write problematic (for installation only, later upgrades via sysupgrade work fine)?

Using mtd -r write for initial flashing should be fine.

[raenye]

Regular sysupgrade says this:

Device mt7621-rfb-ax-nor not supported by this image
Supported devices: wodesys,wd-r1802u mt7621-rfb-ax-nor - Image version mismatch: image 1.1, device 1.0.
Please wipe config during upgrade (force required) or reinstall.
Reason: Config cannot be migrated from swconfig to DSA
Image check 'fwtool_check_image' failed.

But sysupgrade -F worked fine. Maybe I missed it since I tried -f in lowercase?

[hauke]

Regular sysupgrade says this:

Device mt7621-rfb-ax-nor not supported by this image
Supported devices: wodesys,wd-r1802u mt7621-rfb-ax-nor - Image version mismatch: image 1.1, device 1.0.
Please wipe config during upgrade (force required) or reinstall.
Reason: Config cannot be migrated from swconfig to DSA
Image check 'fwtool_check_image' failed.

But sysupgrade -F worked fine. Maybe I missed it since I tried -f in lowercase?

I think even sysupgrade -n should be sufficient to install it now, after you added: SUPPORTED_DEVICES += mt7621-rfb-ax-nor.

[raenye]

The point is that the vendor firmware upgrade web page issues sysupgrade (with no flags), so it fails anyway; thus the user needs to manually run sysupgrade -Fn without the SUPPORTED_DEVICES modification, sysupgrade -n with it, or just mtd -r write. Do we really have a preference here?

I cannot test anymore since I installed OpenWrt on my last vendor-firmware-running device, but certainly after sysupgrade -F it required a factory reset since the LEDE settings did not play well with OpenWrt. In this sense mtd write is better, as it cannot keep the old config.

Bottom line:

• Should I add SUPPORTED_DEVICES += mt7621-rfb-ax-nor even if I cannot test it? does it matter that another device (yuncore_g720) has this line too?
• Should I amend the initial installation instructions to use sysupgrade -n or sysupgrade -Fn even if I cannot test it? (I did test mtd -r write)

Thanks @hauke.

[hauke]

I would prefer if you add SUPPORTED_DEVICES += mt7621-rfb-ax-nor even when you can not test it any more.

It should not be a problem when an other device uses the same too. This is probably the name of the Mediatek reference board both designs are based on.

I have no real preference if you suggest mtd -r write or sysupgrade -n for initial flashing to the users.

[raenye]

I would prefer if you add SUPPORTED_DEVICES += mt7621-rfb-ax-nor even when you can not test it any more.

Done, thanks.

BTW, I also have an AC1200 Wodesys device (mt7628+mt7612e based, 64/8 RAM/ROM). Should I bother submitting a PR for it? or 64/8 is too little?

[hauke]

I would prefer if you add SUPPORTED_DEVICES += mt7621-rfb-ax-nor even when you can not test it any more.

Done, thanks.

BTW, I also have an AC1200 Wodesys device (mt7628+mt7612e based, 64/8 RAM/ROM). Should I bother submitting a PR for it? or 64/8 is too little?

64/8 RAM/ROM is still fine if there are no other restrictions and the device is cheap or someone already has it.