TJA1120A 1000BASE-T1 Linux 端配置 我们的ECU板基于am72a7，采用TJA1120A PHY和DP83TG721EVM-MC媒体转换器。 目前链接已开启 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 我将 TJA1120 的 eth0 设置为从模式，并通过硬件跳线将主设备配置为媒体变流器。 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) 现在我已经将我的ECU设置为192.168.1.100我的电脑（连接到媒体变流器）连接到 192.168.1.101 ping 命令没有生效，但是当我用电脑 ping ECU 时，ECU 上的 LED 指示灯会闪烁。 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 自动以太网是否需要进行任何额外配置？ Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 根据新的日志，1000BASE-T1 端似乎工作正常。检测到 TJA1120 PHY，链路速度为 1 Gbit/s，主/从状态正确，SQI 报告为 7/7。 然而，以太网接口统计信息仍然显示 RX 数据包为零，而 TX 数据包却在增加。这表明接收到的帧没有到达 Linux MAC/网络协议栈。 请重新检查 Linux 设备树中的 RGMII 时序配置。日志显示接口配置为“phy/rgmii”。如果您的电路板设计要求 PHY 提供内部 RGMII 延迟，则设备树通常应使用“rgmii-id”而不是普通的“rgmii”实例。RGMII 延迟配置不匹配会导致出现以下情况：PHY 链路已建立且 SQI 良好，但 Linux 无法成功接收数据包。 您能否在电脑端使用 Wireshark 检查一下，看看是否能看到 ECU 发送的任何帧？例如，在 ECU 上启动 eth0 后，请检查 PC 上是否捕获到来自 ECU MAC 地址的 ARP、IPv6 邻居发现或任何其他以太网帧。 同时，请在 ECU 端运行 tcpdump，并从 PC 端进行 ping 操作： tcpdump -ni eth0 -e arp 或 icmp 如果没有捕获到 ARP/ICMP 数据包，并且 RX 计数器保持为零，则问题很可能仍然出在 MAC 到 PHY 的 RGMII 路径或其设备树定时配置中，而不是出在 1000BASE-T1 链路本身中。 顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration Pavel，正如你所说，我已将 CONFIG3,4 引脚连接到 RGMII-ID（根据 TJA1120A 数据手册 6.7.2，我尝试了 RGMII-ID 和 RGMII-ID (TX/RX)）。同时将 phy-mode 设置为“rgmii-id”。 &cpsw_port1 { status = "okay"; phy-mode = "rgmii-id"; phy-handle = <&cpsw3g_phy0>; }; 这反映在 dmesg 中 [ 6.817790] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-id link mode 但是 ping 命令仍然不起作用。 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 但我按照您说的，尝试在电脑上进行ping测试的同时监测ECU端。 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 是我电脑以太网端口的 MAC 地址。 这些消息在电脑端显示“目标主机不可达”后约 2 秒开始出现。 Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 谢谢你的更新。这项新成果非常有用。 我们现在可以假设 RGMII-ID 有效。 一个重要的观察结果是，来自 PC 的 ARP 请求是 VLAN 0 优先级标记帧： 以太网类型 802.1Q，VLAN 0，以太网类型 ARP 而 ECU ARP 回复是未标记的 ARP 帧。请检查 PC 接口、桥接、VLAN、QoS 或驱动程序/卸载配置是否需要带标签的流量，或者未带标签的 ARP 回复是否被过滤或未与 ARP 请求关联。 注意：以下 Linux 命令仅供参考，可能需要根据您的具体 Linux 发行版、网络接口名称和系统配置进行调整。 请捕获PC端的流量： sudo tcpdump -eni -vvv '(arp or icmp or vlan)' 然后再次开始 ping 命令。 如果 PC 捕获未显示来自 ECU MAC 地址 `64:1c:10:1c:06:e2` 的 ARP 回复，则问题仍然出在 ECU 到 PC 的传输路径或媒体转换器路径中。   如果 PC 捕获显示 ARP 回复，但 PC 仍然报告“目标主机不可达”，则问题很可能出在 PC 端的 Linux 网络/VLAN/过滤配置中。   作为额外的隔离测试，请尝试在电脑上添加静态 ARP 条目：   sudo ip neigh replace 192.168.1.100lladdr 64:1c:10:1c:06:e2 dev nud permanent   然后重复 ping 命令，同时捕获两端的流量。 顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 所以问题似乎出在ECU到PC的传输方向上： ECU MAC TX 路径， RGMII TX MAC 和 TJA1120A 之间的时序/延迟配置， TJA1120 传输路径， 媒体变流器接收路径， 或者可能是 RGMII 接口上的信号完整性/板级时序问题。 CONFIG 引脚连接定义了 RESET 后的默认配置，但当 NXP TJA11xx Linux 驱动程序处于活动状态时，PHY 可以通过 MDIO 根据 Linux 设备树重新配置。所以，用销钉捆扎实际上没有任何效果。 1.如果只有一个方向受到影响，则测试适用的方向性 RGMII 延迟变体可能很有用，例如： phy-mode = "rgmii-id"; /* RX 和 TX 内部延迟 */ phy-mode = "rgmii-rxid"; /* 仅接收内部延迟 */ phy-mode = "rgmii-txid"; /* 仅发送内部延迟 */ phy-mode = "rgmii"; /* 无 PHY 内部延迟 */ 另外，请确保所选的 Linux phy 模式与您的硬件设计中预期的 MAC/PHY 延迟所有权相匹配。   2. 同时，我还建议从 ECU 向 PC 发送流量，并检查 RGMII TX 引脚上是否有活动。例如，您可以运行： ping *I eth0 192.168.1.101   并用示波器监测 MAC 和 TJA1120A 之间的 RGMII TX 信号，特别是 TXC、 TX_CTL、 TXD[3:0]。 如果 Linux 尝试发送数据时这些引脚上没有任何活动，则问题可能仍然出在 PHY 之前的 MAC/驱动程序/配置路径中。如果 RGMII TX 引脚上有活动，但在 PC 端未观察到有效帧，则应重点关注 RGMII TX 时序、延迟配置、信号质量或媒体转换器接收路径。   3.请重复静态 ARP 测试，同时强制 PC 使用预期接口： sudo ip neigh replace *92.168.1.100lladdr 64:1c:10:1c:06*e2 dev eno1 nud permanent ip 邻居*显示 192.168.1.100开发 eno1 ip rou*e 获取 192.168.1.100 sudo tcpdump -*ni eno1 -vvv '（arp 或 icmp）' ping *I eno1 192.168.1.100 注意：以上 Linux 命令仅供参考，可能需要根据您的具体 Linux 发行版、网络接口名称和系统配置进行调整。 如果静态 ARP 条目有效，PC 就不再需要发送 ARP 请求。它应该直接向ECU MAC地址发送ICMP回显请求帧。这些帧至少应该在 PC 端的 tcpdump 中可见。如果即使 PC 端的 tcpdump 也未显示出站 ICMP 帧，请检查 PC 的路由、邻居表和接口选择。 如果在 PC 端可以看到传出的 ICMP 帧，但在 ECU 端看不到，则说明 PC 到 ECU 方向的单播流量仍然无法完全正常工作。如果 ECU 接收到 ICMP 帧并生成回复，但 PC 没有接收到回复，则问题仍然存在于 ECU 到 PC 的传输方向上。   顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration 当然，帕维尔，我也尝试在电脑端监测流量。 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 在 PC 端的 tcpdump 中，没有收到来自 64:1c:10:1c:06:e2 的响应。 添加静态 ARP 条目后，ECU 和 PC 端的 tcpdump 均未捕获到任何消息。 似乎是ECU PHY没有响应。 Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 谢谢你的更新。这是个好消息。很高兴它现在对你有用。 我从你的日志中没有发现任何可疑之处——没有发现任何明显的缺失。作为最后的健全性检查，您还可以反向运行 iperf3 测试。 关于您提到的 `rgmii-txid`：这是一个 Linux 通用设备树 `phy-mode` 值。它不一定需要在 TJA1120A 数据手册中使用完全相同的 Linux 命名。TJA1120A支持 RGMII TXC 和 RXC 时钟路径中的独立延迟配置——请参考寄存器 RGMII_TXC_DELAY_CONFIG 和 RGMII_RXC_DELAY_CONFIG。此外，引脚绑定本身仅支持有限的配置。   如果我之前的回复帮助您解决了问题，请将其标记为解决方案，以便其他用户更容易参考。 顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration 感谢你的见解，帕维尔。 我们让它运行起来了 我担心的是，TJA1120A 数据手册中没有提到“rgmii-txid”，它只是将延迟时间缩短到 TX_CLK。但是“rgmii-txid”对我们仍然有效。请澄清一下。我已将 DT 中的值更改为“rgmii-txid”，因为您提到 DT 可以覆盖 CONFIG_PIN 绑定。供您参考，PIN 绑定目前为 RGMII-ID（根据数据手册，仅在 RX 上延迟）。 我用 Windows 电脑 ping ECU 时，这是 ECU 端的 TCP 转储。 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 一切正常，我们也做了iperf3测试。 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. 我们假设现在一切都已安排妥当，如有遗漏，请告知。如果您没有其他补充，我将把您的回复标记为解决方案。 谢谢！

