Linux/DM385: Wrong phy id from Marvell 88E1510

Mikael Nelson

Part Number: DM385

Tool/software: Linux

Hi Everyone,

I'm attempting to get our ethernet phy working and running into an issue. We are on a DM385 with a Marvell 88E1510 phy chip. The steps I've taken to get this chip working so far are:

1. Enable Marvell phy's in the kernel config

2. Patch the kernel's Marvell phy driver to add support for the 88E1510 ()

3. Bring the phy out of reset in uboot

At this point, upon bootup, davinci_mdio.c could probe the phy and would print:

davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
davinci_mdio davinci_mdio.0: detected phy mask fff7ffff
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[19]: device 0:13, driver unknown

At that point, I was able to modify the kernel's devices.c (arch/arm/mach-omap2/devices.c) to change the phy_id of cpsw_slaves[] from 0:00 to 0:13. After this change, CPSW could find the phy, however the id it gives is incorrect:

CPSW phy found : id is : 0x4820482
PHY 0:01 not found

From the modification to the marvell driver I made, the id should be 0x01410dd0, not 0x4820482. If I modify the driver to change the id to 0x4820482, davinci_mdio.c will correctly find the driver for the phy. Even though it finds the driver, it does not actually work.

Does anyone know why my phy id is coming back as 0x4820482 instead of 0x01410dd0?

Thanks!

over 8 years ago

0 Dwarakesh Radhakrishnan over 8 years ago

Guru 13660 points

Hi Mikael,

Have you checked if the pull up on the lines of MDIO are provided as specified ? Please do check the marvel requirement of MDIO/MDC

0 Mikael Nelson over 8 years ago in reply to Dwarakesh Radhakrishnan

Intellectual 645 points

Hi Dwarakesh,

Both our MDIO/MDC lines have 2.2k resistor pull ups on the lines.

Is there anything else you'd suggest looking at?

0 Dwarakesh Radhakrishnan over 8 years ago in reply to Mikael Nelson

Guru 13660 points

Hi,

You can probe the MDIO/MDC lines and check the signal is fine ?

0 Mikael Nelson over 8 years ago in reply to Dwarakesh Radhakrishnan

Intellectual 645 points

Hey Dwarakesh,

Yes, the MDIO/MDC signals look good. We see the bus is running at about 833KHz.

0 Dwarakesh Radhakrishnan over 8 years ago in reply to Mikael Nelson

Guru 13660 points

Hi Mikael,

Please do verify if the bootstrap configuration of PHY is fine. Also cross verify the above patch is configuring the PHY correctly at the init time.

0 Mikael Nelson over 8 years ago in reply to Dwarakesh Radhakrishnan

Intellectual 645 points

Hi Dwarakesh,

This might be the issue. I'm not very familiar with bringing up a phy, so I'm unsure of how to verify the bootstrap configuration. Could you provide me some direction so I can figure out how to do that?

Also, are you referring to the patch for the marvell driver in my first post? If so, we're not even getting to the point of loading the driver yet as far as I can tell. It won't load the driver until the phy id is returned correctly.

Thanks!

0 Mikael Nelson over 8 years ago in reply to Mikael Nelson

Intellectual 645 points

Hey Dwarakesh,

I've been looking into this a bit further and one thing that I notice that is wrong (not sure if it actually matters) is that the MDIO Clock is not calculated correctly.

in davinci_mdio.c's __davinci_mdio_reset, we get the clock rate for the mdio_in clock. This, on my system, gets reported as 150MHz.

The bus_freq that is configured in data->pdata.bus_freq is 1MHz.

The divisor calculation results in a value of 0x95.

The actual output that I'm seeing on the bus is actually 833KHz.

Working the numbers backwards, I see that the ACTUAL mdio_in clock is 125MHz.

From what I can gather, the mdio_in clock value is from cpsw_ick clock. Do you know where the 150MHz is getting set at?

Another interesting thing that I saw in the TRM is in section 2.3.2. It says:

The SATA SERDES also provides references for EMAC switch IP (125 MHz for GMII, 50 MHz RMII, 5 MHz RGMII).

Is this where the 125MHz is coming from? Since my phy is supposed to be using RGMII, should I actually be receiving a 5MHz clock?

Let me know what you think.

0 Dwarakesh Radhakrishnan over 8 years ago in reply to Mikael Nelson

Guru 13660 points

Hi,

You can select the RGMII in GMII_SEL register. Please use 0x48140650 address with devmem2 tool to set the value and check.

0 Dwarakesh Radhakrishnan over 8 years ago in reply to Dwarakesh Radhakrishnan

Guru 13660 points

Hi Mikael,

I just noticed your question properly. First SerDes clocks are different from peripheral clock(which is the cpsw_iclk or emac_iclk). cpsw_iclk is derived from sysclk5 which in turn from sysclk4, which is from L3_PLL settings. Please check you L3_PLL registers to cross-confirm, what is being configured. MDC as you rightly pointed out, derives from this clock. You can adjust the divisor and check the MDC value. You can make it to 1MHz as expected and check if it is making any difference. AFAI read, there is only maximum limitation in MDC clock which 2.5MHz from the DM38x end and 25MHz from the marvel. Irrespective of the RGMII/MII/MGII configuration, if MDIO/MDC is proper, then you will be getting proper PHY ID

0 Mikael Nelson over 8 years ago in reply to Dwarakesh Radhakrishnan

Intellectual 645 points

Looks like we're good, I'm reading a value of 0x33A (0b1100111010). This sets us to RGMII mode with no internal delay and RGMII enabled.

0 Dwarakesh Radhakrishnan over 8 years ago in reply to Mikael Nelson

Guru 13660 points

Good to hear, what was the issue ?

0 Mikael Nelson over 8 years ago in reply to Dwarakesh Radhakrishnan

Intellectual 645 points

Hey Dwarakesh,

Sorry, my last reply was misleading. I was just referring to the register contents as being correctly configured for RGMII. I'm still unable to detect the phy id correctly.

I've also tried adjusting the output clock to 1MHz by changing the div value however that also had no effect on the correct phy id detection.

Any other ideas?

Processors

Processors forum

Linux/DM385: Wrong phy id from Marvell 88E1510