Can Huawei MA5671A GPON SFP (2.5Gbps Download, 1.25Gbps Upload) be used with BPi-R4’s 10 gbps SFP WAN port after ONT cloning process (Vendor ID changes)? I have read about BPi- R4’s SFP WAN port fixed to 10gbps. And I have seen some kernel patch fixes 1gbps sfp support to 2.5gbps on BPi-R3. Is it also possible for BPi-R4?
I have one at home I’ll do some tests!
I am using BPI-R4 with Huawei MA5671A (bought on AliExpress - rooted version with Web GUI available) in SFP WAN port with no problems. It worked “out of the box” at 2.5GBs and there was no need to install any patches (auto-negotiation works by default as I believe).
I am using official OpenWRT snapshot version on my BPI-R4.
But remember, to access and configure your MA5671A via BPI-R4 there’s some modification of network/firewall settings needed to be done on BPI-R4 side. It would be more hassle free to connect it to some switch with SFP port (if you have one) to do the configuration (ONT s/n, h/w, etc. cloning).
Hi @Zbignief, I have the same stick, but I never got it working. In my SFP ethernet adapter the stick works without the fiber link connected like a charm. On openwrt (latest version and/or snapshot, bpi-r4) I don’t get any connection or ping to the web interface of the stick. The interface never comes up, but the stick is detected (dmesg)
Would you mind sharing your configs (static IP, firewall etc for the stick)? Did you have any other adjustments? EEPROM, ethtool , etc?
Your help is appreciated. cheers
Mostly the webinterface is only available when interface comes up…also your mac on r4 needs an ip in same subnet as Webinterface of your stick. Afaik there are tricks suggesting the link is up (dts overlay to simulate LOS signal is not there).
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.
1 Like
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