FS26 Reset issue Hi Team, We are facing a reset issue in the SBC section. During initial testing, I assembled only the NXP Semiconductors MFS2633HMDB2AD SBC section and checked the reset output. The reset line was HIGH, and the IC was working properly. After assembling the MCU and other related components, the PMIC reset line is always LOW, and all associated reset signals are being pulled LOW. When I connect the JTAG debugger, the reset line becomes HIGH and the system enters debug mode successfully. Additional observations: Removed  MCU reset line using a 0Ω resistor. MCU reset line is HIGH. PMIC reset line remains LOW. FS26 is working correctly in debug mode. Without JTAG connection, the PMIC reset output remains LOW. It appears that the issue occurs only after MCU integration. The SBC section works correctly when tested independently, but after MCU connection, the PMIC reset sequence is not releasing. Thanks.

HSE設置 S32K311 以下の内容はすべて添付ファイルからコピーしたものです。 S32DS バージョン: S32DS.3.5_b220726_win32.x86_64(1).exe RTDバージョン: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 サポートパッケージ バージョン: SW32K3_S32DS_3.5.6_D2309.zip SBAFバージョン: SBAF_S32K311_0_0_15_0 ビン ファイル: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSEバージョン: HSE_FW_S32K311_0_2_40_0 バイナリファイルはs32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pinkです。 FULL_MEMを使用する セーフブートなし 現在発生している問題 プログラムはここで停止します: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );`           Re: HSE INSTALL S32K311 これは補足的なprintf情報です。 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC構成ワード -0x4039C02C: 0x00000000 ライフサイクル関連情報 - 0x402AC200: 0x00000000 HSEステータス: 0x00000000 ネットで調べてみたところ、チップに付属しているSBAFは、私が現在使用しているHSEファームウェアを認識しないようです。 Re: HSE INSTALL S32K311 SBAFがHSEファームウェアをフラッシュメモリからHSE_NVMにコピーできなかったことが原因ではないかと疑っています。もしこれが原因であれば、どのように解決すればよいでしょうか？ Re: HSE INSTALL S32K311 これが私が印刷したデータです。 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSEステータス: 0x00000000 HSEファームウェアが起動していません（NVMが空であるか、ファームウェアが破損しています） Re: HSE INSTALL S32K311 こんにちは@iiiddd HSE_CONFIG_GPR3(0x4039C028)の価値について教えていただけますか?ビット0は、HSEファームウェアが存在するかどうかを示します。 BR、VaneB Re: HSE INSTALL S32K311 私が使用しているRTDライブラリは、UTESTを作成する際に呼び出されます。 gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); FLS_MAX_VIRTUAL_SECTOR 定義が使用されます。私のRTDライブラリはデフォルトで135ですが、アドレス0x1B000000ULにアクセスするには136が必要です。私が使用しているRTDライブラリはHSEと互換性がないのでしょうか？

FS26リセットの問題 チームの皆さん、こんにちは。 SBCセクションでリセットの問題が発生しています。 初期テストでは、NXPセミコンダクターズのSBCセクションMFS2633HMDB2ADのみ組み立て、リセット出力を確認しました。リセットラインはHIGHで、ICは正常に動作していました。 MCUおよび関連部品を組み立てた後、PMICリセットラインは常にLOWとなり、関連するすべてのリセット信号はLOWに引き出されます。 JTAGデバッガを接続すると、リセットラインがHIGHになり、システムは正常にデバッグモードに入ります。 その他の観察事項： 0Ω抵抗を使ってMCUリセットラインを取り外しました。 MCUリセットラインが高値です。 PMICリセットラインはLOWのままです。 FS26はデバッグモードで正常に動作しています。 JTAG接続がない場合、PMICのリセット出力はLOWのままです。 この問題はMCU統合後にのみ発生するようです。SBCセクションは独立してテストすると正常に動作しますが、MCU接続後はPMICリセットシーケンスが解除されません。 ありがとうございます。

HSE INSTALL S32K311 All the content below is copied from the attachment. S32DS version: S32DS.3.5_b220726_win32.x86_64 (1).exe RTD version: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 Support Package Version: SW32K3_S32DS_3.5.6_D2309.zip SBAF version: SBAF_S32K311_0_0_15_0 Bin file: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSE version: HSE_FW_S32K311_0_2_40_0 The bin file is s32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pink Use FULL_MEM No safe boot A problem currently encountered The program will get stuck here: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );`           Re: HSE INSTALL S32K311 This is supplementary printf information. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC configuration word -0x4039C02C: 0x00000000 Lifecycle-related information - 0x402AC200: 0x00000000 HSE Status: 0x00000000 I've looked up information online, and it seems the SBAF that comes with the chip doesn't recognize the HSE firmware I'm currently using. Re: HSE INSTALL S32K311 I suspect that SBAF failed to copy the HSE firmware from the flash memory to the HSE_NVM. If this is the problem, how should I resolve it? Re: HSE INSTALL S32K311 This is the data I printed. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSE Status: 0x00000000 HSE firmware not started (NVM empty or firmware corrupted) Re: HSE INSTALL S32K311 Hi @iiiddd  Could you please share the value of HSE_CONFIG_GPR3 (0x4039C028)? Bit 0 indicates whether the HSE Firmware is present. BR, VaneB Re: HSE INSTALL S32K311 The RTD library I'm using is called when writing UTEST. gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); The FLS_MAX_VIRTUAL_SECTOR definition will be used. My RTD library defaults to 135, but accessing the address 0x1B000000UL requires 136. Is the RTD library I'm using incompatible with HSE?

