Support for RTL838x based managed switches

There used to be a confusing situation with regards to how the flash was being read either in 3 or 4 byte mode and the PLL (frequency) of the flash access on RTL838X SoCs. Strangely settings done during boot of the switch will not be reset properly by a software-triggered reset of the SoC. Because this is very device dependent we needed to collect information and try out different strategies with different devices, because at some point during development were were fixing one device and breaking another. Now this is understood and the code in OpenWRT takes care of this automatically, so you can ignore those columns.


This will be for an RS232 transciever. You'll have to determine the pin layout first (input signals, output signal, where those capacitors connect to...). Then, if you're lucky, you may be able to find the actual part that matches this layout. See for example these 16-pin RS232 transceivers from maxim integrated. The RS232 transceivers that I've seen up to now, are pin compatible clones of maxim parts, but I think the packages were smaller.

1 Like

A quick update: The patch with the support for the RTL9300-based SoCs such as the ZyXEL XGS-1210-12 was merged at the beginning of the this week into OpenWRT/master. The patch also contained some other interesting things to play with:

  • there is now full support also for RTL839x-based SoCs, such as the 48-port ZyXEL GS1900-48
  • Quality of Service and Rate Control went in with a default configuration, if you mark ethernet frames as high priority before sending them to the switch, then they should get precedence automatically on a congested outgoing line. This has not been tested at all, so if anyone wants to test-drive this... There is a debugfs-based interface for playing around with configuration settings for this, too but to start with you don't need that.

There are no specific device .dts for any 9300 or 8390-based switches in owrt/master, but you can find them in the current development master at
There is another interesting piece of new code, which allows to enable Energy Efficient Ethernet in that dev-tree, too. Since this seems to be an interoperability thing, it would be cool if people would test it. The energy savings can be considerable, going down from about 0.6 Watts per port to 0.2 watts, which is not only going to make your equipment less hot, save on your energy bill but also will be nice for the climate (use "ethtool --set-eee lanX eee on" to test).
And there is also progress on the mainlining front. We are hopeful to get the first set of patches into the next Linux kernel release.
Finally, development on the L3 routing offloading has started, don't hold your breath yet, but at least the first step has been done.


Looking through the code I'm not able to find anything regarding PoE configuration/setup. How is the difference between a switch supporting PoE and one that doesn't support PoE defined/configured? I have both a DGS-1210-10 and a DGS-1210-10P, it appears that the DTS contains no information regarding PoE. I also have a DGS-1210-28P and a DGS-1210-28MP which differ greatly in the PoE budget. Where would that difference be configured/set?


The DTS would only contain an extra node for the second UART, which is connected to the PoE management MCU. Unless maybe on that TI-platform, but in any case the DTS doesn't have much info on PoE. This is all managed in userspace, so the place to specify the total power budget would be the uci config.

@RaylynnKnight I have this on my GS1900-10HP:

# cat /etc/config/poe 
config poe poe
	option budget	77
	option port1	1
	option port2	0
	option port3	0
	option port4	0
	option port5	0
	option port6	0
	option port7	0
	option port8	0

No PoE devices connected atm though, so nothing reported at the moment:

