MacchiatoBIN DoubleShot + SFP GPON

Hi all,

i’m doing some tests with MacchiatoBIN DS and various SFP GPON on the 2.5Gbit/s SFP cage.
Test were successful with Huawei MA5671 in 2500Base-X mode, now i’m trying to make it work with VSOL 2801F (same as CarlitoX V2.0).

I’ve found this thread that is changing some quirks for another SFP GPON (Sercom FGS-202):

I’ve made same changes for my VSOL 2801F but without success. The SFP port is not enabled :frowning:

Putting some logs in the various phases of sfp.c kernel driver here is the output:

root@mcbin:~# dmesg | grep eth3
[    3.035066] mvpp2 f4000000.ethernet eth3: Using firmware node mac address 00:51:82:11:22:03
[   11.873853] sfp sfp-eth3: Host maximum power 2.0W
[   11.878594] sfp sfp-eth3: SFP_S_DOWN
[   11.882513] sfp sfp-eth3: SFP_MOD_PROBE
[   11.886367] sfp sfp-eth3: SFP_S_DOWN
[   12.189648] sfp sfp-eth3: SFP_MOD_PROBE
[   12.201279] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
[   12.208182] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
[   12.255376] sfp sfp-eth3: module OEM              V2801F           rev 1.0  sn 202101195032     dc 210119
[   12.265160] sfp sfp-eth3: module_t_start_up
[   12.269361] sfp sfp-eth3: SFP_MOD_WAITDEV
[   12.273396] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode
[   12.280912] sfp sfp-eth3: SFP_S_DOWN
[   12.284503] sfp sfp-eth3: skipping hwmon device registration due to broken EEPROM
[   12.292018] sfp sfp-eth3: diagnostic EEPROM area cannot be read atomically to guarantee data coherency
[  493.248711] mvpp2 f4000000.ethernet eth3: configuring for inband/1000base-x link mode
[  493.257761] sfp sfp-eth3: SFP_MOD_PRESENT
[  493.261796] sfp sfp-eth3: SFP_MOD_ERROR
[  493.265648] sfp sfp-eth3: SFP_S_DOWN
[  493.319654] sfp sfp-eth3: SFP_MOD_PRESENT
[  493.323685] sfp sfp-eth3: SFP_MOD_ERROR
[  493.327535] sfp sfp-eth3: SFP_S_WAIT
[  493.331133] sfp sfp-eth3: event == SFP_E_TIMEOUT
[  493.335795] sfp sfp-eth3: SFP_F_TX_FAULT bit basso
[  493.340634] sfp sfp-eth3: sfp_sm_link_check_los
[  493.345183] sfp sfp-eth3: los ok

So the SFP should be enabled. This stick is working on normal media converter and on my Unifi Switch. So there is something missing in the PHY negotiation.

Here is a dump of EEPROM:

root@mcbin:~# ethtool -m eth3
	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x01 (SC)
	Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Encoding                                  : 0x03 (NRZ)
	BR, Nominal                               : 1200MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF,km)                           : 20km
	Length (SMF)                              : 20000m
	Length (50um)                             : 0m
	Length (62.5um)                           : 0m
	Length (Copper)                           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 1310nm
	Vendor name                               : OEM
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : V2801F
	Vendor rev                                : 1.0
	Option values                             : 0x00 0x1c
	Option                                    : RX_LOS implemented, inverted
	Option                                    : TX_FAULT implemented
	Option                                    : TX_DISABLE implemented
	BR margin, max                            : 0%
	BR margin, min                            : 0%
	Vendor SN                                 : 202101195032
	Date code                                 : 210119
	Optical diagnostics support               : Yes
	Laser bias current                        : 16.574 mA
	Laser output power                        : 1.4542 mW / 1.63 dBm
	Receiver signal average optical power     : 0.0408 mW / -13.89 dBm
	Module temperature                        : 61.15 degrees C / 142.07 degrees F
	Module voltage                            : 3.3241 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              : Off
	Laser output power high warning           : Off
	Laser output power low warning            : Off
	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                  : Off
	Laser rx power high warning               : Off
	Laser rx power low warning                : Off
	Laser bias current high alarm threshold   : 75.000 mA
	Laser bias current low alarm threshold    : 1.000 mA
	Laser bias current high warning threshold : 70.000 mA
	Laser bias current low warning threshold  : 3.000 mA
	Laser output power high alarm threshold   : 3.1622 mW / 5.00 dBm
	Laser output power low alarm threshold    : 1.1220 mW / 0.50 dBm
	Laser output power high warning threshold : 2.8183 mW / 4.50 dBm
	Laser output power low warning threshold  : 1.2589 mW / 1.00 dBm
	Module temperature high alarm threshold   : 90.00 degrees C / 194.00 degrees F
	Module temperature low alarm threshold    : -10.00 degrees C / 14.00 degrees F
	Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
	Module temperature low warning threshold  : -5.00 degrees C / 23.00 degrees F
	Module voltage high alarm threshold       : 3.6000 V
	Module voltage low alarm threshold        : 3.0000 V
	Module voltage high warning threshold     : 3.4700 V
	Module voltage low warning threshold      : 3.1299 V
	Laser rx power high alarm threshold       : 0.1584 mW / -8.00 dBm
	Laser rx power low alarm threshold        : 0.0015 mW / -28.24 dBm
	Laser rx power high warning threshold     : 0.1258 mW / -9.00 dBm
	Laser rx power low warning threshold      : 0.0019 mW / -27.21 dBm

If needed I can also dump in raw format.

Thanks in advance for the help

you would need to enable debugging for the phy and phylink layers to get a better idea of why the device is not being enabled. We can look at your logs, however you would probably have a more productive conversation on the netdev mailing list. With the other broken GPON modules the customer did not work through us but discussed with Russell King directly. Since there are already patches and there is a long historic discussion the other developers that worked on this problem for other GPON modules would probably have better insight to what is broken regarding this module.

yes i’m talking with Russell.

At the moment the only way to brings up the SFP port is to un-plug/plug the stick after an “ifconfig eth3 up”

Hi,

May I know which FW you use to connect with Huawei MA5671A? I am using OpenWRT 22.03 and encountered below error. Also tried the Snapshot FW. Same issue. Thank you!

[  215.723384] sfp sfp-eth3: please wait, module slow to respond
[  256.094746] sfp sfp-eth3: module HUAWEI           MA5671A          rev 0000 sn 485754434B7D9E9E dc 181116  
[  256.134703] hwmon hwmon3: temp1_input not attached to any thermal zone
[  261.833262] sfp sfp-eth3: module persistently indicates fault, disabling

The ONU modules have historically behaved badly. You can try applying the following quirk that is going into mainline to your OpenWRT build and see if it helps. [PATCH] net: sfp: Add tx-fault quirk for Huawei MA5671A SFP ONT — Netdev

I’ve lost a lot of time on that issue, but wats more easily than expected.

Are you plug-in also fiber on the module? Otherwise it’s fixed on RX_LOSS and SFP driver will not bring up the interface

Yeah, I had noticed that patch and confirmed it was merged into stable linux kernel 5.10.146 I am using before I asked help here.

I did not plug the fiber into the Huawei MA5671A module before you told me. However, it still doesn’t work even though I plug now.

BTW, below is the output of ethtool -m eth3. It’s binary format instead of human readable format like yours. Is it normal? I want to test the module with another device. However, I don’t have one in my hand for now.

root@OpenWrt:~# ethtool -m eth3
Offset          Values
------          ------
0x0000:         03 04 01 00 00 00 02 00 00 00 00 03 0c 00 14 c8 
0x0010:         00 00 00 00 48 55 41 57 45 49 20 20 20 20 20 20 
0x0020:         20 20 20 20 00 00 00 00 4d 41 35 36 37 31 41 20 
0x0030:         20 20 20 20 20 20 20 20 30 30 30 30 05 1e 00 9d 
0x0040:         00 1a 00 00 34 38 35 37 35 34 34 33 34 42 37 44 
0x0050:         39 45 39 45 31 38 31 31 31 36 20 20 68 e0 03 6c 
0x0060:         49 43 48 32 30 30 35 39 30 32 20 20 20 20 20 20 
0x0070:         20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 
0x0080:         30 33 32 43 55 57 31 30 4b 31 30 32 39 30 39 36 
0x0090:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x00a0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x00b0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x00c0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x00d0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x00e0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x00f0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0100:         5f 00 ce 00 5a 00 d3 00 8c a0 75 30 88 b8 79 18 
0x0110:         af c8 00 00 88 b8 00 00 9b 82 22 d0 7b 86 2b d4 
0x0120:         09 cf 00 0d 07 cb 00 10 00 00 00 00 00 00 00 00 
0x0130:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0140:         00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00 
0x0150:         01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 4c 
0x0160:         2e 44 81 20 10 6f 35 e9 00 09 ff ff ff ff 00 00 
0x0170:         00 40 ff ff 00 40 00 00 70 00 00 00 00 00 00 00 
0x0180:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0190:         30 33 30 33 32 43 55 57 00 00 00 00 00 00 fe 18 
0x01a0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x01b0:         ff ff ff ff ff ff ff ff ff ff ff ff 00 02 14 31 
0x01c0:         39 32 44 38 37 41 34 41 38 30 44 33 38 45 30 00 
0x01d0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x01e0:         00 00 00 00 00 00 00 00 01 38 33 30 31 00 41 26 
0x01f0:         e4 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

To see human readable you have to install full ethtool, not the minimal one.

Regarding the link at this point you can try to patch sfp.c driver and skip los check to make interface up

I’ll try to send you later the part of the code that need to be changed :slight_smile:

the file to modify is under /drivers/net/phy/sfp.c

On function

static void sfp_sm_link_check_los(struct sfp *sfp)

the default one is this:

        if (los)
                sfp_sm_next(sfp, SFP_S_WAIT_LOS, 0);
        else
                sfp_sm_link_up(sfp);

just remove the if/else and leave only sfp_sm_link_up(sfp) to bring up link without checking the RX_LOS status

it’s a dirty way :wink:

Hi, I have created another topic because the below reason.

You have reached the reply limit for this topic
We’re sorry, but new users are temporarily limited to 3 replies in the same topic.
Instead of adding another reply, please consider editing your previous replies, or visiting other topics.

But I am trusted user now and can continue replying this topic. In case you missed my ping in that topic. I replied again in your this topic as below:

Still not works even I changed the driver as you told. I am wondering if I bought a broken module.

@stich86
You mentioned:

Test were successful with Huawei MA5671 in 2500Base-X mode

Have you changed the driver like this? Did you also use the OpenWRT? Thanks!