Adding device support for TP-Link OC200


I would like to add support for the TP-Link OC200 "SDN Controller", which seems to run a custom version of LEDE 17.01 (Kernel 4.4) by default.

Target mvebu, boardname is armada-3720-eck

Marvell Armada 3720 SOC
ESMT M15T4G16256A-DEB DDR3-1866 SD-RAM (512MB)
Samsung klm4g1fete-b041 eMMC Flash (4GB)
Atheros AR8236 Ethernet Switch

The GPL-Source at contains the dts-files and a patch for the (marvell?) DSA-Driver to make it work with the ar8236, which is why the compatible-section for the switch in the dts says 'marvell'. There are also patches for the emmc to force it's voltage to 1.8v and work around a broken hs200 mode.

Currently waiting for pin headers with 2mm pitch so kann get some boot logs from serial console. Hopefully this time i don't kill it like on the sg2216

One of the developers has a tree for it:;a=shortlog;h=refs/heads/oc200

So you won't have to start from scratch :slightly_smiling_face:

1 Like

thanks, almost missed that. guess i will just try to build an image from this tree and see if i can ramboot it. Then it is on to check for missing and/or broken things. Won't happen for a few days though.

As you see from the staging tree, @stintel (and I) has (have) been looking into this device a bit, as well as @blogic.

The SoC itself is 1.8V, so the board has room for a level shifter to bring that up to 3.3V for the UART header. U13 on the backside of the board takes a MAX3373E, and you'll need to bridge a few unpopulated resistors. Otherwise it's the usual TP-Link layout: TX, RX, GND, VCC.

The device uses a combination of NOR and NAND flash. The (1.8V!) NOR flash has the bootloader, while the main firmware is stored in NAND. Firmware images are signed, and I am not aware of any exploits or measures to defeat the signature checking. Once you have serial access, you can load an initramfs via TFTP. As you can tell, getting to the bootloader is no small feat to start with.
stintel's tree has some FW building script(s), IIRC. My scripts to dump firmware images can be found here:

Finally, the (fast ethernet) switch used in the device is supported by OpenWrt, but only via swconfig. The mvebu target normally uses DSA. As you've found, the GPL sources for the OC200 contain patches to add a DSA driver for the switch, but I'm not sure what other work stintel and blogic have put into this by now.

Be careful with the 1.8V devices, and have fun hacking! :smiley:

1 Like

The NOR flash contains a base64 encoded RSA public key. I suspect the bootloader uses this to verify the signature of the image while uploading it in recovery mode (keep pressing the reset button for ~10s during boot to enter it). The web interface shows a pop-up with Checksum Error., at the same time the console shows [ERROR]lib/dkmgt/dkmgt_firmware.c:196 | firmware RSA verify failed

So my idea was to generate a new RSA key pair locally, sign the image with the private key, and overwrite the public key in the NOR flash, hoping that the bootloader will then accept the OpenWrt image. Unfortunately I keep failing to read the NOR flash with my Odroid XU4, and I have no other 1.8v SPI reader around, so I can't confirm this option works or not.

The other option explained by @svanheule is no easy task if you're not great at soldering.

For those who manage that, here's the procedure to boot via TFTP and flash OpenWrt to NAND.

  • abort boot with ctrl-b
  • configure a TFTP server on
  • run tftpboot
  • note the filename it's trying to download
  • binwalk bin/targets/mvebu/cortexa53/openwrt-mvebu-cortexa53-tplink_oc200-initramfs-kernel.bin and note the offset of the DT at the end of the image
  • copy bin/targets/mvebu/cortexa53/openwrt-mvebu-cortexa53-tplink_oc200-initramfs-kernel.bin to your TFTP directory and give it the filename noted in the previous step
  • run tftpboot again
  • run bootefi 0x5000000 0x68DA200 - to get the 2nd argument, add the offset of the DT you noted earlier to the first argument, e.g. 0x5000000 + 0x18DA200 = 0x68DA200
  • wait for OpenWrt to finish booting, then scp bin/targets/mvebu/cortexa53/openwrt-mvebu-cortexa53-tplink_oc200-squashfs-sysupgrade.bin to /tmp
  • sysupgrade openwrt-mvebu-cortexa53-tplink_oc200-squashfs-sysupgrade.bin

I've just verified the above procedure with an image built from my oc200 branch which was just rebased on master + my gcc10 branch, and it's still working.


This device has now become even more relevant, since Gl-Inet has stopped selling its Brume, which is very similar to the OС200.

I have experience hacking the bootloader for Armada 7. I think it also will be possible to fix bootloader here. But I don’t have an OC200 device :frowning: So, If someone donate me OC200, I will gladly make it full support in OpenWrt.

1 Like

Has anyone checked, if the small USB port(type C) of the OС200 is connected to the USB data bus, or it is for power only? I would like to use it as an network OTG device.

I looked into the DTS file, and there eth0 is at 100mbit/sec. Well, yes, AP8236 is a 100mbit/sec switch. That is, the device loses all attractiveness because of this :frowning: