Message-ID: <24146e10-5e9c-42f5-9bbe-fe69ddb01d95@broadcom.com>
Date: Tue, 24 Jun 2025 15:29:25 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>,
 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

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.

Good luck!
-- 
Florian

Powered by blists - more mailing lists