TJA1120A 1000BASET1 Linux side configuration We are using TJA1120A PHY on our ECU board based on am72a7, and DP83TG721EVM-MC Media Converter. Right now the Link is ON root@am62axx-evm:~# dmesg | grep eth
[ 0.000000] psci: probing for conduit method from DT.
[ 0.944429] optee: probing for conduit method.
[ 1.352845] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006
[ 1.365779] am65-cpsw-nuss 8000000.ethernet: Use random MAC address
[ 1.452604] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5
[ 1.459737] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32
[ 1.467615] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1
[ 1.488042] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
[ 5.875382] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL)
[ 5.890378] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode
[ 6.618291] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL)
[ 6.629693] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode
[ 6.662963] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 38.194116] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[ 116.023614] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off I made TJA1120 eth0 to slave mode, and configured(HW Jumpers) master to Media converter root@am62axx-evm:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 1000baseT1/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 1000baseT1/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
master-slave cfg: forced slave
master-slave status: slave
Port: Twisted Pair
PHYAD: 4
Transceiver: external
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Current message level: 0x000020f7 (8439)
drv probe link ifdown ifup rx_err tx_err hw
Link detected: yes
SQI: 7/7 root@am62axx-evm:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 64:1C:10:1C:06:E2
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::661c:10ff:fe1c:6e2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:24044 (23.4 KiB) Now i have set my ECU to 192.168.1.100 and my PC(connected to Media Converter) to 192.168.1.101 Ping is not happening but LED indicators on ECU blink when I ping from my PC acs@a-tract-10:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.101 icmp_seq=1 Destination Host Unreachable
From 192.168.1.101 icmp_seq=2 Destination Host Unreachable
From 192.168.1.101 icmp_seq=3 Destination Host Unreachable
From 192.168.1.101 icmp_seq=4 Destination Host Unreachable
From 192.168.1.101 icmp_seq=5 Destination Host Unreachable
From 192.168.1.101 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.100 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7185ms
pipe 4 Is there any extra configuration to be done for Auto-Ethernet? Re: TJA1120A 1000BASET1 Linux side configuration Hello @vikyhre ,
Based on the new logs, the 1000BASE-T1 side seems to be working correctly. The TJA1120 PHY is detected, the link is up at 1 Gbit/s, the master/slave status is correct and SQI is reported as 7/7.
However, the Ethernet interface statistics still show RX packets equal to zero while TX packets are increasing. This suggests that the received frames are not reaching the Linux MAC/network stack.
Please re-check the RGMII timing configuration in the Linux device tree. The log shows that the interface is configured as "phy/rgmii". If your board design expects the PHY to provide the internal RGMII delays, the device tree should typically use "rgmii-id" instead of plain "rgmii" instance. A mismatch in RGMII delay configuration can result in exactly this behavior: PHY link up and good SQI, but no successful packet reception by Linux.
Could you also check with Wireshark on the PC side whether any frames transmitted by the ECU are visible there? For example, after bringing eth0 up on the ECU, please check whether ARP, IPv6 neighbor discovery or any other Ethernet frames from the ECU MAC address are captured on the PC.
At the same time, please run tcpdump on the ECU side while pinging from the PC:
tcpdump -ni eth0 -e arp or icmp
If no ARP/ICMP packets are captured and the RX counter remains zero, the issue is most likely still in the MAC-to-PHY RGMII path or its device-tree timing configuration, not in the 1000BASE-T1 link itself.
Best regards,
Pavel Re: TJA1120A 1000BASET1 Linux side configuration Pavel, just as you said I made CONFIG3,4 pins to RGMII-ID (as per 6.7.2 of TJA1120A Datasheet, I tried both RGMII-ID and RGMII-ID (TX/RX) ). Also set phy-mode as "rgmii-id" &cpsw_port1 {
status = "okay";
phy-mode = "rgmii-id";
phy-handle = <&cpsw3g_phy0>;
}; This was reflected in dmesg [ 6.817790] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-id link mode But pinging was still not working acs@a-tract-10:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.101 icmp_seq=1 Destination Host Unreachable
From 192.168.1.101 icmp_seq=2 Destination Host Unreachable
From 192.168.1.101 icmp_seq=3 Destination Host Unreachable
From 192.168.1.101 icmp_seq=4 Destination Host Unreachable
From 192.168.1.101 icmp_seq=5 Destination Host Unreachable
From 192.168.1.101 icmp_seq=6 Destination Host Unreachable
From 192.168.1.101 icmp_seq=7 Destination Host Unreachable
From 192.168.1.101 icmp_seq=8 Destination Host Unreachable
From 192.168.1.101 icmp_seq=9 Destination Host Unreachable
From 192.168.1.101 icmp_seq=10 Destination Host Unreachable
From 192.168.1.101 icmp_seq=11 Destination Host Unreachable
From 192.168.1.101 icmp_seq=12 Destination Host Unreachable
From 192.168.1.101 icmp_seq=13 Destination Host Unreachable
From 192.168.1.101 icmp_seq=17 Destination Host Unreachable
From 192.168.1.101 icmp_seq=18 Destination Host Unreachable
From 192.168.1.101 icmp_seq=19 Destination Host Unreachable
From 192.168.1.101 icmp_seq=20 Destination Host Unreachable
From 192.168.1.101 icmp_seq=21 Destination Host Unreachable
From 192.168.1.101 icmp_seq=22 Destination Host Unreachable
From 192.168.1.101 icmp_seq=23 Destination Host Unreachable
From 192.168.1.101 icmp_seq=24 Destination Host Unreachable
^C
--- 192.168.1.100 ping statistics ---
25 packets transmitted, 0 received, +21 errors, 100% packet loss, time 24598ms
pipe 4 But i tried to monitor on ECU side while pinging from my PC as you said root@am62axx-evm:~# tcpdump -ni eth0 -e arp or icmp
[ 36.233694] am65-cpsw-nuss 8000000.ethernet eth0: entered promiscuous mode
[ 36.240729] kauditd_printk_skb: 5 callbacks suppressed
[ 36.240737] audit: type=1700 audit(1748612373.780:19): dev=eth0 prom=256 old_ prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 36.257330] audit: type=1300 audit(1748612373.780:19): arch=c00000b7 syscall= 208 success=yes exit=0 a0=4 a1=107 a2=1 a3=fffffb4ab040 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty S2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null)
[ 36.285128] audit: type=1327 audit(1748612373.780:19): proctitle=74637064756D 70002D6E690065746830002D6500617270006F720069636D70
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:39:47.956062 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:47.956161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:49.001519 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:49.001576 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:50.025527 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:50.025574 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:51.049972 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:51.050015 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:52.073514 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:52.073561 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:53.097481 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:53.097522 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:54.121912 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:54.121951 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:55.145488 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:55.145526 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:56.169569 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:56.169613 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:57.193883 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:57.193925 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:58.217586 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:58.217629 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:39:59.241465 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:39:59.241500 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:00.265877 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:00.265913 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:01.289403 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:01.289468 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:02.313582 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:02.313638 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:03.337456 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:03.337503 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:04.361696 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:04.361800 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:05.385632 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:05.385679 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:06.409875 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:06.409933 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:07.433415 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:07.433464 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:08.457402 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:08.457451 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:09.482122 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:09.482161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:10.505290 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:10.505346 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:11.529470 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:11.529514 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:12.554164 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:12.554205 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:13.577538 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:13.577575 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:14.601223 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:14.601263 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:15.625718 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:15.625758 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:16.649218 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:16.649272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:17.673325 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:17.673371 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:18.698021 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:18.698065 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:19.721618 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:19.721706 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:20.745228 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:20.745272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:21.770216 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:21.770260 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:22.793695 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:22.793738 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
13:40:23.817397 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
13:40:23.817436 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
^C
72 packets captured
72 packets received by filter
0 packets dr[ 88.275081] am65-cpsw-nuss 8000000.ethernet eth0: left promiscuous mode
opped by kernel
[ 88.287106] audit: type=1700 audit(1748612425.824:20): dev=eth0 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 88.340396] audit: type=1300 audit(1748612425.824:20): arch=c00000b7 syscall=57 success=yes exit=0 a0=4 a1=1 a2=2 a3=1d22f010 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null)
[ 88.367618] audit: type=1327 audit(1748612425.824:20): proctitle=74637064756D70002D6E690065746830002D6500617270006F720069636D70 4c:cf:7c:bf:f6:a1 is MAC Address of Ethernet Port in my PC These messages start around 2s after Destination Host Unreachable shown in PC side. Re: TJA1120A 1000BASET1 Linux side configuration Sure Pavel, i tried to monitor traffic on PC side too acs@a-tract-10:~$ sudo tcpdump -eni eno1 -vvv '(arp or icmp or vlan)'
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:53:50.356677 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:51.372439 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:52.396579 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:53.420576 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:54.444417 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:55.468262 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:56.492603 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:57.516072 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:58.540535 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:53:59.564468 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:54:00.588407 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
20:54:01.612074 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel There is no response from 64:1c:10:1c:06:e2 in this tcpdump on PC side Also adding static ARP entry resulted in no messages in tcpdump on both ECU and PC side Seems like ECU PHY is the one not responding Re: TJA1120A 1000BASET1 Linux side configuration Hello @vikyhre ,
Thank you for the update. The new result is very useful.
We may assume for now, that RGMII-ID works.
One important observation is that the ARP requests from the PC are VLAN 0 priority-tagged frames:
ethertype 802.1Q, vlan 0, ethertype ARP
while the ECU ARP replies are untagged ARP frames. Please check whether the PC interface, bridge, VLAN, QoS or driver/offload configuration expects tagged traffic or whether untagged ARP replies are filtered or not associated with the ARP request.
Note: The Linux commands below are intended as examples and may need to be adapted according to your specific Linux distribution, network interface name and system configuration.
Please capture the traffic on the PC side:
sudo tcpdump -eni -vvv '(arp or icmp or vlan)'
Then start the ping again.
If the PC capture does not show the ARP replies from ECU MAC address `64:1c:10:1c:06:e2`, then the issue is still in the ECU-to-PC transmit path or media-converter path.
If the PC capture shows the ARP replies, but the PC still reports “Destination Host Unreachable”, then the issue is most likely in the PC-side Linux network/VLAN/filtering configuration.
As an additional isolation test, please try adding a static ARP entry on the PC:
sudo ip neigh replace 192.168.1.100 lladdr 64:1c:10:1c:06:e2 dev nud permanent
Then repeat the ping while capturing traffic on both sides.
Best regards,
Pavel Re: TJA1120A 1000BASET1 Linux side configuration Hello @vikyhre ,
so the issue appears to be on the ECU-to-PC transmit direction:
ECU MAC TX path,
RGMII TX timing / delay configuration between the MAC and TJA1120A,
TJA1120 transmit path,
media converter receive path,
or potentially signal integrity / board-level timing on the RGMII interface.
The CONFIG pin strapping defines the default configuration after reset, but when the NXP TJA11xx Linux driver is active, the PHY can be reconfigured through MDIO according to the Linux device tree. So, pin strapping has actually no effect.
1. If only one direction is affected, it may be useful to test the applicable directional RGMII delay variants, for example:
phy-mode = "rgmii-id"; /* RX and TX internal delay */
phy-mode = "rgmii-rxid"; /* RX internal delay only */
phy-mode = "rgmii-txid"; /* TX internal delay only */
phy-mode = "rgmii"; /* no PHY internal delay */
And, please make sure that the selected Linux phy-mode matches the intended MAC/PHY delay ownership for your hardware design.
2. In parallel, I would also recommend generating traffic from the ECU toward the PC and checking whether there is activity on the RGMII TX pins. For example, you can run:
ping *I eth0 192.168.1.101
and monitor the RGMII TX signals by oscilloscope between the MAC and TJA1120A, especially
TXC, TX_CTL, TXD[3:0].
If there is no activity on these pins while Linux is trying to transmit, the issue may still be in the MAC/driver/configuration path before the PHY. If there is activity on the RGMII TX pins, but no valid frames are observed on the PC side, then the focus should be on RGMII TX timing, delay configuration, signal quality, or the media-converter receive path.
3. Please also repeat the static ARP test while explicitly forcing the PC to use the expected interface:
sudo ip neigh replace *92.168.1.100 lladdr 64:1c:10:1c:06*e2 dev eno1 nud permanent
ip neigh*show 192.168.1.100 dev eno1
ip rou*e get 192.168.1.100
sudo tcpdump -*ni eno1 -vvv '(arp or icmp)'
ping *I eno1 192.168.1.100
Note: The Linux commands above are intended as examples and may need to be adapted according to your specific Linux distribution, network interface name and system configuration.
With a valid static ARP entry, the PC should no longer need to send ARP requests. It should transmit ICMP Echo Request frames directly to the ECU MAC address. These frames should be visible at least in the PC-side tcpdump. If even the PC-side tcpdump does not show outgoing ICMP frames, please check the PC routing, neighbor table and interface selection.
If outgoing ICMP frames are visible on the PC side but not on the ECU side, then the PC-to-ECU direction is still not fully working for unicast traffic. If the ECU receives the ICMP frames and generates replies, but the PC does not receive them, then the issue remains in the ECU-to-PC transmit direction.
Best regards,
Pavel
Re: TJA1120A 1000BASET1 Linux side configuration Thanks for your insight Pavel We got it running One concern i have is that "rgmii-txid" which is delay only to TX_CLK is not mentioned in TJA1120A Datasheet. But still 'rgmii-txid" worked for us. Please clarify this. I changed in DT to "rgmii-txid" since you mentioned that DT can override CONFIG_PIN strapping. FYI PIN Strapping is currently at RGMII-ID (delay only on RX as per datasheet). While pinging from my Windows PC, this is the TCP Dump on ECU side root@am62axx-evm:~# tcpdump -eni eth0 -vvv '(arp or icmp or vlan)'
[ 215.833728] am65-cpsw-nuss 8000000.ethernet eth0: entered promiscuous mode
[ 215.840752] kauditd_printk_skb: 5 callbacks suppressed
[ 215.840759] audit: type=1700 audit(1748634353.108:19): dev=eth0 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 215.857358] audit: type=1300 audit(1748634353.108:19): arch=c00000b7 syscall=208 success=yes exit=0 a0=4 a1=107 a2=1 a3=ffffde476290 items=0 ppid=702 pid=718 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null)
[ 215.885142] audit: type=1327 audit(1748634353.108:19): proctitle=74637064756D70002D656E690065746830002D7676760028617270206F722069636D70206F7220766C616E29
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:45:55.112784 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10277, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:45:56.000964 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 46
19:45:56.001026 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28
19:45:57.107220 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10278, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:45:59.106805 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10279, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:45:59.716185 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40251, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15523, length 40
19:45:59.716296 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 29682, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15523, length 40
19:45:59.754274 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10616, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:45:59.755177 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:45:59.755780 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10617, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:45:59.756348 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:46:00.177694 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10618, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:46:00.178362 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:46:00.179078 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10619, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:46:00.179855 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44)
19:46:00.732239 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40252, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15524, length 40
19:46:00.732328 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 29831, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15524, length 40
19:46:01.109894 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10280, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:46:01.711155 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10281, offset 0, flags [none], proto UDP (17), length 36)
192.168.1.101.61820 > 192.168.1.255.1534: [udp sum ok] UDP, length 8
19:46:01.738880 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40253, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15525, length 40
19:46:01.738946 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 29920, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15525, length 40
19:46:02.750107 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40254, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15526, length 40
19:46:02.750195 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30149, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15526, length 40
19:46:03.111448 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10282, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:46:03.508387 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10283, offset 0, flags [none], proto UDP (17), length 36)
192.168.1.101.61822 > 192.168.1.255.1534: [udp sum ok] UDP, length 8
19:46:03.683562 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10284, offset 0, flags [none], proto UDP (17), length 36)
192.168.1.101.59781 > 192.168.1.255.1534: [udp sum ok] UDP, length 8
19:46:03.758158 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40255, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15527, length 40
19:46:03.758229 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30382, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15527, length 40
19:46:04.720461 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10620, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:04.721105 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:04.721816 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10621, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:04.722500 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:04.748806 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.101 tell 192.168.1.100, length 28
19:46:04.749036 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.101 is-at e8:cf:83:9e:c0:6e, length 46
19:46:04.768096 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40256, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15528, length 40
19:46:04.768169 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30526, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15528, length 40
19:46:05.113187 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10285, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:46:05.145241 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10622, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:05.146309 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:05.146984 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10623, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:05.147546 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44)
19:46:05.704832 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10286, offset 0, flags [none], proto UDP (17), length 36)
192.168.1.101.1534 > 192.168.1.255.1534: [udp sum ok] UDP, length 8
19:46:05.778897 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40257, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15529, length 40
19:46:05.778982 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30742, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15529, length 40
19:46:06.783379 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40258, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15530, length 40
19:46:06.783462 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30781, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15530, length 40
19:46:07.102734 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10287, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
19:46:09.110867 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10288, offset 0, flags [none], proto UDP (17), length 78)
192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50
^C
48 packets captured
48 packets received by filter
0 packets dr[ 231.946244] am65-cpsw-nuss 8000000.ethernet eth0: left promiscuous mode
opped by kernel
[ 231.958251] audit: type=1700 audit(1748634369.220:20): dev=eth0 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 232.008325] audit: type=1300 audit(1748634369.220:20): arch=c00000b7 syscall=57 success=yes exit=0 a0=4 a1=1 a2=2 a3=2c26c010 items=0 ppid=702 pid=718 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null)
[ 232.035539] audit: type=1327 audit(1748634369.220:20): proctitle=74637064756D70002D656E690065746830002D7676760028617270206F722069636D70206F7220766C616E29 Things are working, we did an iperf3 test too root@am62axx-evm:~# iperf3 -c 192.168.1.101
Connecting to host 192.168.1.101, port 5201
[ 5] local 192.168.1.100 port 35040 connected to 192.168.1.101 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 0 266 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 266 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec 0 266 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 943 Mbits/sec 0 266 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 944 Mbits/sec 0 266 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec 0 266 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver
iperf Done. We assume everything is sorted by now, please tell us if we are missing anything. I will mark your reply as solution if you have nothing more to add. Thanks Re: TJA1120A 1000BASET1 Linux side configuration Hello @vikyhre ,
Thank you for the update. This is very good news. I'm glad it works for you now.
I do not see anything suspicions in your logs - I do not see anything obviously missing. As a final sanity check, you may also run the iperf3 test in the reverse direction.
Regarding your concern about `rgmii-txid`: this name is a Linux generic device-tree `phy-mode` value. It does not necessarily have to appear in the TJA1120A datasheet using the exact same Linux naming. TJA1120A supports independent delay configuration in the RGMII TXC and RXC clock paths - please refer to registers RGMII_TXC_DELAY_CONFIG and RGMII_RXC_DELAY_CONFIG. And the pin strapping naturally supports only limited set of configurations.
If my previous reply helped resolve the issue, please feel free to mark it as the solution for easier reference to other users.
Best regards,
Pavel
記事全体を表示