LLDP SDK で Set Custom Hostname NXP LX2160ARBD BoardのLLDP SDKのホスト名を変更したいです。local.conf で「hostname」と「hostname_pn-base-files」を使ってみましたが、しかしビルド後はデフォルトのホスト名が表示されます。カスタムレイヤーのホスト名とホストファイルを修正するためにbbappend付きのbase-filesレシピも試しましたが、それでもうまくいきませんでした。他にできることは何でしょうか? Re: Set Custom Hostname in LLDP SDK 私はそれぞれのディストリビューションのbbファイルでパラメータHOST_NAME = "CUSTOM_HOSTNAME"を使い、私の場合はls-image-mainです。 カスタムレイヤーにls-image-main.bbappendを作成し、そのファイルにこの行を追加しました。ディストリビューションのレシピをビルディングした後、ホスト名の変更が画像に反映されました。 Re: Set Custom Hostname in LLDP SDK Yoctoにカスタムマシンを追加したい場合は、以下を参照できます https://docs.nxp.com/bundle/UG10081_LLDP_L6.1.55_2.2.0/page/topics/how_to_add_a_custom_machine_in_flexbuild_based_on_.html よろしくお願いします。

Can ELE Retain Keys in Host-Inaccessible Non-Volatile Storage? Hi, I would like to ask about persistent key storage for use with the EdgeLock Secure Enclave (ELE). Based on my understanding of the KW47 Security Reference Manual, keys used by ELE for cryptographic operations can be stored persistently using the Key Storage Services. My understanding of the typical flow is as follows: 1. Create a Key Blob for the target key and export it to the host. 2. Store the exported Key Blob in non-volatile memory such as Flash. 3. When the key is needed for a cryptographic operation, import the Key Blob and use the key through ELE. In this approach, the Key Blob is generated by ELE, so the host cannot read the actual key material. However, since the Key Blob itself is stored by the host in Flash, it appears that the host could still delete or overwrite the Key Blob. My question is: Is there a way to store a key (or its Key Blob) in a non-volatile storage area that is accessible by ELE but not accessible by the host, allowing cryptographic operations to be performed by ELE without the key material or Key Blob ever being exposed to the host at any point? In other words, is it possible for ELE to own and manage persistent key storage entirely within a secure region, such that the host never handles the key or Key Blob directly? Thank you in advance for your guidance.

