Support for RTL838x based managed switches

Maybe you could try directly with H3C as the OEM. Unfortunately it is kinda hard to correlate the HPE branded models to the right H3C models. Some are easy, the HPE 5120-EI is the H3C S5120-EI, but the HPE 5510-HI is the H3C S5000V3-EI. I guess the HPE 1920 could be H3C S5120V2-LI, but HPE didn't push the upgrade to ComWare 7 out.
In general, everything OfficeConnect 19xx, FlexNetwork and FlexFabric is developed and manufactured by H3C.
Everything formerly ProCurve now Aruba is cooked up by HPE itself.
I have no idea what hell the officeconnect 1820/1920s crawled out ( both are same Hardware different Firmware, just like the 1920/5120-SI, 1950/5130-EI, ...).

Thanks a lot! This should ease my work significantly.
Regarding Linux for 1920s, it shouldn't be that much necessary, but could help sorting out PoE, I still haven't found a way to get a root shell on those.

Kind of off-topic, but wouldn't you mind asking about 1820s (J9979A/J9980A) as well, or helping me get in touch with that representative? :wink:
Probably won't differ that much from Netgear GS728TX/S3300X-28X, what I extracted from their images and flash dumps is really, REALLY, similar, and I've got GPL sources from Netgear. Unfortunately all the switch magic is hidden in the Fastpath application running in userspace.

@tgt79 Regarding 1820s, they are different hardware - Broadcom Fastpath based, as I mentioned previously, at least J9979A/J9980A which I own. All of them (8/26/52-ports, PoE/non-PoE as well) run the same binary.

I'm now adding support for the Netgear GS110TPv3 which appears to have less multiplexing of the GPIO values used for SFP as follows:

====== Fiber =================
Fiber Port Number: 2

------------ Fiber Detect
LPort  Present  MediaChg  OE Status              LOS Status
------ -------- --------- ---------------------- ----------------------
8      OE       OE        Enabled  (GPIO:EXT_14) Enabled  (GPIO:EXT_7 )
9      OE       OE        Enabled  (GPIO:EXT_13) Enabled  (GPIO:EXT_6 )

------------ Fiber Optical
LPort  I2C DEV  I2C TYPE  ID    Delay   SCK    SDA
------ -------- --------- ----- ------- ------ ------
8      0        8 BITS    0x50  1000    EXT_36 EXT_28
9      1        8 BITS    0x50  1000    EXT_36 EXT_27

------------ Fiber TX Disable
LPort  Method
------ ------
8      GPIO(EXT_9 )
9      GPIO(EXT_8 )

I've not used SFP modules on Linux before, so other than ensuring I have a link on the SFP port are there any diagnostic or utility programs I can use to verify the SFP is fully functional?

@Leo-PL just to be sure: are you talking about "1920s" as plural of 1920 (JG* product number) or about the actual 1920S Series (JL* product number).

Edit: one thing I like about the HPE OfficeConnect switches is their lifetime warranty, because it really covers a lifetime. The default warranty runtime is 100 years :slight_smile: and so far they have been delivering (replaced one 4200G after 15 years, and a 1820 after 4 that got hit by lightning). You will only get refurbished devices as replacements after a certain point though.

ethtool. you should be able to read out the eeprom, and sensor data if available, using ethtool -m. And you should be able to talk to the phy if there is one in the SFP (copper only). Look for the PHYAD address in the link settings and autoneg works all ways.

You'll also see the SFPs detected in the kernel log:

[    3.880851] i2c-gpio i2c-gpio-0: Slow GPIO pins might wreak havoc into I2C/SMBus bus timing
[    3.890693] i2c-gpio i2c-gpio-0: using lines 184 (SDA) and 185 (SCL)
[    3.898350] i2c-gpio i2c-gpio-1: Slow GPIO pins might wreak havoc into I2C/SMBus bus timing
[    3.908070] i2c-gpio i2c-gpio-1: using lines 190 (SDA) and 191 (SCL)
[    3.915831] libphy: SFP I2C Bus: probed
[    3.920568] sfp sfp-p9: Host maximum power 1.0W
[    3.926509] libphy: SFP I2C Bus: probed
[    3.931234] sfp sfp-p10: Host maximum power 1.0W
[    4.342773] sfp sfp-p10: module FiberStore       SFP1G-SX-85      rev      sn D87B2312465      dc 171202  
[    4.433086] sfp sfp-p9: module OEM              GLC-T            rev B    sn M0312A804        dc 130823  

