XGSPON SFP occasionally won't power up properly and no link detected

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

I have the [X-ONU-SFPP (SFP+ XGSPON ONU Stick) - PON dot WIKI](https://X-ONU-SFPP SFP+ XGSPON ONU) SFP+ stick plugged into the SFP+ cage on the BPI-R4. When powering on the BPI-R4, chances are that the stick won’t boot properly (even though it’s recognized in Linux) and it stays in disabled state with no link detected, and I need to unplug and re-plug the SFP+ stick in order for it to work properly.

Logs from a boot where it works:

[   13.763775] br-wan: port 2(eth2) entered forwarding state
[   13.755137] br-wan: port 2(eth2) entered blocking state
[   13.750166] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 10Gbps/Full - flow control off
[   13.662742] mtk_soc_eth 15100000.ethernet eth2: entered promiscuous mode
[   13.655734] mtk_soc_eth 15100000.ethernet eth2: entered allmulticast mode
[   13.650470] br-wan: port 2(eth2) entered disabled state
[   13.645164] br-wan: port 2(eth2) entered blocking state
[   13.621630] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
[   13.604193] mt7530-mmio 15020000.switch wan: entered promiscuous mode
[   13.597365] mt7530-mmio 15020000.switch wan: entered allmulticast mode
[   13.592167] br-wan: port 1(wan) entered disabled state
[   13.586964] br-wan: port 1(wan) entered blocking state
[   13.577675] mt7530-mmio 15020000.switch wan: configuring for phy/internal link mode
[   11.628969] mtk_soc_eth 15100000.ethernet eth2: switched to inband/10gbase-r link mode
[   11.619509] sfp sfp1: module OEM              XGSPONST2001     rev A-01 sn 092142509000169  dc 250902

and ethtool reports Link detected: yes.

Versus when it doesn’t work correctly:

[   14.047996] mtk_soc_eth 15100000.ethernet eth2: entered promiscuous mode
[   14.041064] mtk_soc_eth 15100000.ethernet eth2: entered allmulticast mode
[   14.035778] br-wan: port 2(eth2) entered disabled state
[   14.030534] br-wan: port 2(eth2) entered blocking state
[   13.998130] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
[   13.987976] mt7530-mmio 15020000.switch wan: entered promiscuous mode
[   13.981203] mt7530-mmio 15020000.switch wan: entered allmulticast mode
[   13.975979] br-wan: port 1(wan) entered disabled state
[   13.970796] br-wan: port 1(wan) entered blocking state
[   13.962010] mt7530-mmio 15020000.switch wan: configuring for phy/internal link mode
[   11.669379] mtk_soc_eth 15100000.ethernet eth2: switched to inband/10gbase-r link mode
[   11.659856] sfp sfp1: module OEM              XGSPONST2001     rev A-01 sn 092142509000169  dc 250902

and ethtool reports Link detected: no. When I hot plug it the link comes up almost immediately (so it doesn’t need to wait for the stick to boot to recognize that).

I have patched the kernel with the long startup quirk and to ignore TX_FAULT (shares serial console pin).

root@hostname:~# ubus call system board
{
	"kernel": "6.6.119",
	"hostname": "hostname",
	"system": "ARMv8 Processor rev 0",
	"model": "Bananapi BPI-R4",
	"board_name": "bananapi,bpi-r4",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.5",
		"revision": "r29087-d9c5716d1d",
		"target": "mediatek/filogic",
		"description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
		"builddate": "1766005702"
	}
}

Thanks

2

Did you solve the issue? I’m considering buying the Banana Pi BPI-R4 for this exact purpose.

3

No, and I don’t really have any ideas on how to troubleshoot this. Might see if I can access the serial console on the TX_FAULT pin while its in the SFP cage to see if it has any useful information, or take a multimeter to the SFP power pins (but the light is on so…?), but the easier solution will probably just be getting a UPS so the BPI-R4 doesn’t go down at all during outages.

4

I ran into the same XGS-PON SFP problem on a Banana Pi BPI-R4 running OpenWrt 25.12.5 / Linux 6.12.94.

My module identifies as:

OEM XGSPONST2001
rev A-01

With the stock sfp.ko, the BPI-R4 repeatedly reported:

sfp sfp1: module transmit fault indicated
sfp sfp1: module transmit fault recovered
sfp sfp1: module transmit fault indicated
...
sfp sfp1: module persistently indicates fault, disabling

sfp-wan was then left down.

I found that this is addressed by the upstream Linux SFP quirk for OEM XGSPONST2001. The fix adds prefix matching for the EEPROM part number and applies the existing Potron fixup, which ignores the broken TX_FAULT/LOS signals and uses the longer startup handling.

I backported those upstream changes to the OpenWrt 25.12.5 / 6.12.94 kernel and built a drop-in sfp.ko.

With the patched module loaded, my BPI-R4 reported:

mtk_soc_eth 15100000.ethernet sfp-wan: Link is Up - 10Gbps/Full

and the TX_FAULT shutdown loop stopped occurring. The patched module also survived a reboot.

I’ve documented the build process and provided the tested module here:

The binary is specifically for OpenWrt 25.12.5 / Linux 6.12.94 on a BPI-R4, so other kernel versions should rebuild using the included patches rather than assuming binary compatibility.

Hopefully this saves someone else from going down the rabbit hole I did.