imx8mmini sai1 max sample rates hi     sai1 connect a codecs support sample rates 768khz/32bit. SAI1-RX0 connect codec_DOUT. have no data with 768khz/32bit and L/R channels to read.but SAI1-TXFS/SAI1-TXC could output 768khz/49.152Mhz. read L/R channels with 768khz/16bit and 384khz/32bit is ok.kernel version 6.1.36. thanks. Re: imx8mmini sai1 max sample rates about codecs dts as below: run arecord cmd with "-f S32_LE -r 384000 -c 2 -d 1 test.wav" or "-f S16_LE -r 786000 -c 2 -d 1 test.wav" is ok. but run with "-f S32_LE -r 768000 -c 2 -d 1 test.wav",test.wav is NULL. Re: imx8mmini sai1 max sample rates Hello, Could you please share your device tree configuration? Which CODEC are you using? Best regards. Re: imx8mmini sai1 max sample rates Hello, If you are getting errors related to the sample rate, could be caused by clock source since it is not able to generate the necessary frequency for that sample rate. Sometimes, is needed to use a dedicated clock source such as an external clock to get an specific sample rate. Best regards. Re: imx8mmini sai1 max sample rates when read with 768kHz 32bit x 2 channel,SAI1_TXFS/SAI1_TXC output is ok(768khz/49.152Mhz),The codec data output pin (connect to SAI1_RX0)has data output when checked with an oscilloscope.Is it possible that imx8mmini sdma is not worKing? Re: imx8mmini sai1 max sample rates Hello, Do you get underflow or overflow errors during testing? Best regards. Re: imx8mmini sai1 max sample rates get kernel print errors during testing as below: [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?)

HSE INSTALL S32K311 下面的所有内容都是从附件中复制 S32DS版本：S32DS.3.5_b220726_win32.x86_64 (1).exe RTD版本：SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311支持包版本：SW32K3_S32DS_3.5.6_D2309.zip SBAF版本：SBAF_S32K311_0_0_15_0， Bin文件：s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSE版本：HSE_FW_S32K311_0_2_40_0， bin文件为s32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pink 使用FULL_MEM 没有安全启动 当前遇到的一个问题 程序运行会一直卡在这里while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );             Re: HSE INSTALL S32K311 这个是补充的printf信息 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC 配置字-0x4039C02C: 0x00000000 生命周期相关信息-0x402AC200: 0x00000000 HSE Status: 0x00000000 我从网上查阅资料，是不是芯片出场自带的SBAF不识别我现在使用的HSE固件？ Re: HSE INSTALL S32K311 我怀疑是SBAF没有将flash中的hse固件复制到hse_nvm中，如果是这个问题，我应该怎么解决 Re: HSE INSTALL S32K311 这个是我打印的数据 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSE Status: 0x00000000 HSE 固件未启动（NVM 空或固件损坏） Re: HSE INSTALL S32K311 嗨@iiiddd 请问能否提供 HSE_CONFIG_GPR3 (0x4039C028) 的值？位 0 表示 HSE 固件是否存在。 BR，VaneB Re: HSE INSTALL S32K311 我在编写 UTEST 时调用了 RTD 库。 gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); 将使用 FLS_MAX_VIRTUAL_SECTOR 定义。我的 RTD 库默认值为 135，但访问地址 0x1B000000UL 需要 136。我使用的RTD库与HSE不兼容吗？

Adding support for PN5180 in Zephyr Hi, I was wondering whether or not there would ever come support for the PN5180 NFC reader in Zephyr. I am very interested in combining NXP’s IMXRT1064, PN5180 and Zephyr. Are there any prospects of adding the NFC reader library in Zephyr or adding support for Zephyr in the NFC reader library? Thanks! Re: Adding support for PN5180 in Zephyr What is the reason why PN5180 can not be used in combination with zephyr? Re: Adding support for PN5180 in Zephyr Hello, Unfortunately. Zephyr can't support PN5180. For the more information please refer to the information as the link. URL:https://www.nxp.com/design/software/embedded-software/zephyr-os-for-edge-connected-devices:ZEPHYR-OS-EDGE. Have a nice day. ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -----------------------------------------------------------------------------

在 Zephyr 中添加对 PN5180 的支持 您好，我想知道 Zephyr 是否有可能支持 PN5180 NFC 阅读器。我对将 NXP 的 IMXRT1064、PN5180 和 Zephyr 结合起来非常感兴趣。Zephyr 是否有可能添加 NFC 读取器库，或者 NFC 读取器库是否有可能添加对 Zephyr 的支持？谢谢！ Re: Adding support for PN5180 in Zephyr 为什么PN5180不能与Zephyr一起使用？ Re: Adding support for PN5180 in Zephyr 你好， 很遗憾。Zephyr 不支持 PN5180。更多信息请参考链接中的资料。 URL: https://www.nxp.com/design/software/embedded-software/zephyr-os-for-edge-connected-devices:ZEPHYR-OS-EDGE . 祝你今天过得愉快。 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -----------------------------------------------------------------------------

ELE能否将密钥保留在主机无法访问的非易失性存储中？ 您好， 我想咨询一下关于 EdgeLock 安全隔离区 (ELE) 的持久密钥存储的问题。 根据我对 KW47 网络安全参考手册的理解，ELE 用于加密操作的密钥可以使用密钥存储服务持久存储。我对典型流程的理解如下： 1. 为目标密钥创建密钥 Blob 并将其导出到主机。 2. 将导出的密钥 Blob 存储在非易失性存储器（例如闪存）中。 3. 当需要密钥进行加密操作时，导入密钥块并通过 ELE 使用该密钥。 在这种方法中，密钥块由 ELE 生成，因此主机无法读取实际的密钥材料。然而，由于密钥块本身由主机存储在闪存中，因此主机似乎仍然可以删除或覆盖密钥块。 我的问题是： 是否有一种方法可以将密钥（或其密钥块）存储在 ELE 可访问但主机不可访问的非易失性存储区域中，从而允许 ELE 执行加密操作，而无需在任何时候将密钥材料或密钥块暴露给主机？ 换句话说，ELE 是否有可能完全在安全区域内拥有和管理持久密钥存储，从而使主机永远不会直接处理密钥或密钥块？ 感谢您事先的指导。

MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello NXP Support, We are using an MCXN547VKLT on a custom board with an external MCU-Link probe. The SWD connection fails when starting a debug session: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. The SWD-DP can be detected correctly: DPID = 0x6BA02477 However, access to CPU0 AHB-AP (AP0) fails with: WIRE ACK FAULT The Debug Mailbox request also fails. LinkServer reports: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR What we have checked: SWD frequency tested from 1 MHz down to 10 kHz SWDIO and SWCLK waveforms look good on an oscilloscope VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDC and I/O supplies = 3.3 V RESET_B works correctly MCU-Link firmware: CMSIS-DAP V3.172 LinkServer version: 26.5.59 The same MCU-Link works with an MCXN947 development board The MCXN547 was replaced with a new chip, but the problem remains USB ISP works correctly with VID/PID 1FC9:014F. Using blhost, we can: Erase internal Flash Program and read internal Flash Run the application successfully Enumerate the application USB composite device The ROM reports: Security State = UNSECURE We also read the PFR through USB ISP: CMPA is completely erased (0xFF) CFPA is erased except for the ROM-generated CMAC No customer SOCU or Debug Authentication configuration is present Could you please advise: What conditions are required before AP0 and AP2 become accessible? Is DM-AP status 0x60F93638 associated with a known power, reset, or hardware configuration issue? Are there any known MCXN547 errata related to SWD or Debug Mailbox access? Which power and reset signals should we check for this symptom? MCXN Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello Luis, We have now been able to establish an SWD debug connection by using the SPSDK Debug Mailbox tool. The procedure we used is as follows: 1. Reset the MCU through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ tool reset -f mcxn547 2. Start a debug session through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ cmd -f mcxn547 start-debug-session 3. After the debug session has been opened, we connect to the Cortex-M33 core with LinkServer over SWD. We did not use any authentication keys, passwords, debug credentials, or mass erase commands. It appears that the "start-debug-session" command temporarily enables AP0 through the always-accessible AP2 Debug Mailbox. We also used the GDET register sequence from the NXP LS_preconnect_MCXN5XX.scp script after opening the debug session. The sequence disables the aGDET and dGDET reset routing and disables SPC glitch detection during debugging. Regarding the power supplies: - VDD_VBAT is directly connected to VDD, and both are 3.3 V. - VDD_P4 is directly connected to VDD, and both are 3.3 V. - VDD_ANA is connected to VDD through a ferrite bead. - VDD is 3.3 V. However, we now have another debugging problem. When the board is powered on normally without an SWD debug reset, the firmware runs correctly. However, when we enter the debug session using the Debug Mailbox reset procedure described above, the firmware does not start correctly. The debug connection is lost when single-stepping through the following SDK function: static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_Type *base, spc_dcdc_voltage_level_t voltageLevel) { base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } More specifically, the connection is lost when ACTIVE_CFG is written to change the active-mode DCDC voltage level. The behavior is therefore different between the following two cases: 1. Cold power-on: The firmware starts and runs normally. 2. Debug Mailbox reset followed by start-debug-session and SWD connection: The firmware reaches the SPC DCDC configuration, but the debugger loses the target when ACTIVE_CFG is written, and the application cannot start normally. Could the Debug Mailbox reset leave the SPC, DCDC, GDET, or reset status in a different state compared with a full power-on reset? Is there a required sequence before modifying SPC ACTIVE_CFG after starting a Debug Mailbox debug session? For example: - waiting for SPC_SC[BUSY] to clear; - clearing an SPC or GDET status flag; - unlocking or disabling glitch detection; - using a specific reset type; - avoiding a soft reset after start-debug-session; - or applying the complete LS_preconnect_MCXN5XX.scp sequence? Could writing the DCDC voltage level while debugging trigger a GDET event, DCDC protection event, brownout reset, or another system reset? Please also advise which registers we should capture immediately before the ACTIVE_CFG write. We can provide values for registers such as SPC_SC, SPC_CNTRL, SPC_ACTIVE_CFG, SPC_GLITCH_DETECT_SC, CMC_SRS, CMC_SSRS, and the Debug Mailbox CSW. Best Regards,

S32K328 HSE-B: Mem_43_INFLSを使用したA/Bスワップの推奨アーキテクチャ（Vector FOTAなし） NXPチームの皆様、こんにちは。 現在、S32K328上で動作する既存のアプリケーションにOTA A/Bスワップのサポートを追加する設計・実装段階にあります。 これは、完全なFOTAフレームワークを統合するのではなく、既存のソフトウェアをOTA機能で拡張する初期実装です。 現在の環境 MCU:S32K328(8MB Pフラッシュ) AUTOSARスタック:ベクターMICROSAR RTD: S32K3_RTD_6_0_0_QLP04_D2508_ASR_REL_4_7_REV_0000_20250822 バイナリ転送インターフェース:UART 画像アクティベーションサービス: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE A/B スワップは RTD 設定により有効化されます OTAバイナリは、カスタムOTA CDDによってUART経由で受信されます。 現在のVector構成には、NvM/Fee（D-Flash）専用のMemAccMが含まれています。P-FlashアプリケーションをプログラミングするためのMemAccM設定はなく、Vector OTA/FOTAも使用していません。 そのため、OTA CDDのMem_43_INFLSを使って非アクティブなアプリケーションのフラッシュを直接消去・プログラムすることを検討しています。 以下の点についてご指導いただければ幸いです。 1. 推奨されるアプローチ VectorのOTA/FOTAパッケージを使わない場合、A/Bスワップ環境でOTA画像プログラミングを管理するための推奨される低レベルのドライバーはMem_43_INFLSでしょうか? あるいは、MemAccMは、カスタムOTA実装の場合も含め、P-Flashプログラミングに対応するように拡張されるべきでしょうか？ 2. 非アクティブなフラッシュブロックのアドレス指定 HSE A/Bスワップを有効にした後： 非アクティブなアプリケーションP-Flashブロックは常にメモリレイアウトで定義された固定物理アドレスを通じてアクセスされるのでしょうか? あるいは、HSEはパッシブブロックに対して何らかの論理マッピングや抽象化を提供しているのでしょうか？ 3. 有効化の前提条件 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK を正常に実行するための必須の前提条件は何ですか？ 例： 画像ヘッダー形式 メタデータの要件 整列制約 認証/署名要件 フラッシュ状態または属性 4. フラッシュコントローラの並行処理 S32K328のC40フラッシュコントローラーはDフラッシュ(Fee/NvM)とPフラッシュ(非アクティブブロック)間の同時操作をサポートしていますか? そうでない場合、推奨される同期戦略は何ですか？ アプリケーションレベルのスケジューリング RTDドライバ仲裁 MemAccM の使用状況 5. 推奨される建築様式 以下のアーキテクチャはNXPの推奨事項に準拠していますか？ UART ↓ カスタムOTA CDD ↓ Mem_43_INFLS（非アクティブなPフラッシュの消去/書き込み） ↓ 画像認証 ↓ HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK ↓ システムリセット ↓ HSE/BAF がパッシブブロックをアクティブ化します 私たちは特に、この軽量化アプローチが適切であり、HSE（環境・安全・衛生）要件に準拠しているかどうかについて、ご助言を求めています。 HSE A/Bスワップ対応のカスタムOTAに関するアプリケーションノート、RTD例、または参考実装があれば、ぜひご指導いただけるとありがたいです。 再開まで今しばらくお待ちください。 よろしくお願いします、 ヴェンカテシュ KV #s32k328