And also the phys (if it exists) when you ifconfig the port up:

[5309425.355075] rtl83xx-switch switch@bb000000 lan9: PHY [i2c:sfp-p9:16] driver [Marvell 88E1111]

This is all mostly testing i2c. But that's the really important part. You could also verify that you can turn off the laser by using an SFP with DOM as detector in the other end.

1 Like

Courageous souls, eager to try out my new RTL8231 driver, can find the freshly submitted patches here:
https://lore.kernel.org/linux-gpio/cover.1620735871.git.sander@svanheule.net/T/

You will need an MDIO bus to connect to the expander chip, for which I currently use a bitbanged implementation:

mdio1: mdio {
        compatible = "virtual,mdio-gpio";
        #address-cells = <1>;
        #size-cells = <0>;

        /* Requires upstream driver for internal GPIOs*/
        gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>,
                <&gpio0 3 GPIO_ACTIVE_HIGH>;

        pinctrl-names = "default";
        pinctrl-0 = <&gpio_mdx_pins>, <&gpio_shadowing>;

        gpio1: expander@0 {
                compatible = "realtek,rtl8231";
                reg = <0x0>;

                gpio-controller;
                #gpio-cells = <2>;
                gpio-ranges = <&gpio1 0 0 37>;
        };
};

switchcore@1b000000 {
        compatible = "simple-bus";
        #address-cells = <1>;
        #size-cells = <1>;
        ranges = <0x0 0x1b000000 0x20000>;

        pinctrl_gpio: pinmux@a0e0 {
                compatible = "pinctrl-single";
                reg = <0xa0e0 0x4>;

                pinctrl-single,bit-per-mux;
                pinctrl-single,register-width = <32>;
                pinctrl-single,function-mask = <0x1>;
                #pinctrl-cells = <2>;

                gpio_mdx_pins: pinmux_gpio_mdx_pins {
                        pinctrl-single,bits = <0x0 0x0 0x1>;
                };
        };

        pinctrl_shadowing: pinmux@0144 {
                compatible = "pinctrl-single";
                reg = <0x0144 0x4>;

                pinctrl-single,bit-per-mux;
                pinctrl-single,register-width = <32>;
                pinctrl-single,function-mask = <0x1>;
                #pinctrl-cells = <2>;

                gpio_shadowing: pinmux_gpio_shadowing {
                        pinctrl-single,bits = <0x0 0x0 0x2>;
                };
        };
};
2 Likes

Do you mean the 1st part about Linux sources of my post? If so, it's about JG537A specifically, so not even a 1920, but 1910.

If it's about the last part (1820), then neither again, I meant the Aruba stuff here, which I'm working on as well, I just wanted to clarify that those are very different hardware than 1920 series.

Great work! I tried to backport the pending patches to my 5.10 branch and it works :slight_smile:

Currently, I tested only minimal support of RTL8231-related drivers.

...
[    1.786474] libphy: GPIO Bitbanged MDIO: probed
[    1.868006] rtl8231-pinctrl: Failed to locate of_node [id: -2]
[    1.879438] rtl8231-leds: Failed to locate of_node [id: -2]
...
[    6.531362] rtl8231-leds rtl8231-leds.1.auto: scan mode missing or invalid
[    6.539227] rtl8231-leds: probe of rtl8231-leds.1.auto failed with error -22
...
/sys/class/gpio, /sys/kernel/debug/gpio
root@OpenWrt:/# ls -alh /sys/class/gpio/
drwxr-xr-x    2 root     root           0 Jan  1  1970 .
drwxr-xr-x   17 root     root           0 Jan  1  1970 ..
--w-------    1 root     root        4.0K Jan  1  1970 export
lrwxrwxrwx    1 root     root           0 Jan  1  1970 gpiochip451 -> ../../devices/platform/mdio-gpio/mdio_bus/gpio-0/gpio-0:00/gpio/gpiochip451
lrwxrwxrwx    1 root     root           0 Jan  1  1970 gpiochip488 -> ../../devices/platform/soc/b8003500.gpio-controller/gpio/gpiochip488
--w-------    1 root     root        4.0K Jan  1  1970 unexport
root@OpenWrt:/# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 451-487, parent: mdio_bus/gpio-0:00, rtl8231-pinctrl, can sleep:
 gpio-454 (                    |reset               ) in  hi    <-- released (reset button on BSH-G24MB, active-low)

