lowlight opensource ai-isp test on imx95   There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) FLOL cidautai/FLOL Lightweight CNN High SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low KinD zhangyhuaee/KinD Retinex + CNN Medium RetinexNet-lite Derived Light CNN Medium EnlightenGAN-lite Derived Small CNN Very High Fast LLIE CNN Various Small CNN High Tested above open-source models with UVC to perform performance evaluation on the exip-os08a20 module with linear mode. Found that SCI（GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexib...） computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed. i.MX Processors Sensor

S32 Design Studio - Export and Debug 1 Table of Contents • Introduction • Open the generated project in S32 Design Studio • Debug the generated application in S32 Design Studio • Debug the code generated from the Simulink model • Conclusion 2 Introduction This article explains how to take a project generated with the Model-Based Design Toolbox (MBDT) in Simulink and open, build, and debug it in S32 Design Studio. It focuses on the transition from model execution in Simulink to target-level debugging and validation on S32 hardware. 3 Open the generated project in S32 Design Studio MBDT generates code from Simulink models and exports it as an S32 Design Studio-compatible project. After a successful model build, the generated _Config folder contains the files required by the IDE. The project can then be opened directly from Simulink or imported into S32 Design Studio for further configuration, building, and debugging on S32 hardware. Before opening or debugging the project in S32 Design Studio, build the Simulink model. The build process generates the code and project structure required for IDE integration. You can open the generated project either directly from Simulink or manually from within S32 Design Studio. Use the Simulink option when you want to launch the generated project immediately after configuration. Use the IDE import option when you want to manage the project manually from an S32 Design Studio workspace. Open the project from Simulink To open the project from Simulink, open the model Hardware Settings from the Hardware tab or press Ctrl + E. Then go to Hardware Implementation → Hardware board settings → Target hardware resources → S32 Design Studio Project and select Open. Figure 1. S32 Design Studio project settings in Simulink A dialog appears and prompts you to select the S32 Design Studio installation path. Figure 2. S32 Design Studio installation path selection To select the S32 Design Studio installation path later, or to change it during toolbox usage, click Browse in the S32 Design Studio location field under the Tools Paths group. Figure 3. S32 Design Studio path changing The generated project opens in S32 Design Studio and is ready to build, configure, or debug. Figure 4. Generated project opened in S32 Design Studio Open the project inside the IDE To import the project manually into S32 Design Studio, follow these steps: Inside the IDE, select File → Import → Existing Projects into Workspace. Figure 5. Importing an existing project into the workspace Browse for the _Config folder in Select root directory. Before clicking Finish, make sure that Copy projects into workspace is disabled. If the project is copied into the S32 Design Studio workspace, the build process will fail. Figure 6. Directory selection for the generated project 4 Debug the generated application in S32 Design Studio To build and debug the project in S32 Design Studio, select the project and click Debug. S32 Design Studio builds the project and automatically switches to the Debug perspective. Note: Ensure that the target hardware board is connected before starting the debug session. Figure 7. Starting the debug session Figure 8. Debug perspective in S32 Design Studio After the debugger launches and the application is loaded on the target, you can use the following actions to control program execution and inspect the generated code: The Breakpoint action sets a breakpoint when you double-click in the left margin of a .c file:   Figure 9. Breakpoint set in the generated source file The Step Over (F6) action executes the current line while remaining in the same function: Figure 10. Step Over action in the Debug toolbar The Step Into (F5) action enters a called function: Figure 11. Step Into action in the Debug toolbar The Step Return (F7) action runs to the end of the current function: Figure 12. Step Return action in the Debug toolbar The Resume (F8) action runs until the next breakpoint: Figure 13. Resume action in the Debug toolbar Figure 14. Breakpoint reached after pressing Resume action The Suspend (F9) action pauses execution at the current instruction: Figure 15. Suspend action in the Debug toolbar Figure 16. Function paused after pressing Suspend action The Terminate (Ctrl + F2) action stops the debug session and disconnects from the target: Figure 17. Terminate action in the Debug toolbar The Disconnect action leaves the target running while detaching the debugger: Figure 18. Disconnect action in the Debug toolbar 5 Debug the code generated from the Simulink model The code generated by the Simulink model can be found in the _step() function. To enter this function, set a breakpoint before the function call, run the application until the breakpoint is reached, and then select Step Into. Alternatively, Ctrl + Click the function name to open the function and place a breakpoint inside it. Figure 19. modelName_step function In this function, you will also find the generated code for the blocks placed inside the Simulink model. Figure 20. Generated step function in the source code To monitor variable values, hover over a variable to see its current value: Figure 21. Variable value displayed on hover Alternatively, add the variable to the Expressions view by selecting Add new expression, entering the variable name, and pressing Enter. Figure 22. Add new expression in Expressions view Figure 23. Variable added to Expressions view Upon running the code, if the value changes, it will be highlighted. Figure 24. Variable value highlighted during debug The names of the variables in the generated code are the same as the names they have in the Simulink model, making it easier to debug the generated code. Figure 25. Variable name in Simulink model and generated code 6 Conclusion After identifying the generated function and monitoring key variables, you can validate how the Simulink model behavior maps to the generated application running on the target hardware. For more tutorials on installing, activating, and using S32 Design Studio, see the S32 Design Studio tutorials on the community page: S32 Design Studio Knowledge Base.

