Re: Supporting SGMII to 100BaseFX SFP modules, with broadcom PHYs

Maxime Chevallier
2025-06-25T05:54:50Z

Hi Florian,

On Tue, 24 Jun 2025 15:29:25 -0700
Florian Fainelli <florian.fainelli@broadcom.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