PMIC PF8200 I2Cレジスタのデフォルト値/リセット値 私はOTP構成でPF8200を使用しています。 PMICの設定を変更するために、SCFWを使っていくつかのレジスタに新しい値をロードする必要があります。 OTP値によってロードされないレジスタビットには、データシートにデフォルト値が指定されていません。 これらの値を知ることで、OTPによって既にロードされていないすべてのレジスタをロードすることが有用かどうかを判断できます。 ありがとう; Re: PMIC PF8200 I2C register default/reset values 迅速なご回答ありがとうございます。 電源投入後のデフォルト値に関する情報は見つかりませんでした。 どうか、この情報をどこで見つけられるか教えさせてください! Re: PMIC PF8200 I2C register default/reset values こんにちは、 OTPからロードされないレジスタまたはビットは、電源投入後にデフォルト値に初期化されます。したがって、デフォルト設定とは異なる値が必要な場合を除き、すべての非OTPレジスタをSCFW経由で設定する必要はありません。 追加の初期化が必要かどうかを判断するには、希望する設定とデフォルトのレジスタ値を比較してください。 PF82ファミリのI2Cレジスタマップをご参照ください お役に立てば幸いです！ Re: PMIC PF8200 I2C register default/reset values どのレジスターに興味があるのか確認していただけますか? Re: PMIC PF8200 I2C register default/reset values 例えば、レジスタ05 INT_MASK_1。 しかし、すべてのレジスタはOFF_TOGGLEとして指定されています。 ありがとうございます。

