Support for RTL838x based managed switches

With Zyxel it took between 1 Month and 3. But then it was always top-quality with much more than I had hoped for. I have no experience with TP-Link. But if you know it has an 838x SoC, then you can try to boot any of the images for that SoC. Usually it should allow you to at least get to a command-line prompt. If you have the tech-support command available in the original console, then you will get all the info needed to make a proper image.

https://www.gigadevice.com/wp-content/uploads/2021/04/2021-GigaDevice-Selection-Guide_21.04.21.pdf

With HP/Aruba I lately waited almost half a year!

Got another TP-Link, SG2218. Any idea how to get a serial console on this? The marked area are the traces for TTL-RX/TX with the missing resistors. The solder pads are spaced about 1mm apart, and i have no idea what is going on here. Apparently there are supposed to be a mix of pull-up and pull-down Resistors.
Imgur

My best guess:

  • U13: MAX3224 transceiver (or pin compatible e.g. ZT1385E)
  • R69: pull-up
  • R70: pull-down

If U22 is a 74LVC1G125 line buffer

  • R398: Jumper to buffer input
  • R356: Jumper from buffer input to buffer output
  • R355: Jumper to buffer output via R369 (?)

For serial input on U13[17], I don't see any missing components. For serial output, you could bridge R398, and then solder a wire to U22[2].

For inspiration on what parts might have been intended to go on TP-Link board serial console sections, have a lookt at the T2500G.

I did some testing for those of you who were hoping to use this hardware as a regular gigabit router and unfortunately there is no good news.

Simple routing scenario between lan1 and lan2 and the built in 500MHz MIPS processor maxes out at about 30-40 Mbps. So anyone hoping to use these switches as regular routers, let alone gigabit routers, may be disappointed.

Then, under load there's plenty od debug messages showing up:

[37810.616994] RX buffer overrun: status 1, mask: ffeff
[37810.622565] RX buffer overrun: status 1, mask: ffeff
[37810.738777] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a700015c, cur a7000160
[37810.749419] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a7000178, cur a700017c
[37810.822050] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a700015c, cur a7000160
[37810.832183] RX buffer overrun: status 101, mask: ffeff
[37810.838016] RX buffer overrun: status 1, mask: ffeff
[37810.843584] RX buffer overrun: status 1, mask: ffeff
[37810.919709] RX buffer overrun: status 101, mask: ffeff
[37810.925591] RX buffer overrun: status 1, mask: ffeff

But these are most likely not too relevant to the overall system performance.

Just for the record.

1 Like

yes, these are just debug messages that state that the ring buffer maxes out because the CPU is not able to move the arriving packets fast enough. You can ignore that.

Indeed, the single core MIPS CPU is not very powerful. The iperf values are about 50MBit/s for the 8380, and about 160MBit for the 9300, the 8390 is somewhere in between. There are some optimizations still possible, such as more offloading. I am just now adding CRC offloading, but which only adds 10% in speed. There could be other possibilities such as jumbo-frames and in principle there should not be the need to do an extra copy from the user space, the SoC should be able to do DMA from anywhere, this could be particularly interesting.

There is more hope, though, since in principle all SoCs can at least offload simple L3 routing for example between subnets. The 9300+ can offload even complex routing scenarios. To be useful, there is however also the need for netfilter offload (because otherwise you basically build a mere bridge, since the L3 forward would happen before the packet meets a firewall) which also all SoCs can do. This will take quite a bit more work. I have written the 9300 L3 offloading already. Now I am looking at the 8380 packet inspection engine (to understand how to use it with netfilter), which can also do simple L3 forwarding as an inspection result. This kind of offloading would very considerably speed up things, for simple scenarios probably close to wirespeed, but will take months to arrive.

Finally, the dual InterAptiv core 9310 Routers are expected to have a competitive routing speed even without any offloading. Here new routers for consumers are being currently released to meet the expectations of people who want to switch networks with .ax wifi routers.

2 Likes

I'm currently in correspondence with TP-Link's GPL team regarding the issues/inconsistencies observed between stock and GPL released uboot for the T1600G-28TSv3. (feature set and board model support)

Got a response and ticket number back next day. It seems you have to get through their first layer of support playing dumb though. Then email communication feels a lot more reasonable.