TJA1120A 1000BASET1 Linux側の構成 ECUボードTJA1120A am72a7ベースの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 eth0からスレーブモードTJA1120設定し、ハードウェアジャンパーをマスターからメディアコンバーターに設定しました 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に設定しました。そして私のPC(メディアコンバーターに接続)は192.168.1.101に変換しています ピングは発生していませんが、PCからピングすると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と報告されています。 しかし、イーサネットインターフェースの統計では、受信パケットはゼロであり、送信パケットは増加しています。これは受信フレームがLinuxのMAC/ネットワークスタックに届いていないことを示唆しています。 LinuxデバイスツリーでRGMIIのタイミング設定を再確認してください。ログにはインターフェースが「phy/rgmii」として設定されていることが示されています。基板設計でPHYが内部RGMII遅延を提供することを想定している場合、デバイスツリーは通常単なる「rgmii」インスタンスではなく 「rgmii-id」 を使うべきです。RGMIIの遅延設定の不一致はまさにこのような動作を引き起こすことがあります:PHYリンクアップと良好なSQIはあるものの、Linuxによるパケット受信は成功しません。 PC側のWiresharkでECUから送信されたフレームが見えるかどうかも確認してもらえますか?例えば、eth0をECUに起動した後、ECUのMACアドレスからのARP、IPv6の隣接検出、その他のイーサネットフレームがPC上でキャプチャされているか確認してください。 同時に、PCからpingを実行しながら、ECU側でtcpdumpを実行してください。 tcpdump -ni eth0 -e arp または icmp ARP/ICMPパケットがキャプチャされず、RXカウンタがゼロのままの場合、問題は1000BASE-T1リンク自体ではなく、MAC-to-PHY RGMIIパスまたはそのデバイスツリーのタイミング構成にある可能性が最も高いです。 よろしくお願いいたします。 パベル Re: TJA1120A 1000BASET1 Linux side configuration パベルさん、おっしゃる通り、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 しかし、あなたの言うとおり、PCから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は私のPCのイーサネットポートのMACアドレスです これらのメッセージは、PC側で「宛先ホストに到達できません」と表示されてから約2秒後に始まります。 Re: TJA1120A 1000BASET1 Linux side configuration もちろん、パベル。私もPC側でトラフィックを監視しようと試みました。 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 さん。 したがって、問題はECUからPCへの送信方向にあるようです: ECU MAC TX パス、 MACとTJA1120A間のRGMII TXタイミング/遅延設定、 TJA1120送信経路、 メディアコンバータ受信経路、 またはRGMIIインターフェース上の信号整合性/ボードレベルのタイミングも考慮されます。 CONFIGピンのストラップはリセット後のデフォルト構成を定義しますが、NXP TJA11xx Linux**ドライバ**がアクティブな場合、Linuxデバイスツリーに従ってMDIOを通じてPHYを再構成できます。つまり、ピンストラップは実際には効果がありません。 1.片方向のみが影響を受ける場合は、例えば以下の通り、該当する方向性RGMII遅延バリアントをテストすると良いでしょう。 phy-mode = "rgmii-id"; /* RXおよびTXの内部遅延 */ phy-mode = "rgmii-rxid"; /* 受信内部遅延のみ */ phy-mode = "rgmii-txid"; /* TX内部遅延のみ */ phy-mode = "rgmii"; /* PHY内部遅延なし */ また、選択したLinuxの物理モードが、ハードウェア設計の意図された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. また、PCに期待されるインターフェースを強制しつつ、静的ARPテストを繰り返してください: sudo ip neigh replace *92.168.1.100lladdr 64:1c:10:1c:06*e2 dev eno1 nud permanent ip neigh*show 192.168.1.100dev eno1 ip rou*e get 192.168.1.100 sudo tcpdump -*ni eno1 -vvv '(arp または icmp)' ping *I eno1 192.168.1.100 注:上記のLinuxコマンドはあくまで例であり、特定のLinuxディストリビューション、ネットワークインターフェース名、システム構成に応じて調整が必要になる場合があります。 有効な静的ARPエントリがあれば、PCはARPリクエストを送信する必要がなくなります。ICMPエコー要求フレームをECUのMACアドレスに直接送信する必要があります。これらのフレームは、少なくともPC側のtcpdumpで確認できるはずです。PC側のtcpdumpでも出力ICMPフレームが表示されない場合は、PCルーティング、隣接テーブル、インターフェース選択を確認してください。 PC側では送信ICMPフレームが確認できるのにECU側では確認できない場合、PCからECUへのユニキャストトラフィックの通信はまだ完全には機能していない。ECUがICMPフレームを受信して応答を生成するにもかかわらず、PCがそれを受信しない場合、問題はECUからPCへの送信方向にあると考えられます。   よろしくお願いいたします。 パベル Re: TJA1120A 1000BASET1 Linux side configuration こんにちは、 @vikyhre さん。 最新情報のご提供ありがとうございます。この新しい結果は非常に有用です。 現時点では、RGMII-IDは正常に動作すると仮定してよいだろう。 重要な点として、PCからのARP要求はVLAN 0優先度タグ付きフレームであるということが挙げられる。 ethertype 802.1Q、vlan 0、ethertype ARP 一方、ECUのARP応答はタグなしのARPフレームである。PCインターフェース、ブリッジ、VLAN、QoS、またはドライバー/オフロード構成がタグ付きトラフィックを想定しているか、タグなしのARP応答がARPリクエストにフィルタリングされているか、または関連していないかを確認してください。 注:以下のLinuxコマンドはあくまで例であり、特定のLinuxディストリビューション、ネットワークインターフェース名、システム構成に応じて調整が必要になる場合があります。 PC側のトラフィックをキャプチャしてください。 sudo tcpdump -eni -vvv '(arp または icmp または vlan)' それから再びpingを開始します。 PCキャプチャでECU MACアドレス「64:1c:10:1c:06:e2」からのARP応答が表示されない場合、問題は依然としてECUからPCへの送信パスまたはメディアコンバーターパスにあります。   PCキャプチャでARPの返信が表示されても、PCが「宛先ホストに到達不可」と表示される場合、PC側のLinuxネットワーク/VLAN/フィルタリング設定に問題がある可能性が高いです。   追加の隔離テストとして、PCに静的なARPエントリを追加してみてください。   sudo ip neigh replace 192.168.1.100lladdr 64:1c:10:1c:06:e2 dev nud permanent   次に、両側のトラフィックをキャプチャしながら、ピングを繰り返します。 よろしくお願いいたします。 パベル Re: TJA1120A 1000BASET1 Linux side configuration こんにちは、 @vikyhre さん。 最新情報のご提供ありがとうございます。これは非常に良いニュースです。今はうまくいっているようで良かったです。 ログには不審な点は見当たりませんし、明らかに欠落しているものも見当たりません。最終的な確認として、iperf3テストを逆方向に実行してみるのも良いでしょう。 「rgmii-txid」に関するご懸念についてですが、この名前はLinuxの汎用デバイスツリー「phy-mode」値です。必ずしも同じLinux名でTJA1120Aデータシートに表示される必要はありません。TJA1120A RGMII TXCおよびRXCクロックパスにおける独立した遅延設定をサポートしています。レジスタRGMII_TXC_DELAY_CONFIGおよびRGMII_RXC_DELAY_CONFIGを参照してください。そしてピンストラップは当然ながら限られた構成セットしかサポートしていません。   もし前回の返信で問題解決に役立ったなら、他のユーザーが参照しやすくするために、その回答を解決策としてマークしていただけると嬉しいです。 よろしくお願いいたします。 パベル Re: TJA1120A 1000BASET1 Linux side configuration パベルさん、貴重なご意見ありがとうございます。 動作確認済み 私が懸念しているのは、TX_CLKに対する遅延のみである「rgmii-txid」がTJA1120Aのデータシートに記載されていないことです。しかし、それでも「rgmii-txid」は私たちの場合はうまく機能しました。この点についてご説明ください。DTはストラップを上書きできるとおっしゃっていたので、DTで「rgmii-txid」CONFIG_PIN変更しました。参考までに、PINストラップは現在RGMII-IDに設定されています（データシートの通り、RXのみ遅延が発生します）。 Windows PCからpingを実行した際の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. すべて解決済みと想定しておりますが、何か不足している点がありましたらお知らせください。他に付け加えることがなければ、あなたの回答を解決済みとしてマークします。 よろしくお願いします。

