i2cdetect -y <bus-nr-found>
Should only show devices with the module inserted and empty when module removed.
This depends on which driver is loaded first…afaik both are builtin so you have no chance to change this order.
Is there some command which may reveal something useful about the module state when booting a 6.1 kernel?
You need to go back to the electrical diagram.
-y 3 will match SFP1 or ETH2
-y 4 will match SFP2 or ETH1
I got a LuLeey SFP XPON stick (LL-XS2510) and while it is being detected at boot, I can’t seem to access its local web interface.
It is based on the Realtek RTL9601D chipset which is analyzed a bit more here: ODI Realtek DFP-34X-2C2 | Hack GPON (hack-gpon.org)
I tried going through the steps described in various forums that I need to set my local IP to something different, like 192.168.1.2, because the interface itself uses 192.168.1.1 for web and ssh access. But even with disabled firewall, routing set up and everything I couldn’t connect to the stick, so I assume the physical network connection is not working properly.
According to the spec it has a HSGMII interface, but I don’t know what that means in terms of drivers or whatever I need to add to OpenWrt. Maybe a patch to the kernel or load a module?
As you can see from the additional information, I unfortunately don’t have the fiber connection set up yet, as my ISP hasn’t provided it. So, I can’t test if that connection is working. I’m just assuming, if I can’t access the web interface, then I also wouldn’t be able to use the fiber connection.
Anyone can help me out here?
Here is some more data about my system in the hopes it helps debug the issue.
ubus call system board
{
"kernel": "6.1.82",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 0",
"model": "Bananapi BPI-R4",
"board_name": "bananapi,bpi-r4",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r25736-d1eb0bec39",
"target": "mediatek/filogic",
"description": "OpenWrt SNAPSHOT r25736-d1eb0bec39"
}
}
dmesg |grep sfp
[ 9.130662] sfp sfp1: Host maximum power 3.0W
[ 9.135489] sfp sfp2: Host maximum power 3.0W
[ 9.459003] sfp sfp2: module OEM XPON-Stick rev sn XPON23111101 dc 231127
dmesg |grep eth1
[ 4.725229] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc00a500000, irq 103
[ 9.468465] mtk_soc_eth 15100000.ethernet eth1: switched to inband/1000base-x link mode
[ 10.494261] device eth1 entered promiscuous mode
[ 10.499379] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
[ 10.513704] br-lan: port 1(eth1) entered blocking state
[ 10.518991] br-lan: port 1(eth1) entered disabled state
ethtool -m eth1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x00 0x00 0x00 0x02 0x22 0x00 0x01 0x00 0x00
Transceiver type : Ethernet: 1000BASE-LX
Transceiver type : FC: intermediate distance (I)
Transceiver type : FC: Longwave laser (LC)
Transceiver type : FC: Single Mode (SM)
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 20km
Length (SMF) : 20000m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1310nm
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : XPON-Stick
Vendor rev :
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : XPON23111101
Date code : 231127
lsmod
aquantia 28672 0
at24 20480 0
authenc 16384 2 crypto_safexcel,authencesn
authencesn 16384 0
cfg80211 307200 5 mt7996e,mt7915e,mt76_connac_lib,mt76,mac80211
compat 16384 2 mac80211,cfg80211
crypto_safexcel 122880 0
des_generic 16384 0
gpio_button_hotplug 16384 0
i2c_mux 16384 1 i2c_mux_pca954x
i2c_mux_pca954x 16384 0
leds_gpio 16384 0
libcrc32c 16384 1 nf_tables
libdes 24576 2 crypto_safexcel,des_generic
mac80211 589824 4 mt7996e,mt7915e,mt76_connac_lib,mt76
md5 16384 1 crypto_safexcel
mdio_i2c 16384 1 sfp
mt76 77824 3 mt7996e,mt7915e,mt76_connac_lib
mt76_connac_lib 53248 2 mt7996e,mt7915e
mt7915e 147456 0
mt7996e 122880 0
nf_conntrack 90112 7 nft_redir,nft_nat,nft_masq,nft_flow_offload,nft_ct,nf_nat,nf_flow_table
nf_defrag_ipv4 16384 1 nf_conntrack
nf_defrag_ipv6 20480 1 nf_conntrack
nf_flow_table 32768 2 nf_flow_table_inet,nft_flow_offload
nf_flow_table_inet 16384 0
nf_log_syslog 20480 0
nf_nat 40960 4 nft_redir,nft_nat,nft_masq,nft_chain_nat
nf_reject_ipv4 16384 2 nft_reject_ipv4,nft_reject_inet
nf_reject_ipv6 16384 2 nft_reject_ipv6,nft_reject_inet
nf_tables 176128 21 nft_fib_inet,nf_flow_table_inet,nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet,nft_reject,nft_redir,nft_quota,nft_objref,nft_numgen,nft_nat,nft_masq,nft_log,nft_limit,nft_hash,nft_flow_offload,nft_fib_ipv6,nft_fib_ipv4,nft_fib,nft_ct,nft_chain_nat
nfnetlink 20480 1 nf_tables
nft_chain_nat 16384 0
nft_ct 20480 0
nft_fib 16384 3 nft_fib_inet,nft_fib_ipv6,nft_fib_ipv4
nft_fib_inet 16384 0
nft_fib_ipv4 16384 1 nft_fib_inet
nft_fib_ipv6 16384 1 nft_fib_inet
nft_flow_offload 16384 0
nft_hash 16384 0
nft_limit 16384 0
nft_log 16384 0
nft_masq 16384 0
nft_nat 16384 0
nft_numgen 16384 0
nft_objref 16384 0
nft_quota 16384 0
nft_redir 16384 0
nft_reject 16384 3 nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet
nft_reject_inet 16384 0
nft_reject_ipv4 16384 0
nft_reject_ipv6 16384 0
nvme 40960 0
nvme_core 69632 1 nvme
ppp_async 24576 0
ppp_generic 45056 3 pppoe,ppp_async,pppox
pppoe 24576 0
pppox 20480 1 pppoe
pwm_fan 16384 0
rtc_pcf8563 20480 0
seqiv 16384 0
sfp 32768 0
sha1_ce 16384 0
sha1_generic 16384 2 crypto_safexcel,sha1_ce
sha512_arm64 20480 0
slhc 16384 1 ppp_generic
usb_common 16384 3 xhci_plat_hcd,xhci_hcd,usbcore
usbcore 196608 4 xhci_plat_hcd,xhci_pci,xhci_mtk_hcd,xhci_hcd
xhci_hcd 143360 3 xhci_plat_hcd,xhci_pci,xhci_mtk_hcd
xhci_mtk_hcd 24576 0
xhci_pci 20480 0
xhci_plat_hcd 16384 0
Have you tried to access the web-ui when the sfp gets link? This seems to be a common issue with the gpon sfps
What do you mean with “gets link”? If you mean have a fiber cable connected, then I can’t do that right now, because I don’t have the cable yet, nor the port from my ISP to connect the other end to.
Hi,
I have been looking at the SFP code in the Linux kernel. I have a bunch of SFP / SFP+ from fs.com. Any SFP / SFP+ connected to a fibre cable will not support any form of negotiation, so I think a reasonable default for SFP / SFP+ is to have auto-negotiation disabled. Similarly, if one has an SFP / SFP+ RJ45 Ethernet, it works fine if auto-negotiation is disabled, because it only affects the SERDES side, the PHY-cable side still does its own auto-negotiation. So, this would seem to suggest that the best default for all SFP / SFP+ is to have auto-negotiation disabled. Then, we could have some C22/C45/ROLLBALL detection code, and if the SFP / SFP+ supports any of those, then we can switch auto-negotiation on as needed.
The point I am trying to make is that I think auto-negotiation should default of off for SFP / SFP+ interfaces.
Yes this is what i mean…there was a workaround by defining another (unrelated) gpio for sfp slot,but i do not remember which one has to be changed
Hi,
Here is the sfp patch that I find fixes most SFP / SFP+ in the BPI-R4. It defaults all SFPs to autoneg off, instead of autoneg on.
sfp-fix.diff.txt (407 Bytes)
The LOS (loss of signal) didn’t go low until there was a good connection on fibre side Therefore phylink did not see it as a link that is up.
So in that particular case, we simulated the los signal, by changing it to another gpio pin, one of the gpio-header, which can easily be modified high/low.
Hi,
To test link up, just do a fibre loopback. Take a single fibre and loop it back from the TX to the RX, assuming you are testing a number duplex fibre link. If you are testing a different sort of SFP+ transceiver, there are different ways to test it without the other end working.
Be careful when looping…if tx level is larger than rx can handle you can break receiver
HSGMII is a vendor-specific non-standard way to “overclock” SGMII to that it can be used for data rates up to 2500MBit/s. Normal (and standardized) SGMII only supports up to 10M/100M/1000M, half-duplex and full-duplex. The problem is that HSGMII is not defined by any standard, so every vendor does it a bit different. When it comes to those xPON SFP modules, typically what it means is actually just 2500Base-X as there is no need to negotiated lower speeds (ie. the connection between the host and the xPON module will always be 2500MBit/s and both ends will signal bandwidth bottlenecks using flow-control instead of being able to negotiated a lower speed like with “real” SGMII or even RealTek HSGMII when used to connect 2500Base-T PHYs which of course also support 10M/100M/1000M speeds).
Now when it comes to that xPON module you’ve shown the EEPROM data and it (unfortunately) wrongly states to be
So that means 1000Base-X in 10/8 PCS coding. As many modules EEPROM report wrong speeds, you can add a quirk to the SFP driver to make it assume the module uses 2500Base-X even though it is reporting the speed wrongly. So that one is easy to solve – however, as one cannot easily know the configured speed of the module, we currently don’t have a way to do this in a “clean” way, ie. without breaking support for the very same module on host boards which only support up to 1000MBit/s speed.
And there also is another problem: This module only reports a link to Linux if there actually is a link on the xPON fiber interface. Ie. as long as no fiber is connected and no link is negotiated, you cannot even access the built-in Web-UI of the module. Also that can be worked-around, by ignoring both, the physical TX_FAULT pin as well as the TX_FAULT bit in the status field read over I2C.
1 Like
That’s not true. Those are merely transceivers. So if both ends support Clause-37 in-band-status, then AN will work. Nothing to do with the SFP module itself, but with the link partner supporting Clause-37 AN or not. If the link partner doesn’t support it, you got to switch it off on the local end as well. Simple as that.
Thank you again, Daniel, for this elaborate answer!
Since the underlying chip is a Realtek RTL9601D, I might be lucky and it is supported? On the other hand, my ISP provides me (hopefully soon) with a 500/100 connection, so the higher speeds aren’t even necessary. 1000M should be fine in that case.
These are also part of the SFP driver? I guess I will have to build my own OpenWrt then, or at least the kmod. 
RealTek HSGMII is a proprietary RealTek-specific non-standard which works if you are using only RealTek chips. It is used e.g. to connect RealTek RTL8221B 2.5G PHYs to RTL93xx switch SoCs.
As we are dealing with the BPi-R4 the host in our case is a MediaTek SoC. Luckily RealTek’s “HSGMII” is more of less compatible with standard 2500Base-X in case of those xPON which only use a fixed speed of 2500MBit/s. And, of course, we can just use 1000Base-X (RealTek and many of those xPON SFP vendors wrongly call that SGMII, but it is not the (originally Cisco) SGMII standard but rather just “a serialized gigabit media independent interface” not “THE serialized gigabit media independent interface”, so what they actually mean is 1000Base-X.
I know all that sounds confusing, and the cause for that confusion must be somewhere in the marketing departments (deliberately) misunderstanding the engineers working in the same company.
Yes, you will have to patch-out TX_FAULT from the sfp driver. Also that cannot go upstream as there actually is a bit in the EEPROM which can tell the OS that TX_FAULT is not implemented and should be ignore. However, in case of this module:
so the argument of ignoring it anyway won’t go down easy with upstream Linux maintainers…
@frank-w is correct. A loopback can break the receiver in some cases.
Of the SFP transceivers I have (yours might be different), all the ones that cover 10km or less can handle a loopback without an added attenuator inline.
Ones over 10km generally cannot handle loopback unless an attenuator is added to the line.
I’m not sure if your stick also has speed auto adaption implementation (and a dedicated EEPROM rather than simulated one) like ODI. For ODI stick(I’m using it), you need to modify stick’s eeprom to make kernel know it supports 2.5G. Check this:
Besides, for sticks using real eeprom(like ODI) rather than i2c simulated eeprom(like ma5671a), there is no path to do speed auto negotiation and Linux would only follow speed data in eeprom. Although firmware implementation on ODI’s stick has some kind of speed auto adaption, it is not a generic implementation so linux upstream doesn’t accept a quirk for that stick to fix at 2500basex mode. So you have to modify your eeprom to set to a larger speed rate.