Multi Source Translation Content

ディスカッション

MPC5746Cは周囲温度115℃でハングアップする（起動せず、UARTも動作しない）。パート: MPC5746C(Power Architecture Z4、SDK:NXP MPC57xxプラットフォームSDK) 周囲温度115℃での恒温槽試験中、当社のMPC5746Cベースのボードは起動時に完全に反応しなくなり、UARTコンソール出力が全くなくなります。この現象は、その温度での起動試行のたびに発生します。冷却後、部品は完全に回復するようです。室温で再フラッシュ/再起動すると、永続的な損傷なく正常な動作に戻ります。興味深いことに、基板が115°Cの状態でもPEMicro JTAGデバッグプローブを使ってフラッシュを再プログラムすることは可能です。これは、温度でバージョンストリングをフラッシングし、冷却後に新しいバージョンを読み返すことで確認済みです。したがって、デバッグプローブのフラッシュ経路は115°Cで動作します。アプリケーションのブートパスだけがハング/悪い状態になります。マニュアルにはMCUが最大125°Cまで持続できると書かれています。問題の根本原因と解決方法を教えていただけませんか。 Re: MPC5746C hangs (no boot, no UART) at 115°C ambient こんにちは、マニュアルにはMCUが最大125°Cまで持続できると書かれています。はい、それは問題ありません。問題の根本原因と解決方法を教えていただけませんか。これはカスタムボードであり、冷却後に問題が解消されることから、私は次のことを疑っています。 1. 時計の起動に関する問題（最も可能性が高い） 115℃の場合：外部水晶発振器（FXOSC）の起動時間が長くなります。発振器のゲインマージンが減少する。負荷コンデンサの値は温度によって変化する。プリント基板からの漏洩電流が増加します。デバッグロジックは独自のインフラストラクチャを利用し、アプリケーションがmain(に到達する)に依存しないため、デバッガーは部品にアクセスできます。 FXOSCステータスビット CMUクロックモニタの障害 FIRCのみのブート実験 FIRCから完全に実行し、外部水晶発振器を一時的に無効にする JTAGのプログラミングが115°Cで動作し続けていることは、コアインフラストラクチャがまだ生きており、故障がフラッシュアレイ自体ではなくアプリケーションのブートパスの非常に早い段階で起きていることを示す最も強い手がかりですよろしくお願いいたします。ピーター Re: MPC5746C hangs (no boot, no UART) at 115°C ambient @petervlna さん、貴重なご意見ありがとうございます。これを受けて、同僚の@mnargundと私はさらに調査を進め、MPC5746Cを115℃で正常に起動させることに成功しました。以下に、調査結果の概要を示します。根本原因: 事前初期化時にシステムをFIRC、FXOSC、PLLを起動するように設定し、その後システムクロックをFIRCからPLLに切り替えました。続いて、DRUN モードへのモード遷移をトリガーしました（システムはデフォルトで既に DRUN モードでしたが、マニュアルに記載されているように、新しい設定を有効にするには同じモードへの遷移が必要です）。そして、MC_ME_GS.MTRANS をポーリングして遷移が完了するのを待ちました。しかし、MC_ME_GS.MTRANSがクリアされた後でも、コードはIVOR1例外でエラーを起こしました。これは、実行が続行された時点で遷移が完全に安定していなかったことを示している可能性があります。高温（115℃）では、室温よりも遷移に時間がかかるようで、次の命令が実行されたときにシステムが不安定な状態になる。回避策の適用例: MC_ME_GSの後に明示的なソフトウェア遅延を挿入しました。MTRANSのポーリングを行い、その後の初期化を進めます。500ミリ秒の遅延を設けると、115℃の環境下でも起動は安定して成功する。100ミリ秒の遅延もテストしましたが、私たちの環境では問題なく動作しました。初期化のこの段階で安全に挿入できる最大推奨ソフトウェア遅延はありますか? 125℃までの全動作温度範囲において、動作前にクロックの安定性を確実に確保するための推奨手順はありますか？

