Support for RTL838x based managed switches

Just to let you know that we are making progress on the Multi-Gigabit version of the RTL switch chips. We have managed to boot for the first time the Zyxel XS1930-10 which has 8 1/2.5/5/10GBit Ethernet ports and 2 10GBit SFP+ uplink ports. The SoC is an RTL9313 with (according to the specs) a dual InterAptiv MIPS CPU at 1GHz. So far none of the Ethernet / Switch functionality works, and only one CPU boots up, but the chip seems very similar to the RTL839x chips, so there is hope for quick progress.
A boot-log and more information can be found at

5 Likes

Out of curiosity, are there Linux drivers for the AQR813 PHY? I found this repository but it only seems to be for single NIC PHYs:

There is no Linux driver. But modern PHYs are normally not very complicated to set up. One needs to set some configuration values and power them up. Only when it comes to things like EEE it gets more complicated. For some of the PHYs supported so far like the RTL8214C, hardly a line of code is necessary. Looking into the existing binary driver the ARQ PHYs look reasonable.

The Ethernet driver also looks doable as basically the same registers exist as on the RTL838x and 9x. Very little work was necessary to port from 8x to 9x.

More problematic is the L2 functionality, here there is no documentation. Fortunately there is a kind of API of the ASIC wherein you can access e.g. the forwarding database entries through a table interface. This interface seems to be identical, at least the registers used are identical. The table contents is probably not, but can be understood with trial and error plus studying the binary driver. Finally, one of us will get access to SoC documentation next year.

1 Like

Thanks a lot, very informative!

Just a few updates from me on the TP-Link T1600G:

Unfortunately, I had to put the device into service so I can't carry on right now. However, I'd like to report a few things that I've found out in the meantime that make the device a less-ideal target:

According to my ghidra dumps, the stock firmware verifies the RSA signature of the firmware update and the boot loader does not allow flashing of a new firmware. An easy installation is only possible if someone finds an exploit in the stock firmware.

I've basically figured out how fan control and LED control work, but some GPIOs don't react to software changes. This might be related to the port LED control, as some GPIOs have a very strange voltage level (somewhat around 1.7V) until the stock firmware has completely booted. The port LEDs are not set up in U-Boot.

I'll try my best to document my findings the Wiki and I hope that someone else can carry on.

Hey guys! Here I am again :stuck_out_tongue:

So I got a GS1900-10HP and booted a ramdisk image (local master build). So far so good. However, I cannot ping it from my client, nor SSH into it. It seems to have an IP like it should and plugging or unplugging cables prints a link down/up message over serial, so that looks all right.

I have some UCI defaults presets but it doesn't look like they'd be interfering at first sight (they work fine on MT7621 DSA, ath79, etc. - all master).

Can someone check and tell me if this looks off? Was built off master d346beb08c3a7867497000dc382635ee8ea0eedb with a few extra patches (but nothing invasive; and the same builds work for ath79 & mt7621 here).

Not sure if the VLAN (which seems default?) is doing anything here?

# cat /etc/config/network 

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd5f:d064:8a98::/48'

config device 'switch'
        option name 'switch'
        option type 'bridge'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config bridge-vlan 'wan_vlan'
        option device 'switch'
        option vlan '1'
        option ports ' lan1 lan10 lan2 lan3 lan4 lan5 lan6 lan7 lan8 lan9'

config interface 'wan'
        option ifname 'switch.1'
        option proto 'dhcp'

config device 'wan_switch_1_dev'
        option name 'switch.1'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config bridge-vlan 'lan_vlan'
        option device 'switch'
        option vlan '100'
        option ports 'lan1:t'

config interface 'lan'
        option ifname 'switch.100'
        option proto 'static'
        option ip6assign '60'
        option ipaddr '10.0.0.254/24'

config device 'lan_switch_100_dev'
        option name 'switch.100'
        option macaddr 'xx:xx:xx:xx:xx:xx'