如何在不启用任何中断的情况下将 LPI2C 外设与 DMA 配合使用？ 你好， 我正在使用NXP S32K396 MCU ，并且希望在不启用任何中断的情况下使用 eDMA 执行 LPI2C 主站事务。在我的项目中，我使用了LPI2C1外设。 当启用以下中断时，我可以使用 DMA 成功执行 LPI2C 读写事务： LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn 然而，RTD LPI2C DMA 实现似乎依赖于这些中断。 在 Lpi2c_Ip_MasterSendData() 函数中，LPI2C 主中断始终由驱动程序启用： 此外，通过 Lpi2c_Ip_MasterTxDmaConfig() 和 Lpi2c_Ip_MasterRxDmaConfig() 配置的 TX 和 RX 的 DMA TCD 始终启用 DMA 主循环完成中断： Lpi2c_DmaTransferList[9u] .Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT ; Lpi2c_DmaTransferList[9u] .Value = 1U; 我还注意到，在其他函数中 - Lpi2c_Ip_MasterSendDataBlocking() 似乎没有为 LPI2C 传输配置 DMA TCD。 我希望使用 DMA 执行完整的 LPI2C 发送和接收事务，同时禁用 LPI2C1_IRQn 和 eDMA 通道中断。   如果可以的话，NXP能否提供一个使用DMA的LPI2C主控端TX/RX示例，其中LPI2C和DMA中断均被禁用？   MCU：NXPS32K396 RTD：6.0.0 NXP Studio：3.6.1   非常感谢您的帮助。非常感谢！ 如有需要，我可以附上我的项目文件。 Re: How to use LPI2C peripheral with DMA without enabling any interrupts? 你好@ rkhw 从当前的驱动程序实现来看，“Lpi2c_Ip_MasterSendData()”依赖于LPI2C主中断和DMA主循环完成中断来进行传输完成和状态处理。 因此，如果不启用中断，就无法启用 DMA。RTD驱动程序不支持此用法。

SPI用のDMAを設定する必要があります 私はS32DS IDEとRTD 3.0を使っています。SPIでDMAを起動する方法や、ステップバイステップの手順や、もしあれば他の例コードがあれば教えてもらえますか? Re: I need to configure DMA for SPI ご回答ありがとうございます。 この作業はs32k322 MCUで行ってください Re: I need to configure DMA for SPI こんにちは@ershi RTDにはDMAを用いたSPI通信用の2つの例コードが付属しており、1つは低レベルドライバ(Ip)を用い、もう1つは高レベルドライバ(MCAL)を使用します。例のインポート方法については、HOWTO: S32 Design Studio - Create a New S32DS Project from Example Threadを参照してください。 また、スレッドの 例であるS32K31 SPI Multiple Packet Transmit and Receive: Solution for DMA Cache Issueの例を参照することもできます。 BR、VaneB Re: I need to configure DMA for SPI こんにちは@ershi これらの例はS32K322向けに特別に設計されているわけではありませんが、リファレンス・マニュアルに特に記載されていない限り、S32K3 ファミリ全体で機能性は概ね同じです。したがって、このプロジェクトを実装の参考として活用し、必要に応じてデバイスに合わせて調整することができます。 Re: I need to configure DMA for SPI すべて設定しましたが、最初は動作せず、(Lpspi_Ip_AsyncTransmit)でLPSPI_IP_STATUS_SUCCESSとして返され、2回目は失敗と表示されますLPSPI_IP_STATUS_FAIL、DMAなしでこのAPIを使ってデータをSPI経由で送信できますLpspi_Ip_SyncTransmit()いくつかの設定スクリーンショットを添付しました。 Re: I need to configure DMA for SPI こんにちは@ershi RMやIntCtrl_Ipドライバーの設定画像も共有してもらえますか? Re: I need to configure DMA for SPI こんにちは、 @VaneBさん RMとIntCtrl_IPドライバの設定のスクリーンショットと、詳細な参考のために短い動画クリップを添付しました。 LPSPIの設定ページで1つの違いに気づきました。SPI GeneralタブのSpi_Phy_TxDmaChannelの項目で、TX設定とRX設定で名前が異なっています。 追加情報が必要な場合はお知らせください。 InterruptsInterrupts割り込み RMRMRM Re: I need to configure DMA for SPI こんにちは@ershi 情報を共有していただきありがとうございます。 一つだけ気づいたことがあります。Dma_Ipドライバー構成では、DMA_SPI_CALLBACK_0を割り込みコールバックとして定義しています。しかし、LPSPI DMAのコールバックはドライバーから既に提供されており、Lpspi_Ip_Irq.cで見つけることができますファイル。 LPSPI2の場合、設定するコールバックは以下のとおりです。 TX DMAチャネルのLpspi_Ip_LPSPI_2_IrqTxDmaHandler RX DMAチャネルのLpspi_Ip_LPSPI_2_IrqRxDmaHandler

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