gpiochip0: GPIOs 488-511, parent: platform/b8003500.gpio-controller, b8003500.gpio-controller:
 gpio-488 (                    |red:sys_loop        ) out lo 
 gpio-490 (                    |mdio-gpio           ) out lo 
 gpio-491 (                    |mdio-gpio           ) in  hi 
root@OpenWrt:/# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 451-487, parent: mdio_bus/gpio-0:00, rtl8231-pinctrl, can sleep:
 gpio-454 (                    |reset               ) in  lo    <-- pressed

gpiochip0: GPIOs 488-511, parent: platform/b8003500.gpio-controller, b8003500.gpio-controller:
 gpio-488 (                    |red:sys_loop        ) out lo 
 gpio-490 (                    |mdio-gpio           ) out lo 
 gpio-491 (                    |mdio-gpio           ) in  hi 
root@OpenWrt:/# REBOOT       <-- reboot triggered

IMO, CONFIG_MDIO_BITBANG and CONFIG_MDIO_GPIO may have to be selected by CONFIG_MFD_RTL8231.

EDIT:

repo: https://github.com/musashino-build/openwrt/tree/tgtbump/rtk_5.10_rtl8231

1 Like

I get those warning messages too, but I don't know how to get rid of them. I've put them in the cover letter of my patch sent and asked for guidance :slight_smile:

Althought this currently uses CONFIG_MDIO_GPIO, this is not a hard requirement. Any MDIO bus will do. A next step would be to implement the hard MDIO bus provided by the LED/GPIO peripheral. Then the bitbanging won't required anymore. This driver also shouldn't be specific to the Realtek platform. It's an MDIO device, so any MDIO bus should do.

1 Like

Ah, indeed. thank you!

I've updated the pinmux config in the DTS snippet I posted above. @johnd2 was experiencing spontaneous device resets after my driver probed the RTL8231. But the T1600G also does register shadowing, which wasn't disabled by the pinmux config. I've added another pinmux config (really an peripheral enable setting, but whatever, we need to set that flag correctly) to make sure the register shadowing is disabled.

Edit: The extra pinctrl didn't fix the reset issue on the T1600G yet... :confused:

3 Likes

I finally got my DLink DGS-1210-10P version F1 to work properly with OpenWRT. Up until now it was not letting traffic pass the switch, one could merely ping/ssh to it. The only packets that seemed to pass were MDNS frames from the printer. I started to compare register settings one-by-one with my Zyxel GS1900 10HP and stumbled on the Packet Inspection Engine being set up with forwarding rules by u-boot, even if "rtk network on" is never used to configure the network. This is the comparison between the relevant registers:

U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Oct 20 2017 - 15:42:41)