i.MX95におけるUSXGMIIマルチレート こんにちは、 i.MX95に以下のイーサネット速度をサポートできるイーサネットポートを実装できるかどうかを評価しようとしています。 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te 一般的に、デザイン上に10Gbit対応のイーサネットPHYを設置し、USXGMIIまたはXFIのいずれかのインターフェースを通じてi.MX95イーサネットコントローラに接続する必要があります 私たちの理解では、USXGMIIインターフェースは理論上マルチレートインターフェースであり、1リンクで10Gbitから10bitまでのあらゆる速度を実現できます。 これに対し、XFIインターフェースは単一レートのインターフェースで、10Gbitしか対応できません。 i.MX95のリファレンスマニュアル(例:)セクション104.2、表621)i.MX95はXFIおよび「10G-USXGMII」の両方をサポートしています。最初は、私たちが望むUSXGMIIインターフェースがサポートされているように見えます。 しかし、いくつか私たちを困惑させる点があります。 1.「10G-USXGMII」という宣言は、理論上はインターフェースがUSXGMIIリンクであることを意味するかもしれませんが、実際には10Gbitモードでしか動作しません。 2. NXP評価ボードIMX95LPD5EVK-19は、Marvell AQR113C PHYを使用して10GBase-Tポートを実装しています。 a) 図1のブロック図、セクション1.1では、PHYがUSXGMIIインターフェースに接続されているように見えます: b) 関連するセクション2.11.3「10 Gbitイーサネットインターフェース」では、AQR113Cイーサネットトランシーバーが10Gbitから10bitまでのすべてのデータレートをサポートするとされており、真のUSXGMIIを示唆しています: c) この節では、イーサネットPHYを接続するインターフェースがXFIであることも記載されています。 結論として、i.MX95がフルのマルチレートUSXGMIIに対応しているのか、それとも10Gbit専用バージョンのみ対応しているのか混乱しています。 NXPの評価ボードを参考にしてみましたが、そのボードの10GbEポートがUSXGMII(10Gbitから10bitまでのマルチレート対応)で接続されているのか、XFI(10Gbitのみ)で接続されているのかも分かりません。 教えていただけますか: i.MX95に10Gbitから10Gbitまでの速度をサポートする真のマルチレート10GbEポートを実装することは可能でしょうか? Re: USXGMII multi-rate on i.MX95 詳細なご回答をいただき、誠にありがとうございます。 これで私たちの側の混乱は解消されました！ Re: USXGMII multi-rate on i.MX95 1. 「10G-USXGMII」の意味 「10G-USXGMII」とは、10G専用モードではなく、標準的なマルチレートUSXGMIIプロトコルを指します。「10G」は固定されたSerDesレーン速度を示し、USXGMIIは10M、100M、1G、2.5G、5G、10Gイーサネットの帯内レート適応をサポートしています。 i.MX95では、このモードはPCS_PROT_10G_SXGMII設定で表されます。 2. i.MX95 EVKで使用されたインターフェース i.MX95 EVKは、USXGMIIではなくXFI（10GBASE-R）を使用します。imx95-19x19-evk.dtsでは、enetc_port2 は次のように設定されています。 phy-mode = "10gbase-r"; したがって、搭載されているAQR113CはXFIモードで動作します。 3. 真のマルチレートUSXGMIIはサポートされていますか？ はい。i.MX95 NETCハードウェアはUSXGMIIをサポートし、LinuxのENETC4ドライバはenetc4_set_port_speed()を通じて速度変更を処理します。Marvell AQR113CはUSXGMIIホストインターフェースモードもサポートしています。 4. カスタムボードに必要なものは何ですか？ マルチレート動作を完全に有効にするには： デバイスツリーの設定： phy-mode = "usxgmii"; managed = "in-band-status"; AQR113Cのファームウェアを、XFIではなくUSXGMIIホストモードに設定してください。 EVKは10GbEポートにXFIを使用していますが、カスタムi.MX95設計ではUSXGMIIをAQR113C(または類似のPHY)と組み合わせて、10M/100M/1G/2.5G/5G/10Gを単一のMACからPHYリンクまでサポートできます。 よろしくお願いします。 Re: USXGMII multi-rate on i.MX95 もう一つ追加で質問します:Marv AQR113C ellのドライバはNXP Linux BSPに含まれているのか、それとも自分たちで用意しなければならない外部モジュールですか? Re: USXGMII multi-rate on i.MX95 私は元の投稿者ではありませんが、私もusxgmiiを動作させようとしています。 NXPは、usxgmiiがBSPカーネル上で動作するかどうかを検証したことがありますか？mv-cux3610 PHYで使用しようとしていますが、以下のエラーが発生します。 [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 これは、NetC PCSがUSXGMIIサポートを宣伝しておらず、10Gbase-R、2500-basex、SGMIIのみが原因のようです: (これはLF-6.18.YのLinux-IMXブランチでの話です) Re: USXGMII multi-rate on i.MX95 このドライバーはNXP Linux BSPに含まれています。リンク: https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c Re: USXGMII multi-rate on i.MX95 お返事ありがとうございます！ 最後に質問です。i.MX95 EVKのenetc_port2とAQR113CをUSXGMIIモードに設定することは可能でしょうか？これにより、EVK上でUSXGMIIインターフェースのマルチレート機能をテストできるのでしょうか?

USXGMII multi-rate on i.MX95 Hi, we are trying to evaluate if we can implement an ethernet port on the i.MX95 that is able to support the following ethernet speeds: 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te In general this requires us to place a 10Gbit capable ethernet PHY on our design and connect it to the i.MX95 ethernet controller via one of two interfaces: USXGMII or XFI From our understanding the USXGMII interface is a multi-rate interface in theory, meaning it can facilitate all speeds from 10Gbit to 10bit over one link. In contrast the XFI interface is a single-rate interface that can only facilitate 10Gbit. According to the i.MX95 reference manual (e.g. section 104.2, table 621) the i.MX95 supports both XFI and "10G-USXGMII". So initially it looks like our desired interface USXGMII seems to be supported. There are several points that confuse us however: 1. The declaration "10G-USXGMII" could be interpreted to mean that the interface is a USXGMII link in theory but it only really works in the 10Gbit mode. 2. The NXP eval board IMX95LPD5EVK-19 implements a 10GBase-T port using a Marvell AQR113C PHY. a) In the block diagram in figure 1, section 1.1 the PHY looks to be connected to the USXGMII interface: b) In the associated section 2.11.3 "10 Gbit Ethernet Interface" the AQR113C ethernet transceiver is said to support all data rates from 10Gbit to 10bit, hinting at true USXGMII: c) This section also mentions that the interface used to connect the ethernet PHY is XFI: So in conclusion we are confused wether or not the i.MX95 supports the full multi-rate USXGMII or only a 10Gbit-only version. We tried to look at the NXP eval board as a reference but we are not sure either if the 10GbE port on that board is connected via USXGMII (allowing multi-rate from 10Gbit to 10bit) or via XFI (10Gbit only). Could you please clarify for us: Is it possible to implement a true multi-rate 10GbE port on the i.MX95 that supports speeds from 10Gbit to 10bit? Re: USXGMII multi-rate on i.MX95 Thank you very much for this in-depth response. This clears up any confusion on our side! Re: USXGMII multi-rate on i.MX95 1. Meaning of "10G-USXGMII" "10G-USXGMII" refers to the standard multi-rate USXGMII protocol, not a 10G-only mode. The "10G" denotes the fixed SerDes lane speed, while USXGMII supports in-band rate adaptation for 10M, 100M, 1G, 2.5G, 5G, and 10G Ethernet. On i.MX95, this mode is represented by the PCS_PROT_10G_SXGMII setting. 2. Interface Used on the i.MX95 EVK The i.MX95 EVK uses XFI (10GBASE-R) rather than USXGMII. In imx95-19x19-evk.dts, enetc_port2 is configured as: phy-mode = "10gbase-r"; Therefore, the onboard AQR113C operates in XFI mode. 3. Is True Multi-Rate USXGMII Supported? Yes. The i.MX95 NETC hardware supports USXGMII, and the Linux ENETC4 driver handles speed changes through enetc4_set_port_speed(). The Marvell AQR113C also supports USXGMII host-interface mode. 4. What Is Needed on a Custom Board? To enable full multi-rate operation: Configure the device tree: phy-mode = "usxgmii"; managed = "in-band-status"; Configure the AQR113C firmware for USXGMII host mode instead of XFI. The EVK uses XFI for its 10GbE port, but a custom i.MX95 design can use USXGMII with the AQR113C (or a similar PHY) to support 10M/100M/1G/2.5G/5G/10G over a single MAC-to-PHY link. Thanks Re: USXGMII multi-rate on i.MX95 I am not the original poster but I am also trying to get usxgmii working. Has NXP ever validated if usxgmii works on the BSP kernel? I am trying to use it with a mv-cux3610 phy but I get these errors: [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 it seems to be caused by the netc PCS not advertising usxgmii support, only 10gbase-r, 2500-basex and sgmii: (this is on the lf-6.18.y linux-imx branch) Re: USXGMII multi-rate on i.MX95 Just one more follow-up question: Is the driver for the Marvell AQR113C included in the NXP Linux BSP or is it an out-of-tree module we must supply ourselves? Re: USXGMII multi-rate on i.MX95 Thank you for your reply! Last question from my side: Is it possible to configure the enetc_port2 and the AQR113C on the i.MX95 EVK to USXGMII mode? Would this allow us to test the multi-rate functionality of the USXGMII interface on the EVK? Re: USXGMII multi-rate on i.MX95 the driver has been included in NXP Linux BSP, link: https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c

FRDM-K64FでMCUxpresso 25.6を使用した場合、SDカードのシンボルが未定義になる 私のプロジェクトでは、双方向無線システム用の個別のパーソナライズデータを読み込むためにSDカードを使用したいと考えています。#include "tx_api.h" を取得していますまた、#include "tx_event_flags.h" が未定義として扱われます。 これは、SDKにAzure RTOSを含めていなかったためです。 私は「manage sdk components」を使ってAzureをSDKにインストールしてこれを克服しようとしましたが、どうやらAzure RTOSのサポートは2.11で終了しており、この問題に気づく前にプロジェクトに読み込んでいました。 SO I created a new SDK online, but it drops back to 2.10 to get Azureサポート.しかし、プロジェクトのSDKを変更しようとすると、持っているSDKを削除できず、別のSDKを追加しようとすると、SDK 2.x_FRDM-K64Fがすでに存在すると表示されます。 Azureのサポートはどうすればいいですか?SDカードへのアクセスだけに必要なんです!

VR5510: I2C ウォッチドッグ リフレッシュは、非同期モードが有効になっている場合でも ISR でブロックされます - 真の非ブロッキング サポート NXPチームの皆様、こんにちは。 現在VR5510 PMICのデバッグを行っているのですが、ウォッチドッグの更新に関連するリアルタイムスケジューリングの問題に遭遇しました。 MCAL I2C ウォッチドッグのリフレッシュ (I2C を介して VR5510 ウォッチドッグにフィードする) は、 同期 手術。同期待機は割り込みコンテキスト内から呼び出されるため、CPUをブロックし、他のタスクのリアルタイムスケジューリングを低下させます。 ドライバーの設定やコードに 非同期 オプションがあるのに気づきました。しかし実際には同期のビジー待機(I2C転送が完了するまでブロックとポーリングを行う)を実行しているため、実際には転送を呼び出し元から切り離すことはありません。 私の質問： VR5510のウォッチドッグリフレッシュを公式にサポートされた方法で実行することは可能ですか？ 真のノンブロッキング （例えば割り込み駆動かDMA駆動のI2C)で、他のタスクを停止させないために? 非同期オプションがノンブロッキングであることが想定されている場合、現在の同期ビジーウェイト動作は既知の制限事項でしょうか、それとも私の側の設定の問題でしょうか？ 何かご助言、設定例、またはサンプルコードをご提供いただければ大変ありがたいです。 よろしくお願いします。 Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは、 @Jerry_cao 投稿ありがとうございます。 あなたが言及しているのは、使用されている以下のAPIでしょうか？ Std_ReturnType I2c_AsyncTransmit(uint8 チャネル、 const I2c_RequestType ∗ RequestPtr ) 「？ どのバージョンのRTDが使用されていますか？ BR チェイン Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは： 私のバージョンは：   * プロジェクト:RTD AUTOSAR 4.4 * プラットフォーム:CORTEXM *   ペリフェラル           : VR5510 * 依存関係：なし * * Autosar バージョン:4.4.0 * Autosar リビジョン:ASR_REL_4_4_REV_0000 *   AUTOSAR Conf.Variant : * ソフトウェアバージョン：4.0.2 * ビルドバージョン：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 著作権 2020-2023 NXP セミコンダクターズ * 無断転載を禁じます。 * この関数を使用する Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは、 @Jerry_cao ご確認いただきありがとうございます。 対応するコードを確認すると、 I2C非同期通信用のVR5510ソリューションはRTD5.0.0QLP04に実装されていることがわかります。 詳細については、このバージョンのRTDに含まれる関連コードをご確認ください。 BR チェイン Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s こんにちは： 私のバージョンは：   * プロジェクト:RTD AUTOSAR 4.4 * プラットフォーム:CORTEXM *   ペリフェラル           : VR5510 * 依存関係：なし * * Autosar バージョン:4.4.0 * Autosar リビジョン:ASR_REL_4_4_REV_0000 *   AUTOSAR Conf.Variant : * ソフトウェアバージョン：4.0.2 * ビルドバージョン：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 著作権 2020-2023 NXP セミコンダクターズ * 無断転載を禁じます。 * この関数を使用する Pmic_VR55XX_TriggerWatchdog