I need to configure DMA for SPI I am using S32DS IDE and RTD 3.0 can anyone tell me how to start the DMA with SPI with step by step instructions or any other example code if available Re: I need to configure DMA for SPI Thank you for your response Do this work for s32k322 MCU Re: I need to configure DMA for SPI Hi @ershi  Included with the RTDs are provided two example codes for SPI communication using DMA, one using Low-Level Drivers (Ip) and one using High-Level Drivers (MCAL). You can refer to the thread HOWTO: S32 Design Studio - Create a New S32DS Project from Example for guidance on how to import the examples. Also, you can refer to the example provided in the thread Example S32K31 SPI Multiple Packet Transmit & Receive: Solution for DMA Cache Issue. BR, VaneB Re: I need to configure DMA for SPI Hi @ershi  Although the examples are not specifically designed for the S32K322, the functionality is generally the same across the S32K3 family, unless otherwise stated in the Reference Manual Therefore, you can use this project as a reference for your implementation and adapt it as needed for your specific device. Re: I need to configure DMA for SPI I had configurated everything but still it is not working initially it is return as LPSPI_IP_STATUS_SUCCESS  for (Lpspi_Ip_AsyncTransmit )and second time it is showing failed LPSPI_IP_STATUS_FAIL  I can able to send the data through spi using this api without the dma Lpspi_Ip_SyncTransmit() I have attached few configuration screenshot  Re: I need to configure DMA for SPI Hi @ershi  Could you also share images of the RM and IntCtrl_Ip driver configurations? Re: I need to configure DMA for SPI Hi @VaneB  I've attached the screenshots for the RM and IntCtrl_IP driver configurations, along with a short video clip for your detailed reference. I noticed one difference in the LPSPI configuration page. In the SPI General tab, under Spi_Phy_TxDmaChannel, the naming is different between the TX and RX configurations. Please let me know if you need any additional details InterruptsInterruptsInterrupts RMRMRM Re: I need to configure DMA for SPI Hi @ershi  Thank you for sharing all the information. I just have one observation. In the Dma_Ip driver configuration, you have defined DMA_SPI_CALLBACK_0 as the Interrupt Callback. However, the LPSPI DMA callbacks are already provided by the driver and can be found in the Lpspi_Ip_Irq.c file. For LPSPI2, the configured callbacks should be: Lpspi_Ip_LPSPI_2_IrqTxDmaHandler for the TX DMA channel Lpspi_Ip_LPSPI_2_IrqRxDmaHandler for the RX DMA channel

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. 我们假设现在一切都已安排妥当，如有遗漏，请告知。如果您没有其他补充，我将把您的回复标记为解决方案。 谢谢！

我需要为SPI配置DMA。 我正在使用 S32DS IDE 和 RTD 3.0，请问有人能告诉我如何通过 SPI 启动 DMA 吗？最好能提供详细的步骤说明或示例代码。 Re: I need to configure DMA for SPI 谢谢你的回复 请对 s32k322 MCU 执行此操作 Re: I need to configure DMA for SPI 嗨@ershi RTD 附带两个使用 DMA 进行 SPI 通信的示例代码，一个使用低级驱动程序 (Ip)，一个使用高级驱动程序 (MCAL)。您可以参考主题HOWTO: S32 Design Studio - 从示例创建新的 S32DS 项目，以获取有关如何导入示例的指导。 另外，您可以参考主题“示例 S32K31 SPI 多数据包发送和接收：DMA 缓存问题的解决方案”中提供的示例。 BR，VaneB Re: I need to configure DMA for SPI 嗨@ershi 虽然这些示例并非专门为 S32K322 设计，但除非参考手册另有说明，否则其功能在 S32K3 系列中通常相同。因此，您可以将此项目作为您实现的参考，并根据您的特定设备进行必要的调整。 Re: I need to configure DMA for SPI 我已经配置好了一切，但它仍然无法正常工作。第一次调用 (Lpspi_Ip_AsyncTransmit) 时返回 LPSPI_IP_STATUS_SUCCESS，第二次调用时返回失败 LPSPI_IP_STATUS_FAIL。我可以使用这个 API 通过 SPI 发送数据，而无需使用 DMA 调用 Lpspi_Ip_SyncTransmit()。我附上了一些配置截图。 Re: I need to configure DMA for SPI 嗨@ershi 能否也分享一下RM和IntCtrl_Ip驱动程序的配置图片？ Re: I need to configure DMA for SPI 嗨@VaneB 我已附上 RM 和 IntCtrl_IP 驱动程序配置的屏幕截图，以及一段简短的视频片段，供您详细参考。 我注意到LPSPI配置页面中有一处不同。在SPI常规选项卡中， Spi_Phy_TxDmaChannel下的命名在TX和RX配置中有所不同。 如果您需要任何其他详细信息，请告诉我。 InterruptsInterrupts打断 RMRMRM Re: I need to configure DMA for SPI 嗨@ershi 感谢您分享所有信息。 我只有一点看法。在 Dma_Ip 驱动程序配置中，您已将 DMA_SPI_CALLBACK_0 定义为中断回调。然而，LPSPI DMA 回调函数已由驱动程序提供，可以在 Lpspi_Ip_Irq.c 文件中找到。文件。 对于 LPSPI2，配置的回调函数应为： TX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqTxDmaHandler RX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqRxDmaHandler

S32 Design Studio for ARM v2.2 ライセンス拡張版 こんにちは。S32 Design Studio for ARM v2.2のインストールにおけるアクティベーション期間の延長についてサポートをお願いします。アクティベーションコードはFAF2-FCC2-8A8E-87ACです。よろしくお願いいたします。 こんにちは。S32 Design Studio for ARM v2.2のインストールにおけるアクティベーション期間の延長についてサポートが必要です。アクティベーションコード：FAF2-FCC2-8A8E-87AC。ありがとうございます！ Re: S32 Design Studio for ARM v2.2许可延期 こんにちは、 お客様のライセンス期間を延長いたしました。 よろしくお願いいたします。 ピーター

i.MX8M Plus - SD2_VSELは3.3Vに固定されています チームの皆さん、こんにちは。 SD2の電圧は3.3Vである必要があります。設計に1.8Vは入れたくありません。 では、PDをSD_VSEL(PMICピン)に入れて電圧を3.3Vに固定することはできますか? また、SoCからGPIOピンを1つ保存することもできます ハードウェアコントロールを進めて、ソフトウェアコントロールは提供されませんか? i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: i.MX8M Plus - SD2_VSEL fixed at 3.3V こんにちは、@ramkrish。 NXPサポートにご連絡いただきありがとうございます! EVKでは、SDカードの電圧切り替え信号がプロセッサのGPIOに接続されています。 SDドライバーはカード初期化および交渉の過程で自動的に3.3Vと1.8Vを切り替えます。高速microSDカードが検出され、カードとホストの両方が低電圧動作をサポートしている場合、ドライバーは1.8V信号に移行し、高性能モードを有効にします。 必要に応じてSDインターフェース電圧を手動で調整することもできます。しかし、このシステムは、動作条件に応じて電圧変動を自動的に処理するように既に設計されている。 よろしくお願いします、 チャビラ

IMXRT LPUART 非阻塞传输 API 使得错误处理变得困难。 您好， 我一直在研究 LPUART 的“传输”API，用于基于中断的非阻塞传输。它似乎很好地封装了所有“正常情况”下的 LPUART 中断处理等，并提供了一个良好的高级 API，用于在数据准备就绪时接收数据（即）。处理 IDLE、RX 就绪、TX 完成等状态）。然而，这使得处理 UART 错误变得非常困难。 LPUART_TransferHandleIRQ 函数内部没有错误处理，并且在 fsl_lpuart.c 中紧随其后的是一个虚假的空 LPUART_TransferHandleErrorIRQ 函数，其中包含注释“由用户实现”。这看起来完全是半成品。 处理 UART 错误的唯一方法似乎是覆盖默认的 LPUARTx_IRQHandler 函数，这样就不需要调用 LPUARTx_RX_DriverIRQHandler（或 TX），而是需要调用自己的函数来处理错误，并将“正常情况”中断传递给原始的 LPUARTx_RX/TX_DriverIRQHandler，以便它可以调用 LPUART_TransferHandleErrorIRQ。 此外，您还需要在传输 API 之外通过调用 LPUART_EnableInterrupts 来启用这些错误中断，并在错误处理中调用 LPUART_DisableInterrupts 并处理清除它们等操作。 这样处理错误似乎很麻烦。为什么这项功能没有内置到转账 API 中？ -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 ， 感谢您提供的详细反馈。我理解 SDK 可能有点含糊不清，因为这些 SDK 的目的是为每个外围设备功能提供常见的用例。我们也一直在努力改进我们的 API，这也要感谢像这样的建议。感谢您的建议，我们希望 LPUART 的错误处理功能能在未来的版本中得到实现。 另一方面，请问您想处理哪些具体的错误状态，以及您使用的是哪款设备？有了这些信息，我可以向您推荐一些与这些错误状态相关的文档，这些文档可能会对您的实施有所帮助。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 所有可能的错误。这几乎适用于所有具有传输 API 但没有错误处理的外围设备（SPI、I2C 等）。IMXRT1172 上的 LPUART 存在帧错误、奇偶校验错误和噪声错误，这些错误无法得到处理。遗憾的是，目前所有这些外围设备都需要一些破解才能处理使用传输 API 时出现的错误。我必须覆盖默认的 IRQ 处理程序，以便在调用 SDK 处理程序之前检查错误。 谢谢！ -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 ， 我知道这可能需要额外的开发时间，对此我们深表歉意，我们将继续努力改进我们的SDK。作为参考，您可以查看 SDK（版本 26.6）中名为“LPUART_TransferHandleIRQ”的函数的以下结构，并根据您的应用程序需要实现类似的恢复流程。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 ， 如果您还有其他问题，请告诉我。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 是的，我已经实现了类似的功能。谢谢你发来这个。

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,

i.MX8M Plus - SD2_VSEL 固定为 3.3V 大家好， 我需要SD2电压为3.3V。我的设计中不需要1.8V。 那么我可以将PD放置在SD_VSEL（PMIC引脚）上，使电压固定在3.3V吗？ 此外，我还可以从SoC中节省一个GPIO引脚。 只进行硬件控制而不进行软件控制是否可以？ i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: i.MX8M Plus - SD2_VSEL fixed at 3.3V 嗨@ramkrish ， 感谢您联系恩智浦技术支持！ 在 EVK 上，SD 卡电压开关信号连接到处理器的 GPIO。 SD 驱动程序在卡初始化和协商过程中自动在 3.3V 和 1.8V 之间切换。如果检测到高速 microSD 卡，并且该卡和主机都支持较低电压运行，则驱动程序将切换到 1.8V 信号以启用更高性能模式。 如有需要，您也可以手动控制 SD 接口电压。但是，该系统已经设计成可以根据运行条件自动处理电压转换。 此致， 查维拉

S32 Design Studio for ARM v2.2许可延期 您好，S32 Design Studio for ARM v2.2，Activation Code：FAF2-FCC2-8A8E-87AC，麻烦帮我延期，谢谢！ Hello, I need help extending the activation period for my S32 Design Studio for ARM v2.2 installation. Activation Code: FAF2-FCC2-8A8E-87AC. Thank you! Re: S32 Design Studio for ARM v2.2许可延期 你好， 我们已延长您的许可证期限。 顺祝商祺！ Peter

LS1088A 上的 DDRv 工具存在问题 您好，我正在尝试在基于 LS1088A SoC 的定制板上验证一种新型 DDR4 SO-DIMM，但我遇到了 DDRv 问题。我之前已经验证过其他几款DDR4内存，没有遇到任何问题。 我正在尝试验证的新型 DDR 芯片是来自 Memphis 的 IMM2G72D4SOD8AG-B075I。它的速度等级为 2,666，但我们希望它的运行速度为 2,100 MT/s。我创建了一个新的 QorQ 配置项目，并通过 SPD 成功读取了 DDR 配置。然而，第一步（时钟居中）在“自动搜索和检测写入均衡起始值”部分始终以 0.04% 的失败率失败。 在测试结果摘要中，我看到测试失败，原因是：“DDR接口故障并非由WRLVL_START值引起，请检查板上的硬件问题。 ” 在“日志”部分，我看到以下信息： ################## ## Result for: wrlvl_searcher ## ## ## Run  1 ## ####################################   测试结果：[ ============================================================ 已更新：WRLVL_CNTL = 0x86550605，WRLVL_CNTL_2 = 0x00000000，WRLVL_CNTL_3 = 0x00000000，SDRAM_CLK_CNTL = 0x02800000     ============================================================ 已更新：WRLVL_CNTL = 0x86550607，WRLVL_CNTL_2 = 0x09060C0F，WRLVL_CNTL_3 = 0x0E110B0E，SDRAM_CLK_CNTL = 0x02800000     ============================================================ 已更新：WRLVL_CNTL = 0x86550607，WRLVL_CNTL_2 = 0x09050C0F，WRLVL_CNTL_3 = 0x1611130E，SDRAM_CLK_CNTL = 0x02800000     DDR接口故障并非由于WRLVL_START值的问题，请检查主板上的硬件问题。 测试失败！ {{DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board.}}     错误捕获寄存器： 0xE20, 0x00000000 0xE24, 0x00000000 0xE28, 0x00000000 0xE40, 0x00000080 0xE44, 0x00000000 0xE48, 0x0000001D 0xE4C, 0x00000000 0xE50, 0x00000000 0xE54, 0x00000000 0xE58, 0x00010000     倾倒： 0xF00, 0x00000000 0xF04, 0x00001002 0xF08, 0x0000000A 0xF0C, 0x14000C20 0xF10, 0x00000000 0xF14, 0x00000000 0xF18, 0x00000000 0xF1C, 0x00000000 0xF20, 0x00000000 0xF24, 0x2F003500 0xF28, 0x2A003600 0xF2C, 0x3E004A00 0xF30, 0x44004600 0xF34, 0x3A007000 0xF38, 0x00000000 0xF3C, 0x00000000 0xF40, 0x00000000 0xF44, 0x00000000 0xF48, 0x00000001 0xF4C, 0x94000000 0xF50, 0x0F001300 0xF54, 0x0C001800 0xF58, 0x1F002C00 0xF5C, 0x22002700 0xF60, 0x1C000000 0xF64, 0x00009000 0xF68, 0x00000020 0xF6C, 0x00000000 0xF70, 0x0060007B 0xF74, 0x00000000 0xF78, 0x00000000 0xF7C, 0x00000000 0xF80, 0x00000000 0xF84, 0x00000000 0xF88, 0x00000000 0xF8C, 0x00000000 0xF90, 0x00000000 0xF94, 0x80000000 0xF98, 0x00000000 0xF9C, 0x29002B00 0xFA0, 0x2B002B00 0xFA4, 0x27002D00 0xFA8, 0x28002E00 0xFAC, 0x27000000 0xFB0, 0x10000003 0xFB4, 0x42344241 0xFB8, 0x40334332 0xFBC, 0x43404150 0xFC0, 0x00004133 0xFC4, 0x44424444 0xFC8, 0x44415134 0xFCC, 0x51414251 0xFD0, 0x42414241 0xFD4, 0x50434252 0xFD8, 0x50444342 0xFDC, 0x42413444 0xFE0, 0x43514340 0xFE4, 0x44424444 0xFE8, 0x42514441 0xFEC, 0x40423443 0xFF0, 0x43424342 0xFF4, 0x43415042 0xFF8, 0x51415341 0xFFC, 0x54000D0D       数据： 0x00000005 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000   ]   我还附上了验证失败过程中的详细 CCS 日志。   请问这是什么意思？我们该如何调试这个问题？ QorIQ LS1设备 Re: Problem with DDRv tool on LS1088A 与新型DDR4 SO-DIMM相比，以前使用的是哪种SO-DIMM？新旧版本之间的任何变化 Re: Problem with DDRv tool on LS1088A 你好， 对于您提供的具体转储，最可行的解释是：控制器在训练期间引发了自动校准错误 ( ACE )，DDRv 的写入均衡搜索无法通过调整 WRLVL_START 找到有效的运行区域。首先，这指向 RESET/时钟/配置/DQ-map/SI 检查，其中 DDR RESET 和 DQn_MAP 排在首位，因为在 NXP 调试历史中，两者都反复与此 DDRv 故障类别相关联。因此，在调整裕量之前，请验证 DDR 时钟/RCW、DDR RESET 时序、SPD 衍生的秩/几何、DQ 映射和功耗/SI。 此致

S32 Design Studio for ARM v2.2 license extended Hello, I need help extending the activation period for my S32 Design Studio for ARM v2.2 installation. Activation Code: FAF2-FCC2-8A8E-87AC. Thank you! Hello, I need help extending the activation period for my S32 Design Studio for ARM v2.2 installation. Activation Code: FAF2-FCC2-8A8E-87AC. Thank you! Re: S32 Design Studio for ARM v2.2许可延期 Hello, We have extended your license. Best regards, Peter

