lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ba220c3-1a89-69ff-4c90-e2777a0dd04e@mistywest.com>
Date: Tue, 2 May 2023 13:16:06 -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 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.

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).

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?

Thanks Horatiu,

this definitely showed clearly where there is a problem.

-- 

Ron


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