It’s so cool seeing you make progress @ddejean 
I know that you don’t got the POE version, but I found this conversation:
How realistic is it to get POE working? I saw that we don’t have any datasheets for the RTL8239 POE chip.
It’s realistic until we’ve tried and failed. Then it’s possible 
According to this, realtek-poe now supports the GS1900-24EP:
That switch has two RTL8238 controllers behind a Nuvoton NUC029ZAN microcontroller:
It’s reasonable to assume that the RTL8238 and RTL8239 are similar enough that you can ignore the differences for a start.
But the GS1900-24EP design is like most of these realtek PoE switches, where you talk to the microcontroller frontend and not directly to the PSE controllers. Is the XMG1915-EP similar?
If it is, then I believe it’s likely using a variant of the protocol implemented by realtek-poe, over either UART or I2C.
EDIT: I see on https://svanheule.net/switches/xmg1915-10ep that it indeed includes a Nuvoton NUC029ZAN. Maybe it just works with the latest realtek-poe release?
2 Likes
Sure.
But I’m a bit confused wrt which logic hole to stay in, given your proposal to add a callback just a few weeks after this:
Status: I now have the two PHYs working correctly, I rebased my code and an updated branch is available here. I already have a few patches to submit to add the serdes mapping (as we discussed earlier) and the support for 10g-qxgmii. Coming soon 
However I still observe something strange. When the switch boots, the port 1 is directly initialized:
[ 8.960585] RESETTING 9300, CPU_PORT 28
[ 9.165455] rtl838x-eth 1b00a300.ethernet eth0: configuring for fixed/internal link mode
[ 9.174499] In rtl838x_mac_config, mode 1
[ 9.179889] rtl83xx-switch switch@1b000000 lan1: configuring for phy/10g-qxgmii link mode
[ 9.189095] rtl93xx_phylink_mac_config SDS is 2
[ 9.194150] rtl9300_sds_set 31
[ 9.302953] rtl9300_phy_enable_10g_1g 1gbit phy: 00001140
[ 9.310034] rtl9300_phy_enable_10g_1g 1gbit phy enabled: 00001140
[ 9.317826] rtl9300_phy_enable_10g_1g 10gbit phy: 00002040
[ 9.324987] rtl9300_phy_enable_10g_1g 10gbit phy after: 00002040
[ 9.332740] rtl9300_phy_enable_10g_1g set medium: 00000000
[ 9.339930] rtl9300_phy_enable_10g_1g set medium after: 00000002
[ 9.366720] rtl9300_serdes_setup: Configuring RTL9300 SERDES 2
[... calibration sequence for serdes 2 here ...]
[ 10.104716] realtek-otto-pcs 1b000000.switchcore:pcs: pcs_config(10g-qxgmii) for port 0 and sds 2 not yet fully implemented
[ 10.119913] 8021q: adding VLAN 0 to HW filter on device lan1
[ 10.126511] rtl838x-eth 1b00a300.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 10.148814] rtl83xx-switch switch@1b000000: add IPv4 route 192.168.1.1/32 (VLAN 0, MAC 80:94:e2:7c:80:00)
[ 10.159980] rtl83xx-switch switch@1b000000: lower interface lan1 not found
[ 10.167652] rtl83xx-switch switch@1b000000: fib_add() failed
[ 10.174167] rtl83xx-switch switch@1b000000: add IPv4 route 192.168.1.255/32 (VLAN 0, MAC 80:94:e2:7c:80:00)
[ 10.185294] rtl83xx-switch switch@1b000000: skip loopback/broadcast addresses and default routes
[ 10.196062] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 10.203824] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 10.212083] rtl83xx-switch switch@1b000000: add IPv4 route 192.168.1.0/24 (VLAN 0, MAC 80:94:e2:7c:80:00)
[ 10.223042] rtl83xx-switch switch@1b000000: lower interface lan1 not found
[ 10.230992] rtl83xx-switch switch@1b000000: fib_add() failed
[ 11.728673] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 14.379010] rtl83xx-switch switch@1b000000: delete IPv4 route 192.168.1.0/24 (VLAN 0, MAC 80:94:e2:7c:80:00)
[ 14.390166] rtl83xx-switch switch@1b000000: no such gateway: 0.0.0.0
[ 14.397261] rtl83xx-switch switch@1b000000: fib_del() failed
[ 14.403930] rtl83xx-switch switch@1b000000: delete IPv4 route 192.168.1.255/32 (VLAN 0, MAC 80:94:e2:7c:80:00)
[ 14.415280] rtl83xx-switch switch@1b000000: skip loopback/broadcast addresses and default routes
[ 14.425844] rtl83xx-switch switch@1b000000: delete IPv4 route 192.168.1.1/32 (VLAN 0, MAC 80:94:e2:7c:80:00)
[ 14.437064] rtl83xx-switch switch@1b000000: no such gateway: 0.0.0.0
[ 14.440513] procd: - early -
[ 14.444300] rtl83xx-switch switch@1b000000: fib_del() failed
[ 14.447831] procd: - watchdog -
[ 15.085477] procd: - watchdog -
[ 15.089638] procd: - ubus -
[ 15.151952] procd: - init -
[ 15.829595] kmodloader: loading kernel modules from /etc/modules.d/*
[ 15.937356] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 17.263448] urngd: v1.0.2 started.
[ 20.264059] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
Then the phy connected to serdes 2 is working, it transmits traffic and so on, but it can't communicate with the other part of the switch (the other phy, and the two SFP ports). And after a long while, the rest of the configuration is restarted somehow:
[ 74.593027] RESETTING 9300, CPU_PORT 28
[ 74.836861] rtl838x-eth 1b00a300.ethernet eth0: configuring for fixed/internal link mode
[ 74.845952] In rtl838x_mac_config, mode 1
[ 74.851363] rtl838x-eth 1b00a300.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 74.860956] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 74.868431] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 74.896632] rtl83xx-switch switch@1b000000 lan1: configuring for phy/10g-qxgmii link mode
[ 74.906047] rtl93xx_phylink_mac_config SDS is 2
[ 74.911348] rtl9300_sds_set 31
[ 75.041944] rtl9300_phy_enable_10g_1g 1gbit phy: 00000140
[ 75.049187] rtl9300_phy_enable_10g_1g 1gbit phy enabled: 00000140
[ 75.056998] rtl9300_phy_enable_10g_1g 10gbit phy: 00002040
[ 75.064305] rtl9300_phy_enable_10g_1g 10gbit phy after: 00002040
[ 75.072166] rtl9300_phy_enable_10g_1g set medium: 00000002
[ 75.079454] rtl9300_phy_enable_10g_1g set medium after: 00000002
[ 75.106416] rtl9300_serdes_setup: Configuring RTL9300 SERDES 2
It this a normal behavior ? Does anyone know what could happen ?
4 Likes
yes, that’s normal. lan1 is configured for failsafe mode early
2 Likes
Would be great if you manage to add this soon (but no hurry). Then I can wait with my next PR for PHY ←→ PCS changes to include this as well so we don’t have conflicts.
2 Likes
Great work! Eyeing the PoE flavour... Getting very tempting.
yes, that’s normal. lan1 is configured for failsafe mode early
Makes sense, however I wonder why there's almost a minute with almost nothing happening (in the traces) before the second initialization begins?
Until now I haven't observed otherwise on my GS1900, XGS1210 and XGS1250 hardware. It's definitely not an anomaly at this point.
If you are testing using an initramfs image, it might be due to the dropbear init script generating SSH keys.
From what I’ve seen, this is all triggered by userspace and various factors may delay this. As mentioned, the failsafe mode initializes the first port. The second initialization stage is then triggered when all networking is brought up by userspace (i.e. netifd transitioning interfaces to UP).
Working on different devices, the delay differs quite a lot depending on various factors. As Jan mentioned, the dropbear init script may delay this. I regularly see the second initialization being delayed quite a lot after a sysupgrade because JFFS2 does quite some stuff in that case. In general I guess it depends on what runs before netifd actually brings up the whole networking.
I’m not 100% sure but somewhat confident.
1 Like
@ddejean I'm not sure I'm fully understanding, but does this commit mean half of the XMG1915-10EP Ethernet ports are unusable again?