Support for RTL838x based managed switches

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, ...

show tech-support (you can also do that over ssh/ telnet on the gs1900 series) will provide a lot of information already.

--
sadly the gs1900-16 seems not to be marketed in Europe, so availability and information are scarce.

1 Like

Here's show tech-support from my Zyxel GS1900-16:

I've actually got a pending patch for ZyXEL GS1900-16 support, but have issues and haven't had time to get back to it. If you want something to start with try my branch at https://github.com/RaylynnKnight/openwrt/tree/realtek-zyxel-16. As I said it may need work as I was having an issue with it and I haven't had time to get back to testing it.

3 Likes

Look forward to running OpenWRT on my GS1900-16 and to a simple interface. All I need is just VLANs, no other fancy features that the stock firmware provides.

Thank you!

1 Like

What issues did you have with the GS1900-16?

Build was done after re-basing code on master changes from about 10 days ago that had some VLAN issues. I've not had time to test again since the patch for that issue was merged

Ah, right. So there never were any specific issues with the GS1900-16.

The VLAN issue is fixed, so I assume your patch will work fine if @wired wants to test it.

sg-250 afaik similar hardware to a sg-350...

marvell... lots of serdes junk... may take a bin over x-modem tho' :wink:

specs
Packet Processor - AlleyCat3: 98DX3235 (GE), 98DX1235 (FE)
Embedded CPU - Marvell MSIS /400Mhz
PHY88E1680 - Integrated Octal 10/100/1000 Mbps Energy Efficient Ethernet Transceiver
88E3680 - Integrated Octal 10/100 Mbps Energy Efficient Ethernet Transceiver
88E1543 - Combo port support
DRAM - 512 MB (DDR3)
Flash - 256 MB NAND Flash
1 Like