Contributor
New Contributorhi,
great to know that you can see some tx signals toggling.
Sorry, i understand your statement here:
When making networking command through the linux terminal, these GMII signals still seem to not be affected still.
Do you mean, you are only able to capture the tx signals at the beginning. After that even if you send networking commands, the signal tap does not trigger? Does Linux acknowledge the tx packets?
Maybe you have some idea? Perhaps the EMAC is expecting some specific GMII packets back? I have not yet hooked it up to the external PHY - so perhaps it needs some signals from an external PHY?
For GMII signals, i believe there are no handshaking required. You can check that with the loopback design that you have. The loopback rx and tx signals should be identical.
ContributorIn answer to the first question - yes, for instance using these commands:
sudo ip addr flush dev eth0
sudo ip addr add 192.168.70.5/24 dev eth0
sudo ip link set eth0 up
sudo ip addr flush dev eth1
sudo ip addr add 192.168.71.1/24 dev eth1
sudo ip link set eth1 upWe can observe effects in Linux:
root@localhost:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fid
lo: 181360 2510 0 0 0 0 0 0 181360 2510 0 0 0
eth0: 6660 25 0 0 0 0 0 0 9662 61 0 0 0
eth1: 6360 20 0 0 0 0 0 0 10132 68 0 0 0
eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0
root@localhost:~# ping -I 192.168.71.1 192.168.70.5
PING 192.168.70.5 (192.168.70.5) from 192.168.71.1 : 56(84) bytes of data.
64 bytes from 192.168.70.5: icmp_seq=1 ttl=64 time=0.148 ms
64 bytes from 192.168.70.5: icmp_seq=2 ttl=64 time=0.030 ms
64 bytes from 192.168.70.5: icmp_seq=3 ttl=64 time=0.061 ms
64 bytes from 192.168.70.5: icmp_seq=4 ttl=64 time=0.017 ms
64 bytes from 192.168.70.5: icmp_seq=5 ttl=64 time=0.029 ms
root@localhost:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fid
lo: 204920 2840 0 0 0 0 0 0 204920 2840 0 0 0
eth0: 6660 25 0 0 0 0 0 0 9662 61 0 0 0
eth1: 6360 20 0 0 0 0 0 0 10132 68 0 0 0
eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0Similarly:
root@localhost:~# ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group defaul0
link/ether aa:b3:a3:d6:4e:04 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
7200 34 0 0 0 0
TX: bytes packets errors dropped carrier collsns
9662 61 0 0 0 0
root@localhost:~# ping -I 192.168.70.5 192.168.71.1
PING 192.168.71.1 (192.168.71.1) from 192.168.70.5 : 56(84) bytes of data.
64 bytes from 192.168.71.1: icmp_seq=1 ttl=64 time=0.155 ms
64 bytes from 192.168.71.1: icmp_seq=2 ttl=64 time=0.033 ms
64 bytes from 192.168.71.1: icmp_seq=3 ttl=64 time=0.025 ms
...
root@localhost:~# ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group defaul0
link/ether aa:b3:a3:d6:4e:04 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
7200 34 0 0 0 0
TX: bytes packets errors dropped carrier collsns
9662 61 0 0 0 0And arping has the same effect:
root@localhost:~# sudo arping -I eth1 -c 50 192.168.70.5
ARPING 192.168.70.5
Timeout
Timeout
Timeout
Timeout
root@localhost:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fid
lo: 250716 3484 0 0 0 0 0 0 250716 3484 0 0 0
eth0: 6960 30 0 0 0 0 0 0 9662 61 0 0 0
eth1: 6360 20 0 0 0 0 0 0 10422 73 0 0 0
eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0I think it means that the packets are not even trying to exit via the GMII interface. Is this correct? If so - maybe there is a solution?
New Contributorhi,
thank you for the clarifications.
If ping works and you can see the signals toggling, i believe the loopback design is working from hardware perspective. The original issue for the discussion is actually solved right?
For the arping timeout. I believe we need to investigate from Linux.
From your screenshot, i can see that the tx packet from cat /proc/net/dev actually increased. I am not sure if the increment from 68 to 73 for tx is due to the arping. Could you please help to check that?
If the answer is yes, maybe there are configurations needed to handle looped ARP packets.
These are the things that i have found to bypass some checks in linux:
echo 1 > /proc/sys/net/ipv4/conf/eth1/accept_localecho 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignoreecho 1 > /proc/sys/net/ipv4/conf/eth1/rp_filterHere are the commands that you can use to debug further:
tcpdump -i eth1 -e -vvThanks - I will try this and see if it works
