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.

S32K358 eMIOS ISR stuck at 85°C Dear NXP Support Team, we are facing an issue on S32K358 during temperature tests at around 85°C.   In our application we use 6 eMIOS channels, each one configured to generate interrupts on both PWM edges with a frequency of 200Hz.   At 85°C, the MCU sometimes gets stuck inside one eMIOS ISR. The ISR does not exit because the code checks the interrupt flag by reading the eMIOS registers, but the flag is 0 (file Emios_Mcl_Ip_Irq.c 😞   if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))    After debugging, we noticed that when the issue occurs, the variable containing the eMIOS base address is NULL (Emios_Ip_paxBase). When the application works correctly, the same pointer is valid and the eMIOS registers are read properly. It seems that, in some conditions, the reference to the eMIOS peripheral is corrupted or cleared during ISR execution.   Do you have any indication about possible known issues or root causes, such as stack overflow, memory corruption, concurrent accesses, ISR handling, or temperature-related behavior?   Best regards, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi vane, I'm currently using RTD 7.0.0 Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Which RTD version are you working with? Any additional information would be helpful. Also, in RTD versions prior to 6.0.0, there was a known issue related to the incorrect memory mapping of static variables within function scope (ARTD-159985). This issue describes a problem where the variable Emios_Ip_paxBase, defined in both Emios_Mcl_Ip.c and Emios_Mcl_Ip_Irq.c, is assigned inconsistent initialization characteristics. Further details are provided in the Software Release Notes. BR, VaneB Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Could you please provide a simple application that reproduces the observed behavior? Also, could you confirm whether you are working with a custom board or an evaluation board? Additionally, could you share how the testing is being performed to confirm that the issue occurs at 85 °C? Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , Currently i'm working with a custom board with S32K358 where i use these eMIOS_1 channels to generate PWM of 200 Hz: ch3, ch9,  ch11, ch12, ch13, ch19. Code is generated using SImulink  Putting my custom board into a climatic cell at 85°C i've observed the stucking behaviour after some time. While i was debugging with S32DS (3.6.7) I've found out that it stuck into the ISR(EMIOS1_1_IRQ) so i've put into it some custom counter near entry/exit function, and also into Emios_Pwm_IrqHandler and Emios_Pwm_Ip_IrqHandler functions, in order to detect what parts of the code are executed.  After some tests i've found out that, when it stucks, inside static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) {     /* Check that an event occurred on Emios channel */     if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))     {         /* Check that an event occurred on EMIOS channel */         if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))         {             Emios_Pwm_Ip_IrqHandler(Instance, Channel);         }         else         {             /* Do nothing - in case of spurious interrupts, return immediately */         }     } }   the if condition: if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))   is always 0 because, for some reason, Emios_Ip_paxBase[Instance] points to 0. This means that nobody is clearing the interrupt flag so it enters in a loop where it cannot escape.   here's the code i've used to detect this probelm: static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) {     // uint32_t s;     // uint32_t c;     // uint32_t s_flag;     // uint32_t s_ovr;     dbg_pwm_last_instance = Instance;     dbg_pwm_last_channel = Channel;     dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance];     dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;     dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;         dbg_emiosipirq_static_state1++;     /* if (Instance == 1)     {         switch (Channel)         {             case 16:                 dbg_emiosipirq_static_cnt_ch16++;                 break;             case 17:                 dbg_emiosipirq_static_cnt_ch17++;                 break;             case 18:                 dbg_emiosipirq_static_cnt_ch18++;                 break;             case 19:                 dbg_emiosipirq_static_cnt_ch19++;                 break;             default:                 dbg_emiosipirq_static_cnt_oth1++;                 break;         }     }     else     {         dbg_emiosipirq_static_cnt_oth2++;     } */     /* Lettura reale dei registri vista dal codice */    /*  s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;     c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;     s_flag = s & (uint32)eMIOS_S_FLAG_MASK;     s_ovr  = s & (uint32)eMIOS_S_OVR_MASK;     dbg_pwm_last_s = s;     dbg_pwm_last_c = c;     dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK;     dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK;     dbg_pwm_last_s_and_flag = s_flag;     dbg_pwm_last_s_and_ovr = s_ovr;     if (s_flag != 0U)     {         dbg_pwm_s_flag_yes++;     }     else     {         dbg_pwm_s_flag_no++;     }     if (s_ovr != 0U)     {         dbg_pwm_s_ovr_yes++;     }     else     {         dbg_pwm_s_ovr_no++;     }     if ((s_flag == 0U) && (s_ovr != 0U))     {         dbg_pwm_flag0_ovr1_count++;     }     else if ((s_flag != 0U) && (s_ovr != 0U))     {         dbg_pwm_flag1_ovr1_count++;     }     else if ((s_flag != 0U) && (s_ovr == 0U))     {         dbg_pwm_flag1_ovr0_count++;     }     else     {         dbg_pwm_flag0_ovr0_count++;     } */     /* Check that an event occurred on EMIOS channel */     if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))     {         dbg_emiosipirq_static_state2++;         /* Check that an event occurred on EMIOS channel */         if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))         {             dbg_emiosipirq_static_state3++;             Emios_Pwm_Ip_IrqHandler(Instance, Channel);         }         else         {             dbg_emiosipirq_static_state4++;             /* Do nothing - in case of spurious interrupts, return immediately */         }     }     else     {         dbg_emiosipirq_static_state5++;         //Emios_Pwm_Ip_IrqHandler(Instance, Channel);         //Emios_Pwm_Ip_IrqHandler(1, 19);     } } These are the global vars in which i've stored the addresses which Emios_Ip_paxBase should point to: dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; I've put also some custom code to read NVIC registers run time: attached you can find the file with Thread, general registers, NVIC registers and variables expressions, EMIOS registers, for 6 tests i made. Also i will provide you the S32DS project i used to test this behaviour in a private message. I hope all these information could be usefull. I remain at your disposal for any further information. BR, SImon Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Thank you very much for providing this information. Since the code appears to be getting stuck in EMIOS1_1_IRQ, which corresponds to eMIOS 1 Channel 19 based on your configuration, let’s try to narrow the analysis to this specific part. To simplify the debugging and rule out any interference from other modules, please create a minimal test project that only includes this eMIOS configuration. This will help us isolate the behavior and better understand the root cause. For guidance, you can review the examples provided in the thread S32M27x/S32K3 – eMIOS Usage. Does the same behavior still occur? Also, if you have an evaluation board, it would be great if you could try the same code there. Re: S32K358 eMIOS ISR stuck at 85°C Hi vane, I'll try this week to give you a simple project that replicate the behaviour Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , I tested the issue on my custom board using a simplified configuration that only includes the six eMIOS1 channels. Unfortunately, in this setup I am not able to reproduce the error. The application runs correctly and does not get stuck in EMIOS_1_IRQ. At the moment, I am looking into whether it is feasible to load the complete project developed for our custom board onto the EVB. Before proceeding, I would also like to understand if the hardware differences between the custom board and the EVB could potentially lead to any unexpected behavior or even damage to the EVB. BR, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Our evaluation boards are designed mainly for use at room temperature and have not been tested or qualified for very low or very high temperatures. You may still use the evaluation boards outside the room-temperature range, but we cannot guarantee their performance under those conditions. Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , After several attempts, I managed to create an EVB project that reproduces the application running on my custom board as closely as possible. In particular, I configured all the pins in the same way as in my custom project. I then tested this project on my custom board under 85°C conditions, and the eMIOS ISR issue still occurred: the application continued to get stuck. After that, I tested exactly the same project on the EVB under the same temperature conditions and over (90°C), but I was not able to reproduce the issue—the EVB continued to operate correctly without getting stuck. At this point, what would you recommend as the next steps to identify the root cause of the problem and find a possible solution? Please let me know if you need any additional information, measurements, or debugging data from my side. I have attached a ZIP file containing the complete EVB project and the pictures of the K358 on my custom board and on the EVB. Thank you for your support. BR Simone Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  As the issue is observed on your custom board but not on the EVB, it would be worthwhile to investigate whether the root cause could be hardware-related. I recommend comparing your hardware design against the EVB schematic and reviewing the S32K3 Hardware Design Guideline to verify that all relevant recommendations have been properly implemented.

S32K358 eMIOS ISR 卡在 85°C 尊敬的恩智浦技术支持团队： 我们在 S32K358 上进行 85°C 左右的温度测试时遇到了问题。   在我们的应用中，我们使用了 6 个 eMIOS 通道，每个通道都配置为在 PWM 的两个边沿生成中断，频率为 200Hz。   在 85°C 时，MCU 有时会卡在某个 eMIOS 中断服务例程 (ISR) 中。ISR 无法退出，因为代码会通过读取 eMIOS 寄存器来检查中断标志，但该标志的值为 0（文件 Emios_Mcl_Ip_Irq.c）。 😞   如果( 0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32) eMIOS_S_FLAG_MASK ))   调试后我们发现，当问题出现时，包含 eMIOS 基地址的变量（ Emios_Ip_paxBase）为 NULL 。而当应用程序正常运行时，该指针有效，并且 eMIOS 寄存器也能被正确读取。 似乎在某些情况下，对 eMIOS 外设的引用在 ISR 执行期间会被损坏或清除。   您是否有任何关于可能存在的已知问题或根本原因的线索，例如堆栈溢出、内存损坏、并发访问、中断服务例程处理或温度相关行为？   顺祝商祺！ 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨，范恩 我目前使用的是 RTD 7.0.0 版本。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 你使用的是哪个版本的RTD？任何其他信息都将不胜感激。 此外，在 6.0.0 之前的 RTD 版本中，存在一个与函数作用域内静态变量的内存映射不正确相关的已知问题 (ARTD-159985)。 此问题描述了在 Emios_Mcl_Ip.c 中定义的变量 Emios_Ip_paxBase 存在的问题。Emios_Mcl_Ip_Irq.c 被赋予了不一致的初始化特性。更多详情请参阅软件版本说明。 BR，VaneB Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 能否提供一个能够重现所观察到的现象的简单应用程序？另外，能否确认一下您使用的是定制电路板还是评估电路板？ 另外，能否分享一下测试是如何进行的，以确认该问题是否在 85°C 时出现？ Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 目前我正在使用一块带有 S32K358 的定制板，其中我使用以下 eMIOS_1 通道生成 200 Hz 的 PWM：ch3、ch9、ch11、ch12、ch13、ch19。代码是使用 Simulink 生成的。 我将定制电路板放入 85°C 的气候箱中一段时间后，观察到了卡顿现象。 我在使用 S32DS (3.6.7) 进行调试时我发现它卡在了 ISR(EMIOS1_1_IRQ) 中，所以我在入口/出口函数附近以及 Emios_Pwm_IrqHandler 和 Emios_Pwm_Ip_IrqHandler 函数中都添加了一些自定义计数器，以便检测代码的哪些部分正在执行。 经过一些测试，我发现，当它卡住时，内部…… static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { /* 检查 Emios 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) { /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK)))) { Emios_Pwm_Ip_IrqHandler(实例, 通道); } 别的 { /* 什么也不做 - 如果遇到虚假中断，立即返回 */ } } } if 条件： 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) 始终为 0，因为由于某种原因，Emios_Ip_paxBase[Instance] 指向 0。这意味着没有人清除中断标志，因此它进入了一个无法逃脱的循环。 以下是我用来检测此问题的代码： static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { // uint32_t s; // uint32_t c; // uint32_t s_flag; // uint32_t s_ovr; dbg_pwm_last_instance = 实例; dbg_pwm_last_channel = Channel; dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; dbg_emiosipirq_static_state1++; /* 如果 (实例 == 1) { 切换（通道） { 案例16： dbg_emiosipirq_static_cnt_ch16++; 休息; 案例17： dbg_emiosipirq_static_cnt_ch17++; 休息; 案例18： dbg_emiosipirq_static_cnt_ch18++; 休息; 案例19： dbg_emiosipirq_static_cnt_ch19++; 休息; 默认： dbg_emiosipirq_static_cnt_oth1++; 休息; } } 别的 { dbg_emiosipirq_static_cnt_oth2++; } */ /* Lettura reale dei registri vista dal codice */ /* s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; s_flag = s & (uint32)eMIOS_S_FLAG_MASK; s_ovr = s & (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s = s; dbg_pwm_last_c = c; dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK; dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s_and_flag = s_flag; dbg_pwm_last_s_and_ovr = s_ovr; 如果 (s_flag != 0U) { dbg_pwm_s_flag_yes++; } 别的 { dbg_pwm_s_flag_no++; } 如果 (s_ovr != 0U) { dbg_pwm_s_ovr_yes++; } 别的 { dbg_pwm_s_ovr_no++; } 如果 ((s_flag == 0U) && (s_ovr != 0U)) { dbg_pwm_flag0_ovr1_count++; } 否则如果 ((s_flag != 0U) && (s_ovr != 0U)) { dbg_pwm_flag1_ovr1_count++; } 否则如果 ((s_flag != 0U) && (s_ovr == 0U)) { dbg_pwm_flag1_ovr0_count++; } 别的 { dbg_pwm_flag0_ovr0_count++; } */ /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) { dbg_emiosipirq_static_state2++; /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK)))) { dbg_emiosipirq_static_state3++; Emios_Pwm_Ip_IrqHandler(实例, 通道); } 别的 { dbg_emiosipirq_static_state4++; /* 什么也不做 - 如果遇到虚假中断，立即返回 */ } } 别的 { dbg_emiosipirq_static_state5++; //Emios_Pwm_Ip_IrqHandler(Instance, Channel); //Emios_Pwm_Ip_IrqHandler(1, 19); } } 以下是我存储 Emios_Ip_paxBase 应指向的地址的全局变量： dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; 我还添加了一些自定义代码，用于在运行时读取 NVIC 寄存器：附件中包含线程、通用寄存器、NVIC 寄存器和变量表达式、EMIOS 寄存器等文件，以及我进行的 6 次测试。 另外，我会在私信中提供我用来测试此行为的 S32DS 项目。 希望这些信息对大家有所帮助。如有任何其他疑问，请随时联系我。 BR， 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 非常感谢您提供这些信息。 由于代码似乎卡在了 EMIOS1_1_IRQ 中，根据您的配置，它对应于 eMIOS 1 通道 19，让我们尝试将分析范围缩小到这一特定部分。 为了简化调试并排除其他模块的任何干扰，请创建一个仅包含此 eMIOS 配置的最小测试项目。这将有助于我们找出问题所在，并更好地了解其根本原因。如需指导，您可以查看S32M27x/S32K3 – eMIOS 使用主题中提供的示例。 同样的行为是否仍然存在？另外，如果您有评估板，最好能在上面测试一下相同的代码。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨，范恩 我本周会尝试给你一个简单的项目来复现这种行为。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 我们的评估板主要设计用于室温环境，尚未经过极低或极高温度的测试或认证。 您仍然可以在室温范围之外使用评估板，但我们无法保证它们在这些条件下的性能。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 我用简化的配置在我的定制板上测试了这个问题，该配置只包括六个 eMIOS1 通道。遗憾的是，在这种配置下我无法重现该错误。应用程序运行正常，不会卡在 EMIOS_1_IRQ 中。 目前，我正在研究将为我们定制板开发的完整项目加载到 EVB 上是否可行。在继续之前，我还想了解一下定制板和 EVB 之间的硬件差异是否可能导致任何意外行为，甚至损坏 EVB。 BR， 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 经过多次尝试，我终于创建了一个 EVB 项目，该项目尽可能地重现了在我的定制板上运行的应用程序。具体来说，我将所有引脚的配置方式都与我的自定义项目中的配置方式相同。 然后我在 85°C 的条件下用我的定制板测试了这个项目，eMIOS ISR 问题仍然存在：应用程序继续卡住。 之后，我在相同的温度条件下，甚至在 90°C 以上，对 EVB 进行了完全相同的项目测试，但我无法重现该问题——EVB 继续正常运行，没有出现卡顿。 此时，您会建议采取哪些后续步骤来确定问题的根本原因并找到可能的解决方案？ 如果您需要我提供任何其他信息、测量数据或调试数据，请告诉我。 我附上了一个 ZIP 文件，其中包含完整的 EVB 项目以及我的定制板和 EVB 上的 K358 图片。 感谢您的支持。 BR 西蒙娜 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 由于该问题仅在您的定制板上出现，而未在 EVB 上出现，因此值得调查根本原因是否与硬件有关。 我建议您将您的硬件设计与 EVB 原理图进行比较，并查看 S32K3 硬件设计指南，以验证所有相关建议是否已正确实施。

S32K389 AES_ACCEL 在加密 64KB 数据时会挂起/冻结 您好，NXP团队： 我正在使用S32K389并测试AES_ACCEL (ACE/MSC)模块。我在处理大型数据缓冲区时遇到了稳定性问题。 测试设置： 模式： AES-密码块链接(CBC) 案例 1（通过）：加密4KB数据工作正常。 案例 2（失败）：加密64KB数据会导致芯片在执行 AES 服务时立即崩溃/挂起。 观察到的行为： S32DS（S32 设计工作室）在执行 AES 服务期间冻结。 尝试通过调试器连接到 S32K389 完全失败。 问题： 对于每个 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生成验证服务存在以下限制： 我还在确认加密方面是否存在限制。我稍后会通知你。 此致， 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。 此致， 显龙

A query regarding joining the nxp communities for nxp cup 2026 I am participating in NXP Cup in 2026. In that I have got a mail to be part of some communities and groups to be updated in real time and to be updated with the resources and all but I can't access those group links in the mail. That's the issue I am facing and I want the resolution for it. 

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. 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. 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: 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. Best Regards, xianlong

关于加入 NXP 2026 杯社区的咨询 我将参加 2026 年 NXP 杯。我收到一封邮件，邀请我加入一些社区和群组，以便实时获取最新信息和资源，但我无法访问邮件中的这些群组链接。这就是我面临的问题，我希望得到解决方案。

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

imx8mmini sai1 最大采样率 hi sai1连接编解码器支持 768kHz/32bit 采样率。SAI1 -RX0 连接 codec_DOUT。 没有 768kHz/32bit 和 L/R 通道的数据可供读取。但SAI1-TXFS/SAI1-TXC 可以输出 768kHz/49.152MHz 的数据。读取 768kHz/16bit 和 384kHz/32bit 的 L/R 通道数据正常。内核版本 6.1.36。 谢谢。 Re: imx8mmini sai1 max sample rates 关于编解码器 DTS 的信息如下： 运行 arecord 命令，参数为“-f S32_LE -r 384000 -c 2 -d 1 test.wav”或者“-f S16_LE -r 786000 -c 2 -d 1 test.wav”也可以。但是运行“-f S32_LE -r 768000 -c 2 -d 1 test.wav”，test.wav 为 NULL。 Re: imx8mmini sai1 max sample rates 你好， 请问您能否分享一下您的设备树配置？ 你使用的是哪种编解码器？ 顺祝商祺！ Re: imx8mmini sai1 max sample rates 你好， 如果出现与采样率相关的错误，可能是由于时钟源无法产生该采样率所需的频率造成的。 有时需要使用专用时钟源（例如外部时钟）来获得特定的采样率。 顺祝商祺！ Re: imx8mmini sai1 max sample rates 当使用 768kHz 32bit x 2 通道读取时，SAI1_TXFS/SAI1_TXC 输出正常（768kHz/49.152MHz）。用示波器检查时，编解码器数据输出引脚（连接到 SAI1_RX0）有数据输出。imx8mmini sdma 是否有可能不工作？ Re: imx8mmini sai1 max sample rates 你好， 测试过程中是否出现下溢或溢出错误？ 顺祝商祺！ Re: imx8mmini sai1 max sample rates 测试过程中出现如下内核打印错误： [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: 捕获写入错误（DMA 或 IRQ 问题？）

ELEはホストがアクセスできない非揮発性ストレージに鍵を保持できますか? こんにちは、 EdgeLock セキュア・エンクレーブ(ELE)での永続キー保存についてお尋ねしたいです。 私の理解によると、ELEが暗号操作に使用する鍵は、キーストレージサービスを使って永続的に保存できます。私が理解している典型的な流れは以下のとおりです。 1. 対象キーのキーブロブを作成し、ホストにエクスポートします。 2. エクスポートしたキーブロブをフラッシュメモリなどの不揮発性メモリに保存します。 3. 暗号化操作に鍵が必要な場合は、キーブロブをインポートし、ELE を介して鍵を使用します。 この方法では、キーブロブはELEによって生成されるため、ホストは実際のキー素材を読み取ることができません。しかし、Flashではキーブロブ自体がホストに保存されているため、ホストはキーブロブを削除したり上書きしたりできるようです。 私の質問は次のとおりです。 ELEからはアクセス可能だがホストからはアクセスできない不揮発性ストレージ領域に鍵（またはそのキーブロブ）を保存する方法はありますか？これにより、鍵マテリアルやキーブロブがホストに一切公開されることなく、ELEが暗号化操作を実行できるようになります。 言い換えれば、ELEが永続的なキーストレージを完全にセキュアな領域内で所有および管理し、ホストがキーやキーブロブを直接扱うことがないようにすることは可能でしょうか？ ご指導をよろしくお願いいたします。

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を参照してください。 -----------------------------------------------------------------------------

FS26 RESET 问题 大家好， 我们在SBC部分遇到了RESET问题。 在初步测试期间，我只组装了 NXP Semiconductors MFS2633HMDB2AD SBC 部分，并检查了 RESET 输出。RESET 线为高电平，集成电路工作正常。 组装好 MCU 和其他相关组件后，PMIC RESET 线始终为低电平，所有相关的 RESET 信号都被拉低。 连接 JTAG 调试器后，复位线变为高电平，系统成功进入调试模式。 补充说明： 使用 0Ω 电阻移除 MCU RESET 线。 MCU RESET line is HIGH. PMIC RESET 线保持低电平。 FS26 在调试模式下运行正常。 如果没有 JTAG 连接，PMIC RESET 输出将保持低电平。 这个问题似乎只在MCU集成后才会出现。单独测试时，SBC 部分工作正常，但连接 MCU 后，PMIC RESET 序列无法释放。 谢谢。

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

imx8mmini sai1 最大サンプルレート hi SAI1 Connectのコーデックはサンプルレート768kHz/32bitに対応しています。 SAI1-RX0 codec_DOUT接続。 768kHz/32bitおよびL/Rチャネルで読み取れるデータはありませんが、SAI1-TXFS/SAI1-TXCは768kHz/49.152Mhzを出力可能です。768khz/16bitおよび384khz/32bitのL/Rチャネル読み取りは問題ありません。カーネルバージョン6.1.36です。 ありがとうございます。 Re: imx8mmini sai1 max sample rates コーデックdtsについては以下の通りです。 「-f S32_LE -r 384000 -c 2 -d 1 test.wav」を指定して arecord コマンドを実行します。または「-f S16_LE -r 786000 -c 2 -d 1 test.wav」でも問題ありません。しかし、「-f S32_LE -r 768000 -c 2 -d 1 test.wav」で実行すると、test.wav は NULL になります。 Re: imx8mmini sai1 max sample rates こんにちは、 デバイスツリーの設定を教えていただけますか? どのコーデックを使用していますか？ よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、 サンプルレートに関連するエラーが出る場合、クロックソースがそのサンプルレートに必要な周波数を生成できないため、原因かもしれません。 特定のサンプリングレートを得るためには、外部クロックなどの専用のクロックソースを使用する必要がある場合があります。 よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、 テスト中にアンダーフローエラーやオーバーフローエラーが発生しますか？ よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates 768kHzの32ビット×2チャンネルで読み取ると、SAI1_TXFS/SAI1_TXC出力は正常(768kHz/49.152MHz)です。コーデックのデータ出力ピン（SAI1_RX0に接続）は、オシロスコープで確認するとデータ出力があります。imx8mminiのSDMAが動作していない可能性はありますか？ Re: imx8mmini sai1 max sample rates テスト中に以下のようなカーネル出力エラーが発生しました。 [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: キャプチャ書き込みエラー (DMA または IRQ の問題?)

TJA1120A 1000BASE-T1 Linux 端配置 我们的ECU板基于am72a7，采用TJA1120A PHY和DP83TG721EVM-MC媒体转换器。 目前链接已开启 root@am62axx-evm:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 0.944429] optee: probing for conduit method. [ 1.352845] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.365779] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.452604] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.459737] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32 [ 1.467615] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.488042] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 5.875382] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 5.890378] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.618291] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL) [ 6.629693] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode [ 6.662963] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 38.194116] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down [ 116.023614] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off 我将 TJA1120 的 eth0 设置为从模式，并通过硬件跳线将主设备配置为媒体变流器。 root@am62axx-evm:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 1000baseT1/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1000baseT1/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: off master-slave cfg: forced slave master-slave status: slave Port: Twisted Pair PHYAD: 4 Transceiver: external MDI-X: Unknown Supports Wake-on: d Wake-on: d Current message level: 0x000020f7 (8439) drv probe link ifdown ifup rx_err tx_err hw Link detected: yes SQI: 7/7 root@am62axx-evm:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 64:1C:10:1C:06:E2 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::661c:10ff:fe1c:6e2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:118 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:24044 (23.4 KiB) 现在我已经将我的ECU设置为192.168.1.100我的电脑（连接到媒体变流器）连接到 192.168.1.101 ping 命令没有生效，但是当我用电脑 ping ECU 时，ECU 上的 LED 指示灯会闪烁。 acs@a-tract-10:~$ ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable From 192.168.1.101 icmp_seq=2 Destination Host Unreachable From 192.168.1.101 icmp_seq=3 Destination Host Unreachable From 192.168.1.101 icmp_seq=4 Destination Host Unreachable From 192.168.1.101 icmp_seq=5 Destination Host Unreachable From 192.168.1.101 icmp_seq=6 Destination Host Unreachable ^C --- 192.168.1.100 ping statistics --- 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7185ms pipe 4 自动以太网是否需要进行任何额外配置？ Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 根据新的日志，1000BASE-T1 端似乎工作正常。检测到 TJA1120 PHY，链路速度为 1 Gbit/s，主/从状态正确，SQI 报告为 7/7。 然而，以太网接口统计信息仍然显示 RX 数据包为零，而 TX 数据包却在增加。这表明接收到的帧没有到达 Linux MAC/网络协议栈。 请重新检查 Linux 设备树中的 RGMII 时序配置。日志显示接口配置为“phy/rgmii”。如果您的电路板设计要求 PHY 提供内部 RGMII 延迟，则设备树通常应使用“rgmii-id”而不是普通的“rgmii”实例。RGMII 延迟配置不匹配会导致出现以下情况：PHY 链路已建立且 SQI 良好，但 Linux 无法成功接收数据包。 您能否在电脑端使用 Wireshark 检查一下，看看是否能看到 ECU 发送的任何帧？例如，在 ECU 上启动 eth0 后，请检查 PC 上是否捕获到来自 ECU MAC 地址的 ARP、IPv6 邻居发现或任何其他以太网帧。 同时，请在 ECU 端运行 tcpdump，并从 PC 端进行 ping 操作： tcpdump -ni eth0 -e arp 或 icmp 如果没有捕获到 ARP/ICMP 数据包，并且 RX 计数器保持为零，则问题很可能仍然出在 MAC 到 PHY 的 RGMII 路径或其设备树定时配置中，而不是出在 1000BASE-T1 链路本身中。 顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration Pavel，正如你所说，我已将 CONFIG3,4 引脚连接到 RGMII-ID（根据 TJA1120A 数据手册 6.7.2，我尝试了 RGMII-ID 和 RGMII-ID (TX/RX)）。同时将 phy-mode 设置为“rgmii-id”。 &cpsw_port1 { status = "okay"; phy-mode = "rgmii-id"; phy-handle = <&cpsw3g_phy0>; }; 这反映在 dmesg 中 [ 6.817790] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-id link mode 但是 ping 命令仍然不起作用。 acs@a-tract-10:~$ ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable From 192.168.1.101 icmp_seq=2 Destination Host Unreachable From 192.168.1.101 icmp_seq=3 Destination Host Unreachable From 192.168.1.101 icmp_seq=4 Destination Host Unreachable From 192.168.1.101 icmp_seq=5 Destination Host Unreachable From 192.168.1.101 icmp_seq=6 Destination Host Unreachable From 192.168.1.101 icmp_seq=7 Destination Host Unreachable From 192.168.1.101 icmp_seq=8 Destination Host Unreachable From 192.168.1.101 icmp_seq=9 Destination Host Unreachable From 192.168.1.101 icmp_seq=10 Destination Host Unreachable From 192.168.1.101 icmp_seq=11 Destination Host Unreachable From 192.168.1.101 icmp_seq=12 Destination Host Unreachable From 192.168.1.101 icmp_seq=13 Destination Host Unreachable From 192.168.1.101 icmp_seq=17 Destination Host Unreachable From 192.168.1.101 icmp_seq=18 Destination Host Unreachable From 192.168.1.101 icmp_seq=19 Destination Host Unreachable From 192.168.1.101 icmp_seq=20 Destination Host Unreachable From 192.168.1.101 icmp_seq=21 Destination Host Unreachable From 192.168.1.101 icmp_seq=22 Destination Host Unreachable From 192.168.1.101 icmp_seq=23 Destination Host Unreachable From 192.168.1.101 icmp_seq=24 Destination Host Unreachable ^C --- 192.168.1.100 ping statistics --- 25 packets transmitted, 0 received, +21 errors, 100% packet loss, time 24598ms pipe 4 但我按照您说的，尝试在电脑上进行ping测试的同时监测ECU端。 root@am62axx-evm:~# tcpdump -ni eth0 -e arp or icmp [ 36.233694] am65-cpsw-nuss 8000000.ethernet eth0: entered promiscuous mode [ 36.240729] kauditd_printk_skb: 5 callbacks suppressed [ 36.240737] audit: type=1700 audit(1748612373.780:19): dev=eth0 prom=256 old_ prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 36.257330] audit: type=1300 audit(1748612373.780:19): arch=c00000b7 syscall= 208 success=yes exit=0 a0=4 a1=107 a2=1 a3=fffffb4ab040 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty S2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 36.285128] audit: type=1327 audit(1748612373.780:19): proctitle=74637064756D 70002D6E690065746830002D6500617270006F720069636D70 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:39:47.956062 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:47.956161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:49.001519 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:49.001576 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:50.025527 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:50.025574 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:51.049972 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:51.050015 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:52.073514 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:52.073561 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:53.097481 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:53.097522 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:54.121912 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:54.121951 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:55.145488 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:55.145526 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:56.169569 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:56.169613 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:57.193883 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:57.193925 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:58.217586 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:58.217629 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:39:59.241465 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:39:59.241500 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:00.265877 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:00.265913 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:01.289403 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:01.289468 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:02.313582 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:02.313638 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:03.337456 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:03.337503 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:04.361696 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:04.361800 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:05.385632 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:05.385679 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:06.409875 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:06.409933 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:07.433415 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:07.433464 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:08.457402 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:08.457451 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:09.482122 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:09.482161 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:10.505290 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:10.505346 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:11.529470 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:11.529514 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:12.554164 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:12.554205 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:13.577538 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:13.577575 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:14.601223 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:14.601263 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:15.625718 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:15.625758 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:16.649218 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:16.649272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:17.673325 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:17.673371 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:18.698021 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:18.698065 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:19.721618 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:19.721706 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:20.745228 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:20.745272 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:21.770216 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:21.770260 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:22.793695 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:22.793738 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 13:40:23.817397 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 13:40:23.817436 64:1c:10:1c:06:e2 > 4c:cf:7c:bf:f6:a1, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 ^C 72 packets captured 72 packets received by filter 0 packets dr[ 88.275081] am65-cpsw-nuss 8000000.ethernet eth0: left promiscuous mode opped by kernel [ 88.287106] audit: type=1700 audit(1748612425.824:20): dev=eth0 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 88.340396] audit: type=1300 audit(1748612425.824:20): arch=c00000b7 syscall=57 success=yes exit=0 a0=4 a1=1 a2=2 a3=1d22f010 items=0 ppid=701 pid=713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 88.367618] audit: type=1327 audit(1748612425.824:20): proctitle=74637064756D70002D6E690065746830002D6500617270006F720069636D70 4c:cf:7c:bf:f6:a1 是我电脑以太网端口的 MAC 地址。 这些消息在电脑端显示“目标主机不可达”后约 2 秒开始出现。 Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 谢谢你的更新。这项新成果非常有用。 我们现在可以假设 RGMII-ID 有效。 一个重要的观察结果是，来自 PC 的 ARP 请求是 VLAN 0 优先级标记帧： 以太网类型 802.1Q，VLAN 0，以太网类型 ARP 而 ECU ARP 回复是未标记的 ARP 帧。请检查 PC 接口、桥接、VLAN、QoS 或驱动程序/卸载配置是否需要带标签的流量，或者未带标签的 ARP 回复是否被过滤或未与 ARP 请求关联。 注意：以下 Linux 命令仅供参考，可能需要根据您的具体 Linux 发行版、网络接口名称和系统配置进行调整。 请捕获PC端的流量： sudo tcpdump -eni -vvv '(arp or icmp or vlan)' 然后再次开始 ping 命令。 如果 PC 捕获未显示来自 ECU MAC 地址 `64:1c:10:1c:06:e2` 的 ARP 回复，则问题仍然出在 ECU 到 PC 的传输路径或媒体转换器路径中。   如果 PC 捕获显示 ARP 回复，但 PC 仍然报告“目标主机不可达”，则问题很可能出在 PC 端的 Linux 网络/VLAN/过滤配置中。   作为额外的隔离测试，请尝试在电脑上添加静态 ARP 条目：   sudo ip neigh replace 192.168.1.100lladdr 64:1c:10:1c:06:e2 dev nud permanent   然后重复 ping 命令，同时捕获两端的流量。 顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 所以问题似乎出在ECU到PC的传输方向上： ECU MAC TX 路径， RGMII TX MAC 和 TJA1120A 之间的时序/延迟配置， TJA1120 传输路径， 媒体变流器接收路径， 或者可能是 RGMII 接口上的信号完整性/板级时序问题。 CONFIG 引脚连接定义了 RESET 后的默认配置，但当 NXP TJA11xx Linux 驱动程序处于活动状态时，PHY 可以通过 MDIO 根据 Linux 设备树重新配置。所以，用销钉捆扎实际上没有任何效果。 1.如果只有一个方向受到影响，则测试适用的方向性 RGMII 延迟变体可能很有用，例如： phy-mode = "rgmii-id"; /* RX 和 TX 内部延迟 */ phy-mode = "rgmii-rxid"; /* 仅接收内部延迟 */ phy-mode = "rgmii-txid"; /* 仅发送内部延迟 */ phy-mode = "rgmii"; /* 无 PHY 内部延迟 */ 另外，请确保所选的 Linux phy 模式与您的硬件设计中预期的 MAC/PHY 延迟所有权相匹配。   2. 同时，我还建议从 ECU 向 PC 发送流量，并检查 RGMII TX 引脚上是否有活动。例如，您可以运行： ping *I eth0 192.168.1.101   并用示波器监测 MAC 和 TJA1120A 之间的 RGMII TX 信号，特别是 TXC、 TX_CTL、 TXD[3:0]。 如果 Linux 尝试发送数据时这些引脚上没有任何活动，则问题可能仍然出在 PHY 之前的 MAC/驱动程序/配置路径中。如果 RGMII TX 引脚上有活动，但在 PC 端未观察到有效帧，则应重点关注 RGMII TX 时序、延迟配置、信号质量或媒体转换器接收路径。   3.请重复静态 ARP 测试，同时强制 PC 使用预期接口： sudo ip neigh replace *92.168.1.100lladdr 64:1c:10:1c:06*e2 dev eno1 nud permanent ip 邻居*显示 192.168.1.100开发 eno1 ip rou*e 获取 192.168.1.100 sudo tcpdump -*ni eno1 -vvv '（arp 或 icmp）' ping *I eno1 192.168.1.100 注意：以上 Linux 命令仅供参考，可能需要根据您的具体 Linux 发行版、网络接口名称和系统配置进行调整。 如果静态 ARP 条目有效，PC 就不再需要发送 ARP 请求。它应该直接向ECU MAC地址发送ICMP回显请求帧。这些帧至少应该在 PC 端的 tcpdump 中可见。如果即使 PC 端的 tcpdump 也未显示出站 ICMP 帧，请检查 PC 的路由、邻居表和接口选择。 如果在 PC 端可以看到传出的 ICMP 帧，但在 ECU 端看不到，则说明 PC 到 ECU 方向的单播流量仍然无法完全正常工作。如果 ECU 接收到 ICMP 帧并生成回复，但 PC 没有接收到回复，则问题仍然存在于 ECU 到 PC 的传输方向上。   顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration 当然，帕维尔，我也尝试在电脑端监测流量。 acs@a-tract-10:~$ sudo tcpdump -eni eno1 -vvv '(arp or icmp or vlan)' tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 20:53:50.356677 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:51.372439 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:52.396579 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:53.420576 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:54.444417 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:55.468262 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:56.492603 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:57.516072 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:58.540535 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:53:59.564468 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:54:00.588407 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 20:54:01.612074 4c:cf:7c:bf:f6:a1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 28 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel 在 PC 端的 tcpdump 中，没有收到来自 64:1c:10:1c:06:e2 的响应。 添加静态 ARP 条目后，ECU 和 PC 端的 tcpdump 均未捕获到任何消息。 似乎是ECU PHY没有响应。 Re: TJA1120A 1000BASET1 Linux side configuration 你好@vikyhre ， 谢谢你的更新。这是个好消息。很高兴它现在对你有用。 我从你的日志中没有发现任何可疑之处——没有发现任何明显的缺失。作为最后的健全性检查，您还可以反向运行 iperf3 测试。 关于您提到的 `rgmii-txid`：这是一个 Linux 通用设备树 `phy-mode` 值。它不一定需要在 TJA1120A 数据手册中使用完全相同的 Linux 命名。TJA1120A支持 RGMII TXC 和 RXC 时钟路径中的独立延迟配置——请参考寄存器 RGMII_TXC_DELAY_CONFIG 和 RGMII_RXC_DELAY_CONFIG。此外，引脚绑定本身仅支持有限的配置。   如果我之前的回复帮助您解决了问题，请将其标记为解决方案，以便其他用户更容易参考。 顺祝商祺！ 帕维尔 Re: TJA1120A 1000BASET1 Linux side configuration 感谢你的见解，帕维尔。 我们让它运行起来了 我担心的是，TJA1120A 数据手册中没有提到“rgmii-txid”，它只是将延迟时间缩短到 TX_CLK。但是“rgmii-txid”对我们仍然有效。请澄清一下。我已将 DT 中的值更改为“rgmii-txid”，因为您提到 DT 可以覆盖 CONFIG_PIN 绑定。供您参考，PIN 绑定目前为 RGMII-ID（根据数据手册，仅在 RX 上延迟）。 我用 Windows 电脑 ping ECU 时，这是 ECU 端的 TCP 转储。 root@am62axx-evm:~# tcpdump -eni eth0 -vvv '(arp or icmp or vlan)' [ 215.833728] am65-cpsw-nuss 8000000.ethernet eth0: entered promiscuous mode [ 215.840752] kauditd_printk_skb: 5 callbacks suppressed [ 215.840759] audit: type=1700 audit(1748634353.108:19): dev=eth0 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 215.857358] audit: type=1300 audit(1748634353.108:19): arch=c00000b7 syscall=208 success=yes exit=0 a0=4 a1=107 a2=1 a3=ffffde476290 items=0 ppid=702 pid=718 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 215.885142] audit: type=1327 audit(1748634353.108:19): proctitle=74637064756D70002D656E690065746830002D7676760028617270206F722069636D70206F7220766C616E29 tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 19:45:55.112784 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10277, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:45:56.000964 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.100 tell 192.168.1.101, length 46 19:45:56.001026 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.100 is-at 64:1c:10:1c:06:e2, length 28 19:45:57.107220 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10278, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:45:59.106805 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10279, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:45:59.716185 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40251, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15523, length 40 19:45:59.716296 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 29682, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15523, length 40 19:45:59.754274 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10616, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:45:59.755177 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:45:59.755780 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10617, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:45:59.756348 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:46:00.177694 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10618, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:46:00.178362 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:46:00.179078 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10619, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:46:00.179855 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 101.1.168.192.in-addr.arpa. (44) 19:46:00.732239 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40252, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15524, length 40 19:46:00.732328 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 29831, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15524, length 40 19:46:01.109894 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10280, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:46:01.711155 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10281, offset 0, flags [none], proto UDP (17), length 36) 192.168.1.101.61820 > 192.168.1.255.1534: [udp sum ok] UDP, length 8 19:46:01.738880 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40253, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15525, length 40 19:46:01.738946 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 29920, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15525, length 40 19:46:02.750107 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40254, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15526, length 40 19:46:02.750195 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30149, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15526, length 40 19:46:03.111448 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10282, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:46:03.508387 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10283, offset 0, flags [none], proto UDP (17), length 36) 192.168.1.101.61822 > 192.168.1.255.1534: [udp sum ok] UDP, length 8 19:46:03.683562 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10284, offset 0, flags [none], proto UDP (17), length 36) 192.168.1.101.59781 > 192.168.1.255.1534: [udp sum ok] UDP, length 8 19:46:03.758158 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40255, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15527, length 40 19:46:03.758229 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30382, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15527, length 40 19:46:04.720461 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10620, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:04.721105 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:04.721816 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10621, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:04.722500 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:04.748806 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.101 tell 192.168.1.100, length 28 19:46:04.749036 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.101 is-at e8:cf:83:9e:c0:6e, length 46 19:46:04.768096 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40256, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15528, length 40 19:46:04.768169 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30526, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15528, length 40 19:46:05.113187 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10285, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:46:05.145241 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10622, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:05.146309 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:05.146984 e8:cf:83:9e:c0:6e > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 90: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 1, id 10623, offset 0, flags [none], proto UDP (17), length 72) 192.168.1.101.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:05.147546 e8:cf:83:9e:c0:6e > 33:33:00:00:00:fb, ethertype 802.1Q (0x8100), length 110: vlan 0, p 0, ethertype IPv6 (0x86dd), (flowlabel 0x47a43, hlim 1, next-header UDP (17) payload length: 52) fe80::f1f4:e759:58b0:69e5.5353 > ff02::fb.5353: [udp sum ok] 0 PTR (QM)? 1.230.168.192.in-addr.arpa. (44) 19:46:05.704832 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10286, offset 0, flags [none], proto UDP (17), length 36) 192.168.1.101.1534 > 192.168.1.255.1534: [udp sum ok] UDP, length 8 19:46:05.778897 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40257, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15529, length 40 19:46:05.778982 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30742, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15529, length 40 19:46:06.783379 e8:cf:83:9e:c0:6e > 64:1c:10:1c:06:e2, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 40258, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.101 > 192.168.1.100: ICMP echo request, id 1, seq 15530, length 40 19:46:06.783462 64:1c:10:1c:06:e2 > e8:cf:83:9e:c0:6e, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 30781, offset 0, flags [none], proto ICMP (1), length 60) 192.168.1.100 > 192.168.1.101: ICMP echo reply, id 1, seq 15530, length 40 19:46:07.102734 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10287, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 19:46:09.110867 e8:cf:83:9e:c0:6e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 0, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 128, id 10288, offset 0, flags [none], proto UDP (17), length 78) 192.168.1.101.56435 > 192.168.1.255.59200: [udp sum ok] UDP, length 50 ^C 48 packets captured 48 packets received by filter 0 packets dr[ 231.946244] am65-cpsw-nuss 8000000.ethernet eth0: left promiscuous mode opped by kernel [ 231.958251] audit: type=1700 audit(1748634369.220:20): dev=eth0 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 232.008325] audit: type=1300 audit(1748634369.220:20): arch=c00000b7 syscall=57 success=yes exit=0 a0=4 a1=1 a2=2 a3=2c26c010 items=0 ppid=702 pid=718 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="tcpdump" exe="/usr/bin/tcpdump" subj=kernel key=(null) [ 232.035539] audit: type=1327 audit(1748634369.220:20): proctitle=74637064756D70002D656E690065746830002D7676760028617270206F722069636D70206F7220766C616E29 一切正常，我们也做了iperf3测试。 root@am62axx-evm:~# iperf3 -c 192.168.1.101 Connecting to host 192.168.1.101, port 5201 [ 5] local 192.168.1.100 port 35040 connected to 192.168.1.101 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 0 266 KBytes [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 266 KBytes [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes [ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec 0 266 KBytes [ 5] 5.00-6.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes [ 5] 6.00-7.00 sec 112 MBytes 943 Mbits/sec 0 266 KBytes [ 5] 7.00-8.00 sec 112 MBytes 944 Mbits/sec 0 266 KBytes [ 5] 8.00-9.00 sec 112 MBytes 942 Mbits/sec 0 266 KBytes [ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec 0 266 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver iperf Done. 我们假设现在一切都已安排妥当，如有遗漏，请告知。如果您没有其他补充，我将把您的回复标记为解决方案。 谢谢！

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

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

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