Unable to TX data on VSC8531

Unable to TX data on VSC8531

[Ron Eggler]

Hi,

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.

Thank you,
Ron

Re: Unable to TX data on VSC8531

[Andrew Lunn]

On Sun, Apr 30, 2023 at 07:08:21AM -0700, Ron Eggler wrote:
> Hi,
> 
> 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

So receive definitely works?

It is a long shot, but a couple of decades ago, i had a board where
the PHY came up in loopback mode. All transmits never went out the
cable, they just came straight back again.

When running tcpdump during transmit, do you see each packet twice?

Please run mii-tool on the interface. e.g. for my device:

mii-tool -vv enp2s0:
Using SIOCGMIIPHY=0x8947
enp2s0:: no link
  registers for MII PHY 0: 
    1040 79c9 001c c800 0de1 0000 0064 0000
    0000 0200 0000 0000 0000 0000 0000 2000
    0000 0000 ffff 0000 0000 0400 0f00 0f00
    319b 0053 1002 80d9 84ca 0000 0000 0000
  product info: vendor 00:e0:4c or 00:07:32, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: no link
  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control


	Andrew

Re: Unable to TX data on VSC8531

[Horatiu Vultur]

The 04/30/2023 07:08, Ron Eggler wrote:
> 
> Hi,

Hi Ron,

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

> 
> Thank you,
> Ron

-- 
/Horatiu

Re: Unable to TX data on VSC8531

[Ron Eggler]

Hi Andrew,

On 4/30/23 07:23, Andrew Lunn wrote:
> On Sun, Apr 30, 2023 at 07:08:21AM -0700, Ron Eggler wrote:
>> Hi,
>>
>> 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
> So receive definitely works?
It would appear so as I can monitor traffic that's on the line with 
tcpdump and my arp table sometimes gets populated when an arp broadcast 
for an incomplete entry in the table can be picked up (due to other 
traffic on the network).
> It is a long shot, but a couple of decades ago, i had a board where
> the PHY came up in loopback mode. All transmits never went out the
> cable, they just came straight back again.
>
> When running tcpdump during transmit, do you see each packet twice?

Good idea, I tried this out but cannot make out anything related to 
pings (or arp requests) in tcpdump when I ping at the same time.

However, one thing:

After a fresh rebootI executed:

# ping 192.168.1.222 -c 1

and see the following:

# ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
         inet 192.168.1.123  netmask 255.255.255.0  broadcast 192.168.1.255
         ether be:a8:27:1f:63:6e  txqueuelen 1000  (Ethernet)
         RX packets 469  bytes 103447 (101.0 KiB)
         RX errors 0  dropped 203  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 170

eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
         ether fe:92:66:6c:4e:24  txqueuelen 1000  (Ethernet)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 173

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536  metric 1
         inet 127.0.0.1  netmask 255.0.0.0
         loop  txqueuelen 1000  (Local Loopback)
         RX packets 1  bytes 112 (112.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 1  bytes 112 (112.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

it appears like the ping got sent to the loopback device instead of the 
eth0, is this possible?

The routing table looks like:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
192.168.1.0     *               255.255.255.0   U     0 0        0 eth0

What's going on here?

> Please run mii-tool on the interface. e.g. for my device:
>
> mii-tool -vv enp2s0:
> Using SIOCGMIIPHY=0x8947
> enp2s0:: no link
>    registers for MII PHY 0:
>      1040 79c9 001c c800 0de1 0000 0064 0000
>      0000 0200 0000 0000 0000 0000 0000 2000
>      0000 0000 ffff 0000 0000 0400 0f00 0f00
>      319b 0053 1002 80d9 84ca 0000 0000 0000
>    product info: vendor 00:e0:4c or 00:07:32, model 0 rev 0
>    basic mode:   autonegotiation enabled
>    basic status: no link
>    capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>    advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

I got the following:

# mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD, link ok
   registers for MII PHY 0:
     1040 796d 0007 0572 01e1 45e1 0007 2801
     0000 0300 4000 0000 0000 0000 0000 3000
     9000 0000 0008 0000 0000 0000 3201 1000
     0000 a020 a000 0000 802d 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:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD flow-control

-- 
Ron

Re: Unable to TX data on VSC8531

[Andrew Lunn]

> After a fresh rebootI executed:
> 
> # ping 192.168.1.222 -c 1
> 
> and see the following:
> 
> # ifconfig
> eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
>         inet 192.168.1.123  netmask 255.255.255.0  broadcast 192.168.1.255
>         ether be:a8:27:1f:63:6e  txqueuelen 1000  (Ethernet)
>         RX packets 469  bytes 103447 (101.0 KiB)
>         RX errors 0  dropped 203  overruns 0  frame 0
>         TX packets 0  bytes 0 (0.0 B)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>         device interrupt 170
> 
> eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
>         ether fe:92:66:6c:4e:24  txqueuelen 1000  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 0  bytes 0 (0.0 B)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>         device interrupt 173
> 
> lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536  metric 1
>         inet 127.0.0.1  netmask 255.0.0.0
>         loop  txqueuelen 1000  (Local Loopback)
>         RX packets 1  bytes 112 (112.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 1  bytes 112 (112.0 B)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> it appears like the ping got sent to the loopback device instead of the
> eth0, is this possible?

It is unlikely. Loopback is used for lots of things. Rather than -c 1,
leave it running. There should be an arp sent around once a
second. See if the statistics for lo go up at that rate.

> I got the following:
> 
> # mii-tool -vv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 100baseTx-FD, link ok
>   registers for MII PHY 0:
>     1040 796d 0007 0572 01e1 45e1 0007 2801
>     0000 0300 4000 0000 0000 0000 0000 3000
>     9000 0000 0008 0000 0000 0000 3201 1000
>     0000 a020 a000 0000 802d 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:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD flow-control

So you have the register values to answer Horatiu question.

   Andrew

Re: Unable to TX data on VSC8531

[Ron Eggler]

On 5/1/23 13:12, Andrew Lunn wrote:
>> After a fresh rebootI executed:
>>
>> # ping 192.168.1.222 -c 1
>>
>> and see the following:
>>
>> # ifconfig
>> eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
>>          inet 192.168.1.123  netmask 255.255.255.0  broadcast 192.168.1.255
>>          ether be:a8:27:1f:63:6e  txqueuelen 1000  (Ethernet)
>>          RX packets 469  bytes 103447 (101.0 KiB)
>>          RX errors 0  dropped 203  overruns 0  frame 0
>>          TX packets 0  bytes 0 (0.0 B)
>>          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>          device interrupt 170
>>
>> eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
>>          ether fe:92:66:6c:4e:24  txqueuelen 1000  (Ethernet)
>>          RX packets 0  bytes 0 (0.0 B)
>>          RX errors 0  dropped 0  overruns 0  frame 0
>>          TX packets 0  bytes 0 (0.0 B)
>>          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>          device interrupt 173
>>
>> lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536  metric 1
>>          inet 127.0.0.1  netmask 255.0.0.0
>>          loop  txqueuelen 1000  (Local Loopback)
>>          RX packets 1  bytes 112 (112.0 B)
>>          RX errors 0  dropped 0  overruns 0  frame 0
>>          TX packets 1  bytes 112 (112.0 B)
>>          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> it appears like the ping got sent to the loopback device instead of the
>> eth0, is this possible?
> It is unlikely. Loopback is used for lots of things. Rather than -c 1,
> leave it running. There should be an arp sent around once a
> second. See if the statistics for lo go up at that rate.
Yes, the TX packets on lo actually do increase every second or so when I 
have a ping running,
it's not 1 packet at a time but rather 3 or 4, it's nnot fully 
consistent, when I scroll back the TX packets on the lo interface 
increased like:

23
26
30
33
37
40

>> I got the following:
>>
>> # mii-tool -vv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 100baseTx-FD, link ok
>>    registers for MII PHY 0:
>>      1040 796d 0007 0572 01e1 45e1 0007 2801
>>      0000 0300 4000 0000 0000 0000 0000 3000
>>      9000 0000 0008 0000 0000 0000 3201 1000
>>      0000 a020 a000 0000 802d 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:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>>    link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD flow-control
> So you have the register values to answer Horatiu question.
Yes, I realized now only that mii-tool provides a pretty output like this.
Thanks for that!
-- 
Ron

Re: Unable to TX data on VSC8531

[Ron Eggler]

Hi Horatiu,

[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
   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
   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

-- 
Ron

Re: Unable to TX data on VSC8531

[Horatiu Vultur]

The 05/01/2023 13:34, Ron Eggler wrote:

Hi Ron,
> 
> Hi Horatiu,
> 
> [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?

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

> 
> --
> Ron

-- 
/Horatiu

Re: Unable to TX data on VSC8531

[Ron Eggler]

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

Re: Unable to TX data on VSC8531

[Horatiu Vultur]

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

That is one step foward :)

> 
> 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?

> 
> 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.
I would prefer to leave this to people who have more knowledge then me
to answer to this.

> 
> Thanks Horatiu,
> 
> this definitely showed clearly where there is a problem.
> 
> --
> 
> Ron
> 

-- 
/Horatiu

Re: Unable to TX data on VSC8531

[Ron Eggler]

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