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