S32K389 AES_ACCEL が 64KB のデータを暗号化する際にハング/フリーズするこんにちは、NXPチームの皆様、私はS32K389を使用しており、 AES_ACCEL（ACE/MSC）モジュールをテストしています。大規模なデータバッファをプロセッシング中に安定性の問題に直面しました。テスト設定: モード:AES-CBC CASE 1(合格):4KBデータの暗号化は正しく動作します。企业微信截图_17834738161180.png ケース2(失敗):64KBのデータを暗号化すると、AESサービスが実行されるとチップが即座にクラッシュまたはハングします。観察された行動： S32DS(S32 Design Studio)はAESサービスの実行中にフリーズします。デバッガを介してS32K389に接続しようとすると、完全に失敗します。企业微信截图_17834744241242.png 質問: AES_ACCELトランザクションあたりの最大データ長に関して、既知の制限事項はありますか？よろしくお願いします、シアンロン Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは@wuxianlong 確認させてください。できるだけ早くご連絡いたします。よろしくお願いいたします。ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 遅れてすみません。内部リソースへのアクセス権に問題があり、解決に予想以上に時間がかかっています。できるだけ早くお答えします。ご辛抱いただきありがとうございます。よろしくお願いいたします。ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは@wuxianlong CMACが検証サービスを生成する際には、以下の制限があります。 lukaszadrapa_2-1784041947940.png 暗号化にも制限があるかどうか、現在確認中です。後ほどお知らせします。よろしくお願いいたします。ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは、 @lukaszadrapa ご説明いただき、誠にありがとうございました。暗号化とCMAC検証は、おそらく同じ制約に直面しているだろう。よろしくお願いします、シアンロン Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data サイズ制限は512KBで、LENビットフィールドのサイズは19ビットであるという情報を得ました。興味深いことに、実行が完全にクラッシュした。パラメータが無効な場合にエラーコードを返すだけAES_ACCELと思います。それはXRDCが原因ではないですか？XRDCは有効になっていますか？テスト目的で無効にしてみてもらえますか? よろしくお願いいたします。ルーカス Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは、 @lukaszadrapa 64KBでのテストも依然として失敗します。AECエラー検出を有効にすると、IPドライバマクロが制限を (1 << 19)- 1ビット<64 KBに設定していることがわかりました。 image.png 敬具仙龍

Android 16：为什么恩智浦半导体（NXP）在 vendor_boot 中发明了一种处理设备树的独特方法？检查 Android 16 1.4.0 版本中包含的最后一个 u-boot 启动加载程序，我发现启动加载程序中添加了一个配置选项“CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT”。我以为这样就能解决问题，因为旧版本的 Android 使用“dtbo”分区来存储主设备树。我的理解是错误的，因为主设备树应该放在“vendor_boot”分区中（至少对于vendor_boot v4来说是这样），而dtbo分区填充了设备树覆盖层，这些覆盖层可以应用于主设备树以支持硬件变体。请参见 https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions 文档中明确指出，vendor_boot 中只能有一个设备树。但现在 NXP 已经实现了放弃“dtbo”分区，并使用 vendor_boot 内部的“dt_table_header”结构体，直接向 vendor_boot 添加多个完整的设备树。此标头通常用于“dtbo”分区内，以组织多个设备树覆盖层，但不用于“vendor_boot”分区内。 NXP 的这种处理设备树的特殊方式与 Android 的标准方式相冲突，Android 的标准方式是使用一个主设备树和来自 dtbo 的设备树覆盖层。这使得像我这样使用设备树覆盖概念来维护其 Android 移植版本的用户变得困难。 NXP 为什么选择以这种方式实现设备树变体？你们是否有计划将此行为改回 Android 官方文档中描述的方式？ Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot 你好，请注意，Android 并不强制要求拥有多个设备树，因此，除非操作系统架构发生强制性变更，否则我认为我们提供电路板支持包。的方式不会改变，因为到目前为止，这已经是许多版本的默认做法。另外，请注意，引导加载程序在选择设备树时需要执行以下操作： 1> 识别SoC并加载相应的.dtb文件从存储器到内存。 2> 识别开发板并加载相应的 .dtbo 文件从存储器到内存。 3> 覆盖 .dtb 文件将 .dtbo 合并为一个 DT。 4> 根据合并后的 DT 的内存地址启动内核。因此，我们无法确定应该使用哪个设备树，因为我们使用相同的硬件，只是针对不同的实现/演示做了一些小的改动。我认为只有在使用相同的 SOM（相同的基本配置 SoC+DDR+电源 IC）但使用不同的硬件时，这种方法才有用。因此，这不符合我们交付硬件/软件的方式，添加它也没有任何好处。此致敬礼/Saludos，阿尔多。