S32K312 temperature sensor inaccurate reading Hello NXP Team, I am working on the S32K312​ internal temperature sensor and need help with incorrect temperature readings. I have reviewed similar threads and confirmed the basic configurations, but the ADC results do not reflect the ambient temperature. What I have done so far： (1) TEMPSENSE clock enabled​-Screenshot attached  (2)ADC configuration ADC instance: ADC0 Channel: Temperature Sensor (TEMPSENSE) Trigger mode: Software trigger (3)Measurement routine Periodically start ADC conversion Wait for conversion complete flag Read ADC data register (4)Result However, the converted temperature value does not match the actual ambient temperature. Any guidance, clarification, or reference code for the S32K312 temperature sensor would be greatly appreciated.   Thanks in advance for your support!   Best regards, Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas The temperature channel requires a relatively long sampling time, with a minimum of 1.2 microseconds. Therefore, please check the sampling time settings. Re: S32K312 temperature sensor inaccurate reading I further switched the ADC voltage reference to 0x50, but the issue persists: The temperature readings deviate significantly from the ambient temperature (28°C). Temperature data retrieved via the API exhibits severe fluctuations, as shown in the attached plot. Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas Then you should set TempSense voltage supply to: 5V * 16 = 0x50 Re: S32K312 temperature sensor inaccurate reading The TempSense voltage supply is configured as 0x58, hardware's VDD_HV_A supply voltage is 5V Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas Please check the "TempSense Voltage Supply" and tell me what your current hardware's VDD_HV_A supply voltage is.