Not sure about shorting a pin on gnd,but it is noted as maybe required in readme. See the link there.
I do not think firmware helps here as this seems to be an electrical issue.
thanks for the fast reply, are there any changes to the drivers on the bpi that i can do?
The only thing that can help in software is a patch delay the sfp a bit…there are some ont sfp that use this. But if the grounding of pin 6 is needed sw patches will not help.
I’m trying to find a way to do a patch, specifically to ignore the eeprom check, how can i do that? I’ve installed this image: bpi-r4_bookworm_6.11.0-main.img.gz
where can i find the source of it? cause I’ve found this: GitHub - frank-w/BPI-Router-Linux at 6.11-main but this is a general linux, not necessarily the bpi r4 one, how can i get to the source?
I started adding changes for r4 in my main branches with 6.10 afaik (and building these kernels with ci pipeline),so 6.11-main is the right branch.
You can simply edit the source change build.sh to bpi-r4,do importconfig and build like described in readme.md of the lts branches (e.g. 6.6-main)
thanks for the advice, I’ve patched the image to ignore the EEPORM check but it didn’t solve it. I actually had to solder pin6 to ground to make it work like in the guide i showed you. so now i’m in a position where I connect it and it’s not showing the module removed message all the time (accept when i actually remove it).
now after running:
ethtool -s eth2 autoneg off speed 1000 duplex full
I get a full view of the module:
ginnie@ginnie-hub:~$ sudo ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseX/Full
1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
ginnie@ginnie-hub:~$ sudo ethtool -m eth2
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00
Transceiver type : Ethernet: 1000BASE-LX
Encoding : 0x03 (NRZ)
BR, Nominal : 3200MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 40km
Length (SMF) : 25500m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1310nm
Vendor name : ALCATELLUCENT
Vendor OUI : 20:20:20
Vendor PN : 3FE46541AA
Vendor rev : 0001
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 : ALCLF948A1D1
Date code : 210327
Optical diagnostics support : Yes
Laser bias current : 8.682 mA
Laser output power : 0.0000 mW / -inf dBm
Receiver signal average optical power : 0.0000 mW / -inf dBm
Module temperature : 41.85 degrees C / 107.33 degrees F
Module voltage : 3.2332 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : On
Laser output power high warning : Off
Laser output power low warning : On
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : On
Laser rx power high warning : Off
Laser rx power low warning : On
Laser bias current high alarm threshold : 60.000 mA
Laser bias current low alarm threshold : 2.000 mA
Laser bias current high warning threshold : 60.000 mA
Laser bias current low warning threshold : 2.000 mA
Laser output power high alarm threshold : 3.2000 mW / 5.05 dBm
Laser output power low alarm threshold : 1.1220 mW / 0.50 dBm
Laser output power high warning threshold : 3.2000 mW / 5.05 dBm
Laser output power low warning threshold : 1.1220 mW / 0.50 dBm
Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold : -60.00 degrees C / -76.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -55.00 degrees C / -67.00 degrees F
Module voltage high alarm threshold : 3.4650 V
Module voltage low alarm threshold : 3.1350 V
Module voltage high warning threshold : 3.4650 V
Module voltage low warning threshold : 3.1350 V
Laser rx power high alarm threshold : 0.1600 mW / -7.96 dBm
Laser rx power low alarm threshold : 0.0015 mW / -28.24 dBm
Laser rx power high warning threshold : 0.1600 mW / -7.96 dBm
Laser rx power low warning threshold : 0.0015 mW / -28.24 dBm
ginnie@ginnie-hub:~$ sudo ethtool -i eth2
driver: mtk_soc_eth
version: 6.11.0-bpi-r4-main
firmware-version:
expansion-rom-version:
bus-info: 15100000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
link is still not detected as you can see and i connot activate pppoe, it just dosn’t work, maybe because the link show as not detected.
what i also noticed that after a little while i get this:
[ 74.767503] sfp sfp1: module transmit fault indicated
[ 320.534315] sfp sfp1: module persistently indicates fault, disabling
and than it’s like disconnecting the module. any patches you think that can help solving it? the whole idea with GPON ONT is problematic as far as i know but I really want to try and solve it.
just for the test I took the same SFP to a DLINK media converter and connected the ethernet cable to the wan and i was able to connect via PPPoE. so I wonder, what does the Dlink is doing that we don’t have on the banana pi to make it work directly and skip the extra hardware?
For transmission fault there is also a quirk if it can be ignored…but possibly transmitter is really faulty
Link has to be detected before trying higher layer like pppoe or ip
What is the quirk that can be done? Because if it was a real fault, I wouldn’t expect it to work with a media converter
thats right…if it works with converter the module should be ok so far
i mean the one used for the alcatel G010SP: sfp_fixup_ignore_tx_fault
Thanks a lot, I will try it right after I’ll get another SFP module cause I destroyed the current when trying to solder the pin6 to ground again after my previous attempt fell. But that’s good to see the my model was address specifically in the SFP quirks (3FE46541AA), I’ve added the sfp_fixup_ignore_tx_fault function to the sfp_fixup_nokia.
I just wonder how and if people were using this model without soldering pin6 to ground