Debugging EcoNet's MT7530 PHYs

[Caleb James DeLisle]

Oh sorry, one thing I completely forgot to mention:

I have the reset line labeled "GSW" configured - and it should be 
resetting one or maybe both switches. Also of course mt7530.c resets via 
MDIO. None of this affects the PHY, it still works until the first time 
BMCR_ANRESTART or BMCR_PDOWN is asserted.

Thanks,

Caleb


On 25/01/2026 00:45, Caleb James DeLisle wrote:
> Hello guys,
>
>
> I'm working on the DSA for the EN751221 and I think I'm a bit stuck.
>
>
> Background:
>
> This is a really strange configuration, there are actually two MT7530 
> switches. The first one is MMIO (vendor code says it's in the SoC 
> die), and the second one is MDIO (identified in vendor code as an 
> MCM). AFAICT the SoC switch is configured with only two ports active, 
> Port6->CPU and Port5->MCM Switch. The MCM switch and its PHYs are hung 
> off of the MDIO bus of the SoC switch, and to avoid collisions of PHY 
> numbers, the SoC switch uses PHYs numbered 8,9,10,11,12 in place of 
> 0,1,2,3,4. All of the PHYs (for both switches) identify as 03a2.9412, 
> except for #12 which ids as 03a2.9451.
>
> I THINK the configuration is that the SoC switch port 5 uses PHY#12 
> (borrowed from port4) to talk TRGMII to MCM switch port6, PHY#12 is 
> the odd one in terms of ID so it is probably a TRGMII passthrough.
>
> There is vendor code which seems to tune PHY#0 (similar to 
> mt7530_setup_port6() from linux/mt7530.c except with different 
> frequency), I gather these CORE_PLL_* are not actually modifying PHY#0 
> but rather it's a backdoor to controlling the whole switch (?). In the 
> vendor code, it also tunes PHY#12 exactly the same way, so I may 
> surmise that PHY#12 is the portal from the SoC switch to the MCM switch.
>
> What is clear and has been tested is that traffic flows into one of 
> the ports of the MCM switch, then from there it goes to port6 which is 
> connected to port5 of the SoC switch, then through port6 of the SoC 
> switch to the ETH engine. I just don't know what PHYs are being used 
> to do it.
>
> In any case, this isn't what's blocking me right now.
>
>
> The problem:
>
> Right now, I can get traffic to pass if I do not touch the phys at 
> all, but of course that's not going to be acceptable in upstream. So 
> I'm currently focusing on PHY#2 and trying to make it link up - I have 
> a cable plugged in to the relevant port. I gather PHY#2 can't possibly 
> be muxed with anything, so I shouldn't need to worry about anything 
> except what MDIO messages are sent to PHY#2 (I'm not even trying to 
> pass traffic, just see it's linked up, so even the switch could even 
> be kaput). Furthermore, since this is an MCM module, I gather it 
> should be identical silicon to the MCM switch in the MT7621, so to 
> just make it link up, I really shouldn't be having a lot of difficulty 
> (I am).
>
> I stubbed mt7530_phy_config_init() so it wouldn't change anything from 
> what the bootloader had set, and I isolated the problem to the call to 
> BMCR_ANRESTART. If this is not called, basically nothing on the PHY is 
> touched except for a small change to the , and I have a stable 
> connection. If this is called, I get flapping.
>
> I instrumented the write calls and excluded the c45 emulated reads, 
> this narrowed it down to just these writes:
>
> [ 56.471009] libphy: Old ADV = 05e1, new adv 0de0
> [ 56.491279] mt7530-mmio 1fb58000.switch: mt7531_ind_c22_phy_write(02, 
> 04, 0de1)
> [ 56.520118] libphy: bsmr =796d
> [ 56.524941] libphy: Old ctrl = 1c00, new ctrl 0200
> [ 56.592583] mt7530-mmio 1fb58000.switch: mt7531_ind_c22_phy_write(02, 
> 09, 1e00)
> [ 56.604261] mt7530-mmio 1fb58000.switch: mt7531_ind_c22_phy_write(02, 
> 00, 1200)
>
> ADV: Remove ADVERTISE_CSMA, add MAC_ASYM_PAUSE - I commented 
> out MAC_ASYM_PAUSE in the code, did not fix.
>
> CTRL1000: Add ADVERTISE_1000FULL - Confusing because vendor code also 
> sets ADVERTISE_1000FULL and I doubt MT7530 doesn't support it.
>
> BMCR: BMCR_ANRESTART is added.
>
> Trapping and stubbing out this one write saves the PHY. However, if I 
> do this, then bring it down (+BMCR_PDOWN) and back up again 
> (-BMCR_PDOWN), it also flaps and is unable to synchronize.
>
>
> Possibly related stuff:
>
> I traced through the vendor code and it seems to do the following on 
> setup (I translated it to Linux APIs):
>
> phy_write(phydev, MII_BMCR, BMCR_RESET);
> phy_write_mmd(phydev, MDIO_MMD_VEND2, 0x0417, 0x7775); // mystery 
> register + value
> phy_write_mmd(phydev, MDIO_MMD_VEND1, MTK_PHY_MCC_CTRL_AND_TX_POWER_CTRL,
>               FIELD_PREP(MTK_MCC_NEARECHO_OFFSET_MASK, 0x3) | 0x50); 
> // 0x50 is unknown
> phy_write(phydev, MII_CTRL1000, CTL1000_ENABLE_MASTER | 
> CTL1000_AS_MASTER |
>           CTL1000_PREFER_MASTER | ADVERTISE_1000FULL);
> phy_write(phydev, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART);
>
> So it sets BMCR_ANRESTART without a problem, is it plausible that 
> those other registers need to be hit every time it's reset?
>
>
> Also, the vendor code for configuring the connection between the two 
> switches contains this rather ominous line:
>
> mdio_cl22_write(0,0x1f,0x404,0x1d00); /* 362.5MHz*/
>
> I believe this SoC has a normal 25Mhz crystal, so this kind of implies 
> the switch is running at a totally unique frequency. This is set in 
> the bootloader and I leave it alone (for now), I'm not calling 
> mt7530_setup_port5 or mt7530_setup_port6. I didn't pay much attention 
> to the registers being hit in the switch itself - I assumed the PHY 
> should work even if the switch is messed up, but maybe this is not a 
> good assumption? Is there some register I should be paying attention 
> to on the switch during setup?
>
> FYI, I tried forcing a call to mt7530_pll_setup() on the MII switch, 
> this does not change behavior at all - either way, the PHY works 
> unless I touch it.
>
>
> So (sorry for the essay), any thoughts about what I should try next?
>
>
> Thanks,
>
> Caleb
>