Network is 10.0.0.x.

Hey Borromini,

we have put a lot of effort into refactoring and cleaning up the code in the past weeks in order to push for mainline. Could be that things were broken in that process. Could you try the most conservative repository in https://github.com/bkobl/openwrt/tree/rtl83xx_dev where all the fixes went in and none of the refactoring was done, yet?
Alternatively, it could be just the vlan settings being wrong, but I cannot spot a mistake.

Kobi

1 Like

Should work fine, except for the SFP slots (problem is known and fixed, but not yet merged). I have been booting both the GS1900-10HP and the Netgear GS108Tv3 on that commit, plus some minor local experiments.

As for the config: You are aware that the 10.0.0.254 address only is visible on VLAN 100 on port lan1? You will have DHCP assigned address on VLAN 1, which is the untagged PVID on all ports, if you have a DHCP server connected to one of the ports.

1 Like

@bmork Thanks! I was wondering if that VLAN 100 was default or not.

@anon13997276 Thanks for the tip, I'll give your tree a try as well.

Would any of you mind sharing your /etc/config/network? I'm a bit familiar with DSA thanks to mt7621 but the whole OpenWrt on a switch thing is still quite novel for me :smile:

I can share, but be warned - this is highly specialized for my rather weird network.. This is from my GS1900-10HP, with slighly anonymized mac addresses:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdc9:c30b:d5a2::/48'

config device 'switch'
        option name 'switch'
        option type 'bridge'
        option macaddr 'bc:cf:4f:12:34:56'

config bridge-vlan 
        option device 'switch'
        option vlan '7'
        option ports 'lan2:* lan3:* lan4:* lan5:* lan6:* lan8:t lan9:* lan10:t'

config bridge-vlan 
        option device 'switch'
        option vlan '8'
        option ports 'lan8:t lan10:t'

config bridge-vlan 
        option device 'switch'
        option vlan '9'
        option ports 'lan8:t lan10:t'

config bridge-vlan 
        option device 'switch'
        option vlan '89'
        option ports 'lan7:* lan10:t'

config bridge-vlan 
        option device 'switch'
        option vlan '203'
        option ports 'lan1:* lan8:t lan10:t'

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ifname 'switch.203'
        option ipaddr '192.168.99.51'
        option dns '192.168.99.1'

config device 'lan_switch_203_dev'
        option macaddr 'be:cf:4f:12:34:56'
        option name 'switch.203'

So I have my management interface on VLAN 203. All the other VLANs are simply passed through the switch. The uplink to the rest of my network is lan10 (yes, fibre). lan8 connects to another OpenWrt device, and a number of VLANs are forwarded as tagged between these two ports. lan7 connects to a non-OpenWrt device. Traffic on this port is untagged only. It is also forwarded to lan10, and tagged as VLAN 89 there.

The remaining ports are not in use, except for some testing at the moment. They are all untagged, mostly using VLAN 7 except for lan1 which is sort of an emergency management access. Been experimenting a bit with the SFP slots lately and needed to have a backdoor when losing access over fibre.

This might give a more readable view of the VLAN map:

root@gs1900-10hp:~# bridge vlan                                                                                                                                                                                                                                     
port              vlan-id                                                                                                                                                                                                                                           
lan1              203 PVID Egress Untagged                                                                                                                                                                                                                          
lan2              7 PVID Egress Untagged                                                                                                                                                                                                                            
lan3              7 PVID Egress Untagged                                                                                                                                                                                                                            
lan4              7 PVID Egress Untagged                                                                                                                                                                                                                            
lan5              7 PVID Egress Untagged                                                                                                                                                                                                                            
lan6              7 PVID Egress Untagged                                                                                                                                                                                                                            
lan7              89 PVID Egress Untagged                                                                                                                                                                                                                           
lan8              7                                                                                                                                                                                                                                                 
                  8                                                                                                                                                                                                                                                 
                  9                                                                                                                                                                                                                                                 
                  203                                                                                                                                                                                                                                               
