Debugging EcoNet's MT7530 PHYs

Tue Jan 27 02:53:17 PST 2026

On Tue, Jan 27, 2026 at 11:43:00AM +0100, Caleb James DeLisle wrote:
> Hello, thank you Felix.
> 
> I have a small update: Even if the switch is otherwise untouched, even in
> the bootloader, setting BMCR_ANRESTART is fatal. The bootloader does seem to
> set BMCR_ANRESTART during startup, and BMCR_ANENABLE is set during
> operation. I gather I should define config_aneg and do some ritual in there,
> but mt7530.c and mtk-ge.c don't seem to be doing anything so I'm not sure
> where to look.

Are you resetting the PHYs in some way before accessing them?
Ie. either by using a reset register of the switch or by assigning
genphy_soft_reset to .soft_reset.

Especially if you are not sure the PHY is freshly reset before accessing
it from within Linux, check the page select register (0x1f in C22 mode).

Should that be non-zero you might not actually be touching what you
believe is the AN_RESTART bit, but maybe something entirely different
because you are operating on a different page of registers on which
register 0 isn't BMCR.

> 
> Currently working on getting the vendor OS going so I can try resetting the
> port and see if I can track down what they're doing.
> 
> Thanks,
> 
> Caleb
> 
> 
> On 27/01/2026 11:05, Felix Baumann wrote:
> > Hello arinc9,
> > 
> > maybe you have an idea or could help him out? :)
> > 
> > Regards
> > Felix Baumann
> > 
> > Am 25. Januar 2026 00:53:25 MEZ schrieb Caleb James DeLisle <cjd at cjdns.fr>:
> > > 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
> > > > 
> > > _______________________________________________
> > > openwrt-devel mailing list
> > > openwrt-devel at lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel