The GPL-Source at https://static.tp-link.com/resources/gpl/gpl_oc200.tar.bz2 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
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!
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 192.168.0.101
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
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 So, If someone donate me OC200, I will gladly make it full support in OpenWrt.
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
I would still see many low power applications in IoT, for example. It may also be cheaper than to buy some Raspberry plus power plus CD-Card plus housing.. GB Ethernet costs power..
Well I've looked up the price, it's a bit expensive but.. time will tell.
So, If someone donate me OC200, I will gladly make it full support in OpenWrt.