Android 16: Why has NXP invented an own way to handle device trees in vendor_boot Inspecting last u-boot bootloader contained in Android 16 1.4.0 release I have discovered that an config option "CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT" has been added to the bootloader. I assumed that it fixes the problem, that older Android versions used "dtbo" partition to store the main device tree. In my understanding that was wrong, because main device tree should be placed in "vendor_boot" partition (at least for vendor_boot v4) and dtbo partition gets filled with device tree overlays which can be applied to the main device tree to support hardware variants. See https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions where it is documented, that only one device tree to be inside vendor_boot. But now NXP has made an implementation to abandon "dtbo" partition and use the "dt_table_header" struct inisde vendor_boot to add more than one full device tree directly to vendor_boot. This header is normally used inside "dtbo" partition to organize multiple device tree overlays, but not inside "vendor_boot". This NXP specific way of handling device trees conflicts with the standard Android way to use one main device tree and device tree overlays from dtbo. This makes it hard for users (like me) who use the concept of device tree overlays to maintain their Android ports. Why has NXP chosen to implemeted device tree variants in that way? Do you have plans to change this behaviour back to the way as documented by Android? Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot Hello, Please note that having multiple device tree is not mandatory for Android, so unless there is a mandatory change in the architecture of the OS I do not think this will change on how we provide our BSP as this has been the default for many versions so far. Also, note that for selecting the device tree the bootloader needs to: 1> Identify the SoC and load the corresponding .dtb from storage into memory. 2> Identify the board and load the corresponding .dtbo from storage into memory. 3> Overlay the .dtb with the .dtbo to be a merged DT. 4> Start kernel given the memory address of the merged DT. Following this we do not have a way to identify if one device tree should be used or the other, as we use the same hardware and just small changes for different implementation/demonstration, I would see this useful only if you are working with different hardware while using the same SOM (same basic configuration SoC+DDR+power IC). So, this does not comply on how we deliver our hw/sw and see no benefit on adding it. Best regards/Saludos, Aldo.

S32K389 AES_ACCEL 在加密 64KB 数据时会挂起/冻结您好，NXP团队：我正在使用S32K389并测试AES_ACCEL (ACE/MSC)模块。我在处理大型数据缓冲区时遇到了稳定性问题。测试设置：模式： AES-密码块链接(CBC) 案例 1（通过）：加密4KB数据工作正常。企业微信截图_17834738161180.png 案例 2（失败）：加密64KB数据会导致芯片在执行 AES 服务时立即崩溃/挂起。观察到的行为： S32DS（S32 设计工作室）在执行 AES 服务期间冻结。尝试通过调试器连接到 S32K389 完全失败。企业微信截图_17834744241242.png 问题：对于每个 AES_ACCEL 事务的最大数据长度，是否存在任何已知的限制？此致，显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong 让我查一下。我会尽快回复您。此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 很抱歉耽搁了，我遇到了一些内部资源访问权限方面的问题，解决起来比预期要花更多时间。我会尽快回复。感谢您的耐心等待。此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong CMAC生成验证服务存在以下限制： lukaszadrapa_2-1784041947940.png 我还在确认加密方面是否存在限制。我稍后会通知你。此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 你好， @lukaszadrapa 非常感谢您的解释。加密和 CMAC 验证可能面临同样的局限性。此致，显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 我了解到大小限制为 512KB - LEN 位域的大小为 19 位。有趣的是，程序执行完全崩溃了。我预计 AES_ACCEL 在参数无效的情况下会返回一些错误代码。那不是XRDC引起的吗？XRDC 是否已启用？您能否尝试将其禁用以进行测试？此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 你好， @lukaszadrapa 使用 64KB 进行测试仍然失败。启用 AEC 错误检测后发现，IP 驱动程序宏将限制设置为(1 << 19) - 1 位 < 64 KB。 image.png 此致，显龙