Board: RTL838x CPU:500MHz LXB:200MHz MEM:300MHz
DRAM:  128 MB
SPI-F: 1x32 MB
Loading 1024B env. variables from offset 0x80000
Board Model = DGS-1210-10P-F1 Cameo_bdinfo_get_BoardID [293] 
Switch Model: RTL8380M_INTPHY_2FIB_1G_DEMO (Port Count: 10)
Switch Chip: RTL8380
**************************************************
#### RTL8218B config - MAC ID = 8 ####
Now Internal PHY
Net:   Net Initialization Skipped
rtl8380#0
Hit Esc key to stop autoboot:  0 
u-boot># 
Abort
Ctrl-c was pressed..(Changing to u-boot console mode(0)) 
<INTERRUPT>
u-boot># md.l 0xbb006100 4
bb006100: 00000fff 00000fff 00000001 00000000    ................
u-boot># md.l 0xbb006910 14
bb006910: 00000000 00001003 00000000 00000000    ................
bb006920: 00000043 00440000 00000000 00000000    ...C.D..........
bb006930: 00000000 00000000 00000000 0000ffff    ................
bb006940: ffff0000 00000000 00000000 00001c00    ................
bb006950: 80000000 00000000 00009c1c 00002000    .............. .


On the Zyxel:
RTL838x# printenv boardmodel
boardmodel=ZyXEL_GS1900_10HP
RTL838x# md.l 0xbb006100 4
bb006100: 00000fff 00000000 00000000 00000000    ................
RTL838x# md.l 0xbb006910 14
bb006910: 00000000 00000000 00000000 00000000    ................
bb006920: 00000000 00000000 00000000 00000000    ................
bb006930: 00000000 00000000 00000000 00000000    ................
bb006940: 00000000 00000000 00000000 00000000    ................
bb006940: 00000000 00000000 00000000 00000000    ................

From registers bb006104 (Power control for the 12 Inspection Engines) and bb006108 (template configuration for packet matching) one can see that the 12 Engine blocks are powered on and a template is being configured. bb006914 shows that someone was using the control register to manipulate the IACL table (https://www.svanheule.net/realtek/maple/table/iacl), it seems rule 3 in that table was written to. At this point I got a bit paranoid, because the SDK does not suggest to delete any rules on startup, the default u-boot from the SDK does not set any PIE rules and one could use these to exfiltrate data from the LAN. But it turns out these rules merely protect the switch during configuration, i.e. no leakage of packets from one port to another. The 12 rules I found all redirect all kinds of packets on various layers to the CPU-port, in particular ARP-frames, IPv4 and IPv6 and UDP. Which seems to explain the strange MDNS traffic.
I will submit a patch that on switch initialization will always delete any PIE rules present. This will make the DLink work, and protect against any funny rules in the PIE possibly compromising the network.

1 Like

I somehow get the feeling that the resets caused when loading the RTL8231 driver on the T1600G-28TSv3 are also related to some improper register configuration. Moreover, when the GPL uboot complains about not recognizing the boardname. Does anyone have a full register dump of a RTL8382M at uboot stage of another device which I could compare against mine with faked and not faked boardname?

Dump of a freshly booted Cisco SG220-26: https://svanheule.net/files/dump-sg220.txt.gz

2 Likes

Thanks a lot!

Okay, there are bigger chunk differences between faked and not faked boardname so the uboot skips a lot of setup when not recognizing the boardname.

Still, there are also quite some differences to the SG220-26. I'll have a detailed look maybe I can find something interesting.

Edit:

DMY_REG5 bit GPIO_INTF_SEL is not set so I2C mode is selected.

Tried to set this bit via but also resets.

                        gpio_shadowing: pinmux_gpio_shadowing {
                                pinctrl-single,bits = <0x0 0x1 0x3>;
                        };

PHY_UP_CTRL bit DIS_PHYAUTO_UP is set which may explains why PHY's are not bootet up

lots of MAC and SERDES related changes probably not that relevant for the reset.

For completenes here are the dumps of stock boardmodel and faked boardmodel:

I just bought a Zyxel GS1900-48 and would be happy to test. I can recover in case it is needed, SOIC8/16 clips and even enough spare flash chips are available.

Is there any image I can try? https://biot.com/switches/gs1900-48 lists experimental hardware support in OpenWrt, but I can't find any matching snapshot image.

You find it in the l3 branch of bkobl's openwrt repo on github:

Any hope to get support for the Zyxel GS1900-16?

The hope is with you. Just crack it open, hook up serial and get going...

1 Like

What exactly do I need to do? Is there a guide, e.g. how to hook up the cable to the pins, what data to collect from the boot or otherwise, ...