i.MX8M Plus - SD2_VSEL fixed at 3.3V Hi Team, I have a requirement of SD2 Voltage at 3.3V. I dont want 1.8V in my design. So Can I place PD in SD_VSEL (PMIC Pin) so that Voltage is fixed at 3.3V? Also I can save one GPIO pin from SoC Is it okay to proceed with HW Control and no SW Control will be provided? i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: i.MX8M Plus - SD2_VSEL fixed at 3.3V HI @ramkrish, Thank you for contacting NXP Support! On the EVK, the SD card voltage switching signal is connected to a GPIO of the processor. The SD driver automatically switches between 3.3V and 1.8V during the card initialization and negotiation process. If a high speed microSD card is detected and both the card and host support lower voltage operation, the driver will transition to 1.8V signaling to enable higher performance modes. You can also control the SD interface voltage manually if required. However, the system is already designed to handle the voltage transition automatically whenever the operating conditions require it. Best regards, Chavira

LS1088AのDDRvツールに問題があります こんにちは、LS1088A SoCベースのカスタムボード上で新しいタイプのDDR4 SO-DIMMを検証しようとしているのですが、DDRvで問題が発生しています。過去にいくつかのDDR4モデルを検証しましたが、問題は発生しませんでした。 私が検証しようとしている新しいDDRモデルは、メンフィスのB075I IMM2G72D4SOD8AGです。その速度制限は2,666ですが、2,100MT/sで運行したいと考えています。QorQの新しい構成プロジェクトを作成し、SPD経由でDDR構成を正常に読み込むことができました。しかし、最初のステップ(クロックのセンタリング)は「自動検索と書き込みレベリング開始値の検出」部分で0.04%で一貫して失敗します。 テスト結果の概要を見ると、テストが失敗し、理由は「DDRインターフェースがWRLVL_START値以外の原因で故障しています。ボードのハードウェア問題を調査してください。" ログセクションには、以下の情報が表示されます。 ################## ## Result for: wrlvl_searcher ## ## ## Run  1 ## ####################################   テスト結果: [ ============================================================ 更新: WRLVL_CNTL = 0x86550605、WRLVL_CNTL_2 = 0x00000000、WRLVL_CNTL_3 = 0x00000000、SDRAM_CLK_CNTL = 0x02800000     ============================================================ 更新: WRLVL_CNTL = 0x86550607、WRLVL_CNTL_2 = 0x09060C0F、WRLVL_CNTL_3 = 0x0E110B0E、SDRAM_CLK_CNTL = 0x02800000     ============================================================ 更新: WRLVL_CNTL = 0x86550607、WRLVL_CNTL_2 = 0x09050C0F、WRLVL_CNTL_3 = 0x1611130E、SDRAM_CLK_CNTL = 0x02800000     DDRインターフェースがWRLVL_START値以外の原因で故障しているので、基板のハードウェア問題を調査してください。 <> {{DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board.}}     エラーキャプチャレジスタ: 0xE20、0x00000000 0xE24、0x00000000 0xE28、0x00000000 0xE40、0x00000080 0xE44、0x00000000 0xE48、0x0000001D 0xE4C、0x00000000 0xE50、0x00000000 0xE54、0x00000000 0xE58、0x00010000     ごみ： 0xF00、0x00000000 0xF04、0x00001002 0xF08、0x0000000A 0xF0C、0x14000C20 0xF10、0x00000000 0xF14、0x00000000 0xF18、0x00000000 0xF1C、0x00000000 0xF20、0x00000000 0xF24、0x2F003500 0xF28、0x2A003600 0xF2C、0x3E004A00 0xF30、0x44004600 0xF34、0x3A007000 0xF38、0x00000000 0xF3C、0x00000000 0xF40、0x00000000 0xF44、0x00000000 0xF48、0x00000001 0xF4C、0x94000000 0xF50、0x0F001300 0xF54、0x0C001800 0xF58、0x1F002C00 0xF5C、0x22002700 0xF60、0x1C000000 0xF64、0x00009000 0xF68、0x00000020 0xF6C、0x00000000 0xF70、0x0060007B 0xF74、0x00000000 0xF78、0x00000000 0xF7C、0x00000000 0xF80、0x00000000 0xF84、0x00000000 0xF88、0x00000000 0xF8C、0x00000000 0xF90、0x00000000 0xF94、0x80000000 0xF98、0x00000000 0xF9C、0x29002B00 0xFA0、0x2B002B00 0xFA4、0x27002D00 0xFA8、0x28002E00 0xFAC、0x27000000 0xFB0、0x10000003 0xFB4、0x42344241 0xFB8、0x40334332 0xFBC、0x43404150 0xFC0、0x00004133 0xFC4、0x44424444 0xFC8、0x44415134 0xFCC、0x51414251 0xFD0、0x42414241 0xFD4、0x50434252 0xFD8、0x50444342 0xFDC、0x42413444 0xFE0、0x43514340 0xFE4、0x44424444 0xFE8、0x42514441 0xFEC、0x40423443 0xFF0、0x43424342 0xFF4、0x43415042 0xFF8、0x51415341 0xFFC、0x54000D0D       データ： 0x00000005 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000   ]   検証手順が失敗した際の詳細なCCSログも添付しました。   これが何を意味するのか、また問題のデバッグ方法を説明していただけますか? QorIQ LS1デバイス Re: Problem with DDRv tool on LS1088A 新しいタイプのDDR4 SO-DIMMと比べて、以前使われていたSODIMMはどのようなものでしたか?新旧間の変更点 Re: Problem with DDRv tool on LS1088A こんにちは、 あなたの具体的なダンプに関して最も有効な解釈は、コントローラがトレーニング中に自動キャリブレーションエラー( ACE )を発生させ、DDRvの書き込みレベリング検索が調整しても有効な動作領域を見つけられなかった WRLVL_START です。これはまずリセット/クロック/構成/DQマップ/SIチェックを指し示しており、DDRリセットと DQn_MAP は、NXPのデバッグ履歴においてこのDDRv障害クラスに繰り返し関連付けられているため、優先順位が高い。ですので、チューニングマージンを決める前にDDRクロック/RCW、DDRリセットタイミング、SPD由来のランク/ジオメトリ、DQマッピング、パワー/SIを確認してください。 よろしくお願いします。