I can happily report that by faking the boardname to the existing 8214FC variant (same 8218B PHY's) brings external PHY LAN ports in functioning state and patch errors are gone. I digged through some uboot code and found some interesting looking power on routines where a few miim read/writes seem to do some magic setup work. I assume the SFP ports to be not working since similar setup commands may be required (not included in the source dump) and additional stuff like I2C communication with the SFP modules.

[    2.319713] Realtek RTL8218B (external) mdio-bus:00: Detected external RTL8218B
[    2.344083] Firmware loaded. Size 1168, magic: 83808380
...
[  406.033677] rtl83xx-switch switch@bb000000 lan8: Link is Up - 100Mbps/Full - flow control rx/tx
[  406.093808] switch: port 27(lan8) entered blocking state
[  406.111555] switch: port 27(lan8) entered forwarding state

Port description seems to be mixed up but hey, that can be fixed.

Great work!
Can you point me to the power on routines? This seems to be something TP-Link specific. In principle our drivers in OpenWRT should be able to configure all PHYs into a working mode whatever u-boot did before.

I was checking for RTK_CHIP_RTL8214FC constant when I noticed:

  • rtl8390_phyPortPowerOn
  • rtl8380_phyCmnPowerON
    in ldk_realtek/realtek-V2.1.6.pre2/u-boot-2011.12/board/Realtek/switch/rtk/mac/rtl8380/rtl8380_drv.c and 8390 version respectively.

From here on out I stumbled accross:

  • rtl8214fb_phyPowerOn
    in ldk_realtek/realtek-V2.1.6.pre2/u-boot-2011.12/board/Realtek/switch/rtk/phy/rtl8214f.c which is also used for the RTL8212B variant.

Also: rtl8390_drv_macPhyPatch1 and rtl8390_drv_macPhyPatch2 seem very interesting.

It really seems to be all very badly glued together between the slightly differing version since they probably are close to identical and they tried to reuse already working code. Since the 8214f.c contains 8218B docblocks also.

I assume the rtl8218b_rtl8380_config in rtl8218b.c already inspired the current driver?

OK, I understand what is going on, the PHY was not powered on. This is normally the case for the PHYs on the board. We need to get this also done in the OpenWRT code.

1 Like

This is totally awesome. So this mystery is actually solved besides the implementation. Nice.

The extensions to the RTL8231 frontpanel as LED driver seems to be tackled by @svanheule.

So the only thing left for me to do is further investigate how the I2C for the SFP modules is done right?

~ Sounds of clacking keys ~

Pin configurations on this platform are often embedded in the kernel modules for the drivers. So if you can't just follow the traces, or figure it out from the stock bootloader/OS runtime, you may have some work ahead of you :confused:

Yay, I can work with that. Will have a look in the stock firmware. If I get lost I'll just follow the traces.

Edit:

lib/modules/2.6.32.58/kernel/drivers/net/switch/rtcore$ file rtcore.ko
rtcore.ko: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), BuildID[sha1]=3bb41a7d3e2bfcb1ef662fce87a24ff00bb47bfb, not stripped

The not-stripped brings a tear to the eye.

drv_smi_module_init, drv_smi_write, drv_gpio_init, i2c_sda_out, i2c_sdc_out, drv_gpio_i2c_probe all sounds great. Seems to be a very general module since it also has all the PoE functionality in it which this switch does not have.

Now I have to brush up my MIPS assembly :worried:

rtcore.ko

Does rtk smi list in the U-Boot show anything?

This is the output of Panasonic Switch-M24eG PN28240K, I'm working for adding support:

RTL838x# # rtk smi list
 
Index SCK_DEV SCK_PIN SDA_DEV SDA_PIN  TYPE     ID   Delay     Name
===========================================================================
   00      00      00      00      01  16_1R    75   04000  PCA9539
   01      00      12      00      13   8_0R    70   04000  PCA9545
   02      00      00      00      01  16_1R    20   04000  PCA9555
   03      00      12      00      13   8_0R    50   04000  GBIC-A0H
   04      00      12      00      13   8_0R    51   04000  GBIC-A2H

(Note: this device has no RTL8231 chip)

RTL8382M
   |
   +--- (GPIO12, 13) --- PCA9545
                            |
                            +--- (i2c0) --- SFP0
                            +--- (i2c1) --- SFP1
1 Like

The command exists but it just prints the table headers.

RTL838x# # rtk smi list

 Index SCK_DEV SCK_PIN SDA_DEV SDA_PIN TYPE   ID   Delay Name 
=================================================================
RTL838x# # 

However this might also be caused due to missing boardmodel support in the GPL uboot build. I previously patched my env variables to fake my board from 8214QF to 8214FC variant to make uboot power up the external identical LAN PHYs.

This also made the rtk ledtest command work. Previously I just got:

RTL838x# # rtk ledtest

 led test: Cant get board model

But the FC variant most likely seems to operate the frontpanel 8231 in a different mode since no LED does light up on the QF board.

Furthermore, I'm currently talking with TP-Link's GPL team regarding the missing boardmodel support. For me it seems the GPL bundle they ship with multiple variants of their switches is very outdated and was never updated when new products were added.

1 Like

I had another idea for the signature on TP-Link firmware. Do you know what hash algorithm they use for the signature? Maybe we could provoke a hash collision and reuse the signature of a valid image if it is something weak like md5 or sha1.

  • Guessing by the RSA1 string in the jffs partition it's RSA.
  • Guessing by the signature size (128 bytes) it's RSA 1024bit.

Although, RSA 1024bit is no longer recommended by NIST, it still stands uncracked if I remember correct.

if it is used as encryption, yes. but the images are only signed with RSA. Which means a hash with an arbitrary hash function (MD5, SHA1, SHA2, ...) is created and then only this hash is encrypted with RSA. So if we can recreate the "cleartext" (=the hash) as input for the RSA-Encryption, we can keep the existing "ciphertext" without doing any actual de-/encryption. No need for breaking RSA itself.

I think I got you. So you assume if it is something like MD5, we could just pad the openwrt image with garbage until it has the same hash like an existing firmware update from TP-Link and then just smack on this signature?

MD5 collision should be doable right? SHA1 I'm not sure.