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.
i have no shop-link, but right now i use this 1gbit sfp module and it works:
[ 12.538641] sfp sfp1: module OEM GLC-BX-U-C rev 1.0 sn 1152216730 dc 150602
You want to use one with a rtl8221b on it, behind rollball protocol. I’ve bought the one from the Luleey shop, it has one.
It was reported the BananaPi module is the same.
There are more sources of these modules, but be careful, you might get one with an yt8821 on it, which is not as well supported.
The TP-Link 2.5G module has a rtl8221b on it, but we have not figured out how to reach the phy.
The main difference is the rtl8221b we can control the phy through the kernel. So we can lower the connection speed between MAC and PHY, when the RJ45 is connected at 1000Mbps or lower. That saves quite a bit of power usage. And of course, you have more control over the negotiation and advertisement process.
The yt8821 module is stuck at the highest speed between MAC and PHY. From the kernel side, it is treated as an optical sfp, without any furher control over the connection on the RJ45.
Hi team, I’m seeing some real strange things on my two sfp ports.
I get this error regardless of the sfp+ module I insert
[ 3082.517577] sfp sfp2: Detected broken RTL8672/RTL9601C emulated EEPROM
[ 3082.524118] sfp sfp2: Switching to reading EEPROM to one byte at a time
[ 3082.574024] sfp sfp2: module rev sn dc
[ 3082.578201] sfp sfp2: module is not supported - phys id 0x00 0x00
I have tried Mikrotik S+RJ10, S+85DLC03D, Intel FTLX8571D3BCV-IT, and SFP-10G-T-CIS without any luck (All checked and working fine in multiple other equipment). I cant even debug them. Running 6.6 with all the PHY drivers selected
Any help would be amazing, even if you point out i’m an idiot and haven’t done something correctly
Maybe this 10G XGS-PON ONU SFP+ Stick work on the BPI-R3 and BPI-R4, because on Reddit, on Discord and on Ubiquiti forum have reported that it works (on other hardware but I think they are based on Linux).
You can buy it in group (organized on 8311 Discord) to get it cheaper.
It can be fully configured via the web interface and can also be configured via CLI commands.
.
I think these 2.5G GPON ONU SFP Sticks work on the BPI-R3 and BPI-R4, because here on the forum, on Reddit, on Discord, on Ubiquiti, on Turris and MikroTik forums have reported that they work (on other hardware but I think they are based on Linux).
The hardware in both is identical and they are from the same company, but only the “HSGQ” (newer model) receives firmware updates and already comes with the newer firmware.
The “ODI” and “HSGQ” GPON has an issue that only works at 1000baseX/Full on BPI-R3 and BPI-R4.
It can be fully configured via the web interface and can also be configured via CLI commands.
Rename the sfp.ko module ( example sfp.ko.bkp ). I use that way and it operates at 2500Mb/s. You will lose the diagnostics ( ethtoool -m eth1 on bpi-r3)
There are a misconfigured variable at the eeprom with a baud rate of 1300. That value is for aqn interface at 1.25Gb/s.
Well, i have this stick. And in BPI-R4 is not detected. I have checked this onu-stick in a Mikrotik switch, and it works there Also i have checked this in BPI-R3 and it sometimes work there and sometimes not.
Also i have checked this in BPI-R3 and it sometimes work there and sometimes not.