S32G3 LLCE LIN マスターが「フレームタイムアウトを無効にする」がチェックアウトされているときにRx応答が欠けています NXPのエキスパートの皆様、こんにちは。 現在、S32G3(LINマスターとして動作)でLLCEコンポーネントを使ったLIN実装に取り組んでいます。私たちはS32G_LLCE_1_0_10を使用しています。 LLCE LINファームウェアのフレームタイムアウト構成に関して奇妙な挙動に遭遇しており、ファームウェアのブラックボックスロジックについて内部の詳細や説明を求めたいと思います。 問題の説明: LINチャネルを「Disable Frame Timeout」がUNCHECK(タイムアウト検出が有効)に設定し、Response Timeout値を14に設定した場合: LLCE LINマスターはヘッダー(ブレーク+同期+PID)をバスに正常に送信します。 スレーブノードはヘッダーを受信し、正しいデータとチェックサムを即座に返信します。 しかし、LLCEのLINマスターはランダムまたは継続的にデータの取得・受信に失敗します。データがLLCEファームウェアによって失われたり、破棄されたりしたかのように動作します。 回避策が見つかりました： 他のすべてのハードウェアおよび物理バス環境をまったく同じに保ったまま、設定ツールで「フレームタイムアウトを無効にする」（ファームウェアの内部タイムアウトロジックを無効にする）にチェックを入れるだけで次のようになります。 マスターはデータを一切ドロップせず、スレーブからのすべての応答を正常に受信します。 私たちの質問： LLCE_firmware_user_guide.pdfには内部ステートマシンに関する情報が非常に限られているため、この動作に困惑しています。 LLCEファームウェア内部では、タイムアウト値「14」はどのように正確に計算されるのですか？値14は、特定のGPT/タイマークロックソースに関連する絶対マイクロ秒、ビット時間、またはサイクルを表しますか？ 奴隷が即座に返答したにもかかわらず、なぜ主人はその反応を捉えられないのか？タイムアウトカウンターが早すぎる(例えばヘッダーの送信が終わる前)に始まっている可能性はありますか?それとも「14」という閾値が内部ハードウェアやファームウェアのレイテンシのために小さすぎるのでしょうか? 有効な応答を破棄することなくフレームタイムアウト保護を有効にしたままにしたい場合、このタイムアウト値を適切に計算して設定するための推奨される方法はありますか？ LLCE LINファームウェアの内部タイミングロジックに関するドキュメントやアプリケーションノート、洞察があれば大変ありがたいです。 よろしくお願いいたします！ よろしくお願いします、 cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq ご説明ありがとうございます。 1.DisableFrameTimeoutボックスにチェックを入れると、Linドライバーは最大フレーム長より長いフレームを受け入れます。 2. 「LinResponseTimeout」の場合、リセット値は0Eh = 14で、これはT_Response_Maximum = 1.4 x T_Response_Nominalに対応します。これは1バイトの応答タイムアウト時間（ビット時間）です。 BR チェイン   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、チェンインさん 迅速なご対応ありがとうございます。ご質問への回答と、ファームウェアのバージョンに関する訂正事項を以下にご説明いたします。 ハードウェア：弊社では、NXPの公式リファレンスボードではなく、S32G3をベースにしたカスタムボードを使用しています。 実装：公式のサンプルを直接実行しているわけではありません。これは当社独自の実装ですが、NXPの公式サンプルコードを参考に開発されています。 ファームウェアバージョンの訂正：最初の投稿でバージョンに関して間違いがあったことに気づきました。実際にはS32G_LLCE_1_0_10ではなく、S32G_LLCE_1_0_09を使用しています。 バージョン1.0.09のLIN応答タイムアウトに関連する既知のバグや、この特定のファームウェアバージョンでタイムアウト値「14」がどう解釈されるか確認を手伝ってもらえますか? よろしくお願いいたします、cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq 投稿ありがとうございます。 1. NXPのS32G3ベースのカスタムボード、またはリファレンスボードのどちらをお使いでしょうか？ 2. この問題は、お客様独自の実装で発生したものですか、それともNXPが提供するサンプルで発生したものですか？ BR チェイン Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、チェンインさん ご説明いただきありがとうございます。アプリケーションでDisableFrameTimeoutをチェックし続けることに決めたため、特定のタイムアウト計算は問題になりません。 ただし、DisableFrameTimeoutが有効になっている場合のファームウェアの状態マシンに関する特定の動作について確認しておきたいと思います。 LINマスターがヘッダーを送信し、スレーブが応答しない場合、Lin_GetStatus()を呼び出すとチャネルがLIN_TX_BUSY状態に永久に 固定 されます。 この構成において、LIN_TX_BUSY状態が永続的に続くのは、LLCEファームウェアの想定される正常な動作なのでしょうか？ フレームタイムアウトロジックが完全に無効になっているため、内部ステートマシンは応答データを無期限に待ち続け、ビジー状態から自動的に移行することはないだろうと私は推測します。自分の理解が公式設計と一致しているか確認したいだけです。 よろしくお願いいたします、cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq ご返信ありがとうございます。 フレームタイムアウトが無効でスレーブ応答がない場合、状態機械LLCE_LIN応答完了イベントもタイムアウトイベントも受け取らないため、問題が生じます。したがって、応答なし検出が必要な場合はフレームタイムアウトを有効にするか、LINチャネルを中止・再初期化するアプリケーションレベルのタイムアウトを実装してください。 BR チェイン