lan9              7 PVID Egress Untagged                                                                                                                                                                                                                            
lan10             7                                                                                                                                                                                                                                                 
                  8
                  9
                  89
                  203
switch            7
                  8
                  9
                  89
                  203

The "switch" (i.e. CPU) device do not really need VLANs 7,8,9 and 89. That's just a side effect of how netifd configures this. I haven't figured out how to prevent a VLAN from being added to the CPU port. But this is of course not a big issue. There is no traffic forwarded that way as long as there are no mac addresses showing up on the VLANs on that port.

Thanks, at least I have a hint of what it might look like. I'll go dig for that VLAN 100.

BTW, I see the buildbot is failing on the realtek target, last build is on the old rtl838x target from November 24th. Buildbot log shows this:

ERROR: "rtl838x_smi_wait_op" [drivers/net/phy/rtl83xx-phy.ko] undefined!
ERROR: "smi_lock" [drivers/net/phy/rtl83xx-phy.ko] undefined!
ERROR: "rtl839x_read_phy" [drivers/net/phy/rtl83xx-phy.ko] undefined!
ERROR: "rtl838x_read_phy" [drivers/net/phy/rtl83xx-phy.ko] undefined!
ERROR: "rtl839x_write_phy" [drivers/net/phy/rtl83xx-phy.ko] undefined!
ERROR: "rtl838x_write_phy" [drivers/net/phy/rtl83xx-phy.ko] undefined!
ERROR: "soc_info" [drivers/net/phy/rtl83xx-phy.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[5]: *** [__modpost] Error 1
Makefile:1319: recipe for target 'modules' failed
make[4]: *** [modules] Error 2
make[4]: Leaving directory '/builder/shared-workdir/build/build_dir/target-mips_4kec_musl/linux-realtek_generic/linux-5.4.81'
Makefile:28: recipe for target '/builder/shared-workdir/build/build_dir/target-mips_4kec_musl/linux-realtek_generic/linux-5.4.81/.image' failed
make[3]: Leaving directory '/builder/shared-workdir/build/target/linux/realtek'
make[3]: *** [/builder/shared-workdir/build/build_dir/target-mips_4kec_musl/linux-realtek_generic/linux-5.4.81/.image] Error 2
Makefile:13: recipe for target 'install' failed
make[2]: Leaving directory '/builder/shared-workdir/build/target/linux'
make[2]: *** [install] Error 2
time: target/linux/install#825.45#45.77#136.31
    ERROR: target/linux failed to build.
target/Makefile:23: recipe for target 'target/linux/install' failed
make[1]: *** [target/linux/install] Error 1
make[1]: Leaving directory '/builder/shared-workdir/build'
Build failed - please re-run with -j1 to see the real error message
/builder/shared-workdir/build/include/toplevel.mk:240: recipe for target 'target/install' failed
make: *** [target/install] Error 1
program finished with exit code 2
elapsedTime=149.799989

@blogic Could you take a look at this? I don't seem to run into this locally, at least.

Yes, I saw that. I believe nobody ever tried building that driver as a module... But the buildbots will because it is hidden behind the CONFIG_REALTEK_PHY kernel symbol, and we have that in KernelPackage/phy-realtek

Should definitely be fixed so that modular builds work. But as @anon13997276 mentioned: There are a number of cleanups going on at the moment, in different branches and in parallell. We may have to wait for that to be sorted out and merged, to avoid creating unnecessary addtional conflicts.

This is not a problem for your local build because you don't build that kmod package. Linking the driver in the kernel works fine. But it's actually not enabled at all in the current default config. Also something to be fixed, I guess.

1 Like

I see.

I played with /etc/config/network in the meantime. This makes the switch respond:

# cat /etc/config/network 

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd5f:d064:8a98::/48'

config device 'switch'
        option name 'switch'
        option type 'bridge'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config bridge-vlan 'lan_vlan'
        option device 'switch'
        option vlan '1'
        option ports ' lan1 lan10 lan2 lan3 lan4 lan5 lan6 lan7 lan8 lan9'

config device 'wan_switch_1_dev'
        option name 'switch.1'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'lan'
        option ifname 'switch.1'
        option proto 'static'
        option ip6assign '60'
        option ipaddr '10.0.0.254/24'

config device 'lan_switch_100_dev'
        option name 'switch.100'
        option macaddr 'xx:xx:xx:xx:xx:xx'

I can probably drop the lan_switch_100_dev device as well, when I remove that and reload the network, 10.0.0.254 still responds.

OK, I'm seeing this in /etc/board.d/02_network, seems this is setting the VLAN:

lan_list=""
for lan in /sys/class/net/lan*; do
	lan_list="$lan_list $(basename $lan)"
done
ucidef_set_bridge_device switch
ucidef_set_interface_wan "$lan_list"
ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100

So that's where the VLAN ID 100 comes from. I assume this is needed for some models, or is this cruft from another target?

forgot to mention: both device connected to the GS1900-10HP are powered by it. You should install the rtl83xx-poe package if you are using PoE. Note that you will have to edit /e/c/poe to enable the ports after you do this.

This package allows monitoring the power usage per port. The "ports" array shows lan1 - lan8 in order:

root@gs1900-10hp:~# ubus -v call poe info
{
        "ports": [
                "enabled",
                "enabled",
                "enabled",
                "enabled",
                "enabled",
                "enabled",
                "3.8W",
                "4.4W"
        ],
        "power_budget": "77W",
        "power_consumption": "7.7W"
}

You can also switch power on/off using ubus. Which is incredibly useful as a remote power control for the connected devices. Say for example that tried to boot the device on lan8 from an initramfs, and it never came online. I can now simply toggle power remotely by doing

ubus -v call poe port '{"enable":false,"port":8}'
ubus -v call poe port '{"enable":true,"port":8}'

I find this incredibly useful. It's also fun to watch the comsumption in realtime. Both devices I've connected are radios, and they use a lot more power when the traffic load is higher.

1 Like

Yeah that's included in my build :smile:

Another question: I assume it's Realtek specific, like the name suggests? So not usable for other OpenWrt supported platforms that come with PoE? Like some EdgeRouter models e.g.? Just out of curiosity.

I set the package here to depend on the Realtek target, locally.

The VLAN 100 thing comes from

I'm not convinced that it is a good idea. I believe most users will end up like you: Wondering where the management interface went.

I believe it is better to replicate stock firmware behaviour by default. Assuming users will flash from stock to OpenWrt without necessarily having console, it might even make sense to pick up both management VLAN and address from the stock config. Then you would just reach luci exactly where you just used the stock web gui.

The stock CLI config is available to OpenWrt by simply mounting the partition it is saved in:

root@gs1900-10hp:~# mount -o ro -t jffs2 /dev/mtdblock3 /mnt
[59617.370439] jffs2: notice: (3572) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
root@gs1900-10hp:~# ls -la /mnt/
drwxr-xr-x    4 root     root             0 Jan  1  1970 .
drwxr-xr-x    1 root     root             0 Dec  8 08:23 ..
-rw-r--r--    1 root     root          1052 Jan  1  2020 backup-config
drwxr-xr-x    2 root     root             0 Jan  1  2019 ssh
-rw-r--r--    1 root     root          1985 Nov 14 21:17 startup-config

I don't think a full parser is worth it, but just fetching the management parts might be. This could be done in a uci-defaults script. If someone does the work..,..

1 Like

The current PoE package only implements the Broadcom PoE control protocol. If this happens to be a Broadcom thing, it might be reusable on other devices, but there is currently no universal PoE interface (yet).

Some Realtek switches use different PoE platforms (Microsemi PD69xxx, TI platform on that one TP-Link switch), so these are currently not supported.

1 Like

A follow-up question regarding this: if fw_printenv does not show the bootpartiton variable, does that mean I cannot manipulate it?

# fw_printenv|grep boot
bootargs=console=ttyS0,115200 mem=64M quiet
bootcmd=cst fcTest; boota
bootdelay=0

I first thought boota implied partition 0 but it's just the macro you mentioned, so there's no way to tell from this what partition is active I presume (this is from the OpenWrt ramdisk).

You can manipulate it. But there isn't any automatic config generation (yet). Manual setup example (with slightly obfuscated numbers again):

root@gs1900-10hp:~# echo "/dev/mtd2 0x0 0x1000 0x10000"  >/etc/fw_sys.config 
root@gs1900-10hp:~# fw_printenv -c /etc/fw_sys.config 
resetdefault=0
mac_start=BC:CF:4F:12:34:56
mac_end=BC:CF:4F:12:34:60
sn=S202L28001234
dualfname1=2.60(AAZI.2)C0.bix
dualfname0=x.bin
bootpartition=0

And similar with fw_setsys -c /etc/fw_sys.config of course

I was looking at how to set up this automatically in an elegant way. Generating the config and some symlinks for fw_printsys and fw_setsys is simple. But that would need to run on every boot, which means an additional init script. Or the symlinks would just have to be there on every device and do nothing unless you have that partition config. I don't know what's best?

EDIT: if you wonder about those dualfnameX variables: They are written when you flash from stock firmware. I do not know what they are used for. Maybe just a UI thing. It's the actual file name you flash, so it's pretty meaningless. The "x.bin" is the result of me creating a shorter filename for an OpenWrt initramfs image :slight_smile:

1 Like

Thanks. I rebooted into u-boot, and used the setsys/savesys commands you mentioned earlier. However, bootpartition=0 shows up when I issue printsys, not when I issue printenv. Similarly, with OpenWrt running from RAM fw_printenv doesn't show the bootpartition value either.

Either way, when I issue boot it's clearly booting OpenWrt from partition 0, so all looks well. However, I am missing an overlayfs. I'm seeing these messages:

logread -e jffs2
Wed Dec  9 12:43:44 2020 kern.info kernel: [    0.166640] jffs2: version 2.2 (NAND) (SUMMARY) (ZLIB) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, In.
Wed Dec  9 12:43:44 2020 kern.notice kernel: [    1.306851] 0x000000160000-0x000000260000 : "jffs2"
Wed Dec  9 12:43:44 2020 user.notice kernel: [   12.393597] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
logread -e mount
Wed Dec  9 12:43:44 2020 user.notice kernel: [   12.393597] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
Wed Dec  9 12:44:16 2020 user.notice ucitrack: Setting up non-init /etc/config/fstab reload handler: /sbin/block mount
Wed Dec  9 12:44:18 2020 daemon.err mount_root: failed - mount -t jffs2 /dev/mtdblock8 /rom/overlay: Not a tty

And this, but given it's 16 MB flash, it seems a bit strange?

Wed Dec 9 12:44:18 2020 kern.err kernel: [ 60.471289] Too few erase blocks (2)

/proc/mtd contents:

cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs"
mtd4: 00100000 00010000 "jffs2"
mtd5: 006d0000 00010000 "firmware"
mtd6: 00280000 00010000 "kernel"
mtd7: 00450000 00010000 "rootfs"
mtd8: 00020000 00010000 "rootfs_data"
mtd9: 006d0000 00010000 "runtime2"

/rom size:

df -h /rom
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 4.3M      4.3M         0 100% /rom

ROM size doesn't look outrageous to me, but it might be tight because of the dual partition setup maybe? If I'm not mistaken mtd8 is 131072 bytes (hex 00020000?) which translates to 128 kB? That does sound a bit small for rootfs_data?