Contributor
New ContributorHello,
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.
ContributorHi thanks for the suggestion,
So as you suggested to do, I have set trigger points on these two nodes:
emac0_mac_txen_wire
emac1_mac_txen_wire
When running SignalTap with these as triggers, I am seeing some toggling on the txd line:
I am noticing that for the first few seconds or so, this pattern will continue - and then it will settle here and not update again (i.e. enable will not toggle)
This all happens without making any network commands in the Linux terminal.
When making networking command through the linux terminal, these GMII signals still seem to not be affected still.
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?
In terms of dummy packet generation, I have been using this module:
module gmii_rx_test_pattern #( parameter CLK_FREQ = 125_000_000 // RX clock frequency in Hz )( input wire rx_clk, // GMII RX clock (usually 125 MHz) input wire rstn, // Active low reset output reg [7:0] rxd, // GMII RX data to MAC output reg rx_dv, // Receive data valid output reg rx_er // Receive error ); // Pattern ROM (16 bytes example) reg [7:0] pattern [0:15]; initial begin pattern[0] = 8'h55; // Ethernet preamble pattern[1] = 8'h55; pattern[2] = 8'h55; pattern[3] = 8'h55; pattern[4] = 8'h55; pattern[5] = 8'h55; pattern[6] = 8'h55; pattern[7] = 8'hD5; // SFD pattern[8] = 8'hDE; // Example payload pattern[9] = 8'hAD; pattern[10] = 8'hBE; pattern[11] = 8'hEF; pattern[12] = 8'hCA; pattern[13] = 8'hFE; pattern[14] = 8'hBA; pattern[15] = 8'hBE; end reg [3:0] index; reg sending; always @(posedge rx_clk or negedge rstn) begin if (!rstn) begin rxd <= 8'd0; rx_dv <= 1'b0; rx_er <= 1'b0; index <= 4'd0; sending <= 1'b0; end else begin // Simple state machine to send pattern repeatedly if (!sending) begin rx_dv <= 1'b1; // Start of frame rx_er <= 1'b0; rxd <= pattern[0]; index <= 4'd1; sending <= 1'b1; end else begin rxd <= pattern[index]; index <= index + 1'b1; if (index == 4'd15) begin rx_dv <= 1'b0; // End of frame sending <= 1'b0; end end end end endmoduleI think it is OK. Please do correct me if not.
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 -vv
