Contributor
New ContributorHello K606 ,
You may have a typo for the rx clock.
Could you please try this?
assign emac1_mac_rx_clk_wire = emac0_mac_tx_clk_o_wire; // 1GThank you.
ContributorHi - so I changed this line. However, it seems the issue persists.
Do you know why this might be?
Please also note that the SoC system clocks are confirgured as followed:
root@localhost:~# cat /sys/kernel/debug/clk/clk_summary
enable prepare protect duty hardware
clock count count count rate accuracy phase cycle enable
-------------------------------------------------------------------------------------------------------
qspi-clk 1 1 0 200000000 0 0 50000 Y
osc1 2 2 0 25000000 0 0 50000 Y
periph_pll 1 1 0 2500000000 0 0 50000 Y
peri_pll_c3 1 1 0 500000000 0 0 50000 Y
psi_ref_free_clk 0 0 0 500000000 0 0 50000 Y
psi_ref_clk 0 0 0 500000000 0 0 50000 Y
s2f_user1_free_clk 0 0 0 500000000 0 0 50000 Y
s2f_user1_clk 0 0 0 500000000 0 0 50000 Y
s2f_user0_free_clk 0 0 0 500000000 0 0 50000 Y
s2f_user0_clk 0 0 0 500000000 0 0 50000 Y
emaca_free_clk 3 3 0 250000000 0 0 50000 Y
emac2_clk 1 1 0 250000000 0 0 50000 Y
emac1_clk 1 1 0 250000000 0 0 50000 Y
emac0_clk 1 1 0 250000000 0 0 50000 YSo it seems the clocks are active, but when sending a 'ping' from EMAC0 to EMAC1 - there is no activity on the GMII lines in Fabric (even though it seems the ping is working in userland in the HPS)
root@localhost:~# sudo ip addr add 192.168.70.5/24 dev eth0
root@localhost:~# sudo ip addr add 192.168.70.1/24 dev eth1
root@localhost:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.70.5 netmask 255.255.255.0 broadcast 0.0.0.0
ether 3e:17:2e:db:8b:f6 txqueuelen 1000 (Ethernet)
RX packets 60 bytes 19080 (19.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 168 bytes 27408 (27.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 23
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.70.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether 62:6f:4c:21:f2:f4 txqueuelen 1000 (Ethernet)
RX packets 59 bytes 18762 (18.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 170 bytes 27588 (27.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 40
...
root@localhost:~# ping -I 192.168.70.1 192.168.70.5
PING 192.168.70.5 (192.168.70.5) from 192.168.70.1 : 56(84) bytes of data.
64 bytes from 192.168.70.5: icmp_seq=1 ttl=64 time=0.189 ms
64 bytes from 192.168.70.5: icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from 192.168.70.5: icmp_seq=3 ttl=64 time=0.168 ms
64 bytes from 192.168.70.5: icmp_seq=4 ttl=64 time=0.042 ms
64 bytes from 192.168.70.5: icmp_seq=5 ttl=64 time=0.022 ms
64 bytes from 192.168.70.5: icmp_seq=6 ttl=64 time=0.009 ms
64 bytes from 192.168.70.5: icmp_seq=7 ttl=64 time=0.029 ms
64 bytes from 192.168.70.5: icmp_seq=8 ttl=64 time=0.020 ms
64 bytes from 192.168.70.5: icmp_seq=9 ttl=64 time=0.009 ms
64 bytes from 192.168.70.5: icmp_seq=10 ttl=64 time=0.034 ms
64 bytes from 192.168.70.5: icmp_seq=11 ttl=64 time=0.014 ms
64 bytes from 192.168.70.5: icmp_seq=12 ttl=64 time=0.012 ms
64 bytes from 192.168.70.5: icmp_seq=13 ttl=64 time=0.052 ms
64 bytes from 192.168.70.5: icmp_seq=14 ttl=64 time=0.025 ms
64 bytes from 192.168.70.5: icmp_seq=15 ttl=64 time=0.019 ms
^C
--- 192.168.70.5 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14335mshello,
thank you for the feedback.
May i know if ping is working before the change?
May i know what is the sampling clock for your signal tap?
For 1G speed you may need at least 250MHz sampling clock.
ContributorHi,
So far, the ping has never produced GMII toggles on SignalTap.
I have also tried using a PLL generated 250MHz clock to measure on signal tap (as can be seen in the following diagrams).
In the following, I disconnected the loopback and instead added a 'dummy' rx packet generator - then sent them to the EMAC rxd wire via Fabric:
gmii_rx_test_pattern u_rx_pattern (
.rx_clk(emac1_mac_tx_clk_o_wire),
.rstn(~system_reset),
.rxd(emac0_mac_rxd_wire),
.rx_dv(emac0_mac_rxdv_wire),
.rx_er(emac0_mac_rxer_wire)
);Which produces the following:
But it seems that on the Linux side these packets are not being acknowledged by the kernel:
root@localhost:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls card
lo: 115040 1600 0 0 0 0 0 0 115040 1600 0 0 0 0 0
eth0: 0 0 0 0 0 0 0 0 9136 56 0 0 0 0 0
eth1: 0 0 0 0 0 0 0 0 9316 58 0 0 0 0 0
eth2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0It also seems that sending ARPs do not produce GMII tx toggle in Fabric:
root@localhost:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.70.5 netmask 255.255.255.0 broadcast 0.0.0.0
ether ...
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56 bytes 9136 (9.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 23
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.71.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether ...
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67 bytes 9838 (9.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 40
root@localhost:~# sudo arping -I eth1 192.168.70.5
ARPING 192.168.70.5
Timeout
Timeout ...Hello,
may i know how did you trigger the signal tap?
is it possible to trigger on falling edge for either one of these?
emac1_mac_rxdv_wire
emac0_mac_txen_wire
emac0_mac_rxdv_wire
emac1_mac_txen_wire
As for why the rx packets are not acknowledge by the kernel, you may need to check the packet generator. My suggestion would be to get a known-good packet and reconstruct the packet generator from that.
Since you are able to get the signals for rx side, could you please try that again for loopback mode? This will show how the packet should look like.