S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi NXP team, I’m working with the S32K389 and testing the AES_ACCEL (ACE/MSC) module. I’ve encountered a stability issue when processing large data buffers. Test Setup: Mode: AES-CBC Case 1 (Pass): Encrypting 4KB data works correctly. 企业微信截图_17834738161180.png Case 2 (Fail): Encrypting 64KB data causes the chip to crash/hang immediately when the AES service is executed. Observed Behavior: S32DS (S32 Design Studio) freezes during the execution of the AES service. Attempts to Attach to the S32K389 via the debugger fail completely. 企业微信截图_17834744241242.png Questions: Are there any known limitations regarding the maximum data length per AES_ACCEL transaction? Best Regards, xianlong Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi @wuxianlong Let me check this. I will get back to you as soon as possible. Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data I'm sorry for delay, I have some issues with access rights to internal resources and it takes more time than expected to solve it. I will answer this as soon as possible. Thanks for your patience. Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi @wuxianlong There's following limitation for CMAC generate a verify services: lukaszadrapa_2-1784041947940.png I'm still checking if there's a limitation also for encryption. I will let you know later. Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi,@lukaszadrapa Thank you very much for your explanation. It is probable that encryption and CMAC verification face the same limitations. Best Regards, xianlong Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data I got information that size limitation is 512KB - the size of LEN bit field is 19 bits. Interesting thing is that the execution crashed completely. I would expect that AES_ACCEL just returns some error code in case of invalid parameters. Isn't that caused by XRDC? Is XRDC enabled? Could you try to disable it for test purposes? Regards, Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data Hi,@lukaszadrapa Testing with 64KB still fails. Enabling AEC error detection revealed the IP driver macro sets the limit to (1 << 19) - 1 bit < 64 KB. image.png Best Regards, xianlong

Set Custom Hostname in LLDP SDK I want to change the hostname of the LLDP SDK for NXP LX2160ARBD Board. I tried using "hostname" and "hostname_pn-base-files" in local.conf, but after building it shows the default hostname. I even tried creating a base-files recipe with a bbappend to modify hostname and hosts file in my custom layer, even that didn't work.. What else can be done? Re: Set Custom Hostname in LLDP SDK I have resolved this by using the parameter HOST_NAME = "CUSTOM_HOSTNAME" in the respective distro's bb file, in my case it is ls-image-main. I created a ls-image-main.bbappend in my custom layer and added this line in that file and after building the distro recipe, host name change was reflected in the image. Re: Set Custom Hostname in LLDP SDK If you want to add custom machine in the yocto, you could refer to https://docs.nxp.com/bundle/UG10081_LLDP_L6.1.55_2.2.0/page/topics/how_to_add_a_custom_machine_in_flexbuild_based_on_.html Thanks

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. すべて解決済みと想定しておりますが、何か不足している点がありましたらお知らせください。他に付け加えることがなければ、あなたの回答を解決済みとしてマークします。よろしくお願いします。

