Message-ID: <20250625075441.6036223d@fedora.home>
Date: Wed, 25 Jun 2025 07:54:41 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>, "Russell King
 (Oracle)" <linux@...linux.org.uk>, Vladimir Oltean
 <vladimir.oltean@....com>, Marek Behún <kabel@...nel.org>,
 Robert Hancock <robert.hancock@...ian.com>, Tao Ren <rentao.bupt@...il.com>
Subject: Re: Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

Hi Florian,

On Tue, 24 Jun 2025 15:29:25 -0700
Florian Fainelli <florian.fainelli@...adcom.com> wrote:

> Howdy,
> 
> On 6/24/25 14:39, Maxime Chevallier wrote:
> > Hello everyone,
> > 
> > I'm reaching out to discuss an issue I've been facing with some SFP modules
> > that do SGMII to 100FX conversion.
> > 
> > I'm using that on a product that has 1G-only SFP cage, where SGMII or 1000BaseX
> > are the only options, and that product needs to talk to a 100FX link partner.
> > 
> > The only way this can ever work is with a media-converter PHY within the SFP,
> > and apparently such SFP exist :
> > 
> > https://www.fs.com/fr/products/37770.html?attribute=19567&id=335755
> > 
> > I've tried various SFP modules from FS, Prolabs and Phoenix Contact with
> > no luck. All these modules seem to integrate some variant of the
> > Broadcom BCM5641 PHYs.
> > 
> > I know that netdev@ isn't about fixing my local issues, but in the odd chance anyone
> > has ever either used such a module successfully, or has some insight on what is
> > going on with these Broadcom PHYs, I would appreciate a lot :) Any finding or
> > patch we can come-up with will be upstreamed of course :)
> > 
> > Any people with some experience on this PHY or this kind of module may be
> > able to shed some lights on the findings I was able to gather so far.
> > 
> > All modules have the same internal PHY, which exposes itself as a BCM5461 :
> > 
> > 	ID : 002060c1
> > 	
> > I know that because I was able to talk to the PHY using mdio over i2c, at
> > address 0x56 on the i2c bus. On some modules, the PHY doesn't reply at all,
> > on some it stalls the i2c bus if I try to do 16bits accesses (I have to use 8 bits
> > accesses), and on some modules the regular 16bits accesses work...
> > 
> > That alone makes me wonder if there's not some kind of firmware running in
> > there replying to mdio ?  
> 
> Unclear, but that ID is correct for the BCM5461 and its variants.
> 
> > 
> > Regarding what I can achieve with these, YMMV :
> > 
> >   - I have a pair of Prolabs module with the ID "CISCO-PROLABS     GLC-GE-100FX-C".
> > 
> >     These are the ones that can only do 8bits mdio accesses. When the PHY is
> >     left undriven by the kernel, and you plug it into an SGMII-able SFP port, you
> >     get a nice loop of 'link is up / link is down / link is up / ...' reported
> >     by the MAC (or PCS). Its eeprom doesn't even say that it's a 100fx module
> >     (id->base.e100_base_fx isn't set). It does say "Cisco compatible", maybe it's
> >     using some flavour of SGMII that I don't know about ?
> >     
> >   - I have a pair of FS modules with the ID "FS     SFP-GE-100FX". These behave
> >     almost exactly as the ones above, but it can be accessed with 16-bits mdio
> >     transactions.
> >     
> >   - I have a "PHOENIX CONTACT    2891081" that simply doesn't work
> >   
> >   - And maybe the most promising of all, a pair of "PROLABS    SFP-GE-100FX-C".
> >     These reply on 16bits mdio accesses, and when you plug them with the PHY
> >     undriven by the kernel (so relying only on internal config and straps), I
> >     get link-up detected by the MAC through inband SGMII, and I can receive
> >     traffic ! TX doesn't work though :(
> > 
> > On the MAC side, I tested with 3 different SoC, all using a different PCS :
> >   - A Turris Omnia, that uses mvneta and its PCS
> >   - A dwmac-socfpga board, using a Lynx / Altera TSE PCS to drive the SGMII
> >   - A KSZ9477 and its variant of DW XPCS.
> > 
> > The behaviour is the same on all of them, so I'd say there's a very good chance
> > the modules are acting up. TBH I don't know much about sourcing SFPs, they
> > behave so differently that it may just be that I didn't find the exact reference
> > that for some reason happens to work ?
> > 
> > The link-partner is a device that only does 100BaseX.
> > 
> > On all of these modules, I've tried to either let the PHY completely unmanaged
> > by the kernel, no mdio transactions whatsoever and we leave the default PHY
> > settings to their thing. As nothing worked, I've tried driving the PHY through
> > the kernel's broadcom.c driver, but that driver really doesn't support 100FX so
> > it's also expected that this doesn't work. Unfortunately, I don't have
> > access to any documentation for that PHY...
> > 
> > The driver does say, for a similar model :
> > 
> > 	/* The PHY is strapped in RGMII-fiber mode when INTERF_SEL[1:0]
> > 	 * is 01b, and the link between PHY and its link partner can be
> > 	 * either 1000Base-X or 100Base-FX.
> > 	 * RGMII-1000Base-X is properly supported, but RGMII-100Base-FX
> > 	 * support is still missing as of now.
> > 	 */
> > 
> > Not quite the same as our case as it's talking about RGMII, not SGMII, but
> > maybe the people who wrote that code know a bit more or have access to some
> > documentation ? I've tried to put these persons in CC :)  
> 
> Not sure if you can probe the various pins, but those that would be 
> interesting to measure would be:
> 
> LNKSPD[1] / INTF_SEL[0]
> LNKSPD[2] / INTF_SEL[1]
> RGMIIEN
> EN_10B/SD
> 
> You can forcibly enable RGMII operation by writing to register 0x18, 
> shadow 0b111 (MII_BCM54XX_AUXCTL_SHDWSEL_MISC) and setting bit 7 
> (MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_EN).
> 
>  > > In any case, should anyone want to give this a shot in the future,   
> I'm using the
> > following patch so that the SFP machinery can try to probe PHYs on these
> > non-copper modules - that patch needs splitting up and is more of a hack than
> > anything else.
> > 
> > Thanks a lot everyone, and sorry for the noise if this is misplaced,  
> 
> For 100BaseFX, the signal detection is configured in bit 5 of the shadow 
> 0b01100 in the 0x1C register. You can use bcm_{read,write}_shadow() for 
> that:
> 
> 0 to use EN_10B/SD as CMOS/TTL signal detect (default)
> 1 to use SD_100FX± as PECL signal detect
> 
> You can use either copper or SGMII interface for 100BaseFX and that will 
> be configured this way:
> 
> - in register 0x1C, shadow 0b10 (1000Base-T/100Base-TX/10Base-T Spare 
> Control 1), set bit 4 to 1 to enable 100BaseFX
> 
> - disable auto-negotiation with register 0x00 = 0x2100
> 
> - set register 0x18 to 0x430 (bit 10 -> normal mode, bits 5:4 control 
> the edge rate. 0b00 -> 4ns, 0b01 -> 5ns, 0b10 -> 3ns, 0b11 -> 0ns. This 
> is the auxiliary control register (MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL).
> 
> It's unclear from the datasheet whether 100BaseFX can work with RGMII.

Thank you so much ! I'm trying to achieve SGMII to 100FX, so I'll give
your instructions a try :) Thanks again for the quick answer, I'll let
you know how this goes,

Maxime

Powered by blists - more mailing lists