Support for RTL838x based managed switches

dtw · June 3, 2023, 10:07am

I finally identified the cause of the link regression. Unbelievably, (to me, at least) adding a label for the led makes the link work... I did end up fixing the clock issue on the dev branch and bisected (and carefully rebuilt cleanly and without ccache) all commits and then proceeded to further take apart the various changes until only this one line remained. When I apply it to the wip branch the PHYs get link, and without that line they don't. I don't have a good explanation (yet?) as to why that would make a difference but it's hard to argue with the facts.

--- a/target/linux/realtek/dts-5.15/rtl930x.dtsi
+++ b/target/linux/realtek/dts-5.15/rtl930x.dtsi
@@ -102,6 +102,7 @@
                pinctrl-0 = <&pinmux_a0_gpio0>;

                sys_led: sys-led {
+                       label = "green:power";
                        color = <LED_COLOR_ID_GREEN>;
                        function = LED_FUNCTION_STATUS;
                        gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;

I have since then also modified the bcm84881 driver slightly to accept USXGMII links and to match onto the vendor and product id for my chips (setting compatibles didn't work, but maybe I did it wrong?) and now have working link speed negotiation (up to 1gbit only for now) and link detection in the kernel.

I still can't seem to get any data sent, meaning I'm still stuck with slow ymodem transfers. This is what things look like now:

root@OpenWrt:/# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:02 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
3: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:03 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:04 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
5: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:05 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:06 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
7: lan5@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master switch0 state UP mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:07 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
8: switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:02 brd ff:ff:ff:ff:ff:ff
9: switch0.1@switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 7e:c2:be:f0:b4:03 brd ff:ff:ff:ff:ff:ff

and

root@OpenWrt:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 7e:c2:be:f0:b4:02 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
    inet6 fe80::7cc2:beff:fef0:b402/64 scope link
       valid_lft forever preferred_lft forever
3: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN group default qlen 1000
    link/ether 7e:c2:be:f0:b4:03 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN group default qlen 1000
    link/ether 7e:c2:be:f0:b4:04 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
5: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN group default qlen 1000
    link/ether 7e:c2:be:f0:b4:05 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch0 state LOWERLAYERDOWN group default qlen 1000
    link/ether 7e:c2:be:f0:b4:06 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
7: lan5@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master switch0 state UP group default qlen 1000
    link/ether 7e:c2:be:f0:b4:07 brd ff:ff:ff:ff:ff:ff permaddr 00:00:00:04:82:60
8: switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:c2:be:f0:b4:02 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7cc2:beff:fef0:b402/64 scope link
       valid_lft forever preferred_lft forever
9: switch0.1@switch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:c2:be:f0:b4:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global switch0.1
       valid_lft forever preferred_lft forever
    inet6 fd1e:8084:684c::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::7cc2:beff:fef0:b403/64 scope link
       valid_lft forever preferred_lft forever

An external host has 192.168.1.111 and pings don't go through in either direction. I did also /etc/init.d/firewall stop and fw4 flush. Any pointers would be much appreciated. Boot log in case there's something I'm missing.

Edit: Is it that the RTL93xx initialization isn't quite complete yet, maybe because U-Boot on Zyxel devices sets things up sufficiently to get switch to host networking going? It doesn't look like that's the case for me... Should I be looking more at the RTL93xx dal to get that up and running?

olliver · June 9, 2023, 12:44pm

Haven't read anything below your post (or above have to dive into that one) but devmem 0xbb00cb80 32 should probably be devmem 0x1b00cb80 32 (U-boot and linux use different access addresses, one 'converts them for you'.

afaik, you trigger the mmd path by setting c45 in the dts?

That's insane though, because afaik the function + color SHOULD create label for you weirdness

they not only do, we are currently still depending on that

dtw · June 10, 2023, 3:57pm

Thanks for confirming! I'm glad I'm slowly puzzling things together at least As you can tell I'm very unfamiliar in this part of the world. Is there a way to get additional debug information to see where things are going wrong? My stock kernel comes with /dev/mem and /dev/kmem but strace and friends aren't present.

I did also have a quick peek at the drivers/net/switch/rtk/rtk.ko module from my stock 3.18 kernel, which seems to do all the right initialization but it quickly became apparent that it might be a world of pain to tease that apart sufficiently well to get all the right register and mdio writes to get my PHYs up and running.

The other option I found is this driver from the asuswrt-merlin.ng project which mentions it ought to be compatible with bcm8489x. It's for a 4.1 kernel and the phy_device and driver structs and concepts look different from the mainline kernel, but maybe still worth looking into...

olliver · June 10, 2023, 10:02pm

you can always get a statically compiled version for it so that's easily solveable.

You can always bug your vendor for a GPL code dump It is mandatory after all (which isn't the easiest way for sure).

For now, I've parked openwrt for a little bit, with the issues I was having with 6.1 not booting (and lack of feedback or help on issues on github).

I'll be going back to it in a while, just not right now. Also .. heat ...

dtw · June 11, 2023, 9:10am

Alright, it'll be good to have you back after your break though!

I've requested GPL source from Trendnet almost 2 months ago but I keep hearing that they're looking into it with no commitment on timeframe yet. I'll keep prodding at things a bit more.

hailfinger · July 7, 2023, 7:28am

Thanks for the great work on these switches!

On my NETGEAR GS108T v3 running OpenWrt 23.05-rc2 (official default build), I am missing a GUI for seeing the link state of the switch ports similar to what's present in Network->Switch with my Tp-Link Archer C6 v2 running OpenWrt 22.03 (see screenshot).
Do I have to install an additional package or do I have to look elsewhere in the GUI or is this not yet implemented?

hailfinger · July 7, 2023, 8:02am

Somehow I overlooked the solution from @jow to the above question:

github.com/openwrt/luci

luci-mod-status: introduce ethernet port status view

openwrt:master ← jow-:port-status

opened 01:46PM - 02 Aug 22 UTC

jow-

+361 -0

This commit adds an ethernet port status overview to the main status page. ![…0fd2914f22e4958ba7beec4a7efbb912b944c245](https://user-images.githubusercontent.com/2528802/182389860-323f332f-a5f1-4a80-bb51-27077927af97.png) The design should theoretically scale to many ports. Below is a mock up created by repeating the six original ports multiple times: ![b8521667ff4dd1ac1b5deafcd9c544b81a41f0dc](https://user-images.githubusercontent.com/2528802/182389968-a806ea13-5010-49aa-a9b1-4c7cd7edd4b1.png) Logical network membership and detailled statistics are exposed as tooltips: ![d4650116539ceab8ac0e1cfea281bca5a200155a](https://user-images.githubusercontent.com/2528802/182390055-699f4f62-2968-446f-8526-36d2b35c516b.png) ![e78734f667a6ca6186aaa3f3efdb050a47325593](https://user-images.githubusercontent.com/2528802/182390063-9c96986d-9282-475f-a10e-1e9635f7322f.png) Original forum topic: https://forum.openwrt.org/t/ethernet-port-icons-on-openwrt/130799

a_guy · July 8, 2023, 2:52am

Hey folks, does anyone here know what the status of rtl930x switch SPI driver? Seems like @olliver started something? What's the repo for that?

olliver · July 8, 2023, 11:28am

yeah i have done the work; but when the migration to 6.1 bombed in my face; i briefly gave up for a while. Since nobody else even offered to help; and I had other things that also needed my attention; it has kept lingering there for a while

a_guy · July 8, 2023, 11:31am

I'm ready to help here. Let me know where I could start

olliver · July 8, 2023, 11:49am

Well there's that https://github.com/openwrt/openwrt/pull/12726 but also https://github.com/openwrt/openwrt/pull/12541 that need some TLC

hailfinger · July 23, 2023, 10:33pm

For a small side project at work, I am looking into spending half a week on development for a 20+ port gigabit switch with OpenWrt. Willing to write code, solder, dump chips and other fun stuff if it helps.
Requirements:

Rack mountable
Working Link/Act LEDs
Working STP (willing to build/test/patch anything proposed in https://github.com/openwrt/openwrt/issues/11989)
Supportable in OpenWrt 23.05
Stable (no crashes, L2 works)
At least 20 copper gigabit ports
Less than 800 EUR (used or new)

Nice to have:

Working PoE
48+ ports
SFP for uplink

Any recommendations for a specific model which would benefit from some love or which already works? Currently looking at HPE 1920-24G/48G variants with and without PoE.

flygarn12 · July 24, 2023, 4:37am

3,5days on the side…Do you talk about a new device or a simple drop-off from a current family?
Do you actually have the the device on your desk right now?

I really hope you are familiar with building from source?

Doubt that, “new” goes into main.

andyboeh · July 24, 2023, 6:35am

If it's just a new device port, a backport could be accepted (I did that recently for an ipq40xx device).

Anyway, most of the HPE 1920 devices are already supported or there are patches floating around (for the 48 port model).

hailfinger · July 24, 2023, 1:07pm

The goal is to add support for a currently unsupported or semi-supported device similar to one already supported, i.e. a member of a mostly-supported family. Half a week of effort would be unrealistic for anything else. I have done quite a lot of reverse engineering, firmware and driver development in the past (mostly x86), so my time estimate for such a task is hopefully realistic enough.

No, I'd rather get some advice, then buy.

I was familiar with the OpenWrt build system around 18.06 (for my o2 Box 6431 which needed additional kernel changes), hopefully it hasn't changed much.

a_guy · August 6, 2023, 7:51pm

You could try Verizon CR1000A. We need the rtl9301 SPI driver there.

hailfinger · August 12, 2023, 10:21am

I had a few switches lying around and flashed them to OpenWrt 23.05-rc2.

Netgear GS108Tv3
Zyxel GS1900-24E
Zyxel GS1900-48

They all seem to work well.

I could't find any photos of the inside of the Zyxel switches mentioned above nor do they have a device page. Would it be helpful if I take a few photos of the inside of those switches and create a rudimentary device page? (I have a wiki account.)

Followup question: Does it make sense to add the Zyxel GS1900-24E/GS1900-48 data to an existing wiki page, e.g for the GS1900-8? The contents will be pretty much identical, so copying that to a new page seems pointless.

RaylynnKnight · August 13, 2023, 6:25am

Photos of the first 2 devices are on the corresponding WikiDevi pages. Creating a device page has been on my todo list for quite some time, but I keep getting sidetracked with other tasks!

fenrirkun · August 21, 2023, 11:21am

hello, i have a DGS-1210-10 that works using 10P openwrt firmware.

i have seen your recent PR for DGS-1210-10MP, what can i do to add the base DGS-1210-10 to supported device?

i can build from source, have that particular switch on my desk idling and would like to help/test if needed.

flygarn12 · August 21, 2023, 12:01pm

To begin with if I remember right you need to remove poe package, poe mode led, mode switch (not that it actually do anything but it is in the dts).
Do you have a act mode led on that device?

Does that device have the port expander?