0x6 works in the CPU PORT reset
I tried disabling SDS phy writes, but I still wasn't passing traffic. I'll double check the mdio reset again. One notable symptom is that ethool lan1 returns on 1G modes, and seems pretty confused, which also makes me suspect the dsa driver.
root@OpenWrt:/# ethtool lan1
Settings for lan1:
Supported ports: [ TP MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 16
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: no
I think I am making progress, as I eventually got the dsa driver to get mad at the phy in phylink validate, which lead me to dig more into phylink. I really need to clean up the patch so far, it's clear there needs to be a better way to associate the sds_num with the phy rather than just the MAC/interface. I now have ethtool thinking lan1 is 1000Base-LR with no link, which seems closer to reality than 1000base with fibre/mii
I did get this out of the OEM fw (via /proc/board):
****************************
UBNT-USL8A
****************************
============================
Board GPIO
============================
============================
Board Configuration
============================
====== Port ==================
Type Usr Phy Media Speed Duplex Attr
----------- ---- ------- ----------- -------------- -------- -------
10G 1 (0) 20 Fiber (A) 10M (F) Full 0
10G 2 (0) 16 Fiber (A) 10M (F) Full 0
10G 3 (0) 25 Fiber (A) 10M (F) Full 0
10G 4 (0) 24 Fiber (A) 10M (F) Full 0
10G 5 (0) 27 Fiber (A) 10M (F) Full 0
10G 6 (0) 26 Fiber (A) 10M (F) Full 0
10G 7 (0) 8 Fiber (A) 10M (F) Full 0
10G 8 (0) 0 Fiber (A) 10M (F) Full 0
====== Fiber =================
Fiber Port Number: 8
------------ Fiber Detect
LPort Present MediaChg OE Status LOS Status
------ -------- --------- ---------------------- ----------------------
0 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
1 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
2 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
3 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
4 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
5 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
6 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
7 None Enabled (GPIO: NULL) Enabled (GPIO: NULL)
------------ Fiber Optical Connect by I2C Hardware Controller 0
LPort I2C DEV I2C TYPE ID Delay SCK SDA
------ -------- --------- ----- ------- ------ ------
0 2 8 BITS 0x50 4 8 0
1 4 8 BITS 0x50 4 8 1
2 6 8 BITS 0x50 4 8 2
3 8 8 BITS 0x50 4 8 3
4 10 8 BITS 0x50 4 8 4
5 12 8 BITS 0x50 4 8 5
6 14 8 BITS 0x50 4 8 6
7 16 8 BITS 0x50 4 8 7
====== Led ===================
SYS (REG)
ALARM (REG)
====== WatchDog ==============
Type: REG
I'm not sure if any of these are SDS numbers, but the sds 2/phy16 might be port #2 and not 1?
Put it on the wiki too: https://biot.com/switches/usw-aggregation
Oh no, another one of these shared SCK setups 
Linux currently does not have a driver that supports bitbanged I2C busses with a shared SCK GPIO. I think we'll have to write some driver for that at some point...
None of this is the SDS number. But I got hold of a USW switch and will try to read out the flash today. If I am lucky I can find the SDS/MAC mapping. Could you post a picture of the unpopulated resistors you bridged to get UART working?
The SDA numbers are strange. I doubt these are real GPIO numbers. SCK 8 would make sense because this is the GPIO that is used by the first i2c controller of the RTL9300 SoC. But that one would use GPIOs 9-16 as SDA. If this were indeed the case that it actually uses the internal i2c master, then it might be easier to implement an i2c controller driver for the 93xx devices instead of fixing the bit-bang driver. Still, that would not solve the issue for the 83xx devices.
Edit: I managed to decode the flashrom:
00063120 00 00 00 00 00 00 00 00 00 00 00 00 83 f6 49 fc |..............I.|
00063130 83 f6 44 88 83 f6 3f 14 83 f6 34 78 83 f6 29 dc |..D...?...4x..).|
00063140 83 f6 1f 40 83 f6 14 58 83 f6 0e e4 83 f6 04 48 |...@...X.......H|
00063150 83 f5 f9 ac 83 f5 e9 50 83 f5 ee c4 83 f5 f4 38 |.......P.......8|
00063160 83 f6 19 cc 83 f5 e3 dc 00 00 00 00 00 00 00 00 |................|
00063170 55 42 4e 54 5f 55 53 4c 38 41 00 00 00 00 00 00 |UBNT_USL8A......|
00063180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00063190 00 00 00 00 00 00 00 00 00 00 00 00 00 8d e8 2f |.............../|
000631a0 00 ff 00 00 00 00 00 01 83 f5 e4 28 00 00 00 00 |...........(....|
000631b0 00 00 00 00 00 00 00 00 93 03 68 10 01 00 00 00 |..........h.....| Chip-Id: 0x93036810 = RTL9303_CHIP_ID_8XG
000631c0 00 00 00 01 ff 01 00 00 00 00 00 00P00 ff ff ff |................| Port 0, SDS-idx 0
000631d0 00 00 00 00 01 08 08 00 00 00 00 00P08 ff ff ff |................| Port 8, SDS-idx 1
000631e0 00 00 00 01 01 08 08 00 00 00 00 00P10 ff ff ff |................| Port 16, SDS-idx 2
000631f0 00 00 00 02 01 08 08 00 00 00 00 00P14 ff ff ff |................| Port 20, SDS-idx 3
00063200 00 00 00 03 01 08 08 00 00 00 00 00P18 ff ff ff |................| Port 24, SDS-idx 4
00063210 00 00 00 04 01 08 08 00 00 00 00 00P19 ff ff ff |................| Port 25, SDS-idx 5
00063220 00 00 00 05 01 08 08 00 00 00 00 00P1a ff ff ff |................| Port 26, SDS-idx 6
00063230 00 00 00 06 01 08 08 00 00 00 00 00P1b ff ff ff |................| Port 27, SDS-idx 7
00063240 00 00 00 07 01 08 08 00 00 00 00 00P1c ff ff ff |................| CPU-Port: 28
00063250 00 00 00 ff 08 ff ff 00 ff ff ff 00 ff 00 00 00 |................|
00063260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
.serdes.descp:
000635c0 00 00 00 00 00 00 00 00 00 00 00 00 00 02 08 03 |................| sds_idx 0: SDS 2 SDS mode 8 = 10GRMII_10GR
000635d0 08 04 08 05 08 06 08 07 08 08 08 09 08 ff 00 00 |................| .. sds_idx 7: SDS 9 SDS-modes
000635e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Serdes 2-9 are used, all SerDes have SDS-mode 10GRMII_10GR (0x2 << 2 = 0x8)
mode is shifted 2 bits left for polarity bits so SERDES_POLARITY_NORMAL for
rx/tx (bits 0, 1)
*
00063640 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 00 |................|
00063650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00063680 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 |................|
00063690 00 00 0b a0 00 00 0a 01 ff ff ff ff 00 00 00 00 |................|
000636a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The sequence of ports used (0, 8, 16, 20, 24, 25, 26, 27) seems maybe a bit strange but is not more strange than e.g. the one from the Edgecore:
My suspicion is that e.g. SerDes 2 may be split up to serve MACs 0-8 for GBit Ethernet, while SerDes 6 can only be used for MAC 24 and a 10GBit port. From the SDK there are hints that this distribution SerDes/MAC might make the difference between e.g. an RTL9302 and a RTL9303_8XG
Sorry for beeing a bit late, I just catched up with the thread once again. During my initial investigation for my T1600G-28TS I bulk downloaded firmware files for all similar devices from TP-Link's homepage.
For the boardname in the TL-SG3216v2 firmware I noted BCM56218 based, which is the platform TP-Link used before switching to RTL. I just noticed that I actually never postet that list here.
Firmware boardname list
T1500G-10MPSv1 1.0.0 [20170607-rel35832] RTL8380M_INTPHY_2FIB_1G_DEMO
T1500G-10MPSv2 2.0.6 [20200805-rel54045] RTL8380M_INTPHY_2FIB_1G_DEMO
T1500G-10PSv1 1.0.0 [20170607-rel38008] RTL8380M_INTPHY_2FIB_1G_DEMO
T1500G-10PSv2 2.0.6 [20200805-rel57865] RTL8380M_INTPHY_2FIB_1G_DEMO
T1500G-8Tv1 1.0.0 [20170607-rel34192] RTL8380M_INTPHY_2FIB_1G_DEMO
T1500G-8Tv2 2.0.6 [20200805-rel56922] RTL8380M_INTPHY_2FIB_1G_DEMO
T1600G-18TSv1 1.0.0 [20170602-rel54586] RTL8382M_8218B_INTPHY_8218B_2FIB_1G_DEMO
T1600G-18TSv2 2.0.5 [20200304-rel33762] RTL8382M_8218B_INTPHY_8218B_2FIB_1G_DEMO
T1600G-28PSv1 1.0.1 [20160411-rel34676] BCM5301x
T1600G-28PSv3 3.0.6 [20200805-rel55018] RTL8382M_8218B_INTPHY_8218B_8214QF_DEMO
T1600G-28TSv1 1.0.3 [20160412-rel43154] BCM5301x
T1600G-28TSv3 3.0.6 [20200805-rel55968] RTL8382M_8218B_INTPHY_8218B_8214QF_DEMO
T1600G-52PSv1 1.0.1 [20160411-rel42666] BCM5301x
T1600G-52PSv3 3.0.0 [20180723-rel69194] BCM5301x
T1600G-52PSv4 4.0.5 [20200110-rel51761] RTL8393M_8218B_8214QF_DEMO
T1600G-52TSv1 1.0.3 [20160412-rel52132] BCM5301x
T1600G-52TSv3 3.0.0 [20180212-rel56119] BCM5301x
T1600G-52TSv4 4.0.5 [20200109-rel62193] RTL8393M_8218B_8214QF_DEMO
T1700G-28TQv1 1.0.3 [20160601-rel52662] BCM5301x
T1700G-28TQv2 2.0.1 [20170608-rel61525] BCM5301x
T2500G-10TSv1 1.0.0 [20170411-rel32895] BCM56218 (MIPS32)
T2500G-10TSv2 2.0.5 [20200110-rel53175] RTL8380M_INTPHY_2FIB_1G_DEMO
T2600G-18TSv1 1.0.0 [20170105-rel55239] RTL8382M_8218B_INTPHY_8218B_2FIB_1G_DEMO
T2600G-18TSv2 2.0.3 [20190516-rel33426] RTL8382M_8218B_INTPHY_8218B_2FIB_1G_DEMO
T2600G-28MPSv1 1.0.0 [20160519-rel58928] BCM5301x
T2600G-28MPSv2 2.0.0 [20170928-rel37650] BCM5301x
T2600G-28MPSv3 3.0.3 [20181101-rel50690] BCM5301x
T2600G-28MPSv4 4.0.5 [20200728-rel56922] Broadcom HR3-WH2 SVK (BCM953547K)
TL-SG3424P V4 4.0.5 [20200728-rel56922] Broadcom HR3-WH2 SVK (BCM953547K)
T2600G-28SQv1 1.0.5 [20200304-rel61626] BCM5301x
T2600G-28TSv1 1.0.1 [20160412-rel57988] BCM5301x
T2600G-28TSv2 2.0.0 [20170928-rel34921] BCM5301x
T2600G-28TSv3 3.0.3 [20181101-rel42543] BCM5301x
T2600G-28TSv4 4.0.5 [20200110-rel60612] Broadcom HR3-WH2 SVK (BCM953547K)
T2600G-52TSv1 1.0.1 [20160412-rel52062] BCM5301x
T2600G-52TSv2 2.0.0 [20201103-rel62884] BCM5301x
T2600G-52TSv3 3.0.5 [20200304-rel57813] BCM5301x
T2700G-28TQv2 2.0.0 [20161103-rel60135] Broadcom StrataSwitch (BCM56XX) BCM53000 (MIPS74K)
T2700Gv1 1.1.2 [20151228-rel71001] Broadcom StrataSwitch (BCM56XX) BCM53000 (MIPS74K)
T3700G-28TQv2 2.0.0 [20161103-rel60135] Broadcom StrataSwitch (BCM56XX) BCM53000 (MIPS74K)
T3700Gv1 1.0.6 [20160112-rel53020] Broadcom StrataSwitch (BCM56XX) BCM53000 (MIPS74K)
TL-SG2008Pv1 1.0.0 [20200608-rel76470] RTL8380M_INTPHY_2FIB_1G_DEMO
TL-SG2008v1 1.0.3 [20150624-rel57993] RTL8328S
TL-SG2008v3 3.0.0 [20200730-rel30695] RTL8380M_INTPHY_2FIB_1G_DEMO
TL-SG2210MPv1 1.0.0 [20200608-rel75601] RTL8380M_INTPHY_2FIB_1G_DEMO
TL-SG2210Pv1 1.0.5 [20160912-rel32686] RTL8328S
TL-SG2210Pv3 3.0.0 [20200106-rel43122] RTL8380M_INTPHY_2FIB_1G_DEMO
TL-SG2210Pv3 3.20.0 [20200730-rel32643] RTL8380M_INTPHY_2FIB_1G_DEMO
TL-SG2216v1 1.0.6 [20150713-rel53496] RAPTOR BCM56218 (MIPS32)
TL-SG2216v2 1.0.3 [20150714-rel61832] RAPTOR BCM56218 (MIPS32)
TL-SG2218v1 1.0.0 [20201104-rel49988] RTL8380M_INTPHY_2FIB_1G_DEMO
TL-SG2424v1 1.0.7 [20150713-rel53496] RAPTOR BCM56218 (MIPS32)
TL-SG2424v2 1.0.2 [20150714-rel61832] RAPTOR BCM56218 (MIPS32)
TL-SG2428Pv1 1.0.0 [20200608-rel77345] RTL8382M_8218B_INTPHY_8218B_8214QF_DEMO
TL-SG2452v1 1.0.4 [20151127-rel67331]
TL-SG3210 1.0 1.9.2 RAPTOR BCM56218 (MIPS32)
TL-SG3210v2 1.9.11 [20150714-rel61832] RAPTOR BCM56218 (MIPS32)
TL-SG3210XHP-M2v1 1.0.0 [20201016-rel66100]
TL-SG3216v1 2.1.7 [20150713-rel53496] RAPTOR BCM56218 (MIPS32)
TL-SG3216v2 1.0.2 [20150714-rel61832] RAPTOR BCM56218 (MIPS32)
TL-SG3424P 1.0 1.0.8 RAPTOR BCM56218 (MIPS32)
TL-SG3424Pv2 1.0.9 [20150715-rel33297] RAPTOR BCM56218 (MIPS32)
TL-SG3424v1 1.11.10 [20150713-rel53496] RAPTOR BCM56218 (MIPS32)
TL-SG3424v2 1.0.3 [20150714-rel61832] RAPTOR BCM56218 (MIPS32)
TL-SG3428XMPv1 1.0.0 [20200924-rel58489]
TL-SG3428Xv1 1.0.0 [20200924-rel61713]
TL-SG345x-Series 1.0.0 [20201022-rel69642] RTL8393M_8218B_8214QF_DEMO
It might be a little bit outdated in latest firmware versions though since it was compiled a few months ago.
4 Likes
I am probably asking an already answered question as I have seen work on the reset side.
But I cannot reboot my DGS-1210-28P at all, it will print:
[ 194.251638] reboot: Restarting system
[ 194.255763] System restart.
[ 194.258886] PLL control register: efffffff, applying reset value efffffff
And then get stuck here until I pull the power, note that I have the F2 revision but I have seen reports of it working fine on F2 as well
I believe this is an issue with the backported spi flash driver, which no longer controls 3/4 byte flash access mode. A solution would be to use a GPIO pin for reset. Maybe @svanheule can help with the details.
I'm experiencing the same issue on my GS110TPP with recent master builds.
Paul Fertser has tested my WDT restart patches (feel free to send a Tested-by or other feedback 
), and these provide a properly functioning device restart for him on the DGS-1210-10. Additionally, with the last patch in that series, you can also start using gpio-restart on your device, which should be a full hard device reset in case the WDT restart doesn't work.
3 Likes
I have written a very first I2C driver for the RTL9300. Quite hackish, SDA and SCL pins are hard coded because of some issue reading the dts, but it works.
root@OpenWrt:/# i2cdump -y 0 0x50
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 03 04 07 00 00 00 01 00 00 00 00 01 0d 00 00 00 ???...?....??...
10: 37 1b 00 00 44 65 6c 6f 63 6b 20 20 20 20 20 20 7?..Delock
20: 20 20 20 20 00 00 90 65 47 4c 43 2d 53 58 2d 4d ..?eGLC-SX-M
30: 4d 20 20 20 20 20 20 20 31 2e 30 20 03 52 00 4f M 1.0 ?R.O
40: 00 1a 00 00 38 36 31 38 36 32 30 35 30 30 30 31 .?..861862050001
50: 36 20 20 20 32 30 31 32 30 34 20 20 08 00 00 86 6 201204 ?..?
60: 00 00 11 d3 ae cc 6b 6b e9 ce 4d 7f 7d 04 ca 56 ..????kk??M?}??V
70: 34 16 e5 00 00 00 00 00 00 00 00 00 55 82 51 e7 4??.........U?Q?
80: 53 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 S???????????????
90: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ????????????????
a0: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ????????????????
b0: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ????????????????
c0: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ????????????????
d0: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ????????????????
e0: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 ????????????????
f0: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 fd ????????????????
root@OpenWrt:/# cat /sys/bus/i2c/devices/i2c-0/name
1b00036c.i2c-rtl9300-0
Code is here: https://github.com/bkobl/openwrt/tree/sfp_10g
I wanted to use this to understand the I2C multiplexing, then figure out how to get the SFP+ ports correctly talked to. I already managed to send some traffic on the Ubiquity.
2 Likes
Thanks, I see that they have been merged today so I will give it a go tomorrow.
Thanks for the hard work to anybody working on this target.
3 Likes
Are those SCK/SDA pins also GPIO pins, and muxed to an I2C function here?
Yes. There are 2 I2C master controllers and 1 SPI master controller available. Plus 1 I2C slave and an SPI slave. The slaves allow direct manipulation of the Switch registers to allow more ports to be controlled via a master SoC.
The I2C masters are MST1 and MST2. They share some common configuration registers (RTL9300_I2C_MST_GLB_CTRL for pinmuxing the SDA pins mostly) so they are actually 2 not entirely independent controllers, but up to 8 busses. Each controller has one single dedicated SCK, but they share the SDA pins.
MST1 uses GPIO 8 for SCK, this cannot be changed.
MST2 uses GPIO 17 for SCK, this can also not be changed.
The possible SDA pins are pins 9 to 16. They can be assigned an I2C role via RTL9300_I2C_MST_GLB_CTRL and then are called SDA 0-7. For each individual transfer, a controller can pick one of the SDA pins, which would need to be coordinated with the other controller. SDA7 is special and can be open drain. Also both SCL pins can be set to be open drain via RTL9300_I2C_MST_GLB_CTRL.
So this is actually the same picture we see for how the SFPs are generally set up on these devices. They share one SCK line, but have different SDA lines.
The controller is a funny beast. It can only do up to 16 byte transfers in a go via RTL9300_I2C_MST1_DATA_WORD0-3. In principle it speaks more SMBus than I2C, because it does not allow to control stop or start conditions. There are basically only 4 types of transfers:
- Read with register: Send device address and register address to read from, read up to 16 bytes of data, similar to EEProm reads.
- Write with register: Send device address and register address to write to, write up to 16 bytes of data similar to EEPROM writes
- Read: Send device address and read up to 16 bytes
- Write: Send device address and start writing up to 16 bytes
The first 2 differ from the second 2 by setting RTL9300_I2C_MST1_CTRL2_MEM_ADDR_WIDTH and RTL9300_I2C_MST1_CTRL1_MEM_ADDR to 0. In principle it would allow to send an up to 3 bytes long memory/register address to an EEPROM or much more likely another RTL SoC to read/write from.
I use only the Read/Write commands and map this to rtl9300_i2c_master_xfer. In order to make upper layers handle the 16 byte length limitation I set these as quirks, which makes e.g. the sfp kernel module do queries of 16 bytes each to read the SFP eeprom.
I was not able to actually see how the transfers look on a scope. Frankly I was very lucky to get it working. I had a lot of difficulty understanding what this MEM_ADDR is doing as this is absolutely different from how I2C controllers usually work and did a lucky guess that it would also work with 0 as width, because at the level of rtl9300_i2c_master_xfer there is no way to get this out of the message data.
1 Like
This sounds quite exotic. The I2C framework has some support for multiple masters for the same bus (I2C demux), and multiple busses for the one master (I2C mux), but I'm not sure they would be easy to cascade, or how that would behave. It would be cool if the could be used in a round-robin fashion, to provide access to up to two devices at the same time.
For the SDA/SCL function selection, you would need to use the pinctrl framework. I might even be possible that contructing a bus muxer wouldn't be too hard then.
To me it appears that all SDA pins can be configured as open-drain (but you have the hardware to test, off course). The I2C_OPEN_DRN_SDA_7_0 field is 8 bits wide, and the name also has the 7-0 range.
You are absolutely right. I did not see the size of the field.
BTW: The USW switch has 2 GPIO PCA9555a expander chips which connect to the SFP signals such as TX_Off/LOS. They sit on an I2C bus with shared SCL (of course) and the PCA9555 is supported by the gpio-pca953x driver 
Now I have to make the I2C driver pick up stuff from the .dts. Then I will search the 16 possible I2C busses for the PCA chips.
Yes it looks like it. The Ubiquity device has a module ominously called rtl9300-i2c-mux which probably does the complex mux/demuxing. The key would be to have a pin-muxer and then use the i2c-pinmux muxer to get the many busses set up. But frankly I am getting a headache already looking at the user side of pinmuxes, I am not the right one to write a kernel module for the 9300.
I believe you have an XGS1210, or? That one has 2 SFP modules which are also muxed via SCL 8/SDA9 and SCL8/SDA10. Would you give that a try?
I have an XGS1250-12, which only has one SFP+ port. It is connected to GPIO 8 (SCK) and 10 (SDA), so it could be used with the I2C periperhal, but I won't be able to test the bus muxing.
2 Likes
I decided to write an rtl9300-specific i2c muxer:
which allows to access all the USW-switch I2C SFPs and PCA9555a GPIO expanders:
There are issues however with the PCA9555. I2C writes are not always successful. Now that I know that I can get SDA/SCK from certain PCA pins, I will try to debug the I2C bus with a logic analyzer, there are some unexplored register bits in the I2C master of the rtl9300 which might be useful. Alternatively it might be necessary to implement an SMBus interface, the RTL9300 hardware seems to be more suitable for that.
Hi,
yesterday I rebuilt OpenWRT for the ZyXEL GS1900-48 based on latest the merge_pie branch (+ DTS from xgs1250, and a few fixes that we discussed earlier). But I (still) have the problem that tagged VLAN traffic does not pass through the switch (it works fine on the stock firmware). Here is my /etc/config/network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdc2:9df4:8a19::/48'
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr '58:8b:f3:fe:05:d5'
config bridge-vlan 'lan_vlan'
option device 'switch'
option vlan '1'
option ports 'lan01 lan02 lan03 lan04 lan05 lan06 lan07 lan08 lan09 lan10 lan11 lan12 lan13 lan14 lan15 lan16 lan17 lan18 lan19 lan20 lan21 lan22 lan23 lan24 lan25 lan26 lan27 lan28 lan29 lan30 lan31 lan32 lan33 lan34 lan35 lan36 lan37 lan38 lan39 lan40 lan41 lan42 lan43 lan44 lan45 lan46 lan47 lan48 lan49 lan50'
config bridge-vlan 'dsl_vlan'
option device 'switch'
option vlan '7'
option ports 'lan01:t lan02:t lan03:t lan04:t lan05:t lan06:t lan07:t lan08:t lan09:t lan10:t lan11:t lan12:t lan13:t lan14:t lan15:t lan16:t lan17:t lan18:t lan19:t lan20:t lan21:t lan22:t lan23:t lan24:t lan25:t lan26:t lan27:t lan28:t lan29:t lan30:t lan31:t lan32:t lan33:t lan34:t lan35:t lan36:t lan37:t lan38:t lan39:t lan40:t lan41:t lan42:t lan43:t lan44:t lan45:t lan46:t lan47:t lan48:t lan49:t lan50:t'
config device
option name 'switch.1'
option macaddr '58:8b:f3:fe:05:d5'
#config device
# option name 'switch.7'
# option macaddr '5a:8b:f3:fe:05:d5'
config interface 'lan'
option device 'switch.1'
option proto 'static'
option ipaddr '192.168.2.17'
option netmask '255.255.255.0'
option gateway '192.168.2.11'
option dns '192.168.2.60'
option ip6assign '60'
#config interface 'dsl'
# option device 'switch.7'
# option proto 'static'
# option ipaddr '192.168.7.17'
# option netmask '255.255.255.0'
# option ip6assign '60'
I need VLAN 7 for PPPoE. When I add an interface to that VLAN, I can ping IPs in that VLAN from the switch and vice versa. But two hosts connected to the switch cannot communicate with each other on the tagged VLAN (the untagged default VLAN works fine).
Output of bridge vlan:
port vlan-id
lan01 1 PVID Egress Untagged
7
lan02 1 PVID Egress Untagged
7
lan03 1 PVID Egress Untagged
7
lan04 1 PVID Egress Untagged
7
lan05 1 PVID Egress Untagged
7
lan06 1 PVID Egress Untagged
7
lan07 1 PVID Egress Untagged
7
lan08 1 PVID Egress Untagged
7
lan09 1 PVID Egress Untagged
7
lan10 1 PVID Egress Untagged
7
lan11 1 PVID Egress Untagged
7
lan12 1 PVID Egress Untagged
7
lan13 1 PVID Egress Untagged
7
lan14 1 PVID Egress Untagged
7
lan15 1 PVID Egress Untagged
7
lan16 1 PVID Egress Untagged
7
lan17 1 PVID Egress Untagged
7
lan18 1 PVID Egress Untagged
7
lan19 1 PVID Egress Untagged
7
lan20 1 PVID Egress Untagged
7
lan21 1 PVID Egress Untagged
7
lan22 1 PVID Egress Untagged
7
lan23 1 PVID Egress Untagged
7
lan24 1 PVID Egress Untagged
7
lan25 1 PVID Egress Untagged
7
lan26 1 PVID Egress Untagged
7
lan27 1 PVID Egress Untagged
7
lan28 1 PVID Egress Untagged
7
lan29 1 PVID Egress Untagged
7
lan30 1 PVID Egress Untagged
7
lan31 1 PVID Egress Untagged
7
lan32 1 PVID Egress Untagged
7
lan33 1 PVID Egress Untagged
7
lan34 1 PVID Egress Untagged
7
lan35 1 PVID Egress Untagged
7
lan36 1 PVID Egress Untagged
7
lan37 1 PVID Egress Untagged
7
lan38 1 PVID Egress Untagged
7
lan39 1 PVID Egress Untagged
7
lan40 1 PVID Egress Untagged
7
lan41 1 PVID Egress Untagged
7
lan42 1 PVID Egress Untagged
7
lan43 1 PVID Egress Untagged
7
lan44 1 PVID Egress Untagged
7
lan45 1 PVID Egress Untagged
7
lan46 1 PVID Egress Untagged
7
lan47 1 PVID Egress Untagged
7
lan48 1 PVID Egress Untagged
7
lan49 1 PVID Egress Untagged
7
lan50 1 PVID Egress Untagged
7
switch 1
7
The network config looks right, doesn't it? And the VLANs look like they are being configured correctly.