I am not very familiar with ont’s, but you also have settings in the ont. What it reports as ‘eeprom’ is not so static on these things.
What is exactly in the quirk that you point it to?
Which code and what does it set/clear?
The quirk is not a areal patch to the codeand I do not know how it works at low level. There is a place in drivers/net/phy/sfp.c file where you can declare vendor and part number of the module and to force 2500base-X. There is a list of the modules and the possible rules to be applied and the patch is consisting in adding to the list the above mentoned paramters for a new module. I did it and the module is working, but it seems regression is needed in order to besure that who is currently using the module without the quirk is not suffering problems when the quirk is applied. Hope this clarifies.
Which source do you use? There are many different versions. And what is the code in sfp_quirk_2500basex() in this source?
This is the surce in sfp.c in dev-next:
static void sfp_quirk_2500basex(const struct sfp_eeprom_id *id,
unsigned long *modes,
unsigned long *interfaces)
{
linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseX_Full_BIT, modes);
__set_bit(PHY_INTERFACE_MODE_2500BASEX, interfaces);
}
This is the code used for the quirk in BPI R3:
static void sfp_quirk_2500basex(const struct sfp_eeprom_id *id,
unsigned long *modes)
{
linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseX_Full_BIT, modes);
}
They seems to be same code
Then doesn’t the ont have a config option to set it to reporting 2500 speed capability?
That is the only thing the quirk does.
FIBER_MODEoption forced 1g?
Carefully may lock you out…
The module has a config option to be used for forcing at 2500, but still the EEPROM is not reporting the rigth speed and, as far as I know, Linux is not negotiating 2500. on the contrary using the quirk, I do not know why the modle is running at 2500 even if the module is configured for 1000. This is it. I suppose the quirk forces 2500 even if the EEPROM is not reporting the 2500 speed. I do not think it is only for fiber. The quirk is also used tor some copper sfp not running in FIBER MODE.
Hello, need R3 compatible optical module for connection with TP-Link 1Gb WDM SC 1550/1310nm media converter. Can anyone confirm whether these work?
I haven’t tested this specific module but as it is a simple 1000MBit/s optical module chances for it to work just fine are around 99%.
1 Like
Hi, I have something similar, that report itself as “OEM SFP-GE-T”, doing the loop:
mt7530-mdio mdio-bus:1f sfp2: Link is Up - 1Gbps/Full - flow control off
br-lan: port 5(sfp2) entered blocking state
br-lan: port 5(sfp2) entered forwarding state
mt7530-mdio mdio-bus:1f sfp2: Link is Down
br-lan: port 5(sfp2) entered disabled state
mt7530-mdio mdio-bus:1f sfp2: Link is Up - 1Gbps/Full - flow control off
any thought how it can be fixed?
upd: looks like on BPI R4 something similar works FYI: This $10 1000Base-T SFP Transceiver works with the BPi-R4
upd2: looks like there is patch already done by @dangowrt https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
I i understand correctly it will be integrated into next OpenWRT stable release
For my BPI-R3 I now gave H!Fiber ASF-GE-T-Cisco-2pcs-HF(EU) a try.
But unfortunately with no success.
I run 6.12-main (and also tried others) from Franks Repo BPI-Router-Linux. Thanks for providing this.
Both SFPs RJ45 (originally named lan4 and eth1) are connected to a Gbit/s Switch to test 1000BASE-T.
After
ifup lan4
or
ifup eth1
respectively the Gbit/s Switch LEDs light up and indicate a link.
But the logging says:
Dec 20 08:18:18 kernel: [ 7320.940397] mt7530-mdio mdio-bus:1f lan4: configuring for inband/2500base-x link mode
Dec 20 08:18:19 kernel: [ 7321.013900] mt7530-mdio mdio-bus:1f lan4: validation with support 00,00000000,00000000,00000000 failed: -EINVAL
Dec 20 08:18:19 kernel: [ 7321.024254] sfp sfp-2: sfp_add_phy failed: -EINVAL
Dec 20 08:24:08 kernel: [ 7670.058393] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode
Dec 20 08:24:08 kernel: [ 7670.138427] mtk_soc_eth 15100000.ethernet eth1: validation with support 00,00000000,00000000,00000000 failed: -EINVAL
Dec 20 08:24:08 kernel: [ 7670.149271] sfp sfp-1: sfp_add_phy failed: -EINVAL
# ethtool eth1
Settings for eth1:
Supported ports: [ MII ]
Supported link modes: 2500baseX/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: off
Port: MII
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
# ethtool -m eth1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x00 (unknown or unspecified)
Transceiver codes : 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x00
Transceiver type : Ethernet: 1000BASE-T
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 100m
Length (OM3) : 0m
Laser wavelength : 0nm
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : SFP-GE-T
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 : CSGE2K3K403
Date code : 24052501
# dmesg | egrep -i sfp
[ 1.865361] sfp sfp-2: module OEM SFP-GE-T rev sn CSGE2303947 dc 24052501
[ 1.904782] sfp sfp-1: module OEM SFP-GE-T rev sn CSGE2K3K403 dc 24052501
[ 23.407285] sfp sfp-2: sfp_add_phy failed: -EINVAL
[ 23.447733] sfp sfp-1: sfp_add_phy failed: -EINVAL
In ‘drivers/net/phy/sfp.c’ I see
// OEM SFP-GE-T is a 1000Base-T module with broken TX_FAULT indicator
SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
exists.
Is there a known way (special kernel version, patches etc.) to get SFP-GE-T working with 1000BASE-T?
Are there other brand SFPs around with better support for 1000BASE-T to work in a BPI-R3?
For the h!fibre i needed no quirk/fixup,it worked out-of-the-box…seems there is something broken now.
Seems your mac is forced to 2500-base…and not allowong the 1g mode
ok, but as I’ve seen you use an optical medium (no copper as I do). Maybe this has an impact too on the issue.
What kernel version/patches do you use? I could give this a try…
Ah,right,i use optical one,possibly that eeprom differs
after the big disappointment with cheap H!Fiber ASF-GE-T-Cisco-2pcs-HF(EU) SFPs I have now tested with (not so cheap):
10Gtek ASF-2G2-T+(OEM-EU)
What can i say? It’s awesome!
The first 1000BASE-T Copper RJ45 SFP Transceiver I know of that just works in a BPI-R3 
On Debian + Kernel e.g. 6.12.0-bpi-r3-main.
I can tell you what’s broken:
You forgot to include
<M> Marvell Alaska PHYs
<M> Marvell Alaska 10Gbit PHYs
<M> Marvell 88Q2XXX PHY
<M> Marvell 88X2222 PHY
drivers in your .config. After doing that now even H!Fiber ASF-GE-T-Cisco-2pcs-HF(EU) SFPs work with 1000BASE-T Copper RJ45
thanks to @bruzzin for hinting me the missing drivers
Ok,when the sfp has a phy (seems often for copper sfp,but unlikely for fibre) a driver is maybe needed.
ok, you could consider to include SFP related phy drivers in your build since it is essential for a BPI-R3 based “router”. The overhead to build such additional modules is minimal…
Which one do you need? I try to keep the defconfig as small as possible to reduce compile time (also for pipeline).
Thinking about an additional options for full builds which are appended to the minimal defconfig,but had no good idea how to do it exactly.
1 Like
to support H!Fiber ASF-GE-T-Cisco-2pcs-HF(EU) with 1000BASE-T Copper RJ45 it’s sufficient to set
CONFIG_MARVELL_PHY=m
1 Like
Added to r3/r4 defconfigs
and added function+files to 6.13-rc to append defconfig
1 Like