Message-ID: <eecbad1b-8c38-da98-60e8-5091ca7131ca@mistywest.com>
Date: Thu, 4 May 2023 12:25:28 -0700
From: Ron Eggler <ron.eggler@...tywest.com>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc: netdev@...r.kernel.org
Subject: Re: Unable to TX data on VSC8531

Hi Horatiu,

On 2023-05-02 1:50 p.m., Horatiu Vultur wrote:
> The 05/02/2023 13:16, Ron Eggler wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>>
>> On 2023-05-02 12:11 a.m., Horatiu Vultur wrote:
>>> The 05/01/2023 13:34, Ron Eggler wrote:
>>>
>>> [snip greetings]
>>>
>>>>> I've posted here previously about the bring up of two network interfaces
>>>>> on an embedded platform that is using two the Microsemi VSC8531 PHYs.
>>>>> (previous thread: issues to bring up two VSC8531 PHYs, Thanks to Heiner
>>>>> Kallweit & Andrew Lunn).
>>>>> I'm able to seemingly fully access & operate the network interfaces
>>>>> through ifconfig (and the ip commands) and I set the ip address to match
>>>>> my /24 network. However, while it looks like I can receive & see traffic
>>>>> on the line with tcpdump, it appears like none of my frames can go out
>>>>> in TX direction and hence entries in my arp table mostly remain
>>>>> incomplete (and if there actually happens to be a complete entry,
>>>>> sending anything to it doesn't seem to work and the TX counters in
>>>>> ifconfig stay at 0. How can I further troubleshoot this? I have set the
>>>>> phy-mode to rgmii-id in the device tree and have experimented with all
>>>>> the TX_CLK delay register settings in the PHY but have failed to make
>>>>> any progress.
>>>>> Some of the VSC phys have this COMA mode, and then you need to pull
>>>>> down a GPIO to take it out of this mode. I looked a little bit but I
>>>>> didn't find anything like this for VSC8531 but maybe you can double
>>>>> check this. But in that case both the RX and TX will not work.
>>>>> Are there any errors seen in the registers 16 (0x10) or register 17
>>>>> (0x11)?
>>>> Good point rewgarding the COMA mode, I have not found anything like it.
>>>> The RGMII connectivity should be pretty straight forward per the
>>>> datasheet, TX0-TX4, TX_CLK, TX_CTL, RXD0-RXD4, RX_CLK & RX_CTL.
>>>> Not sure if you've seen this in the subthread that is  ongoing with
>>>> Andrew Lunn but as part of it, I did invoke the mii-tool and got a
>>>> pretty printout of the PHY registers, see below:
>>>>
>>>> # mii-tool -vv eth0
>>>> Using SIOCGMIIPHY=0x8947
>>>> eth0: negotiated 100baseTx-FD, link ok
>>>>     registers for MII PHY 0:
>>>>       1040 796d 0007 0572 01e1 45e1 0005 2801
>>>>       0000 0300 4000 0000 0000 0000 0000 3000
>>>>       9000 0000 0008 0000 0000 0000 3201 1000
>>>>       0000 a020 0000 0000 802d 0021 0400 0000
>>> Unfortunetly, I can't see anything obvious wrong with the registers.
>>>
>>>>     product info: vendor 00:01:c1, model 23 rev 2
>>>>     basic mode:   autonegotiation enabled
>>>>     basic status: autonegotiation complete, link ok
>>>>     capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>>>> 10baseT-FD 10baseT-HD
>>>>     advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>>> Are you expecting to run at 100Mbit?
>> that's right and expected.
>>>>     link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>>>> 10baseT-FD 10baseT-HD flow-control
>>>>
>>>> Alternartively, the registers can be read with phytool also:
>>>>
>>>> # phytool read eth0/0/0x10
>>>> 0x9000
>>>> # phytool read eth0/0/0x11
>>>> 0000
>>> Another thing that you can try, is to put a probe and see if you
>>> actually see the TXCLK? And if I understand correctly that should be at
>>> 25MHz (because the link speed is 100Mbit).
>> Ah, that's a problem:
>> I did probe and the clock I probe is at 2.5MHz, not 25.
> That is one step foward :)
Sure is! I actually found that my TX_CLK is always at 2.5MHz and doesn't 
go to 25MHz(100BaseT) or 125 (1000BaseT).
>> Just to try out, I also temporarily connected it to 1000baseT:
>>
>> # mii-tool -vv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 1000baseT-FD flow-control, link ok
>>    registers for MII PHY 0:
>>      1040 796d 0007 0572 01e1 c1e1 000d 2001
>>      4d47 0300 3800 0000 0000 0000 0000 3000
>>      0000 9000 0008 0000 0000 0000 3201 1000
>>      0000 a020 a000 0000 a035 0021 0400 0000
>>    product info: vendor 00:01:c1, model 23 rev 2
>>    basic mode:   autonegotiation enabled
>>    basic status: autonegotiation complete, link ok
>>    capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>    advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
>> 10baseT-HD
>>    link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>
>> and even here, the TX_CLK remained at 2.5MHz (mind the scope I'm using
>> only goes up to 70MHz but I surely would not expect it to show me a
>> clear clock at 2.5MHz for a faster frequency).
> Then in theory if you force the speed to be 10Mbit, will it work?
I hooked it up to a anopther box, poin-to-point and used:

# ethtool -s eth0 speed 10 duplex half autoneg off mdix auto

on both hosts to force the speed to 10Mbps but I still had problems: 
Data would not make it out onto the line and the ifconfig TX counters 
remained at 0 for eth0 (but the counters on my lo interface incremented 
instead)

>
>> It appears to be "stuck" at 10MBit speed. Also it is at 2.5V instead of
>> 1.8V.
>>
>> Would I be able to configure this through device tree setting?
> I am not sure, if this is possible, shouldn't be a configuration option
> on the MAC side? As if I understand correctly, the MAC should generate
> the TX_CLK in RGMII regardless of the speed.
that is my understanding too, I'm expecting that some option on the MPU 
side is misconfigured. I'm digging through the datasheets.
> I would prefer to leave this to people who have more knowledge then me
> to answer to this.
Yeah, thanks! Your assistance has been very helpful until here!
-- 
Ron

Powered by blists - more mailing lists