* Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) [not found] <CAJbjdrQbAd01WmW-ZQ9d9QKAtUqbQcRkpadtfSH94o9ZUqkhAg@mail.gmail.com> @ 2022-03-07 16:18 ` Giammarco lynx 2022-03-07 17:13 ` Russell King (Oracle) 0 siblings, 1 reply; 18+ messages in thread From: Giammarco lynx @ 2022-03-07 16:18 UTC (permalink / raw) To: linux-arm-kernel Hi all, i'm trying to make link up of a VSOL V2810F into a MacchiatoBIN double-shot on port SFP@2.5GbE (rif https://www.spinics.net/lists/arm-kernel/msg857257.html) The current situation is this one (putting some logs into sfp.c): 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 the SFP reaches the RX_LOS state and there should be a link up (i've forced los=true on the sfp.c), but nothing happens :( here is the current EEPROM dump, if needed I can provide eeprom raw. The SFP works on my MCL220 and Ubiquiti switch 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 Thanks in advance _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-07 16:18 ` Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) Giammarco lynx @ 2022-03-07 17:13 ` Russell King (Oracle) [not found] ` <CAJbjdrRiJMnQJEDCABOVxFyaqnSdBbq7Q-ixqBwW2ni49+gfgQ@mail.gmail.com> 0 siblings, 1 reply; 18+ messages in thread From: Russell King (Oracle) @ 2022-03-07 17:13 UTC (permalink / raw) To: Giammarco lynx; +Cc: linux-arm-kernel Hi, On Mon, Mar 07, 2022 at 05:18:18PM +0100, Giammarco lynx wrote: > Hi all, > > i'm trying to make link up of a VSOL V2810F into a MacchiatoBIN > double-shot on port SFP@2.5GbE (rif > https://www.spinics.net/lists/arm-kernel/msg857257.html) > > The current situation is this one (putting some logs into sfp.c): sfp.c already has debugging present (see the dev_dbg() statements). Those in sfp_sm_event() will show you the complete state machine state and events at entry and exit from each state machine run and is superior to the output provided below, which I can't really make too much sense of. > the SFP reaches the RX_LOS state and there should be a link up (i've > forced los=true on the sfp.c), but nothing happens :( So what state did SFP end up in? There's two ways to know that - either via the debugfs "state" file for the SFP (which should be /sys/kernel/debug/sfp-eth3/state) or by using the provided debug in sfp.c which can be enabled by adding #define DEBUG at the stop of sfp.c. Also defining DEBUG at the top of phylink.c to get further debugging output that will be useful to see what's going on at the MAC side. I suspect you are getting to the "SFP_S_LINK_UP" state, but for some reason the link between the host and the module isn't coming up. Is the PON module connected to the PON network? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CAJbjdrRiJMnQJEDCABOVxFyaqnSdBbq7Q-ixqBwW2ni49+gfgQ@mail.gmail.com>]
[parent not found: <YiZZbskbuqq+I2PW@shell.armlinux.org.uk>]
[parent not found: <CAJbjdrReN4B0XXFFLaTsPj_graAkguQPzP4xtRGbHeGozbJycQ@mail.gmail.com>]
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) [not found] ` <CAJbjdrReN4B0XXFFLaTsPj_graAkguQPzP4xtRGbHeGozbJycQ@mail.gmail.com> @ 2022-03-07 20:12 ` Giammarco lynx 2022-03-07 23:01 ` Russell King (Oracle) 2022-05-08 16:38 ` Pali Rohár 0 siblings, 2 replies; 18+ messages in thread From: Giammarco lynx @ 2022-03-07 20:12 UTC (permalink / raw) To: Russell King (Oracle); +Cc: linux-arm-kernel adding linux-arm-kernel@lists.infradead.org Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx <stich86@gmail.com> ha scritto: > > ok, doing in the way that you suggest, the link is bringing up. > Here is the logs (without ifconfig eth3 up and module plugged): > > [ 3.035643] mvpp2 f4000000.ethernet eth3: Using firmware node mac > address 00:51:82:11:22:03 > [ 11.872410] sfp sfp-eth3: Host maximum power 2.0W > [ 11.877149] sfp sfp-eth3: tx disable 1 -> 1 > [ 11.877155] sfp sfp-eth3: SM: enter empty:detached:down event insert > [ 11.877159] sfp sfp-eth3: SM: exit probe:detached:down > [ 11.877410] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach > [ 11.877414] sfp sfp-eth3: SM: exit probe:down:down > [ 12.180129] sfp sfp-eth3: SM: enter probe:down:down event timeout > [ 12.187906] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > [ 12.194814] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > [ 12.242005] sfp sfp-eth3: module OEM V2801F > rev 1.0 sn 202101195032 dc 210119 > [ 12.251800] mvpp2 f4000000.ethernet eth3: requesting link mode > inband/1000base-x with support 0000000,00000200,00000440 > [ 12.251804] mvpp2 f4000000.ethernet eth3: switched to > inband/1000base-x link mode > [ 12.259318] sfp sfp-eth3: SM: exit present:down:down > [ 12.270123] sfp sfp-eth3: skipping hwmon device registration due to > broken EEPROM > [ 12.277636] sfp sfp-eth3: diagnostic EEPROM area cannot be read > atomically to guarantee data coherency > [ 35.174143] mvpp2 f4000000.ethernet eth3: configuring for > inband/1000base-x link mode > [ 35.182026] mvpp2 f4000000.ethernet eth3: major config 1000base-x > [ 35.188158] mvpp2 f4000000.ethernet eth3: phylink_mac_config: > mode=inband/1000base-x/Unknown/Unknown adv=0000000,00000200,00000440 > pause=04 link=0 an=1 > [ 35.202945] sfp sfp-eth3: SM: enter present:down:down event dev_up > [ 35.209152] sfp sfp-eth3: tx disable 1 -> 0 > [ 35.213387] sfp sfp-eth3: SM: exit present:up:wait > [ 35.280129] sfp sfp-eth3: SM: enter present:up:wait event timeout > [ 35.286253] sfp sfp-eth3: SM: exit present:up:link_up > [ 56.097724] sfp sfp-eth3: los 0 -> 1 > [ 56.101324] sfp sfp-eth3: SM: enter present:up:link_up event los_high > [ 56.107792] sfp sfp-eth3: SM: exit present:up:link_up > [ 56.112876] sfp sfp-eth3: mod-def0 1 -> 0 > [ 56.116903] sfp sfp-eth3: tx-fault 0 -> 1 > [ 56.120933] sfp sfp-eth3: SM: enter present:up:link_up event remove > > Then after "ifconfig eth3 up" i've removed and reinserted the SFP, > this is the log: > > [ 56.127227] sfp sfp-eth3: module removed > [ 56.131175] sfp sfp-eth3: tx disable 0 -> 1 > [ 56.135432] sfp sfp-eth3: SM: exit empty:up:down > [ 56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault > [ 56.146103] sfp sfp-eth3: SM: exit empty:up:down > [ 59.350731] sfp sfp-eth3: mod-def0 0 -> 1 > [ 59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert > [ 59.360619] sfp sfp-eth3: SM: exit probe:up:down > [ 59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 59.686185] sfp sfp-eth3: SM: exit probe:up:down > [ 59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 59.806179] sfp sfp-eth3: SM: exit probe:up:down > [ 59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 59.926179] sfp sfp-eth3: SM: exit probe:up:down > [ 60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.046178] sfp sfp-eth3: SM: exit probe:up:down > [ 60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.166178] sfp sfp-eth3: SM: exit probe:up:down > [ 60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.276177] sfp sfp-eth3: SM: exit probe:up:down > [ 60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.386178] sfp sfp-eth3: SM: exit probe:up:down > [ 60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.506177] sfp sfp-eth3: SM: exit probe:up:down > [ 60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.626176] sfp sfp-eth3: SM: exit probe:up:down > [ 60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 60.746177] sfp sfp-eth3: please wait, module slow to respond > [ 60.751982] sfp sfp-eth3: SM: exit probe:up:down > [ 65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 65.846262] sfp sfp-eth3: SM: exit probe:up:down > [ 70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 70.876192] sfp sfp-eth3: SM: exit probe:up:down > [ 75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 75.926196] sfp sfp-eth3: SM: exit probe:up:down > [ 80.896801] mvpp2 f4000000.ethernet eth3: mac link up > [ 80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 80.966183] sfp sfp-eth3: SM: exit probe:up:down > [ 81.330385] sfp sfp-eth3: los 1 -> 0 > [ 81.333978] sfp sfp-eth3: tx-fault 1 -> 0 > [ 81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear > [ 81.344044] sfp sfp-eth3: SM: exit probe:up:down > [ 81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low > [ 81.354629] sfp sfp-eth3: SM: exit probe:up:down > [ 86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > [ 86.067758] sfp sfp-eth3: module OEM V2801F > rev 1.0 sn 202101195032 dc 210119 > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > inband/1000base-x with support 0000000,00000200,00000440 > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 > [ 86.092636] sfp sfp-eth3: SM: exit present:up:wait > [ 86.097448] sfp sfp-eth3: skipping hwmon device registration due to > broken EEPROM > [ 86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read > atomically to guarantee data coherency > [ 86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout > [ 86.166252] sfp sfp-eth3: SM: exit present:up:link_up > [ 86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full - > flow control off > [ 86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready > > In that way it goes up. So how can we avoid this behaviour? > > Thanks > > Il giorno lun 7 mar 2022 alle ore 20:13 Russell King (Oracle) > <linux@armlinux.org.uk> ha scritto: > > > > Please keep follow-ups on the mailing list. > > > > On Mon, Mar 07, 2022 at 08:04:21PM +0100, Giammarco lynx wrote: > > > ok may be i've enabled it, here is the output: > > > > > > root@mcbin:~# dmesg | grep eth3 > > > [ 3.035655] mvpp2 f4000000.ethernet eth3: Using firmware node mac > > > address 00:51:82:11:22:03 > > > [ 11.759569] sfp sfp-eth3: Host maximum power 2.0W > > > [ 11.764323] sfp sfp-eth3: tx disable 1 -> 1 > > > [ 11.764329] sfp sfp-eth3: SM: enter empty:detached:down event insert > > > [ 11.764333] sfp sfp-eth3: SFP_S_DOWN > > > [ 11.767925] sfp sfp-eth3: SM: exit probe:detached:down > > > [ 11.768259] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach > > > [ 11.768263] sfp sfp-eth3: SFP_MOD_PROBE > > > [ 11.772123] sfp sfp-eth3: SFP_S_DOWN > > > [ 11.775715] sfp sfp-eth3: SM: exit probe:down:down > > > [ 12.080088] sfp sfp-eth3: SM: enter probe:down:down event timeout > > > [ 12.080093] sfp sfp-eth3: SFP_MOD_PROBE > > > [ 12.091720] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > > [ 12.098622] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > > [ 12.145814] sfp sfp-eth3: module OEM V2801F > > > rev 1.0 sn 202101195032 dc 210119 > > > [ 12.155598] sfp sfp-eth3: module_t_start_up > > > [ 12.159799] sfp sfp-eth3: SFP_MOD_WAITDEV > > > [ 12.163834] mvpp2 f4000000.ethernet eth3: requesting link mode > > > inband/1000base-x with support 0000000,00000200,00000440 > > > [ 12.163838] mvpp2 f4000000.ethernet eth3: switched to > > > inband/1000base-x link mode > > > [ 12.171354] sfp sfp-eth3: SFP_S_DOWN > > > [ 12.174944] sfp sfp-eth3: SM: exit present:down:down > > > [ 12.174949] sfp sfp-eth3: skipping hwmon device registration due to > > > broken EEPROM > > > [ 12.182465] sfp sfp-eth3: diagnostic EEPROM area cannot be read > > > atomically to guarantee data coherency > > > [ 58.634098] mvpp2 f4000000.ethernet eth3: configuring for > > > inband/1000base-x link mode > > > [ 58.641979] mvpp2 f4000000.ethernet eth3: major config 1000base-x > > > [ 58.648113] mvpp2 f4000000.ethernet eth3: phylink_mac_config: > > > mode=inband/1000base-x/Unknown/Unknown adv=0000000,00000200,00000440 > > > pause=04 link=0 an=1 > > > [ 58.662900] sfp sfp-eth3: SM: enter present:down:down event dev_up > > > [ 58.669107] sfp sfp-eth3: SFP_MOD_PRESENT > > > [ 58.673137] sfp sfp-eth3: SFP_MOD_ERROR > > > [ 58.677019] sfp sfp-eth3: SFP_S_DOWN > > > [ 58.680643] sfp sfp-eth3: tx disable 1 -> 0 > > > [ 58.684852] sfp sfp-eth3: SM: exit present:up:wait > > > [ 58.740088] sfp sfp-eth3: SM: enter present:up:wait event timeout > > > [ 58.746210] sfp sfp-eth3: SFP_MOD_PRESENT > > > [ 58.750243] sfp sfp-eth3: SFP_MOD_ERROR > > > [ 58.754094] sfp sfp-eth3: SFP_S_WAIT > > > [ 58.757682] sfp sfp-eth3: event == SFP_E_TIMEOUT > > > [ 58.762322] sfp sfp-eth3: SFP_F_TX_FAULT bit basso > > > [ 58.767164] sfp sfp-eth3: sfp_sm_link_check_los > > > [ 58.771715] sfp sfp-eth3: los ok > > > [ 58.774988] sfp sfp-eth3: SM: exit present:up:link_up > > > root@mcbin:~# > > > > So yes, here we believe that the module is operational, but there > > appears to be nothing from the MAC, meaning the 1000base-X link > > didn't establish. > > > > If the module supports 2500base-x and 1000base-x, the problem could > > be that the module is trying to use 2500base-x but is indicating > > 1000base-x in its EEPROM. > > > > It could be trying to detect the speed at power-on time - have you > > tried unplugging and re-plugging it after bringing the interface up? > > > > GPON modules seem to always be a pain to get working. > > > > -- > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-07 20:12 ` Giammarco lynx @ 2022-03-07 23:01 ` Russell King (Oracle) 2022-03-08 10:08 ` Giammarco lynx 2022-05-08 16:31 ` Pali Rohár 2022-05-08 16:38 ` Pali Rohár 1 sibling, 2 replies; 18+ messages in thread From: Russell King (Oracle) @ 2022-03-07 23:01 UTC (permalink / raw) To: Giammarco lynx; +Cc: linux-arm-kernel On Mon, Mar 07, 2022 at 09:12:45PM +0100, Giammarco lynx wrote: > Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx > <stich86@gmail.com> ha scritto: > > Then after "ifconfig eth3 up" i've removed and reinserted the SFP, > > this is the log: > > > > [ 56.127227] sfp sfp-eth3: module removed > > [ 56.131175] sfp sfp-eth3: tx disable 0 -> 1 TX_DISABLE asserted. > > [ 56.135432] sfp sfp-eth3: SM: exit empty:up:down > > [ 56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault > > [ 56.146103] sfp sfp-eth3: SM: exit empty:up:down > > [ 59.350731] sfp sfp-eth3: mod-def0 0 -> 1 Module inserted, and starts booting... > > [ 59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert > > [ 59.360619] sfp sfp-eth3: SM: exit probe:up:down > > [ 59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 59.686185] sfp sfp-eth3: SM: exit probe:up:down > > [ 59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 59.806179] sfp sfp-eth3: SM: exit probe:up:down > > [ 59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 59.926179] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.046178] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.166178] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.276177] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.386178] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.506177] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.626176] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.746177] sfp sfp-eth3: please wait, module slow to respond > > [ 60.751982] sfp sfp-eth3: SM: exit probe:up:down > > [ 65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 65.846262] sfp sfp-eth3: SM: exit probe:up:down > > [ 70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 70.876192] sfp sfp-eth3: SM: exit probe:up:down > > [ 75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 75.926196] sfp sfp-eth3: SM: exit probe:up:down > > [ 80.896801] mvpp2 f4000000.ethernet eth3: mac link up Link established with the host MAC at 1G, probably as part of the module detecting what speed the host is operating at. > > [ 80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 80.966183] sfp sfp-eth3: SM: exit probe:up:down > > [ 81.330385] sfp sfp-eth3: los 1 -> 0 > > [ 81.333978] sfp sfp-eth3: tx-fault 1 -> 0 Some of the modules IOs change state. > > [ 81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear > > [ 81.344044] sfp sfp-eth3: SM: exit probe:up:down > > [ 81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low > > [ 81.354629] sfp sfp-eth3: SM: exit probe:up:down > > [ 86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM Module emulated EEPROM becomes readable about 27 seconds after insertion Firmware probably almost finished booting. > > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > [ 86.067758] sfp sfp-eth3: module OEM V2801F > > rev 1.0 sn 202101195032 dc 210119 > > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > > inband/1000base-x with support 0000000,00000200,00000440 > > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 We've now detected what the module is, and we configure for it, which the EEPROM indicates it supports 1200Mbaud, which is 1G speed. > > [ 86.092636] sfp sfp-eth3: SM: exit present:up:wait > > [ 86.097448] sfp sfp-eth3: skipping hwmon device registration due to > > broken EEPROM > > [ 86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read > > atomically to guarantee data coherency > > [ 86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout > > [ 86.166252] sfp sfp-eth3: SM: exit present:up:link_up sfp.c determines link up... > > [ 86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full - > > flow control off > > [ 86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready Network device now indicates that link has been established at 1G speed. > > In that way it goes up. So how can we avoid this behaviour? Very difficult to avoid it. My guess is that when you power up the system with the module inserted, it sees the interface operating at 2.5G speed and locks itself to 2.5G speed. Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM indicates that it supports 1G speed, so we switch the host interface to 1000base-X, and that causes link to be lost (although I don't see any sign of that happening in your debug.) That means that the module has decided to use 2.5G speed, but its reporting it supports 1G speed in the EEPROM... so its doing something different. No surprises that the link fails to come up. We could add an entry to the sfp_quirks[] table in sfp-bus.c for this module using the sfp_quirk_2500basex function to also indicate it supports 2.5G speed: }, { // VSOL/CarlitoxxPro SFP can also work at 2.5G speed .part = "V2801F", .modes = sfp_quirk_2500basex, However, we are always going to be stuck in the situation that this is going to be unreliable. Whatever speed the network interface is in when this module is inserted, it's going to lock to that speed. If we then change it later, we'll never link. A switch will likely only ever use one speed on its SFP port, meaning it will always present 1000base-X, or it will always present 2500base-X, so it will always work with a switch, but not a more capable MAC interface that can switch between these at will. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-07 23:01 ` Russell King (Oracle) @ 2022-03-08 10:08 ` Giammarco lynx 2022-03-08 11:15 ` Russell King (Oracle) 2022-05-08 16:31 ` Pali Rohár 1 sibling, 1 reply; 18+ messages in thread From: Giammarco lynx @ 2022-03-08 10:08 UTC (permalink / raw) To: Russell King (Oracle); +Cc: linux-arm-kernel Hi Russell, i've tried to change quirks on the sfp-bus.c, but without success: root@mcbin:~# dmesg | grep eth3 [ 3.035613] mvpp2 f4000000.ethernet eth3: Using firmware node mac address 00:51:82:11:22:03 [ 12.115130] sfp sfp-eth3: Host maximum power 2.0W [ 12.119867] sfp sfp-eth3: tx disable 1 -> 1 [ 12.119873] sfp sfp-eth3: SM: enter empty:detached:down event insert [ 12.119877] sfp sfp-eth3: SM: exit probe:detached:down [ 12.120155] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach [ 12.120159] sfp sfp-eth3: SM: exit probe:down:down [ 12.420121] sfp sfp-eth3: SM: enter probe:down:down event timeout [ 12.427901] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM [ 12.434811] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time [ 12.482001] sfp sfp-eth3: module OEM V2801F rev 1.0 sn 202101195032 dc 210119 [ 12.491796] mvpp2 f4000000.ethernet eth3: requesting link mode inband/2500base-x with support 0000000,00000200,00008440 [ 12.491799] sfp sfp-eth3: SM: exit present:down:down [ 12.520104] sfp sfp-eth3: skipping hwmon device registration due to broken EEPROM [ 12.527618] sfp sfp-eth3: diagnostic EEPROM area cannot be read atomically to guarantee data coherency [ 34.635760] mvpp2 f4000000.ethernet eth3: configuring for inband/2500base-x link mode [ 34.643644] mvpp2 f4000000.ethernet eth3: major config 2500base-x [ 34.649768] mvpp2 f4000000.ethernet eth3: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown adv=0000000,00000000,00008440 pause=04 link=0 an=1 [ 34.663452] sfp sfp-eth3: SM: enter present:down:down event dev_up [ 34.669658] sfp sfp-eth3: tx disable 1 -> 0 [ 34.673893] sfp sfp-eth3: SM: exit present:up:wait [ 34.740110] sfp sfp-eth3: SM: enter present:up:wait event timeout [ 34.746236] sfp sfp-eth3: SM: exit present:up:link_up [ 57.613403] sfp sfp-eth3: los 0 -> 1 [ 57.616998] sfp sfp-eth3: SM: enter present:up:link_up event los_high [ 57.623474] sfp sfp-eth3: SM: exit present:up:link_up [ 57.628555] sfp sfp-eth3: mod-def0 1 -> 0 [ 57.632587] sfp sfp-eth3: tx-fault 0 -> 1 [ 57.636615] sfp sfp-eth3: SM: enter present:up:link_up event remove [ 57.642912] sfp sfp-eth3: module removed [ 57.647018] sfp sfp-eth3: tx disable 0 -> 1 [ 57.651236] sfp sfp-eth3: SM: exit empty:up:down [ 57.655872] sfp sfp-eth3: SM: enter empty:up:down event tx_fault [ 57.661940] sfp sfp-eth3: SM: exit empty:up:down [ 59.404709] sfp sfp-eth3: tx-fault 1 -> 0 [ 59.408737] sfp sfp-eth3: SM: enter empty:up:down event tx_clear [ 59.414775] sfp sfp-eth3: SM: exit empty:up:down [ 59.419417] sfp sfp-eth3: mod-def0 0 -> 1 [ 59.423445] sfp sfp-eth3: tx-fault 0 -> 1 [ 59.427471] sfp sfp-eth3: SM: enter empty:up:down event insert [ 59.433333] sfp sfp-eth3: SM: exit probe:up:down [ 59.437968] sfp sfp-eth3: SM: enter probe:up:down event tx_fault [ 59.444003] sfp sfp-eth3: SM: exit probe:up:down [ 59.740106] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 61.836667] sfp sfp-eth3: SM: exit probe:up:down [ 61.940105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 61.946161] sfp sfp-eth3: SM: exit probe:up:down [ 62.050106] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.056159] sfp sfp-eth3: SM: exit probe:up:down [ 62.160105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.166158] sfp sfp-eth3: SM: exit probe:up:down [ 62.270105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.276159] sfp sfp-eth3: SM: exit probe:up:down [ 62.380105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.386159] sfp sfp-eth3: SM: exit probe:up:down [ 62.490105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.496160] sfp sfp-eth3: SM: exit probe:up:down [ 62.600105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.606160] sfp sfp-eth3: SM: exit probe:up:down [ 62.710105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.716159] sfp sfp-eth3: SM: exit probe:up:down [ 62.820105] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 62.826159] sfp sfp-eth3: please wait, module slow to respond [ 62.831965] sfp sfp-eth3: SM: exit probe:up:down [ 67.910109] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 67.916168] sfp sfp-eth3: SM: exit probe:up:down [ 72.950108] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 72.956167] sfp sfp-eth3: SM: exit probe:up:down [ 77.990111] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 77.996175] sfp sfp-eth3: SM: exit probe:up:down [ 81.427524] sfp sfp-eth3: los 1 -> 0 [ 81.431121] sfp sfp-eth3: tx-fault 1 -> 0 [ 81.435148] sfp sfp-eth3: SM: enter probe:up:down event tx_clear [ 81.441185] sfp sfp-eth3: SM: exit probe:up:down [ 81.445820] sfp sfp-eth3: SM: enter probe:up:down event los_low [ 81.451767] sfp sfp-eth3: SM: exit probe:up:down [ 83.030114] sfp sfp-eth3: SM: enter probe:up:down event timeout [ 83.043617] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM [ 83.050525] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time [ 83.097713] sfp sfp-eth3: module OEM V2801F rev 1.0 sn 202101195032 dc 210119 [ 83.107507] mvpp2 f4000000.ethernet eth3: requesting link mode inband/2500base-x with support 0000000,00000200,00008440 [ 83.118375] sfp sfp-eth3: tx disable 1 -> 0 [ 83.122621] sfp sfp-eth3: SM: exit present:up:wait [ 83.127435] sfp sfp-eth3: skipping hwmon device registration due to broken EEPROM [ 83.134954] sfp sfp-eth3: diagnostic EEPROM area cannot be read atomically to guarantee data coherency [ 83.180105] sfp sfp-eth3: SM: enter present:up:wait event timeout [ 83.186242] sfp sfp-eth3: SM: exit present:up:link_up root@mcbin:~# Please note that this stick should supporto HiSGMII (2500base-x), but currently the firmware on-top seems stuck so link only at 1000base-x At the moment we don't have any other solution than put interface UP and then un-plug/plug module again? Thanks, Giammarco Il giorno mar 8 mar 2022 alle ore 00:01 Russell King (Oracle) <linux@armlinux.org.uk> ha scritto: > > On Mon, Mar 07, 2022 at 09:12:45PM +0100, Giammarco lynx wrote: > > Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx > > <stich86@gmail.com> ha scritto: > > > Then after "ifconfig eth3 up" i've removed and reinserted the SFP, > > > this is the log: > > > > > > [ 56.127227] sfp sfp-eth3: module removed > > > [ 56.131175] sfp sfp-eth3: tx disable 0 -> 1 > > TX_DISABLE asserted. > > > > [ 56.135432] sfp sfp-eth3: SM: exit empty:up:down > > > [ 56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault > > > [ 56.146103] sfp sfp-eth3: SM: exit empty:up:down > > > [ 59.350731] sfp sfp-eth3: mod-def0 0 -> 1 > > Module inserted, and starts booting... > > > > [ 59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert > > > [ 59.360619] sfp sfp-eth3: SM: exit probe:up:down > > > [ 59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 59.686185] sfp sfp-eth3: SM: exit probe:up:down > > > [ 59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 59.806179] sfp sfp-eth3: SM: exit probe:up:down > > > [ 59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 59.926179] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.046178] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.166178] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.276177] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.386178] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.506177] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.626176] sfp sfp-eth3: SM: exit probe:up:down > > > [ 60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 60.746177] sfp sfp-eth3: please wait, module slow to respond > > > [ 60.751982] sfp sfp-eth3: SM: exit probe:up:down > > > [ 65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 65.846262] sfp sfp-eth3: SM: exit probe:up:down > > > [ 70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 70.876192] sfp sfp-eth3: SM: exit probe:up:down > > > [ 75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 75.926196] sfp sfp-eth3: SM: exit probe:up:down > > > [ 80.896801] mvpp2 f4000000.ethernet eth3: mac link up > > Link established with the host MAC at 1G, probably as part of the > module detecting what speed the host is operating at. > > > > [ 80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 80.966183] sfp sfp-eth3: SM: exit probe:up:down > > > [ 81.330385] sfp sfp-eth3: los 1 -> 0 > > > [ 81.333978] sfp sfp-eth3: tx-fault 1 -> 0 > > Some of the modules IOs change state. > > > > [ 81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear > > > [ 81.344044] sfp sfp-eth3: SM: exit probe:up:down > > > [ 81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low > > > [ 81.354629] sfp sfp-eth3: SM: exit probe:up:down > > > [ 86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout > > > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > Module emulated EEPROM becomes readable about 27 seconds after > insertion Firmware probably almost finished booting. > > > > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > > [ 86.067758] sfp sfp-eth3: module OEM V2801F > > > rev 1.0 sn 202101195032 dc 210119 > > > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > > > inband/1000base-x with support 0000000,00000200,00000440 > > > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 > > We've now detected what the module is, and we configure for it, which > the EEPROM indicates it supports 1200Mbaud, which is 1G speed. > > > > [ 86.092636] sfp sfp-eth3: SM: exit present:up:wait > > > [ 86.097448] sfp sfp-eth3: skipping hwmon device registration due to > > > broken EEPROM > > > [ 86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read > > > atomically to guarantee data coherency > > > [ 86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout > > > [ 86.166252] sfp sfp-eth3: SM: exit present:up:link_up > > sfp.c determines link up... > > > > [ 86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full - > > > flow control off > > > [ 86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready > > Network device now indicates that link has been established at 1G > speed. > > > > In that way it goes up. So how can we avoid this behaviour? > > Very difficult to avoid it. My guess is that when you power up the > system with the module inserted, it sees the interface operating at > 2.5G speed and locks itself to 2.5G speed. > > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM > indicates that it supports 1G speed, so we switch the host interface > to 1000base-X, and that causes link to be lost (although I don't see > any sign of that happening in your debug.) > > That means that the module has decided to use 2.5G speed, but its > reporting it supports 1G speed in the EEPROM... so its doing something > different. No surprises that the link fails to come up. > > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this > module using the sfp_quirk_2500basex function to also indicate it > supports 2.5G speed: > > }, { > // VSOL/CarlitoxxPro SFP can also work at 2.5G speed > .part = "V2801F", > .modes = sfp_quirk_2500basex, > > However, we are always going to be stuck in the situation that this is > going to be unreliable. Whatever speed the network interface is in when > this module is inserted, it's going to lock to that speed. If we then > change it later, we'll never link. > > A switch will likely only ever use one speed on its SFP port, meaning > it will always present 1000base-X, or it will always present 2500base-X, > so it will always work with a switch, but not a more capable MAC > interface that can switch between these at will. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-08 10:08 ` Giammarco lynx @ 2022-03-08 11:15 ` Russell King (Oracle) 2022-03-08 11:54 ` Giammarco lynx 2022-05-08 16:51 ` Pali Rohár 0 siblings, 2 replies; 18+ messages in thread From: Russell King (Oracle) @ 2022-03-08 11:15 UTC (permalink / raw) To: Giammarco lynx; +Cc: linux-arm-kernel On Tue, Mar 08, 2022 at 11:08:34AM +0100, Giammarco lynx wrote: > Hi Russell, > > i've tried to change quirks on the sfp-bus.c, but without success: Thanks for trying. > Please note that this stick should supporto HiSGMII (2500base-x), but > currently the firmware on-top seems stuck so link only at 1000base-x I've seen that with some of the other modules (the alcatel/lucent ones) where they won't switch to 2.5G unless they are on the PON network and have been configured. So this brings up a question - if it isn't switching to 2500base-X then why doesn't it link when we're in 1000base-X mode. The only other possibility I can think of would be SGMII, which will sync, but won't complete the negotiation. The only way to know that would be to read the GMAC STATUS0 register to see if bit 14 is set (meaning it has gained sync) without bit 0 (link up.) If you have devmem2, boot without the sfp-bus.c patch applied, bring eth3 up, and then run: # devmem2 0xf4133e10 which should dump the status0 register for eth3. > At the moment we don't have any other solution than put interface UP > and then un-plug/plug module again? At the moment, sadly, yes. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-08 11:15 ` Russell King (Oracle) @ 2022-03-08 11:54 ` Giammarco lynx 2022-03-08 12:12 ` Russell King (Oracle) 2022-05-08 16:51 ` Pali Rohár 1 sibling, 1 reply; 18+ messages in thread From: Giammarco lynx @ 2022-03-08 11:54 UTC (permalink / raw) To: Russell King (Oracle); +Cc: linux-arm-kernel Hi Russell, here is the output of devmem without sfp-bus.c quirk: root@mcbin:~# devmem 0xf4133e10 0x0000600A root@mcbin:~# Thanks Il giorno mar 8 mar 2022 alle ore 12:15 Russell King (Oracle) <linux@armlinux.org.uk> ha scritto: > > On Tue, Mar 08, 2022 at 11:08:34AM +0100, Giammarco lynx wrote: > > Hi Russell, > > > > i've tried to change quirks on the sfp-bus.c, but without success: > > Thanks for trying. > > > Please note that this stick should supporto HiSGMII (2500base-x), but > > currently the firmware on-top seems stuck so link only at 1000base-x > > I've seen that with some of the other modules (the alcatel/lucent ones) > where they won't switch to 2.5G unless they are on the PON network and > have been configured. > > So this brings up a question - if it isn't switching to 2500base-X then > why doesn't it link when we're in 1000base-X mode. The only other > possibility I can think of would be SGMII, which will sync, but won't > complete the negotiation. The only way to know that would be to read > the GMAC STATUS0 register to see if bit 14 is set (meaning it has > gained sync) without bit 0 (link up.) > > If you have devmem2, boot without the sfp-bus.c patch applied, bring > eth3 up, and then run: > > # devmem2 0xf4133e10 > > which should dump the status0 register for eth3. > > > At the moment we don't have any other solution than put interface UP > > and then un-plug/plug module again? > > At the moment, sadly, yes. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-08 11:54 ` Giammarco lynx @ 2022-03-08 12:12 ` Russell King (Oracle) [not found] ` <CAJbjdrSRcGVavaWJHuO3_RnP8A30b_ZQS_yAUCUWKCqxrUMwLw@mail.gmail.com> 0 siblings, 1 reply; 18+ messages in thread From: Russell King (Oracle) @ 2022-03-08 12:12 UTC (permalink / raw) To: Giammarco lynx; +Cc: linux-arm-kernel On Tue, Mar 08, 2022 at 12:54:09PM +0100, Giammarco lynx wrote: > Hi Russell, > > here is the output of devmem without sfp-bus.c quirk: > > root@mcbin:~# devmem 0xf4133e10 > 0x0000600A So yes, bit 14 is set, meaning it's in sync, but negotiation has not completed. I think that probably means my theory that the module is operating in SGMII mode is likely to be correct. I would need to check, but I would guess that u-boot configures eth3 for SGMII at boot (despite it always being connected to a SFP cage which doesn't actually make that much sense) and the SFP module detects that the host is in SGMII mode at boot, and locks itself to that. When the kernel boots, it reconfigures the interface to be in 1000base-X mode, which would be way more sensible for the SFP cage given that SFPs are normally used for fibre, and the GPON module no longer links. If we were to add hacks so that this module caused the mcbin to stay in SGMII mode, this would break existing systems where the host boots in 1000base-X mode, causing the module to lock to 1000base-X. So, there is no solution here for the kernel that will work for everyone. This also means that what mode the module is in will depend on what module was _previously_ inserted in the SFP cage, since that will determine the host configuration at the point when the module is inserted. I guess the module has been designed with the assumption that the host it is plugged into will only be capable of operating with a single protocol. I can't see a clean solution to this one that will work for everyone. Sorry. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CAJbjdrSRcGVavaWJHuO3_RnP8A30b_ZQS_yAUCUWKCqxrUMwLw@mail.gmail.com>]
[parent not found: <Yid39zuckqVLVJts@shell.armlinux.org.uk>]
* Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) [not found] ` <Yid39zuckqVLVJts@shell.armlinux.org.uk> @ 2022-03-08 15:51 ` Giammarco lynx 0 siblings, 0 replies; 18+ messages in thread From: Giammarco lynx @ 2022-03-08 15:51 UTC (permalink / raw) To: Russell King (Oracle); +Cc: linux-arm-kernel so correct me if i'm wrong (and i haven't understood correctly): the MCBIN seems to configure the interface on SGMII mode (and the GPON switch on this mode), when the kernel starts it move the interface mode in 1000base-X. When i'm doing the unplug/plug, basically the GPON module see that host is advertising 1000base-X and it negotiates in this way instead of SGMII. Is it right? Thanks Il giorno mar 8 mar 2022 alle ore 16:36 Russell King (Oracle) <linux@armlinux.org.uk> ha scritto: > > On Tue, Mar 08, 2022 at 04:29:15PM +0100, Giammarco lynx wrote: > > for "hack" you mean to force phy in SGMII into DTS? > > No, I meant to basically bodge the sfp/phylink layer detect this > module and use SGMII mode for it. That's not easy to do with the way > the code is presently structured. > > As I also mentioned, doing so will only end up causing other issues. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-08 11:15 ` Russell King (Oracle) 2022-03-08 11:54 ` Giammarco lynx @ 2022-05-08 16:51 ` Pali Rohár 2022-05-09 15:41 ` Russell King (Oracle) 1 sibling, 1 reply; 18+ messages in thread From: Pali Rohár @ 2022-05-08 16:51 UTC (permalink / raw) To: Russell King (Oracle); +Cc: Giammarco lynx, linux-arm-kernel On Tuesday 08 March 2022 11:15:08 Russell King (Oracle) wrote: > I've seen that with some of the other modules (the alcatel/lucent ones) > where they won't switch to 2.5G unless they are on the PON network and > have been configured. Those Alcatel/Lucent GPON SFP modules (including Nokia rebrands) choose 1000base-x vs 2500base-x speed on LAN port based on settings done via OMCI from OLT. With advanced OLT you can "force" that speed, even when SFP is already plugged and running. So if ISP decide that your LAN port is 1G-only then those Alcatel/Lucent GPON SFP modules would never switch to 2500base-x mode with user CPU. Russell, is there any option to ignore speed information stored in SFP EEPROM and try to choose speed at linux runtime? And how to correctly handle behavior of SFP module which changes speed during usage time? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-05-08 16:51 ` Pali Rohár @ 2022-05-09 15:41 ` Russell King (Oracle) 2022-05-09 17:08 ` Pali Rohár 0 siblings, 1 reply; 18+ messages in thread From: Russell King (Oracle) @ 2022-05-09 15:41 UTC (permalink / raw) To: Pali Rohár; +Cc: Giammarco lynx, linux-arm-kernel On Sun, May 08, 2022 at 06:51:59PM +0200, Pali Rohár wrote: > Russell, is there any option to ignore speed information stored in SFP > EEPROM and try to choose speed at linux runtime? If sfp_parse_support() fills in a support mask containing both 1000base-X and 2500base-X, then yes. By default, phylink will choose 2500base-X because that's the fastest speed. ethtool will report that both 1000base-X and 2500base-X is supported, and 2500base-X is being advertised. If you change the advertisement to 1000base-X, then phylink will switch to 1000base-X, and vice versa. > And how to correctly handle behavior of SFP module which changes speed > during usage time? I know of no way that a SFP module can signal to the host that its host interface has changed in some way. There is no provision for a module to state what the host interface actually is of the module - most of what the kernel does is heuristics based on modules that I've had available. SFPs suck in this regard. GPON SFPs suck way harder because they claim SFP MSA compliance but they always seem to be violating the SFP MSA in some regard. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-05-09 15:41 ` Russell King (Oracle) @ 2022-05-09 17:08 ` Pali Rohár 2022-05-09 20:27 ` Russell King (Oracle) 0 siblings, 1 reply; 18+ messages in thread From: Pali Rohár @ 2022-05-09 17:08 UTC (permalink / raw) To: Russell King (Oracle); +Cc: Giammarco lynx, linux-arm-kernel On Monday 09 May 2022 16:41:14 Russell King (Oracle) wrote: > On Sun, May 08, 2022 at 06:51:59PM +0200, Pali Rohár wrote: > > Russell, is there any option to ignore speed information stored in SFP > > EEPROM and try to choose speed at linux runtime? > > If sfp_parse_support() fills in a support mask containing both > 1000base-X and 2500base-X, then yes. By default, phylink will choose > 2500base-X because that's the fastest speed. ethtool will report that > both 1000base-X and 2500base-X is supported, and 2500base-X is being > advertised. > > If you change the advertisement to 1000base-X, then phylink will switch > to 1000base-X, and vice versa. I see... > > And how to correctly handle behavior of SFP module which changes speed > > during usage time? > > I know of no way that a SFP module can signal to the host that its host > interface has changed in some way. There is no provision for a module to > state what the host interface actually is of the module - most of what > the kernel does is heuristics based on modules that I've had available. One GPON module which I tested, signals TX_FAULT when CPU tried to link at wrong speed. This is just my observation, nor sure if it is coincidence... So when kernel set phylink to 2500base-x and GPON SFP module expected CPU to set phylink to 1000base-x then kernel received TX_FAULT. After I switched 2500base-x to 1000base-x TX_FAULT stopped and link started working. Btw, what does TX_FAULT signal means? > SFPs suck in this regard. GPON SFPs suck way harder because they claim > SFP MSA compliance but they always seem to be violating the SFP MSA in > some regard. Yes, this sucks. Importance is that GPON ONU/ONT box (either in media box form factor or SFP form factor) is compliant to GPON standards and then that is also compliant to the vendor OMCI extension for correct provisioning from vendor OLT. For SFP the last importance is that it works in vendor's media box with SFP cage. And that is all. Nobody care about SFF standards compliance. I do not know what we can done here. Maybe SFP subsystem should cycle between phy modes returned by sfp_parse_support() until one start working? Dedicated GPON media boxes are in better shape because they have RJ45 with copper ethernet over twisted pair and this has standardized autonegotiation of speed. So here if provisioning force speed 1Gbps then on LAN RJ45 port is mode changed to 1000base-t. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-05-09 17:08 ` Pali Rohár @ 2022-05-09 20:27 ` Russell King (Oracle) 0 siblings, 0 replies; 18+ messages in thread From: Russell King (Oracle) @ 2022-05-09 20:27 UTC (permalink / raw) To: Pali Rohár; +Cc: Giammarco lynx, linux-arm-kernel On Mon, May 09, 2022 at 07:08:32PM +0200, Pali Rohár wrote: > One GPON module which I tested, signals TX_FAULT when CPU tried to link > at wrong speed. This is just my observation, nor sure if it is > coincidence... > > So when kernel set phylink to 2500base-x and GPON SFP module expected > CPU to set phylink to 1000base-x then kernel received TX_FAULT. After I > switched 2500base-x to 1000base-x TX_FAULT stopped and link started > working. If that's what that GPON module does, that's another invention by a GPON SFP manufacturer. > Btw, what does TX_FAULT signal means? In the SFP MSA, an asserted TX_FAULT means that there is some kind of laser fault with the module. So, using TX_FAULT to signal "host, you got the interface speed wrong" is very much some GPON module manufacturers invention. > Yes, this sucks. Importance is that GPON ONU/ONT box (either in media > box form factor or SFP form factor) is compliant to GPON standards and > then that is also compliant to the vendor OMCI extension for correct > provisioning from vendor OLT. For SFP the last importance is that it > works in vendor's media box with SFP cage. And that is all. Nobody care > about SFF standards compliance. > > I do not know what we can done here. Maybe SFP subsystem should cycle > between phy modes returned by sfp_parse_support() until one start > working? > > Dedicated GPON media boxes are in better shape because they have RJ45 > with copper ethernet over twisted pair and this has standardized > autonegotiation of speed. So here if provisioning force speed 1Gbps then > on LAN RJ45 port is mode changed to 1000base-t. Maybe the right answer is we just stop trying to support GPON modules with all their random manufacturer specific quirks and odd behaviours. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-07 23:01 ` Russell King (Oracle) 2022-03-08 10:08 ` Giammarco lynx @ 2022-05-08 16:31 ` Pali Rohár 2022-05-09 11:13 ` Giammarco lynx [not found] ` <dc809ba8-ec64-4ba7-a8e1-60c24bd30296@Spark> 1 sibling, 2 replies; 18+ messages in thread From: Pali Rohár @ 2022-05-08 16:31 UTC (permalink / raw) To: Russell King (Oracle); +Cc: Giammarco lynx, linux-arm-kernel Hello! On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote: > > > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > > [ 86.067758] sfp sfp-eth3: module OEM V2801F > > > rev 1.0 sn 202101195032 dc 210119 > > > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > > > inband/1000base-x with support 0000000,00000200,00000440 > > > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 > > We've now detected what the module is, and we configure for it, which > the EEPROM indicates it supports 1200Mbaud, which is 1G speed. ... > > > In that way it goes up. So how can we avoid this behaviour? > > Very difficult to avoid it. My guess is that when you power up the > system with the module inserted, it sees the interface operating at > 2.5G speed and locks itself to 2.5G speed. > > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM > indicates that it supports 1G speed, so we switch the host interface > to 1000base-X, and that causes link to be lost (although I don't see > any sign of that happening in your debug.) > > That means that the module has decided to use 2.5G speed, but its > reporting it supports 1G speed in the EEPROM... so its doing something > different. No surprises that the link fails to come up. > > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this > module using the sfp_quirk_2500basex function to also indicate it > supports 2.5G speed: > > }, { > // VSOL/CarlitoxxPro SFP can also work at 2.5G speed > .part = "V2801F", > .modes = sfp_quirk_2500basex, RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP cannot operate on CPU side at 2500base-x nor in other way at 2.5G. Trying to "force" mode to 2500base-x would not work. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-05-08 16:31 ` Pali Rohár @ 2022-05-09 11:13 ` Giammarco lynx 2022-05-09 11:24 ` Pali Rohár [not found] ` <dc809ba8-ec64-4ba7-a8e1-60c24bd30296@Spark> 1 sibling, 1 reply; 18+ messages in thread From: Giammarco lynx @ 2022-05-09 11:13 UTC (permalink / raw) To: Pali Rohár; +Cc: Russell King (Oracle), linux-arm-kernel Hi Pali, no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support HiSGMII mode. I’m currently running another stick (DFP-34X-C2C) at 2.5GbE with my FTTH line here in Italy :) the problem seems related only to SFP driver of macchiato-bin, into a BCM57810s, the stick is working as expected ;) Il giorno dom 8 mag 2022 alle ore 18:31 Pali Rohár <pali@kernel.org> ha scritto: > > Hello! > > On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote: > > > > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > > > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > > > [ 86.067758] sfp sfp-eth3: module OEM V2801F > > > > rev 1.0 sn 202101195032 dc 210119 > > > > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > > > > inband/1000base-x with support 0000000,00000200,00000440 > > > > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 > > > > We've now detected what the module is, and we configure for it, which > > the EEPROM indicates it supports 1200Mbaud, which is 1G speed. > ... > > > > In that way it goes up. So how can we avoid this behaviour? > > > > Very difficult to avoid it. My guess is that when you power up the > > system with the module inserted, it sees the interface operating at > > 2.5G speed and locks itself to 2.5G speed. > > > > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM > > indicates that it supports 1G speed, so we switch the host interface > > to 1000base-X, and that causes link to be lost (although I don't see > > any sign of that happening in your debug.) > > > > That means that the module has decided to use 2.5G speed, but its > > reporting it supports 1G speed in the EEPROM... so its doing something > > different. No surprises that the link fails to come up. > > > > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this > > module using the sfp_quirk_2500basex function to also indicate it > > supports 2.5G speed: > > > > }, { > > // VSOL/CarlitoxxPro SFP can also work at 2.5G speed > > .part = "V2801F", > > .modes = sfp_quirk_2500basex, > > RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP > cannot operate on CPU side at 2500base-x nor in other way at 2.5G. > > Trying to "force" mode to 2500base-x would not work. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-05-09 11:13 ` Giammarco lynx @ 2022-05-09 11:24 ` Pali Rohár 0 siblings, 0 replies; 18+ messages in thread From: Pali Rohár @ 2022-05-09 11:24 UTC (permalink / raw) To: Giammarco lynx; +Cc: Russell King (Oracle), linux-arm-kernel On Monday 09 May 2022 13:13:04 Giammarco lynx wrote: > Hi Pali, > > no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support > HiSGMII mode. Hello! That is really interesting, because I was told that RTL8672 and RTL9601C support only 1000base-x. Maybe RTL9601CI and RTL9601D chips are new version with support for 2500base-x? I have no idea. Anyway, if you have some datasheet or source of information that it supports 2500base-x mode, I would really like to see it. > I’m currently running another stick (DFP-34X-C2C) at > 2.5GbE with my FTTH line here in Italy :) > > the problem seems related only to SFP driver of macchiato-bin, into a > BCM57810s, the stick is working as expected ;) > > Il giorno dom 8 mag 2022 alle ore 18:31 Pali Rohár <pali@kernel.org> ha scritto: > > > > Hello! > > > > On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote: > > > > > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > > > > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > > > > [ 86.067758] sfp sfp-eth3: module OEM V2801F > > > > > rev 1.0 sn 202101195032 dc 210119 > > > > > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > > > > > inband/1000base-x with support 0000000,00000200,00000440 > > > > > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 > > > > > > We've now detected what the module is, and we configure for it, which > > > the EEPROM indicates it supports 1200Mbaud, which is 1G speed. > > ... > > > > > In that way it goes up. So how can we avoid this behaviour? > > > > > > Very difficult to avoid it. My guess is that when you power up the > > > system with the module inserted, it sees the interface operating at > > > 2.5G speed and locks itself to 2.5G speed. > > > > > > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM > > > indicates that it supports 1G speed, so we switch the host interface > > > to 1000base-X, and that causes link to be lost (although I don't see > > > any sign of that happening in your debug.) > > > > > > That means that the module has decided to use 2.5G speed, but its > > > reporting it supports 1G speed in the EEPROM... so its doing something > > > different. No surprises that the link fails to come up. > > > > > > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this > > > module using the sfp_quirk_2500basex function to also indicate it > > > supports 2.5G speed: > > > > > > }, { > > > // VSOL/CarlitoxxPro SFP can also work at 2.5G speed > > > .part = "V2801F", > > > .modes = sfp_quirk_2500basex, > > > > RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP > > cannot operate on CPU side at 2500base-x nor in other way at 2.5G. > > > > Trying to "force" mode to 2500base-x would not work. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <dc809ba8-ec64-4ba7-a8e1-60c24bd30296@Spark>]
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) [not found] ` <dc809ba8-ec64-4ba7-a8e1-60c24bd30296@Spark> @ 2022-05-09 15:47 ` Russell King (Oracle) 0 siblings, 0 replies; 18+ messages in thread From: Russell King (Oracle) @ 2022-05-09 15:47 UTC (permalink / raw) To: les stich; +Cc: Pali Rohár, linux-arm-kernel On Mon, May 09, 2022 at 01:09:52PM +0200, les stich wrote: > Hi Pali, > > no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support HiSGMII mode. I’m currently running another stick (DFP-34X-C2C) at 2.5GbE with my FTTH line here in Italy :) > > the problem seems related only to SFP driver of macchiato-bin, into a BCM57810s, the stick is working as expected ;) It's entirely possible that the problem is not software, but hardware. GPON modules have a dying gasp signal on one of the pins, which if memory serves me correctly, is set to the wrong logic sense on the SolidRun Clearfog A388 and Macchiatobin platforms. I seem to remember that the GPON modules I have don't work in either of these machines for this reason. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) 2022-03-07 20:12 ` Giammarco lynx 2022-03-07 23:01 ` Russell King (Oracle) @ 2022-05-08 16:38 ` Pali Rohár 1 sibling, 0 replies; 18+ messages in thread From: Pali Rohár @ 2022-05-08 16:38 UTC (permalink / raw) To: Giammarco lynx; +Cc: Russell King (Oracle), linux-arm-kernel On Monday 07 March 2022 21:12:45 Giammarco lynx wrote: > adding > > linux-arm-kernel@lists.infradead.org > > Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx > <stich86@gmail.com> ha scritto: > > > > ok, doing in the way that you suggest, the link is bringing up. > > Here is the logs (without ifconfig eth3 up and module plugged): > > > > [ 3.035643] mvpp2 f4000000.ethernet eth3: Using firmware node mac > > address 00:51:82:11:22:03 > > [ 11.872410] sfp sfp-eth3: Host maximum power 2.0W > > [ 11.877149] sfp sfp-eth3: tx disable 1 -> 1 > > [ 11.877155] sfp sfp-eth3: SM: enter empty:detached:down event insert > > [ 11.877159] sfp sfp-eth3: SM: exit probe:detached:down > > [ 11.877410] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach > > [ 11.877414] sfp sfp-eth3: SM: exit probe:down:down > > [ 12.180129] sfp sfp-eth3: SM: enter probe:down:down event timeout > > [ 12.187906] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > [ 12.194814] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > [ 12.242005] sfp sfp-eth3: module OEM V2801F > > rev 1.0 sn 202101195032 dc 210119 > > [ 12.251800] mvpp2 f4000000.ethernet eth3: requesting link mode > > inband/1000base-x with support 0000000,00000200,00000440 > > [ 12.251804] mvpp2 f4000000.ethernet eth3: switched to > > inband/1000base-x link mode > > [ 12.259318] sfp sfp-eth3: SM: exit present:down:down > > [ 12.270123] sfp sfp-eth3: skipping hwmon device registration due to > > broken EEPROM > > [ 12.277636] sfp sfp-eth3: diagnostic EEPROM area cannot be read > > atomically to guarantee data coherency > > [ 35.174143] mvpp2 f4000000.ethernet eth3: configuring for > > inband/1000base-x link mode > > [ 35.182026] mvpp2 f4000000.ethernet eth3: major config 1000base-x > > [ 35.188158] mvpp2 f4000000.ethernet eth3: phylink_mac_config: > > mode=inband/1000base-x/Unknown/Unknown adv=0000000,00000200,00000440 > > pause=04 link=0 an=1 > > [ 35.202945] sfp sfp-eth3: SM: enter present:down:down event dev_up > > [ 35.209152] sfp sfp-eth3: tx disable 1 -> 0 > > [ 35.213387] sfp sfp-eth3: SM: exit present:up:wait > > [ 35.280129] sfp sfp-eth3: SM: enter present:up:wait event timeout > > [ 35.286253] sfp sfp-eth3: SM: exit present:up:link_up > > [ 56.097724] sfp sfp-eth3: los 0 -> 1 > > [ 56.101324] sfp sfp-eth3: SM: enter present:up:link_up event los_high > > [ 56.107792] sfp sfp-eth3: SM: exit present:up:link_up > > [ 56.112876] sfp sfp-eth3: mod-def0 1 -> 0 > > [ 56.116903] sfp sfp-eth3: tx-fault 0 -> 1 > > [ 56.120933] sfp sfp-eth3: SM: enter present:up:link_up event remove > > > > Then after "ifconfig eth3 up" i've removed and reinserted the SFP, > > this is the log: > > > > [ 56.127227] sfp sfp-eth3: module removed > > [ 56.131175] sfp sfp-eth3: tx disable 0 -> 1 > > [ 56.135432] sfp sfp-eth3: SM: exit empty:up:down > > [ 56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault > > [ 56.146103] sfp sfp-eth3: SM: exit empty:up:down > > [ 59.350731] sfp sfp-eth3: mod-def0 0 -> 1 > > [ 59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert > > [ 59.360619] sfp sfp-eth3: SM: exit probe:up:down > > [ 59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 59.686185] sfp sfp-eth3: SM: exit probe:up:down > > [ 59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 59.806179] sfp sfp-eth3: SM: exit probe:up:down > > [ 59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 59.926179] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.046178] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.166178] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.276177] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.386178] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.506177] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.626176] sfp sfp-eth3: SM: exit probe:up:down > > [ 60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 60.746177] sfp sfp-eth3: please wait, module slow to respond > > [ 60.751982] sfp sfp-eth3: SM: exit probe:up:down > > [ 65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 65.846262] sfp sfp-eth3: SM: exit probe:up:down > > [ 70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 70.876192] sfp sfp-eth3: SM: exit probe:up:down > > [ 75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 75.926196] sfp sfp-eth3: SM: exit probe:up:down > > [ 80.896801] mvpp2 f4000000.ethernet eth3: mac link up > > [ 80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 80.966183] sfp sfp-eth3: SM: exit probe:up:down > > [ 81.330385] sfp sfp-eth3: los 1 -> 0 > > [ 81.333978] sfp sfp-eth3: tx-fault 1 -> 0 > > [ 81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear > > [ 81.344044] sfp sfp-eth3: SM: exit probe:up:down > > [ 81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low > > [ 81.354629] sfp sfp-eth3: SM: exit probe:up:down > > [ 86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout > > [ 86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM > > [ 86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time > > [ 86.067758] sfp sfp-eth3: module OEM V2801F > > rev 1.0 sn 202101195032 dc 210119 > > [ 86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode > > inband/1000base-x with support 0000000,00000200,00000440 > > [ 86.088390] sfp sfp-eth3: tx disable 1 -> 0 > > [ 86.092636] sfp sfp-eth3: SM: exit present:up:wait > > [ 86.097448] sfp sfp-eth3: skipping hwmon device registration due to > > broken EEPROM > > [ 86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read > > atomically to guarantee data coherency > > [ 86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout > > [ 86.166252] sfp sfp-eth3: SM: exit present:up:link_up > > [ 86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full - > > flow control off > > [ 86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready > > > > In that way it goes up. So how can we avoid this behaviour? > > > > Thanks Hello! This looks like that your GPON ONT/ONU SFP module is incompatible with GPON OLT to which it is connected. All GPON ONT/ONU units must be fully configurable from OLT, including LAN part of ONU (link between SFP module and your CPU) and therefore it is up to the OLT when it says that LAN part is up. Mostly I saw these issues with GPON ONT/ONU modules from vendor A connected to GPON OLT from vendor B. Generally, you cannot do nothing :-( just replace SFP module by another one which would be from the same vendor as your ISP's OLT. Sometimes may help changing some settings in SFP module or on OLT side, but both changes can be done only via OMCI protocol and only from OLT management console / web interface. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-05-09 20:28 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAJbjdrQbAd01WmW-ZQ9d9QKAtUqbQcRkpadtfSH94o9ZUqkhAg@mail.gmail.com> 2022-03-07 16:18 ` Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS) Giammarco lynx 2022-03-07 17:13 ` Russell King (Oracle) [not found] ` <CAJbjdrRiJMnQJEDCABOVxFyaqnSdBbq7Q-ixqBwW2ni49+gfgQ@mail.gmail.com> [not found] ` <YiZZbskbuqq+I2PW@shell.armlinux.org.uk> [not found] ` <CAJbjdrReN4B0XXFFLaTsPj_graAkguQPzP4xtRGbHeGozbJycQ@mail.gmail.com> 2022-03-07 20:12 ` Giammarco lynx 2022-03-07 23:01 ` Russell King (Oracle) 2022-03-08 10:08 ` Giammarco lynx 2022-03-08 11:15 ` Russell King (Oracle) 2022-03-08 11:54 ` Giammarco lynx 2022-03-08 12:12 ` Russell King (Oracle) [not found] ` <CAJbjdrSRcGVavaWJHuO3_RnP8A30b_ZQS_yAUCUWKCqxrUMwLw@mail.gmail.com> [not found] ` <Yid39zuckqVLVJts@shell.armlinux.org.uk> 2022-03-08 15:51 ` Giammarco lynx 2022-05-08 16:51 ` Pali Rohár 2022-05-09 15:41 ` Russell King (Oracle) 2022-05-09 17:08 ` Pali Rohár 2022-05-09 20:27 ` Russell King (Oracle) 2022-05-08 16:31 ` Pali Rohár 2022-05-09 11:13 ` Giammarco lynx 2022-05-09 11:24 ` Pali Rohár [not found] ` <dc809ba8-ec64-4ba7-a8e1-60c24bd30296@Spark> 2022-05-09 15:47 ` Russell King (Oracle) 2022-05-08 16:38 ` Pali Rohár
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.