HADRWARE:
OS:xlnx-linux5.10
DEVICE-TREE:
/ {
};
&gem2 {
local-mac-address = [00 0a 35 00 22 01];
phy-handle = <&phy1>;//eth0
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
reg = <1>;
};
mii_phyc: ethernet-phy@c {
reg = <0xc>;
#address-cells = <1>;
#size-cells = <0>;
mii_phyd: ethernet-phy@d {
reg = <0xd>;
};
};
rgmii_phya: ethernet-phy@a {
reg = <0xa>;
};
rgmii_phy8: ethernet-phy@8 {
reg = <0x8>;
};
};
};
&gem3 {
local-mac-address = [00 0a 35 00 22 02];
phy-connection-type = "rgmii-txid";//eth1
fixed-link {
speed = <1000>;
full-duplex;
};
};
&spi1 {
bus-num = <1>;
status = "okay";
/* ADG704BRMZ 1:4 SPI mux/demux */
sw0: ethernet-switch@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "nxp,sja1105q";
/* 12 MHz */
spi-max-frequency = <12000000>;
/* Sample data on trailing clock edge */
spi-cpha;
/* SPI controller settings for SJA1105 timing requirements */
fsl,spi-cs-sck-delay = <1000>;
fsl,spi-sck-cs-delay = <1000>;
dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
/* 1102p1 written on chassis */
label = "sw0p0";
phy-handle = <&mii_phyd>;
phy-mode = "mii";
reg = <0>;
};
port@1 {
/* 1102p0 written on chassis */
label = "sw0p1";
phy-handle = <&mii_phyc>;
phy-mode = "mii";
reg = <1>;
};
port@2 {
/* DP83TG720p written on chassis */
label = "sw0p2";
//phy-handle = <&rgmii_phya>;
phy-mode = "rgmii-id";
reg = <2>;
sja1105,role-mac;
fixed-link {
speed = <1000>;
full-duplex;
};
/* this port is unused!*/
};
port@3 {
/* DP83TG720p written on chassis */
label = "sw0p3";
//phy-handle = <&rgmii_phy8>;
phy-mode = "rgmii-id";
reg = <3>;
sja1105,role-mac;
fixed-link {
speed = <1000>;
full-duplex;
};
/* this port is unused!*/
};
port@4 {
/* Internal port connected to gem3 */
ethernet = <&gem3>;
label = "cpu";
phy-mode = "rgmii-rxid";
reg = <4>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
BOOT LOG:
[ 3.380653] sja1105 spi2.0: Probed switch chip: SJA1105Q
[ 3.941006] sja1105 spi2.0: Probed switch chip: SJA1105Q
[ 3.969197] sja1105 spi2.0: Enabled switch tagging
[ 4.034044] sja1105 spi2.0 sw0p0 (uninitialized): PHY [ff0d0000.ethernet-ffffffff:0d] driver [NXP TJA1102 Port 1] (irq=POLL)
[ 4.109987] sja1105 spi2.0 sw0p1 (uninitialized): PHY [ff0d0000.ethernet-ffffffff:0c] driver [NXP TJA1102 Port 0] (irq=POLL)
[ 4.435341] sja1105 spi2.0 sw0p2 (uninitialized): validation of rgmii-id with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00000200 failed: -22
[ 4.450284] sja1105 spi2.0 sw0p2 (uninitialized): PHY [ff0d0000.ethernet-ffffffff:0a] driver [TI DP83TG720CS1.1] (irq=POLL)
[ 4.775465] sja1105 spi2.0 sw0p3 (uninitialized): validation of rgmii-id with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00000200 failed: -22
[ 4.790411] sja1105 spi2.0 sw0p3 (uninitialized): PHY [ff0d0000.ethernet-ffffffff:08] driver [TI DP83TG720CS1.1] (irq=POLL)
[ 4.802236] sja1105 spi2.0: configuring for fixed/rgmii-rxid link mode
[ 4.808766] device eth1 entered promiscuous mode
[ 4.813412] DSA: tree 0 setup
[ 4.818957] of_cfs_init
[ 4.821416] of_cfs_init: OK
[ 4.824329] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4.832186] sja1105 spi2.0: Link is Up - 1Gbps/Full - flow control off
[ 16.152772] macb ff0d0000.ethernet eth0: PHY [ff0d0000.ethernet-ffffffff:01] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL)
[ 16.152785] macb ff0d0000.ethernet eth0: configuring for phy/rgmii-id link mode
[ 16.155350] pps pps0: new PPS source ptp1
[ 16.155445] macb ff0d0000.ethernet: gem-ptp-timer ptp clock registered.
[ 16.156116] macb ff0e0000.ethernet eth1: configuring for fixed/rgmii-id link mode
[ 16.157684] macb ff0e0000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 16.158102] pps pps1: new PPS source ptp2
[ 16.158264] macb ff0e0000.ethernet: gem-ptp-timer ptp clock registered.
[ 16.158502] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 16.158945] sja1105 spi2.0 sw0p0: configuring for phy/mii link mode
[ 16.159551] sja1105 spi2.0 sw0p1: configuring for phy/mii link mode
[ 16.160875] sja1105 spi2.0 sw0p2: configuring for phy/rgmii-id link mode
[ 16.161431] sja1105 spi2.0 sw0p3: configuring for phy/rgmii-id link mode
[ 17.190311] sja1105 spi2.0 sw0p1: Link is Up - 100Mbps/Full - flow control off
[ 17.190339] IPv6: ADDRCONF(NETDEV_CHANGE): sw0p1: link becomes ready
root@zynqmp_ubuntu:~# ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:0a:35:00:22:01 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 39
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1504
inet 169.254.24.184 netmask 255.255.0.0 broadcast 169.254.255.255
ether 00:0a:35:00:22:02 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 34 bytes 5474 (5.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 40
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 240 bytes 17520 (17.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 240 bytes 17520 (17.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
sw0p0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:0a:35:00:22:02 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
sw0p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.24.184 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::5e5d:e01d:428f:f917 prefixlen 64 scopeid 0x20<link>
ether 00:0a:35:00:22:02 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19 bytes 2691 (2.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
sw0p2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:0a:35:00:22:02 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
sw0p3: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:0a:35:00:22:02 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
test send message through sja1105 and tja1102 to automotive eth
root@zynqmp_ubuntu:~# ifconfig sw0p1 192.168.1.2
root@zynqmp_ubuntu:~# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
From 192.168.1.2 icmp_seq=4 Destination Host Unreachable
From 192.168.1.2 icmp_seq=5 Destination Host Unreachable
From 192.168.1.2 icmp_seq=6 Destination Host Unreachable
...
I can detect the package recived from TJA1102 port0 in linux shell by command "tcpdump -i sw0p1".However,I can detect the arp package is send to SJA1105,but i cannot detect signal at SJA1105 port1 tx[3:0].
已解决! 转到解答。
So p04_n_txfrm (the number of packets sent by the sja1105 CPU port) is equal to gem3's rx_frames. So the switch -> DSA master direction works. But gem3's tx_frames (53) translate into 0 p04_n_rxfrm on the switch. Additionally, the switch increments no error counter. So it is likely that the switch actually sees no frame.
I think what may be (partially) wrong is your pinmuxing. From the perspective of the Cadence MAC block, packets do get sent, but they don't reach the correct pins, or in the correct way. At this stage I think you should put a probe on the TX_CTL pin of the Zynq SoC (RX_CTL pin of the SJA1105 port 4). This signal is supposed to stay asserted for the entire duration of an Ethernet frame, and deasserted otherwise. So you shouldn't need a high-speed probe to detect these transitions, if you see any activity there we should be reasonably confident that this pin works as intended. The next thing to check in that case is that the TX_CLK pin of the Zynq SoC sends out an 125MHz clock signal.
There is a disagreement between the diagram and the Device Tree. The diagram
displays RGMII interface between the switch and TJA1102 PHYs while the DT
declares MII. The last is more correct because TJA1102 do not support RGMII.
I assume the actual HW is per the DT and not per the diagram.
"dsa,member = <0 0>" is redundant in your case because there is only one
switch in the system. According to this document, it should not be there.
Aside of the inconsistencies mentioned above, possible reasons for the described
symptoms are:
1. Physical interface problems which make the switch not to recognize the frames
sent to it by the host.
2. Misidentified physical switch port, that is, you are configuring one switch
port as sw0p1 but checking for physical activity on another switch port.
3. Lack of kernel options required for the switch driver to do what you want:
CONFIG_NET_DSA
NET_DSA_TAG_SJA1105
Best Regards,
Platon
Thanks for the correction, the block diagram is indeed wrong, so I corrected it and updated the device tree of the firmware.
HW:
Device-tree:
&gem2 {
local-mac-address = [00 0a 35 00 22 01];
phy-handle = <&phy1>;//eth0
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
reg = <1>;
};
mii_phyc: ethernet-phy@c {
reg = <0xc>;
#address-cells = <1>;
#size-cells = <0>;
mii_phyd: ethernet-phy@d {
reg = <0xd>;
};
};
rgmii_phya: ethernet-phy@a {
reg = <0xa>;
};
rgmii_phy8: ethernet-phy@8 {
reg = <0x8>;
};
};
};
&gem3 {
local-mac-address = [00 0a 35 00 22 02];
phy-connection-type = "rgmii";//eth1
fixed-link {
speed = <1000>;
full-duplex;
};
};
&spi1 {
bus-num = <1>;
status = "okay";
/* ADG704BRMZ 1:4 SPI mux/demux */
sw0: ethernet-switch@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "nxp,sja1105q";
/* 12 MHz */
spi-max-frequency = <12000000>;
/* Sample data on trailing clock edge */
spi-cpha;
/* SPI controller settings for SJA1105 timing requirements */
fsl,spi-cs-sck-delay = <1000>;
fsl,spi-sck-cs-delay = <1000>;
//dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
/* TJA1102p1 written on chassis */
label = "sw0p0";
phy-handle = <&mii_phyd>;
phy-mode = "mii";
reg = <0>;
};
port@1 {
/* TJA1102p0 written on chassis */
label = "sw0p1";
phy-handle = <&mii_phyc>;
phy-mode = "mii";
reg = <1>;
};
port@2 {
/* DP83TG720p written on chassis */
label = "sw0p2";
phy-handle = <&rgmii_phya>;
phy-mode = "rgmii-id";
reg = <2>;
};
port@3 {
/* DP83TG720p written on chassis */
label = "sw0p3";
phy-handle = <&rgmii_phy8>;
phy-mode = "rgmii-id";
reg = <3>;
};
port@4 {
/* Internal port connected to gem3 */
ethernet = <&gem3>;
label = "cpu";
phy-mode = "rgmii";
reg = <4>;
sja1105,role-phy;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
I have confirmed:
1. The kernel configuration has been configured
2. Checked several other ports and there is no signal
3. That is to say, only the physical interface problem needs to be ruled out? Can you give some advice?
In addition, after the port of the switch is connected, I did not perform any configuration of the switch in the user space, but only configured the port sw0p1 separately and then tested it.
Thank you very much!
Hangxiang.guo
COWAROBOT
Hello Hangxiang,
First it is important to diagnose your problem.
For this, please follow the steps below:
- Identify the macb port that is the DSA master. If you run "ip addr show", you should see something like "sw0p1@eth0". This means eth0 is the DSA master.
- Run "ip link set eth0 up && ip link set sw0p1 up" to bring up the ports.
- Run "ethtool -S eth0 | grep -v ': 0'" to read the port counters of the macb DSA master, as well as the port counters of the SJA1105 CPU port. The counters for sja1105 start with "p04_".
- Run "ip addr add 192.168.100.1/24 dev sw0p1 && ping 192.168.100.2" to send some traffic through sw0p1.
- Run again the ethtool command above.
- Compare the initial with the final ethtool output, and observe the counters that increment.
- If you see "N_RX_BYTES", "N_TX_BYTES" increment, this port works fine and the problem is somewhere else.
- If you see "N_RUNT", "N_SOFERR", "N_ALIGNERR", "N_MIIERR" increment, this is an electrical problem with the RGMII connection (likely). Details below.
Assuming an electrical RGMII issue, you should know that the RGMII protocol requires a clock skew of approximately 2 ns to be inserted between the data and the clock lines, in both directions (RX and TX). These delays can be added by either of the 2 MACs (macb or sja1105 CPU port).
I don't know if the macb driver inserts RGMII delays. Probably not. So you must configure the sja1105 CPU port to do so.
To do this, on kernel 5.10 you need to set the phy-mode of port@4 to "rgmii-id" instead of "rgmii". "id" means "both RX and TX internal delays". Although, please note that the phy-mode of "rgmii" is not really wrong - that should have worked too. When you upgrade to a newer kernel, you will find that it requires a new method of specifying RGMII delays - see this commit: https://github.com/torvalds/linux/commit/9ca482a246f017773c6ae9b39a02f51dfcc956d7
On another note, the "sja1105,role-mac" and "sja1105,role-phy" device tree properties have been deprecated in this commit: https://github.com/torvalds/linux/commit/5d645df99ac60fab5368e01f1ddf4a57fa4f719f. So please remove them.
In the end, your port 4 should look like this:
port@4 {
/* Internal port connected to gem3 */
reg = <4>;
ethernet = <&gem3>;
label = "cpu";
phy-mode = "rgmii-id"; /* For compatibility with kernel 5.10 */
/* For compatibility with newer kernels */
rx-internal-delay-ps = <2000>;
tx-internal-delay-ps = <2000>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
According to your suggestion, I modified the device tree of port4, but the problem is still not solved.
- run "ip addr show"
root@zynqmp_ubuntu:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0a:35:00:22:01 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.110/16 brd 172.16.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::bd78:3b65:62a4:dcdd/64 scope link
valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP group default qlen 1000
link/ether 00:0a:35:00:22:02 brd ff:ff:ff:ff:ff:ff
inet 169.254.24.184/16 brd 169.254.255.255 scope global eth1
valid_lft forever preferred_lft forever
7: sw0p0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0a:35:00:22:02 brd ff:ff:ff:ff:ff:ff
inet 169.254.24.184/16 brd 169.254.255.255 scope global sw0p0
valid_lft forever preferred_lft forever
inet6 fe80::5e5d:e01d:428f:f917/64 scope link
valid_lft forever preferred_lft forever
8: sw0p1@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen
link/ether 00:0a:35:00:22:02 brd ff:ff:ff:ff:ff:ff
9: sw0p2@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen
link/ether 00:0a:35:00:22:02 brd ff:ff:ff:ff:ff:ff
-run "ip link set eth1 up && ip link set sw0p1 up"and"ethtool -S eth1 | grep -v ': 0'"
root@zynqmp_ubuntu:~# ip link set eth1 up && ip link set sw0p0 up
root@zynqmp_ubuntu:~# ethtool -S eth1 | grep -v ': 0'
NIC statistics:
tx_octets: 6188
tx_frames: 36
tx_broadcast_frames: 22
tx_multicast_frames: 14
tx_64_byte_frames: 10
tx_65_127_byte_frames: 14
tx_256_511_byte_frames: 12
rx_octets: 4316
rx_frames: 35
rx_broadcast_frames: 3
rx_multicast_frames: 32
rx_65_127_byte_frames: 27
rx_128_255_byte_frames: 8
q0_rx_packets: 35
q0_rx_bytes: 3686
q0_tx_packets: 24
q0_tx_bytes: 3624
q1_tx_packets: 12
q1_tx_bytes: 2564
p04_n_txfrm: 35
p04_n_txbyte: 4316
p04_qlevel_hwm_0: 1
p04_n_tx_bytes_128_255: 8
p04_n_tx_bytes_65_127: 27
p04_n_tx_mcast: 32
p04_n_tx_bcast: 3
-run "ip addr add 192.168.100.1/24 dev sw0p0 && ping 192.168.100.2" and"ethtool -S eth1 | grep -v ': 0'"
root@zynqmp_ubuntu:~# ip addr add 192.168.100.1/24 dev sw0p0 && ping 192.168.100.2
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
From 192.168.100.1 icmp_seq=1 Destination Host Unreachable
From 192.168.100.1 icmp_seq=5 Destination Host Unreachable
^C
--- 192.168.100.2 ping statistics ---
8 packets transmitted, 0 received, +2 errors, 100% packet loss, time 7156ms
pipe 4
root@zynqmp_ubuntu:~# ethtool -S eth1 | grep -v ': 0'
NIC statistics:
tx_octets: 9620
tx_frames: 53
tx_broadcast_frames: 39
tx_multicast_frames: 14
tx_64_byte_frames: 19
tx_65_127_byte_frames: 14
tx_256_511_byte_frames: 20
rx_octets: 6351
rx_frames: 44
rx_broadcast_frames: 4
rx_multicast_frames: 40
rx_65_127_byte_frames: 27
rx_128_255_byte_frames: 17
q0_rx_packets: 44
q0_rx_bytes: 5559
q0_tx_packets: 28
q0_tx_bytes: 5044
q1_tx_packets: 25
q1_tx_bytes: 4576
p04_n_txfrm: 44
p04_n_txbyte: 6351
p04_qlevel_hwm_0: 1
p04_n_tx_bytes_128_255: 17
p04_n_tx_bytes_65_127: 27
p04_n_tx_mcast: 40
p04_n_tx_bcast: 4
-I can't see "N_RX_BYTES", "N_TX_BYTES" increment or "N_RUNT", "N_SOFERR", "N_ALIGNERR", "N_MIIERR" increment.
So p04_n_txfrm (the number of packets sent by the sja1105 CPU port) is equal to gem3's rx_frames. So the switch -> DSA master direction works. But gem3's tx_frames (53) translate into 0 p04_n_rxfrm on the switch. Additionally, the switch increments no error counter. So it is likely that the switch actually sees no frame.
I think what may be (partially) wrong is your pinmuxing. From the perspective of the Cadence MAC block, packets do get sent, but they don't reach the correct pins, or in the correct way. At this stage I think you should put a probe on the TX_CTL pin of the Zynq SoC (RX_CTL pin of the SJA1105 port 4). This signal is supposed to stay asserted for the entire duration of an Ethernet frame, and deasserted otherwise. So you shouldn't need a high-speed probe to detect these transitions, if you see any activity there we should be reasonably confident that this pin works as intended. The next thing to check in that case is that the TX_CLK pin of the Zynq SoC sends out an 125MHz clock signal.
Recently I am using sja1105 to test its gPTP-master function, but it seems that the driver does not support it. My command is "ptp4l -i sw0p2 -m -H -2 -f automotive-master.cfg". However, I was able to use eth0 to time the radar device using "ptp4l -i eth0 -m -H -2 -f automotive-master.cfg". Do not know how to solve this problem?
I don't know what radar you are talking about.
Maybe you should adapt the command a little bit until it becomes "ptp4l -i sw0p2 -m -f automotive-master.cfg --tx_timestamp_timeout 30".
What error are you getting?
My board communicates with the radar via sja1105. There is no error after running the command, but the delay between the scan information timestamp returned by the radar device and my board is about 26658222ms. Under the premise of successful gPTP communication, this value should be a little more than 100ms.
Perhaps it would help if you could show an actual log of the master and of the slave ptp4l processes. I cannot exclude that there is a bug fix missing from the Xilinx kernel. Also, for better visibility, maybe you could consider opening a new thread with this issue and a more detailed explanation. If you do so, please link it here as well, I'm not notified of new threads.
This problem is solved, you need to configure the rgmii of dp83tg720 as "TX and RX Shift Mode", the reason is that the port of "role mac" in the sja1105 driver does not enable sending and receiving delay by default.
The expected convention in the Linux network stack is that if you have a MAC to PHY RGMII connection, the MAC will not enable internal delays, and the PHY will enable internal delays according to the phy-mode value. Example, when phy-mode = "rgmii-txid", this translates into PHY_INTERFACE_MODE_RGMII_TXID in the code, and the PHY driver must enable delays in the TX direction (MAC to PHY), or error if it cannot.
It is expected that the PHY must enable internal delays in both directions, so the correct phy-mode is "rgmii-id".
If you want explicit control of RGMII delays on the SJA1105 port when it is connected to a PHY, you can specify the "rx-internal-delay-ps" and "tx-internal-delay-ps" device tree properties as described in my earlier response. But you need a more recent kernel than 5.10 for this. In 5.10, the sja1105 driver does not parse these device tree properties.
Hi,vladimir,
Sorry to bother you again.
I am now debugging the ptp functionality of the sja1105. I ran "ptp4l -i sw0p2 -m" to use the hardware timestamp, unfortunately the sja1105 driver reported an error, similar to a null pointer error.
The kernel log is as follows:
6,374,132220679,-;sja1105 spi2.0: Reset switch and programmed static config. Reason: RX timestamping
SUBSYSTEM=spi
DEVICE=+spi:spi2.0
4,375,132220689,-;port[0]mode[mii]role[MAC]
4,376,132220815,-;port[1]mode[mii]role[MAC]
4,377,132220939,-;port[2]mode[rgmii]role[MAC]
4,378,132220974,-;port[3]mode[rgmii]role[MAC]
4,379,132221008,-;port[4]mode[rgmii]role[PHY]
4,380,132221235,-;port[2]mode[rgmii]role[MAC]
4,381,132221423,-;port[3]mode[rgmii]role[MAC]
4,382,132221522,-;port[4]mode[rgmii]role[PHY]
1,383,132221712,-;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
1,384,132230570,-;Mem abort info:
1,385,132233364,-; ESR = 0x96000004
1,386,132236414,-; EC = 0x25: DABT (current EL), IL = 32 bits
1,387,132241715,-; SET = 0, FnV = 0
1,388,132244762,-; EA = 0, S1PTW = 0
1,389,132247894,-;Data abort info:
1,390,132250761,-; ISV = 0, ISS = 0x00000004
1,391,132254587,-; CM = 0, WnR = 0
1,392,132257550,-;user pgtable: 4k pages, 48-bit VAs, pgdp=00000008092c1000
1,393,132263980,-;[0000000000000028] pgd=0000000000000000, p4d=0000000000000000
0,394,132270770,-;Internal error: Oops: 96000004 [#1] SMP
4,395,132275630,-;Modules linked in:
4,396,132278672,-;CPU: 1 PID: 1066 Comm: ptp4l Not tainted 5.10.0-xilinx-v2021.2 #1
4,397,132285794,-;Hardware name: xlnx,zynqmp (DT)
4,398,132289963,-;pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
4,399,132295966,-;pc : sja1105_static_config_reload+0x3c4/0x4ac
4,400,132301351,-;lr : sja1105_static_config_reload+0x288/0x4ac
4,401,132306730,-;sp : ffff800011bcbb40
4,402,132310029,-;x29: ffff800011bcbb40 x28: ffff000800c2ae40
4,403,132315332,-;x27: ffff00080085d698 x26: ffff0008018c9280
4,404,132320636,-;x25: 0000000000000005 x24: 0000000000000030
4,405,132325939,-;x23: ffff00080085d530 x22: ffff000800c2ae40
4,406,132331242,-;x21: 0000000000000000 x20: ffff00080085d080
4,407,132336546,-;x19: 0000000000000000 x18: 00000000ffffffff
4,408,132341850,-;x17: 0000000000000001 x16: 0000000000000000
4,409,132347153,-;x15: 0000000000000009 x14: 0000000000000000
4,410,132352457,-;x13: 00000000000001b4 x12: ffff800011283000
4,411,132357760,-;x11: 00000000000001b4 x10: 00000000000008e0
4,412,132363064,-;x9 : 0000000000000008 x8 : 0000000000000001
4,413,132368367,-;x7 : ffffffffffff657a x6 : 0000000000000001
4,414,132373671,-;x5 : 0000000000000001 x4 : 0000000000000001
4,415,132378974,-;x3 : 0000000000000000 x2 : ffff800010ee6c08
4,416,132384278,-;x1 : e61858aa738eb600 x0 : 0000000000000010
4,417,132389582,-;Call trace:
4,418,132392016,-; sja1105_static_config_reload+0x3c4/0x4ac
4,419,132397059,-; sja1105_hwtstamp_set+0x138/0x270
4,420,132401408,-; dsa_slave_ioctl+0x48/0x74
4,421,132405148,-; dev_ifsioc+0x150/0x3bc
4,422,132408627,-; dev_ioctl+0x374/0x630
4,423,132412014,-; sock_do_ioctl+0xb0/0x1fc
4,424,132415667,-; sock_ioctl+0x264/0x4c4
4,425,132419141,-; __arm64_sys_ioctl+0xb8/0xe0
4,426,132423056,-; el0_svc_common.constprop.0+0x94/0x1c0
4,427,132427837,-; do_el0_svc+0x44/0xb0
4,428,132431137,-; el0_svc+0x14/0x20
4,429,132434182,-; el0_sync_handler+0x1a4/0x1b0
4,430,132438175,-; el0_sync+0x174/0x180
0,431,132441476,-;Code: 5400028d d503201f f9427683 9b380ea3 (f9401460)
4,432,132447559,-;---[ end trace bda33f34307116e1 ]---
There's some clues:
root@zynqmp_ubuntu:~# ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 2
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
one-step-sync (HWTSTAMP_TX_ONESTEP_SYNC)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
root@zynqmp_ubuntu:/sys/class/ptp/ptp2# ethtool -T sw0p2
Time stamping parameters for sw0p2:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)
I made a little modification to "sja1105_reload_cbs" to avoid the error:
After running "ptp4l" the print becomes:
root@zynqmp_ubuntu:~# ptp4l -i sw0p2 -m
ptp4l[147.633]: selected /dev/ptp0 as PTP clock
ptp4l[147.642]: port 1 (sw0p2): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[147.643]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[147.644]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[155.136]: port 1 (sw0p2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[155.136]: selected local clock 000a35.fffe.002202 as best master
ptp4l[155.136]: port 1 (sw0p2): assuming the grand master role
ptp4l[156.146]: timed out while polling for tx timestamp
ptp4l[156.146]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[156.146]: port 1 (sw0p2): send sync failed
ptp4l[156.146]: port 1 (sw0p2): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[172.147]: port 1 (sw0p2): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[179.116]: port 1 (sw0p2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[179.116]: port 1 (sw0p2): assuming the grand master role
And the kernel won't go wrong.
The null pointer dereference was solved upstream in this commit:
If you cannot use a public upstream kernel which contains fixes for non-Xilinx drivers, at least you could periodically check for patches on the linux-5.10.y stable branch and apply them yourself.
As for PTP, there are 3 things you need to change. First, the driver takes a long time to collect PTP TX timestamps, because for each packet it must schedule a deferred work item that accesses the slow SPI bus. Secondly, this driver configures the switch to do only L2 timestamping - ptp4l by default timestamps UDP. Thirdly, you should enable the peer delay measurement protocol. So your command becomes:
ptp4l -i sw0p2 -m --tx_timestamp_timeout 30 -2 -P
Thanks for your guidance! I also found that the 1105 driver I used has no way to control the delay of the port, so I tried to configure the phy to enable the delay of TX and RX at the same time and it can communicate normally.