Thanks for the quick reply @frank-w. Love it! The ip range is the same and I also switched the default ip range of the LAN port to not have any interference…
What I wonder, if the missing fiber signal is the reason, why does it work on the sfp adapter? I still miss to get the fiber line at my home activated. Any hint on how to figure out more about the DTS overlay?
As i have no wuch sfp i could not test it. Afaik @ericwoud did this. Afair the overlay remapps the sfp slots los gpio to some on the gpio header to allow manipulating the signal in running system.
I also do not have one, but we helped someone to change the dts, so that the LOS pin can be simulated with a gpio on the gpio header. Simulating the singal from the sfp was ok, the interface was able to go up and the webinterface of the module could be reached.
Do you have the dts overlay somewhere? I remember i did one too and tried with my “normal” sfp,but then i got issues on detection…maybe the gpio i’ve chosen was used by something else
I remember that he edited the dts, did not use an overlay.
I think another option would be to use sfp_fixup_ignore_los() same as sfp_fixup_nokia(). Since sfp_fixup_nokia() also sets the long startup, I guess one could use it for other ont sfps as well.
Do something like
SFP_QUIRK("ALCATELLUCENT", "3FE46541AA", sfp_quirk_2500basex,
sfp_fixup_nokia),
It is a quirk and fixup combined.
Great! If I would love to avoid building a new kernel, I could use fw_setenv on the device or i2cutils to overwrite vendor name and others, so I can use automatically the sfp_fixup_nokia quirk from another device, correct @ericwoud ?
If this quirk+fixup is part of your current kernel, yes, you could give this a try.
I had now some time to try it out… Changing the vendor name and the part name is simple. I used a sfp-ethernet converter and connected via ssh to change the values with:
root@HUAWEI:~# sfp_i2c -i 0 -s "ALCATELLUCENT"
root@HUAWEI:~# sfp_i2c -i 1 -s "3FE46541AA"
Doing the same from the bpi-r4 with i2cdump & i2cset did not work (values never change), I assume you can’t write the eeprom via i2c? But thats just a guess…
The stick is recognized and the new vendor name is detected, but the link still does not get up.
I checked now again what the qirk
SFP_QUIRK("ALCATELLUCENT", "3FE46541AA", sfp_quirk_2500basex,
sfp_fixup_nokia),
does and this one does not included the sfp_fixup_ignore_tx_fault, which is set for the MA5671A …
By gut feeling is that could be the reason @ericwoud ? That would mean I have to patch & build a custom image to apply both. If I find some time I will try it out… Hopefully I get soon my fiber line, that could make it obsolete…
thx for all the advice!
I also have this sfp, and sometimes it doesn’t come up after reboot due to eeprom read error (found in dmesg)
And it doesn’t work in @ericwoud arch linux image, speed negotiation error, but works in OpenWRT
maybe it needs a delay quirk? i guess eric does not added a possible quirk which is added in openwrt but not in mainline (and so also my kernel does not add it).
how are your vendor/product strings?
vendor product strings: HUAWEI MA5671A
Got “mtk_soc_eth 15100000.ethernet end2: autoneg setting not compatible with PCS” on archlinux with 6.18.0-rc1 kernel
Currently it builds kernel from Frank for the R4.
Read a little here:
https://forum.banana-pi.org/search?context=topic&context_id=24345&q=MA5671A&skip_context=true
you should use only -main branches… not seen this error yet with any of latest kernels…but i do not remember any patch for Huawei gpon sfp
I noticed you’ve updated the kernel to 6.18-main branch - I’ll test it later today. However, I’m still observing intermittent issues where the SFP module takes too long to initialize, resulting in EEPROM read errors. I believe we should add both sfp_fixup_long_startup and sfp_fixup_ignore_los quirks for this particular SFP module to address these issues.
currently 6.18-main code (upstream version) defines it like this:
// Huawei MA5671A can operate at 2500base-X, but report 1.2GBd NRZ in
// their EEPROM
SFP_QUIRK("HUAWEI", "MA5671A", sfp_quirk_2500basex,
sfp_fixup_ignore_tx_fault),
looks like openwrt master has not changed this…which openwrt do you use exactly (bpi-wrt, mtk-sdk,…)?
modified quirk in 6.18-main to include the other 2 options
I use upstream OpenWrt 25.12.0-rc1
Thanks for patch, will check it on archlinux from sd card
The linux package is rebuild with Frank’s latest changes
I’ve tested it, unfortunately, it doesn’t work, looks like sfp_quirk_2500basex quirk doesn’t work
[ 30.307951] sfp sfp1: Detected broken RTL8672/RTL9601C emulated EEPROM
[ 30.314506] sfp sfp1: Switching to reading EEPROM to one byte at a time
[ 30.465294] sfp sfp1: module HUAWEI MA5671A rev 0000 sn 48575443DAB849AA dc 180720
[ 30.474729] mtk_soc_eth 15100000.ethernet end2: autoneg setting not compatible with PCS
[ 30.499919] sfp sfp1: skipping hwmon device registration
[ 30.505235] sfp sfp1: diagnostic EEPROM area cannot be read atomically to guarantee data coherency
ethtool -m end2
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 : 1200MBd
Rate identifier : 0x00 (unspecified)
Length (SMF) : 20km
Length (OM2) : 0m
Length (OM1) : 0m
Length (Copper or Active cable) : 0m
Length (OM3) : 0m
Laser wavelength : 1310nm
Vendor name : HUAWEI
Vendor OUI : 00:00:00
Vendor PN : MA5671A
Vendor rev : 0000
Option values : 0x00 0x1a
Option : TX_DISABLE implemented
BR margin max : 0%
BR margin min : 0%
Vendor SN : 48575443DAB849AA
Date code : 180720
Optical diagnostics support : Yes
Laser bias current : 0.000 mA
Laser output power : 0.0001 mW / -40.00 dBm
Receiver signal average optical power : 0.0331 mW / -14.80 dBm
Module temperature : 58.24 degrees C / 136.83 degrees F
Module voltage : 3.3070 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 : On
Laser output power low alarm : Off
Laser output power high warning : On
Laser output power low warning : Off
Module temperature high alarm : On
Module temperature low alarm : Off
Module temperature high warning : On
Module temperature low warning : Off
Module voltage high alarm : On
Module voltage low alarm : Off
Module voltage high warning : On
Module voltage low warning : Off
Laser rx power high alarm : On
Laser rx power low alarm : Off
Laser rx power high warning : On
Laser rx power low warning : Off
Laser bias current high alarm threshold : 0.000 mA
Laser bias current low alarm threshold : 0.000 mA
Laser bias current high warning threshold : 0.000 mA
Laser bias current low warning threshold : 0.000 mA
Laser output power high alarm threshold : 0.0000 mW / -inf dBm
Laser output power low alarm threshold : 0.0000 mW / -inf dBm
Laser output power high warning threshold : 0.0000 mW / -inf dBm
Laser output power low warning threshold : 0.0000 mW / -inf dBm
Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F
Module voltage high alarm threshold : 0.0000 V
Module voltage low alarm threshold : 0.0000 V
Module voltage high warning threshold : 0.0000 V
Module voltage low warning threshold : 0.0000 V
Laser rx power high alarm threshold : 0.0000 mW / -inf dBm
Laser rx power low alarm threshold : 0.0000 mW / -inf dBm
Laser rx power high warning threshold : 0.0000 mW / -inf dBm
Laser rx power low warning threshold : 0.0000 mW / -inf dBm
Then try dropping it by changing to SFP_QUIRK_F and drop the param. I do not have this device so cannot test it.
I guess it works in openwrt because some newer patches in phylink are missing which may break…also noticed that the 2500baseX for my 2.5g copper sfp did not worked on last try.
Hi, OpenWRT 25.12.0-rc2 backported patches from upstream and results “mtk_soc_eth 15100000.ethernet end2: autoneg setting not compatible with PCS” as well, please check this: 25.12.0-rc2 Bananapi BPI-R3 sfp1 stopped working after upgrade from rc1 · Issue #21436 · openwrt/openwrt