# ubus call poe info
	"ports": [
	"power_budget": "77W",
	"power_consumption": "0W"

I'm using the rtl83xx-poe package to manage PoE. It seems to depend on which PoE controller your board has, though (GS1900-10HP has Broadcom ones).

The power budget is preset in /etc/board.d/02_network per device:

case $board in
	ucidef_set_poe 130 "$lan_list"
	ucidef_set_poe 77 "$lan_list"
	ucidef_set_poe 70 "$lan_list"

Maybe we should make the rtl83xx-poe package a standard package of the switches which have PoE capabilities. Similarly how the network configuration for routers is set up on first boot, we could put a switch-dependent setup into /etc/board.d to define power budgets and other fundamental stuff.


I seem to recall @svanheule pointed out the PoE 'dialect' might depend on what PoE controller is used and the rtl83xx-poe package speaks 'Broadcom' since he was able to replicate that. But I might be mistaken. I've only had my eyes on my own ZyXEL switches when it comes to PoE chips on the boards.

That's correct, the current package only works on switches that use the BCM59111 or BCM59121 PSE controllers.

PoE switches with the Microsemi PD69xxx ICs and the TI ICs are currently not supported.

I believe I have enough information now. I am wanting to add the DGS-1210-28P and DGS-1210-28MP support, so it appears that they will share at least a dtsi with DGS-1210-28 and the 02_network configuration will be different depening on power budget. I think including the rtl83xx-poe package as standard for the PoE switches with Broadcom PoE also makes sense. I haven't had a lot of time lately, but am anticipating having some patches soon. Also will be adding the TRENDnet TPE-082WS which is essentially the same hardware as the DGS-1210-10P but with a 75W PoE budget and 256MB RAM. Should I be basing my changes on Openwrt master or on bkobi github?


If you want it merged in master here, on OpenWrt master. Bkobl's tree is still ahead.

The code adding OpenWrt device support would largely be unaffected by the upstreaming effort I think, the latter is a separate codebase more or less.

1 Like

Part of my confusion was that I was looking at the changes related DGS-1210-10P which doesn't currently have an entry in the /etc/board.d/02_network file. It should have an entry setting the PoE budget to 65 (i.e. ucidef_set_poe 65 "$lan_list"). Planning on submitting some patches this weekend!

There appear to be no instructions for installing on DGS-1210-10P in the commit message. I assumed it would be the same as for the DGS-1210-28 given the similarities. The DGS-1210-28 commit has the following statemtent:

To install, upload the sysupgrade image to the OEM webpage or sysupgrade
from the system running from initramfs image.

This seems to imply that the openwrt sysupgrade image can be loaded via the OEM webpage. When attempting this on the DGS-1210-10P I get the following message:

FW upgrade/backup fail, check FW file...

Has using the OEM webpage for installing OpenWrt been confirmed on the DGS-1210 series?


Does the Zyxel GS1900-16 qualify for this also?

As I'm eyeing the ZyXEL GS1900-24E myself, I'm interested about this question as well. The information suggests the RTL8382M SOC, shared with the already supported D-Link DGS-1210-28 rev F1, but I wonder if the 2 * RTL8218B 8-port PHY extenders would pose a complication for potentially supporting this device.

I haven't actually bought a device to play with so far[0], so I'm just curious what the chances are or if there are particular difficulties to be expected based on the known specifications (or if it would be better to look at a different device).

My experiences with the ZyXEL GS1900-8 have been pretty good so far.

[0] but I do have access to one GS1900-24E that's in production use.

1 Like

At least the binary OEM firmware suggests a RTL838x variant as well.

[…]/GS1900-16_Firmware_2.60(AAHJ.3)C0/_GS1900-16_Firmware_2.60(AAHJ.3)C0.bix.extracted$ strings vmlinux_org.bin | grep -i -e 838 -e linux.*mips
Linux version 2.6.19 (gcc version 3.4.4 mipssde-6.03.00-20051020) #2 PREEMPT Tue Jan 5 08:02:18 UTC 2021
1 Like

I haven't opened mine up, but from a video it appears the Zyxel GS1900-16 has 2 identical chips inside each serving 8 ports, so is it more like 2 x 8-port switches connected via an internal port over a 1Gbps link?

Edit: the answer is no, see kobi's reply below:

These PHY chips are connected via QSGMII to the SoC, which serves 10Gbit duplex. So all external ports can talk with each other with 1GBit at the same time.

It is very likely that this device can be easily supported with just the right .dts to set up the 2 RTL8218B properly. That flashing over the web interface does not work should not be a big issue either. Normally there is some magic number wrong which codes for the right model.

1 Like

The ZyXELs can be upgraded from stock web UI in a two-step procedure. You need to create a model specific initramfs build rule with the four letter ZyXEL model code. See the examples:;a=commitdiff;h=1fb413e6579a34a0040b526e681298909dfaa5ac

Note that the current default OpenWrt network configuration is weird and will set up management on a tagged vlan 100 interface. The other end of the management link must therefore be reconfigured when changing from stock to OpenWrt.

So I recommend having console access just in case. The console header is mounted and reachable without opening the case on these ZyXEL, so all you need is the USB TTL UART adapter.

EDIT: I watched the -16 video, and it does look like the odd and unwanted child.... Looks like you have to open that one to access the console header. But at least it's mounted.


Thanks a lot for the info, the easily accessible serial console and the dual-firmware setup (leaving a copy of the OEM firmware in place on the second partition set of these ZyXEL devices) make them really nice to work with.