在 LLDP SDK 中设置自定义主机名我想更改 NXP LX2160ARBD 板的 LLDP SDK 的主机名。我尝试在 local.conf 中使用“hostname”和“hostname_pn-base-files”，但构建完成后，它显示的是默认主机名。我甚至尝试创建一个包含 bbappend 的基础文件配方来修改自定义层中的主机名和 hosts 文件，但仍然无效……还有什么办法吗？ Re: Set Custom Hostname in LLDP SDK 我通过在相应发行版的 bb 文件中使用参数 HOST_NAME = "CUSTOM_HOSTNAME" 解决了这个问题，在我的例子中，它是 ls-image-main。我在自定义层中创建了 ls-image-main.bbappend 文件，并在该文件中添加了这一行，构建发行版配方后，主机名更改反映在了镜像中。 Re: Set Custom Hostname in LLDP SDK 如果您想在 Yocto 中添加自定义机器，可以参考以下内容： https://docs.nxp.com/bundle/UG10081_LLDP_L6.1.55_2.2.0/page/topics/how_to_add_a_custom_machine_in_flexbuild_based_on_.html 谢谢！

ZephyrにおけるPN5180のサポート追加こんにちは、ZephyrでPN5180 NFCリーダのサポートが来るかどうか気になっています。NXPのIMXRT1064、PN5180、Zephyrを組み合わせることに非常に興味があります。ZephyrにNFCリーダライブラリを追加したり、NFCリーダライブラリにZephyrのサポートを追加する可能性はありますか?ありがとう！ Re: Adding support for PN5180 in Zephyr なぜPN5180はZephyrと併用できないのでしょうか? Re: Adding support for PN5180 in Zephyr こんにちは、残念ながら。ZephyrはPN5180をサポートしません。詳細については、リンク先の情報をご覧ください。 URL: https://www.nxp.com/design/software/embedded-software/zephyr-os-for-edge-connected-devices:ZEPHYR-OS-EDGE . 良い１日を。 ------------------------------------------------------------------------------- 注記：この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視していますもし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -----------------------------------------------------------------------------

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

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

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

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

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

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

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

VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking suppo Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao Thanks for the post. May I know if you are referring to the following API used " Std_ReturnType I2c_AsyncTransmit (uint8 Channel, const I2c_RequestType ∗ RequestPtr ) "? Which version RTD is used? BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is： * Project : RTD AUTOSAR 4.4 * Platform : CORTEXM * Peripheral : VR5510 * Dependencies : none * * Autosar Version : 4.4.0 * Autosar Revision : ASR_REL_4_4_REV_0000 * Autosar Conf.Variant : * SW Version : 4.0.2 * Build Version : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) Copyright 2020-2023 NXP Semiconductors * All Rights Reserved. * use this function Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao Thanks for your confirmation. By checking with the corresponding code, the VR5510 Solution for I2C asynchronous communication is implemented in RTD5.0.0QLP04 You may check the related code in this version RTD for details. BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is： * Project : RTD AUTOSAR 4.4 * Platform : CORTEXM * Peripheral : VR5510 * Dependencies : none * * Autosar Version : 4.4.0 * Autosar Revision : ASR_REL_4_4_REV_0000 * Autosar Conf.Variant : * SW Version : 4.0.2 * Build Version : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) Copyright 2020-2023 NXP Semiconductors * All Rights Reserved. * use this function Pmic_VR55XX_TriggerWatchdog

Multi Source Translation Content

Multi Source Translation Content

ディスカッション

2393533_ja-JP

2391904_ja-JP

2395297_zh-CN

2395297_en-US

2391904_zh-CN

2396388_en-US

2391904_en-US

2396388_zh-CN

2112550_en-US

2394420_ja-JP

2112550_zh-CN

1352718_ja-JP

2394420_en-US

2394420_zh-CN

2112550_ja-JP

1352718_en-US

1352718_zh-CN

2393138_ja-JP

2395420_ja-JP

2395420_en-US