S32K3 ADC 外部チャネルの利用 こんにちは。NXPチーム S32K3 ADCの外部チャネルの使い方 . Re: S32K3 ADC Use of external channels こんにちは、 @VaneBさん これに関して、追加の質問があります。 もし私のデザインにマルチマックスがなくても、例えばセンサ1にADC1_X[0]、センサ2にADC1_X[1]、そしてADC1_Xセンサ3にだけ使いたい場合は、MAピンをGPIO出力ピンなど他の用途で再利用してLEDを駆動することは可能でしょうか? 私のデザインはs32k344をベースにしています Re: S32K3 ADC Use of external channels NPXチームの皆様、こんにちは。 このトピックに関連して、以下の図のようなSCHを実装することが可能かどうか確認していただけますか? サポートありがとうございます。 Re: S32K3 ADC Use of external channels @VaneB ご協力いただき、誠にありがとうございました。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin 各ADCは外部アナログ多重化器の8チャネル中1チャネルを選択するために使う3つの外部デコード信号(MA)を提供し、最大4つのマルチプレクサを設置して32の外部チャネルを接続できます。つまり、これら4つのマルチプレクサは同じMA信号を共有します。 ADCは変換対象の現在のチャネルに基づき、これらの外部アナログ多重化器を制御するよう自動設定します。マスクレジスタのビットに応じて、対応する「X」ピンがサンプリングされ、その結果が「MA」と「X」の組み合わせに対応する場所に格納されます。 当社の開発ボードには外部アナログ多重化装置が設計されていないため、そのような例は実装されていません。 Re: S32K3 ADC Use of external channels こんにちは。ヴェインB あなたのプロンプトによると、RTDで外部チャネルADCを使った例が見つかりません。もし対応するルーティンがあれば、ぜひ送っていただけると嬉しいです。どうもありがとうございます。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin RTDで役立つかもしれないADCの実装例が見つかります。 BR VaneB

Unifiのようなソフトウェアではなく、OpenWrtを使ったことを後悔していますか？ 私の無知をお許しください。UnifiではなくOpenWrtを使ったことを後悔していますか？OpenWrtを使って、自宅の実験室用にルーターを設定しています。多くのことを学びつつありますが、時間がかかるので、Unifiのようなきれいな結果には絶対にならないでしょう。 OpenWrtで一番気に入っているのは、安価なデバイスでケーキを設定できて、1Gbpsのルーティングを代わりに行ってくれることです。また、自分のニーズに合わせてUnboundをカスタマイズできるのは素晴らしいです。 Re: Do you regret using OpenWrt instead of something like Unifi? こんにちは、 どのプロセッサを使っていますか? よろしくお願いします。

使用 SDK 的 CAN 通信 S32K144 DEMO 并进行修改，发送扩展帧 使用 SDK 的 CAN 通信 S32K144 DEMO 并进行修改后，发送扩展帧失败。我已经将 idType 更改为 CAN_MSG_ID_EXT，但 CAN 适配器仍然接收到标准帧。我发送的 ID 是 1FFFFFFF，但收到的 ID 是 7FF。如果专家能帮忙解决这个问题，我将不胜感激。   #include "Cpu.h" #include "delay.h" #include "uart.h" #include"key.h" #include"oled.h"   #include "stdint.h" #include "stdbool.h"   volatile int exit_code = 0;   #define LED1(x) PINS_DRV_WritePin(PTD,16,!x); #define LED2(x) PINS_DRV_WritePin(PTD,15,!x); #define LED3(x) PINS_DRV_WritePin(PTD,1,!x); #define LED4(x) PINS_DRV_WritePin(PTD,0,!x);   #define Rx_Filter 0x0 char IRQ_CAN0_RX; char IRQ_CAN1_RX; char IRQ_CAN2_RX; can_message_t recvMsg_CAN0; can_message_t recvMsg_CAN1; can_message_t recvMsg_CAN2; #define RX_MASK_ALL_EXT 0x1FFFFFFF #define RX_MAILBOX_CAN0 (0UL) #define TX_MAILBOX_CAN0 (1UL)   #define RX_MAILBOX_CAN1 (2UL) #define TX_MAILBOX_CAN1 (3UL)   #define RX_MAILBOX_CAN2 (4UL) #define TX_MAILBOX_CAN2 (5UL)       /*CAN0回调函数*/ void CAN0_Callback_Func (uint32_t instance,can_event_t event,uint32_t buffIdx,void *flexcanState)   { （无效）flexcan状态； //阻止此处诊断 (void)实例； (void)buffIdx; CAN_Receive(&can_pal0_instance, RX_MAILBOX_CAN0, &recvMsg_CAN0); //接收报文并重新注册回调函数 switch(event) //回调事件 { case CAN_EVENT_RX_COMPLETE: //接收完成事件 IRQ_CAN0_RX = 1; 休息; case CAN_EVENT_TX_COMPLETE: //发送完成事件 休息; 默认： 休息; }   }       void CAN1_Callback_Func (uint32_t instance,can_event_t event,uint32_t buffIdx,void *flexcanState)   { (void)flexcanState; (void)实例； (void)buffIdx; CAN_Receive(&can_pal1_instance, RX_MAILBOX_CAN1, &recvMsg_CAN1); 切换（事件） { case CAN_EVENT_RX_COMPLETE: IRQ_CAN1_RX = 1; 休息; case CAN_EVENT_TX_COMPLETE: 休息; 默认： 休息; }   }       void CAN2_Callback_Func (uint32_t instance,can_event_t event,uint32_t buffIdx,void *flexcanState)   { (void)flexcanState; (void)实例； (void)buffIdx; CAN_Receive(&can_pal2_instance, RX_MAILBOX_CAN2, &recvMsg_CAN2); 切换（事件） { case CAN_EVENT_RX_COMPLETE: IRQ_CAN2_RX = 1; 休息; case CAN_EVENT_TX_COMPLETE: 休息; 默认： 休息; }   }     void CAN0_Init(void) { CAN_Init(&can_pal0_instance, &can_pal0_Config0); can_buff_config_t Rx_buffCfg = { .enableFD= false， .启用BRS= false， .fdPadding= 0U, .id类型= CAN_MSG_ID_EXT， .isRemote假  };   can_buff_config_t Tx_buffCfg = { .enableFD= false， .启用BRS= false， .fdPadding= 0U, .id类型= CAN_MSG_ID_EXT， .isRemote假  }; CAN_ConfigRxBuff(&can_pal0_instance, RX_MAILBOX_CAN0, &Rx_buffCfg, Rx_Filter); //注册接收配置和MSGID过滤器(如过滤器配置为0x1，则只接受msgid 0x1发来的报文) CAN_ConfigTxBuff(&can_pal0_instance, TX_MAILBOX_CAN0, &Tx_buffCfg); //配置发送 /*设置MSGID的掩码，掩码粗略可以理解为对11bit MSGID地址的过滤 如果位需要过滤设置为1,不过滤设置为0,例如掩码设置为0x7ff则过滤全部标准id,如果设置为0x7fe,则只接受0x01的报文(不存在某0x0的地址)*/ CAN_SetRxFilter(&can_pal0_instance, CAN_MSG_ID_EXT, RX_MAILBOX_CAN0, 0x1FFFFFFFU);//设置MSGID掩码， CAN_InstallEventCallback(&can_pal0_instance,&CAN0_Callback_Func,(void*)0); //注册回调函数 CAN_Receive(&can_pal0_instance, RX_MAILBOX_CAN0, &recvMsg_CAN0); //*****重点****此函数不仅有接收作用还有续订回调函数的作用。 }       void CAN1_Init(void) { CAN_Init(&can_pal1_instance, &can_pal1_Config0); can_buff_config_t Rx_buffCfg = { .enableFD= false， .启用BRS= false， .fdPadding= 0U, .id类型= CAN_MSG_ID_EXT， .isRemote假  };   can_buff_config_t Tx_buffCfg = { .enableFD= false， .启用BRS= false， .fdPadding= 0U, .id类型= CAN_MSG_ID_EXT， .isRemote假  }; CAN_ConfigRxBuff(&can_pal1_instance, RX_MAILBOX_CAN1, &Rx_buffCfg, Rx_Filter); CAN_ConfigTxBuff(&can_pal1_instance, TX_MAILBOX_CAN1, &Tx_buffCfg); CAN_SetRxFilter(&can_pal1_instance,CAN_MSG_ID_EXT,RX_MAILBOX_CAN1,0x1FFFFFFFU); CAN_InstallEventCallback(&can_pal1_instance,&CAN1_Callback_Func,(void*)0); CAN_Receive(&can_pal1_instance, RX_MAILBOX_CAN1, &recvMsg_CAN1); }           void CAN2_Init(void) { CAN_Init(&can_pal2_instance, &can_pal2_Config0); can_buff_config_t Rx_buffCfg = { .enableFD= false， .启用BRS= false， .fdPadding= 0U, .id类型= CAN_MSG_ID_EXT， .isRemote假  };   can_buff_config_t Tx_buffCfg = { .enableFD= false， .启用BRS= false， .fdPadding= 0U, .id类型= CAN_MSG_ID_EXT， .isRemote假  }; CAN_ConfigRxBuff(&can_pal2_instance, RX_MAILBOX_CAN2, &Rx_buffCfg, Rx_Filter); CAN_ConfigTxBuff(&can_pal2_instance, TX_MAILBOX_CAN2, &Tx_buffCfg); CAN_SetRxFilter(&can_pal2_instance,CAN_MSG_ID_EXT,RX_MAILBOX_CAN2,0x1FFFFFFFU); CAN_InstallEventCallback(&can_pal2_instance,&CAN2_Callback_Func,(void*)0); CAN_Receive(&can_pal2_instance, RX_MAILBOX_CAN2, &recvMsg_CAN2); }       int main(void) { /* 在这里编写局部变量定义 */ uint8_t pinstate; int MCU_Freq; uint8_t CANRXDATA_STR1[17]; uint8_t CANRXDATA_STR2[17]; /*** 处理器专家内部初始化。请勿删除此代码！！！***/ #ifdef PEX_RTOS_INIT PEX_RTOS_INIT(); /* 初始化所选的 RTOS。宏由 RTOS 元器件定义。*/ #endif /*** 处理器专家内部初始化结束。***/   CLOCK_SYS_Init(g_clockManConfigsArr, CLOCK_MANAGER_CONFIG_CNT,g_clockManCallbacksArr, CLOCK_MANAGER_CALLBACK_CNT); CLOCK_SYS_UpdateConfiguration(0U, CLOCK_MANAGER_POLICY_AGREEMENT); MCU_Freq = delay_init();//初始化延迟函数 PINS_DRV_Init(NUM_OF_CONFIGURED_PINS, g_pin_mux_InitConfigArr); //初始化IO I2C_MasterInit(&i2c1_instance, &i2c1_MasterConfig0);//初始化I2C外设,用于OLED通讯 LPUART_DRV_Init(INST_LPUART1, &lpuart1_State, &lpuart1_InitConfig0); //初始化构造   CAN0_Init(); CAN1_Init(); CAN2_Init();   oled_init(); //OLED配置参数初始化 OLED_TITLE((uint8_t*)"S32K144",(uint8_t*)"CAN");//OLED显示标题 u1_printf("初始化完成,MCU运行频率为%d Mhz \r\n",MCU_Freq);     while(1)     { /* 按键处理 */ pinstate = KEY_Proc (0); /*if(pinstate ==BTN1_PRES ) { can_message_t Tx_msg = { .cs = 0U， .id = 0x01， .data[0] = 0x0, .data[1] = 0x1, .data[2] = 0x2, .data[3] = 0x3, .data[4] = 0x4, .data[5] = 0x5, .data[6] = 0x6, .data[7] = 0x7, 长度 = 8 }; CAN_Send(&can_pal0_instance, TX_MAILBOX_CAN0, &Tx_msg); u1_printf("CAN0发送报文\r\n");   } 否则如果(pinstate ==BTN2_PRES) { can_message_t Tx_msg = { .cs = 0U， .id = 0x02， .data[0] = 0x20, .data[1] = 0x21, .data[2] = 0x22, .data[3] = 0x23, .data[4] = 0x24, .data[5] = 0x25, .data[6] = 0x26, .data[7] = 0x27, 长度 = 8 }; CAN_Send(&can_pal1_instance, TX_MAILBOX_CAN1, &Tx_msg); u1_printf("CAN1发送报文\r\n"); } 否则如果(pinstate ==BTN3_PRES) { can_message_t Tx_msg = { .cs = 0U， .id = 0x03， .data[0] = 0x30, .data[1] = 0x31, .data[2] = 0x32, .data[3] = 0x33, .data[4] = 0x34, .data[5] = 0x35, .data[6] = 0x36, .data[7] = 0x37, 长度 = 8 }; CAN_Send(&can_pal2_instance, TX_MAILBOX_CAN2, &Tx_msg); u1_printf("CAN2发送报文\r\n"); }*/ u1_printf("123456\r\n"); /* can_message_t Tx_msg = { .cs = 0U， .id = 0x03， .data[0] = 0x30, .data[1] = 0x31, .data[2] = 0x32, .data[3] = 0x33, .data[4] = 0x34, .data[5] = 0x35, .data[6] = 0x36, .data[7] = 0x37, 长度 = 8 }; CAN_Send(&can_pal1_instance, TX_MAILBOX_CAN1, &Tx_msg);*/ // 发送标准帧（用于对照） delay_ms(100); can_message_t std_msg0 = { .cs = 0U， .id = 0x1FFFF111U， .data[0] = 0x30, .data[1] = 0x31, .data[2] = 0x32, .data[3] = 0x33, .data[4] = 0x34, .data[5] = 0x35, .data[6] = 0x36, .data[7] = 0x37, 长度 = 8 }; status_t ret = CAN_Send(&can_pal2_instance, TX_MAILBOX_CAN2, &std_msg0); 如果(返回值 != 状态成功) { u1_printf("CAN2 发送 std_msg0 失败，返回值：%d\r\n",ret); } delay_ms(100);   can_message_t Tx_msg0 = { .cs = 0U， .id = 0x1FFFFFFFU， .data[0] = 0x30, .data[1] = 0x31, .data[2] = 0x32, .data[3] = 0x33, .data[4] = 0x34, .data[5] = 0x35, .data[6] = 0x36, .data[7] = 0x37, 长度 = 8 }; CAN_Send(&can_pal2_instance, TX_MAILBOX_CAN2, &Tx_msg0); delay_ms(100); 如果 (IRQ_CAN0_RX ==1) { int i; u1_printf("CAN0 接收 ID:0x%x \r\n",recvMsg_CAN0.id); for(i=0; i { u1_printf("数据 %d : %x\r\n",i,recvMsg_CAN0.data[i]); if(i==recvMsg_CAN0.length-1) u1_printf("***************\r\n"); } IRQ_CAN0_RX=0; }   如果 (IRQ_CAN1_RX ==1) { int i; u1_printf("CAN1 接收 ID:0x%x \r\n",recvMsg_CAN1.id); for(i=0; i { u1_printf("数据 %d : %x\r\n",i,recvMsg_CAN1.data[i]); if(i==recvMsg_CAN1.length-1) u1_printf("***************\r\n"); } IRQ_CAN1_RX=0; }   如果 (IRQ_CAN2_RX ==1) { int i; u1_printf("CAN2 接收 ID:0x%x \r\n",recvMsg_CAN2.id); for(i=0; i { u1_printf("数据 %d : %x\r\n",i,recvMsg_CAN2.data[i]); if(i==recvMsg_CAN2.length-1) u1_printf("***************\r\n"); } IRQ_CAN2_RX=0; } /*OLED显示*/ sprintf((char*)CANRXDATA_STR1,"CAN0 %02X %02X %02X %02X", recvMsg_CAN2.data[0],recvMsg_CAN2.data[1],recvMsg_CAN2.data[2],recvMsg_CAN2.data[3]); // 格式点：删除(uint8_t)强转，格式符改为%08X sprintf((char*)CANRXDATA_STR2,"ID:%08X %02X %02X %02X %02X", recvMsg_CAN2.id,recvMsg_CAN2.data[4],recvMsg_CAN2.data[5],recvMsg_CAN2.data[6],recvMsg_CAN2.data[7]); OLED_ShowString(0,2,CANRXDATA_STR1,8,0); OLED_ShowString(0,3,CANRXDATA_STR2,8,0);   /*sprintf((char*)CANRXDATA_STR1,"CAN1 %02X %02X %02X %02X",recvMsg_CAN1.data[0],recvMsg_CAN1.data[1],recvMsg_CAN1.data[2],recvMsg_CAN1.data[3]); sprintf((char*)CANRXDATA_STR2,"ID%02X %02X %02X %02X %02X",(uint8_t)recvMsg_CAN1.id,recvMsg_CAN1.data[4],recvMsg_CAN1.data[5],recvMsg_CAN1.data[6],recvMsg_CAN1.data[7]); OLED_ShowString(0,4,CANRXDATA_STR1,8,0); OLED_ShowString(0,5,CANRXDATA_STR2,8,0);   sprintf((char*)CANRXDATA_STR1,"CAN2 %02X %02X %02X %02X",recvMsg_CAN2.data[0],recvMsg_CAN2.data[1],recvMsg_CAN2.data[2],recvMsg_CAN2.data[3]); sprintf((char*)CANRXDATA_STR2,"ID%02X %02X %02X %02X %02X",(uint8_t)recvMsg_CAN2.id,recvMsg_CAN2.data[4],recvMsg_CAN2.data[5],recvMsg_CAN2.data[6],recvMsg_CAN2.data[7]); OLED_ShowString(0,6,CANRXDATA_STR1,8,0); OLED_ShowString(0,7,CANRXDATA_STR2,8,0);*/ /*OLED显示*/   PINS_DRV_TogglePins(PTD, 1 << 0); PINS_DRV_TogglePins(PTD, 1 << 1); PINS_DRV_TogglePins(PTD, 1 << 15); PINS_DRV_TogglePins(PTD, 1 << 16); delay_ms(100);    } /*** 请勿在此行之后编写任何代码，否则将在代码生成过程中删除。***/ /*** RTOS 启动代码。宏 PEX_RTOS_START 由 RTOS 元器件定义。请勿修改此代码！！！***/ #ifdef PEX_RTOS_START PEX_RTOS_START(); /* 启动所选的 RTOS。宏由 RTOS 元器件定义。*/ #endif /*** RTOS 启动代码结束。***/ /*** 处理器专家主程序结束。请勿修改此代码！！！***/ 为了（;;） { 如果(退出代码 != 0) { 休息;    }   } 返回退出代码； /*** 处理器专家主程序结束。请勿在下方编写代码！！！***/ } /*** 主程序结束。请勿修改此文本！！！***/   /* 主程序结束 */ /*! ** @} */ /* ** ################################################################### ** **此文件由 Processor Expert 10.1 [05.21] 创建 **适用于NXP S32K系列微控制器。 ** ** ################################################################### */ Re: Using the SDK's CAN communication S32K144 DEMO and making modifications, the sending of extended HI 在调用CAN_Send之前，请先调用CAN_ConfigTxBuff 。 请参阅“无法接收带有扩展 ID 的 CAN 帧”中的讨论 由于我不确定您使用的是哪个 SDK 版本，我建议您检查SRR位是否设置为 1。详情请参考：当 FlexCAN Tx 发送扩展 ID 时，是否应设置 SRR 位？ 此致， 罗宾 ------------------------------------------------------------------------------- 笔记： - 如果此帖解答了您的问题，请点击“接受为解决方案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

i.MX93 RTC XTALI デューティサイクル こんにちは、 i.MX93のRTC_XTALI入力を駆動するために、PCA9451Aの内蔵32kHz RC発振器を使用する予定です。この出力の周波数は、精度も安定性も高くないことを認識していますが、i.MX93内部で正確な時間基準として使用する意図はありません。 私たちが懸念しているのは、i.MX93のデューティサイクル仕様に関するものです。入力クロックは45%～55%の許容範囲内のデューティサイクルを必要とするが、PCA9451Aは30%～70%というより広い範囲を規定している。 このような条件下でこのクロックソースを使用することに、機能的なリスクはありますでしょうか？ よろしくお願いいたします。 ラファエロ FRDM-i.MX93 i.MX93 Re: i.MX93 RTC XTALI Duty Cycle はい、機能的なリスクはありますが、信号品質が良好であれば、実際には通常そのリスクは低いと言えます。リスクは主に、定常状態の動作よりも、入力バッファの動作とRTCの信頼性（特に起動時と低電力モード）に関連しています。 実際のリスク分析 ケース1 — 通常のデジタル時計表示（おそらく問題なし） もし： 信号はCMOSレベルでクリーン（高速なエッジ、歪みなし） 周波数：約32kHz（非常に低い） 内部的にXTALモードは有効になっていません それから： RTCロジックは主にエッジでトリガーされます 広いデューティサイクル（30～70%）でも、十分なハイ/ローパルス幅（約9～21µs）が得られる。 結論： ほとんどのシリコンでは機能障害は想定されない ―低リスク   ケース2 ― 境界線上の状況または最悪の状況（リスクが存在する） リスクが増加するのは次のような場合です。 （A）入力バッファ閾値＋非対称性相互作用 デューティサイクルが偏っている場合（例：30/70 + 遅いエッジ） VIH/VIL領域付近では、1つのフェーズが限界的になる。 → 原因となる可能性があります: ダブルトリガー 欠落したエッジ 内部準安定性（まれだが可能性あり） （B）超低消費電力／SNVS／RTCドメイン RTCドメインは超低消費電力クロックコンディショニングを使用する可能性がある 内部フィルタリングまたはストレッチロジックは、ほぼ50%のデューティ比を占める可能性がある。 → リスク: クロックの除去または歪み 不安定なRTC増加 （C）XTALモードが誤って使用された場合 ピンが水晶発振子を想定して構成されている場合： → 30～70%の波形は以下のいずれかになります。 内部ピアース発振器のバイアスを乱す 起動または振動を防止する これは実際の故障モードです   CASE 3 — 仕様準拠／生産ばらつき これは最も重要な実務上のリスクです。 i.MX93のデータシートでは、45～55%を明示的に要求しています。 PCA9451Aは30～70％を保証します したがって： 保証仕様の範囲外で動作しています PVT（プロセス／電圧／温度）全体にわたって動作が正式に保証されるわけではありません。 定量的な妥当性チェック 32kHzの場合： 周期 = 31.25 µs デューティサイクルの極値： ケース そろそろ 低時間 50% 15.6 µs 15.6 µs 30% 9.4 µs 21.9 µs 70% 21.9 µs 9.4 µs 最悪の場合： パルス幅は依然として非常に長い（>>内部セットアップ時間） これが、実際にうまくいく理由です 実践的な推奨事項 以下の場合は許容されます： RTCは正確なタイミングには使用されません システムは正確な起動タイミングに依存しない あなたは、保証されない行動を受け入れることになります。 Re: i.MX93 RTC XTALI Duty Cycle こんにちは、ご返信ありがとうございます。 あなたは「内部的にXTALモードは有効になっていません」と書きました。どのレジスタで設定すればいいのでしょうか?(リファレンス・マニュアルには何も記載がありませんでした)また、この再構成が行われる前にプロセッサが外部クロックで駆動されている場合、リスクはありますか? さらに、このクロックソースが不要なら、32 kHzのXTALIピンをGNDに単純に結びつけることができるのかも気になっています。 Re: i.MX93 RTC XTALI Duty Cycle 1.利用可能なi.MX93やPCA9451Aドキュメントで「XTALモードなし」を有効にするレジスタは見つかりませんでした。取得したドキュメントでは、ソフトウェア選択モードではなく、ピンストラップやハードウェアの挙動として記述されています。 2. はい、i.MX93バックアップドメイン供給が有効になる前に RTC_XTALI が駆動されると、文書化されたリスクがあります。i.MX93ハードウェア設計ガイドには、外部32.768 kHzのRTC信号がオフの場合は駆動してはならない NVCC_BBSM_1P8 明記されています。 3. PCA9451Aのデータシートだけが、未使用の  XTAL_IN  ピンをGNDに接続します。

AVB Import Error   Hi, importing TRESOS project from SW32K5_AVB_M7_0.8.0_CD02_D2606 reported more than 5000 errors, what is the reason and how to solve it. Thanks!       回复： AVB 导入报错 Hi Tony. Sorry for the inconvenience. After I installed SW32K5_RTD_R23-11_0.8.1_CD03_D2604.exe and SW32K5_AVB_M7_0.8.0_CD02_D2606.exe, importing a project using tresos Studio 32.0 still reports errors. Although AVB_S32K5_AVTP_IntegrationManual.pdf mentions S32K5 RTD Drivers 0.8.1 CD03, I see in EB Tresos' Module Configurations Dio\Port SW.Version: 0.8.1 D2605. This looks more like the version of SW32K5_RTD_R23-11_0.8.1_D2605.exe you downloaded earlier. Please wait for a response from the internal team and then use the EB Tresos Studio 32.1.4 import to verify if the EB version is causing this. Best Regards, Robin 回复： AVB 导入报错 Hi Robin. Thank you for your response and look forward to hearing back from your internal team. 回复： AVB 导入报错 1. EB Tresos 32.1.4 is now available for download and installation: Please click on S32K3 Standard Software - > Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool - > EB tresos Studio 32.1.4 2. I uninstalled the previously installed SW32K5_AVB_M7_0.8.0_CD02_D2606, SW32K5_M7_gPTP_0.8.0_D2605, SW32K5_RTD_R23-11_0.8.1. 3. Reinstall SW32K5_RTD_R23-11_0.8.1_D2605.exe, SW32K5_M7_gPTP_0.8.0_D2605.exe, SW32K5_AVB_M7_0.8.0_CD02_D2606.exe and select the latest installation for EB Tresos install directory. directory to the latest installation of EB Tresos 32.1.4. Path. 4. Import the AVB project in SW32K5_AVB_M7_0.8.0_CD02_D2606, now you can generate code normally! 回复： AVB 导入报错 Thanks, it works now.

S32K312 — PTB2 上的外部中断 (EIRQ_10) 未触发 你好，恩智浦社区、 我正在使用 RTD 4.0.0（AUTOSAR 4.7）和 S32 Design Studio 3.6.6 在 S32K312（100 引脚 HDQFP）上实现外部中断、目标 PTB2（引脚 48）→EIRQ_10。我参考了使用 PTB26 → EIRQ_13 的 NXP 社区示例 (S32K312_EIRQ_interrupt)，并将其改编为 PTB2。但是，中断回调永远不会被触发。 我验证了 IOMUX 表 (S32K312_IOMUX.xlsx)并确认 PTB2 通过 SIUL_IMCR538（索引 26）正确映射到 EIRQ[10]，SSS=0001（ALT1）--因此引脚路由值似乎是正确的。 如能提供在 100 引脚 S32K312 上使用 PTB2 (EIRQ_10) 的指导或工作示例，将不胜感激。 谢谢！ Re: S32K312 – External Interrupt (EIRQ_10) on PTB2 Not Triggering 你好 我已在下面的主题中作了回复： https://community.nxp.com/t5/S32K/S32K312-External-Interrupt-EIRQ-10-on-PTB2-Not-Triggering/td-p/2376810 顺祝商祺！ Peter Re: S32K312 – External Interrupt (EIRQ_10) on PTB2 Not Triggering 你好，彼得、 感谢您的建议。 我检查了推荐的寄存器，得到了以下运行时值： DISR0 = 0 DIRER0 = 1024 (0x00000400)，启用第 10 位 IREER0 = 1024 (0x00000400)，启用第 10 位 IFEER0 = 0（上升沿配置） imcr[26] = 1 (备选 1) NVIC ISER1 = 4194304 (0x00400000)，对应 IRQ54 (SIUL_IRQ1)，启用第 22 位 我还验证了硬件输入路径： PTB2 配置为 EIRQ10。 读取 PTB2 输入状态正常。 当外部信号施加到 PTB2 时，该引脚读取逻辑 "1"。 信号移除后，引脚读数为逻辑 "0"。 然而，尽管输入状态发生了正确的变化： DISR0 位 10 永远不会被设置。 未输入 SIUL_IRQ1 ISR。 未执行已注册的回调函数。 从这些观察结果来看 物理输入信号正确到达 PTB2。 IMCR 路由已按预期配置。 中断使能寄存器配置正确。 NVIC 启用位被设置。 但是，EIRQ10 事件不会生成 SIUL2 中断状态标志（DISR0 第 10 位仍为 0），因此 ISR 从未被调用。 你能否告知接下来应该检查哪些额外的 SIUL2/EIRQ 寄存器，或者是否有任何已知的 S32K312 上的 PTB2 → EIRQ10 要求，即使引脚输入状态正确变化，也可能会阻止 DISR0 断言？ 此外，我使用的是S32K312（100 引脚 HDQFP），使用 RTD 4.0.0（AUTOSAR 4.7）和 S32 Design Studio 3.6.6。能否请您确认是否存在任何设备特定的限制、SIUL2 路由要求、焊盘特性、特定封装注意事项或 PTB2 → EIRQ10 的 RTD 配置依赖关系？ 由于引脚输入状态变化正确，但 DISR0 第 10 位从未被置位，也从未进入 ISR，因此除了标准端口、ICU 和 NVIC 配置外，我还希望获得有关 S32K312 特定检查的指导。 致以最诚挚的问候， Esakki

Is there mismatch between eIQ guideline? I see these guideline to convert tflite to npu tflite model.  The first guideline: https://docs.nxp.com/bundle/AN14700/page/topics/model_conversion_for_npu.html It is interactive guideline. In this guideline, NXP said that we need to choose right MCUXpresso SDK version. It seems that this guideline is for eIQ Toolkit 1.17.0.110 Ubuntu 20.04.03 Installer. Is that right? The second guideline: https://docs.nxp.com/bundle/AN14700/page/topics/eiq_enablement.html It uses command line neutron-converter --input mobilenet_quant.tflite --output mobilenet_npu.tflite --dump-header-file-input --dump-header-file-output --target imxrt700 --use-sequencer I downloaded eIQ Neutron SDK 3.1.2 (Linux package) and I could run the about command to create npu_tflite model. But in this case, it did not mention about compatible MCUXpresso SDK version. It makes me confused. An I am not sure whether I can used the created npu model in example of MCUXpresso SDK without knowing version. Do you have any comment on this problem? Re: Is there mismatch between eIQ guideline?  @anthony_huereca Could you help me in this case? I ask in the Wednesday, and maybe you missed this post. Thank you. Re: Is there mismatch between eIQ guideline? The Neutron Converter enablement has been reorganized since that app note was written. The latest Neutron Converter can now be found in latest eIQ Neutron SDK. Also inside the eIQ Neutron SDK is the Neutron libraries to use in your project. See this post for details: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/How-to-Update-eIQ-Projects-with-the-Latest-eIQ-Neutron-SDK/ta-p/2270833?lightbox-message-images-2270833=382154i8450392E2394C882 If you use a model converted with the 3.1.2 Neutron Converter then you'll get an mismatch error if you try to run it with the MCUXpresso SDK 26.03. However you can easily update the MCUXpresso SDK 26.03 projects to use the 3.1.2 Neutron libraries to get it to work. You can also follow the latest eIQ NPU MCU labs (RT700 and MCX N) which go through this process.  The app note is already in the process of being updated to reflect the new enablement flow.  Re: Is there mismatch between eIQ guideline? Hi. Thank you. I got your points. I will refer the documentation that you send me.

在 FRDM-IMX95 上调试 Ara240 模块 入门视频 (function() { var wrapper = document.getElementById('lia-vid-6393577020112w960h540r856'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (在我的视频中查看） 本指南提供分步说明，说明如何验证与 Ara240 模块的成功通信以及与 FRDM i.MX 95 开发板接口的运行时软件环境。 打破常规 熟悉 Ara240 模块 Ara240 Module [Top view]Ara240 模块 [俯视图］ Ara240 Module [Back view]Ara240 模块 [后视图］      连接 M.2 模块 本节介绍如何将分立模块 Ara240 连接到 FRDM i.MX 95 开发板。FRDM i.MX 95 快速入门指南中的说明将引导您完成主板上预加载的嵌入式 Linux 映像的启动过程以及如何连接 USB 调试电缆。有关其他详细信息，请参阅 FRDM i.MX 95 开发板官方文档。 参考，引用: FRDM i.MX 95 快速入门指南 FRDM i.MX 95 开发板产品页面 FRDM i.MX 95 入门页面 ARA2-M2-16G-GT 入门 按照以下步骤将 Ara240 模块连接到 FRDM i.MX 95 开发板： 剧透 (加亮显示以阅读) 重要：在进行任何连接之前，请确保主板已关闭电源。 重要：在进行任何连接之前，请确保主板已关闭电源。 将 Ara240 模块插入 FRDM i.MX 95 开发板上的 M.2 Key-M 插槽。 使用提供的螺钉固定模块。 将风扇电缆连接到主板的风扇接头（有关接头的确切位置，请参阅 FRDM i.MX 95 主板文档）。 Connect the Ara240 to the FRDM i.MX 95 development board.将 Ara240 连接到 FRDM i.MX 95 开发板。 开启板电源 按照《FRDM-IMX95 入门》中的说明开启（启动）板。 开机后，检查风扇和 Ara240 模块的绿色 LED 指示灯是否亮起。   获取软件 本节将向您介绍 Ara240 Runtime 软件开发工具包 (SDK)，这是 Ara240 SDK 的精简子集，旨在恩智浦平台上快速启用和执行。Runtime SDK 简化了安装和配置，使开发人员能够以最小的工作量在 Ara240 模块上快速部署和运行 AI/ML 工作负载。 概述 有关 Ara240 软件开发套件 (SDK) 的详细信息，请参阅 Ara240 软件发行说明 Ara240 入门页面仅概述了在特定 i.MX 开发平台上的使用情况 对于任何其他平台，请联系您的恩智浦代表寻求指导。 模块枚举和软件配置 本节提供有关在 FRDM i.MX 95 开发板上验证是否正确安装了 Ara240 模块和 Ara240 Runtime SDK 配置的说明。 验证设备检测 主板成功启动后，连接到串行调试端口以监测系统日志。要确认主板是否检测到 Ara240 模块，请运行以下命令： $ lspci | grep 1e58 预期输出： 0000:01:00.0 Processing accelerators: Device 1e58:0002 (rev 02) 启用 Ara240 设备 为了快速启用，Ara240 运行时 SDK 会在启动时启动。有关详细说明和环境设置步骤，请参阅Ara240 Runtime SDK 文档。 开发人员体验 本节概述了使用 FRDM i.MX 95 开发板支持 Ara240 运行时软件。 验证设置环境 使用以下指南来了解如何连接所需设备。对于大多数演示，你需要摄像头、键盘、鼠标、互联网连接和一个 HDMI 显示器。 Setup preparation for FRDM i.MX 95 board [Top view]FRDM i.MX 95 主板的设置准备 [顶部视图] Setup preparation for FRDM i.MX 95 board [Back view]FRDM i.MX 95 主板的设置准备 [返回视图] 剧透 (加亮显示以阅读) 注意：您可能需要使用 USB 集线器来同时连接键盘、鼠标和摄像头。 注意：您可能需要使用 USB 集线器来同时连接键盘、鼠标和摄像头。   运行时设置 说明 Runtime SDK 提供了一个完整的运行环境，可在 Ara240 模块上实现 AI/ML 加速。要运行演示应用程序，请确保 Ara240 启动过程已成功完成，系统已为演示评估做好准备。 请参阅 Runtime SDK 文档，了解有关以下方面的详细指导： 验证 Runtime SDK 的正确安装。 检查并更新 Ara240 固件版本。 验证代理服务启动状态。 在 Ara240 上执行基准测试。 按照这些步骤操作可确保模块正确初始化并可随时使用。Ara240 支持执行 CNN、LLM、VLM 和代理框架，使高级人工智能工作负载能够直接在 Ara 上运行。有关全面的示例和端到端工作流程指导，请参阅Ara SDK文档页面。 FRDM-IMX9

Configure WDOG within 128 Bus Clocks Clarification I am experiencing unexpected WDOG behavior according to my understanding of the reference manual in regard to the following: "All watchdog control bits, timeout value, and window value are write-once after reset within 128 bus clocks. This means that after a write has occurred they cannot be changed unless a reset occurs." My initial interpretation of this is that you must configure the WDOG within the first 128 bus clocks after reset, or it will use the default configuration with UPDATE=0. This will then prevent you from re-configuring the WDOG again. I however am experiencing something different. Since the KE1 out of reset runs the Bus and Core clock at the same frequency, I decided to look at the CYCLECOUNTER in the IAR debugger when I reconfigure the WDOG, as I thought it would tell me how many bus clocks have also passed since reset. It showed 144 cycles had passed since release from reset. So I started adding longer and longer delay loops at the start of the function to see if it would still allow me to reconfigure well past 144 cycles. No matter how long the delay, as long as it was below the default 8ms timeout of the WDOG, it would successfully reconfigure the WDOG. I observed this behavior with, and without the debugger, just to ensure the debugger did not play any role. I was also able to confirm timing via strobing the reset signal with Oscope. So now my understanding of the reference manual is that you can reconfigure the WDOG once out of reset. And once you perform the first write to the WDOG, you get 128 bus clocks to reconfigure the remaining register fields. For example, lets say I wait 1000 bus clocks out of reset and then configures the WDOG_CS register. I then get 128 bus clocks after configuring the WDOG_CS to configure the WDOG_TOVAL. Once TOVAL is configured, the new configuration takes effect. Is this the correct interpretation of the reference manual? Or is my previous interpretation correct where you get 128 bus clocks out of reset, or the default configuration takes effect? Re: Configure WDOG within 128 Bus Clocks Clarification Hello @sean_dvorscak , Thanks for you post. You may refer to section "30.4.3.2.1 Unlocking the Watchdog" and section "30.5.2 Configure Watchdog" in KE1xFP100M168SF0RM. The correct interpretation appears to be as follows: After reset, the WDOG is enabled and operates with its reset-default settings. The WDOG configuration registers are still available for an initial configuration sequence. Once the watchdog is unlocked , the remaining configuration registers must be written within 128 bus clocks . If UPDATE=0, then after that initial configuration is completed, the WDOG configuration cannot be changed again until the next reset. If UPDATE=1, the WDOG can be unlocked and reconfigured again later, with the same 128 bus clock window applying after each unlock. This interpretation is consistent with your measurements: even when more than 128 bus clocks had elapsed since reset, the WDOG could still be reconfigured successfully, provided this happened before the default watchdog timeout expired. In other words, the 128 bus clock configuration window is associated with the unlock sequence, not simply with the elapsed time since reset release. If no new configuration is completed, the WDOG continues operating with its reset default settings. Hope it helps. BR Celeste ------------------------------------------------------------------------------------------------------------------------ Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! ------------------------------------------------------------------------------------------------------------------------ Re: Configure WDOG within 128 Bus Clocks Clarification There are certain command sequence need to follow in order to update WATCHDOG setting.I dont know where the 128 bus clocks come from but take the K80 Sub-Family Reference Manual, Rev. 4, 09/2015 for example： As long as ALLOW_UPDATE in the watchdog control register is set, you can unlock and modify the write-once-only control and configuration registers: 1. Write 0xC520 followed by 0xD928 within 20 bus clock cycles to a specific unlock register (WDOG_UNLOCK). 2. Wait one bus clock cycle. You cannot update registers on the bus clock cycle immediately following the write of the unlock sequence. 3. An update window equal in length to the watchdog configuration time (WCT) opens. Within this window, you can update the configuration and control register bits. These register bits can be modified only once after unlocking.If none of the configuration and control registers is updated within the update window,the watchdog issues a reset, that is, interrupt-then-reset, to the system. Trying to unlock the watchdog within the WCT after an initial unlock has no effect. Re: Configure WDOG within 128 Bus Clocks Clarification Thank you for the clarification. Glad to know I have more than 128 bus clocks out of reset to configure WDOG. If they ever make a new revision of KE1xFP100M168SF0RM, I'd like to suggest removing the "... within 128 bus clocks." from the first sentence of section 30.4.3.1. Appreciate the suggestion might be silly, but I only suggest it because I found some misinformation online citing that wording to suggest you only get 128 bus clocks to configure WDOG out of reset. It also unfortunately makes the Google AI overview regurgitate the same misinformation (... gotta love the future 🙂 ). Which is why I had to ask the question here myself. Re: Configure WDOG within 128 Bus Clocks Clarification Understood. Unfortunately, to the best of my knowledge, there is no new roadmap for the Kinetis family. We have recently introduced the MCX family, which you may consider exploring if you’re interested. MCX Arm Cortex-M Industrial and IoT MCUs | NXP Semiconductors

S32DS | S32k144 RTD DIO 引脚项目错误 你好 我正在尝试在装有 S32DS 3.6.7 的 S32K144 LQFP100 上使用 RTD AUTOSAR (MCAL) 设置一个基本的 LED 闪烁示例。我在 Pins 工具（.mex 文件）中将 PTC11 配置为 GPIO 输出，并在外围设备/MCAL 视图中添加了 Dio 和端口组件。 但是，当我点击 "更新代码 "时，代码生成失败，并出现以下错误： - [CODEGEN] 生成文件 'Port_Ci_Port_Ip_PBcfg.c' 失败 - TypeError：PinMode.match 不是函数 at GetPDO_IP (:187) - [CODEGEN] 生成文件 'Port_PBcfg.c' 失败 在 GetPDO（port_utils.js：235） 我的设置： -主板：S32K144 LQFP100 -S32DS 版本：3.6.7 -RTD/PlatformSDK_S32K1_S32M24 -引脚：PTC11 配置为 portC: port_11、输出、GPIO-添加了 MCAL 元器件：Dio + 端口（均在 AUTOSAR 模式下） 在端口 MCAL 配置中，PortPin_0 的 "PortPin Direction（端口引脚方向）"和 "PortPin Mode（端口引脚模式）"字段显示为灰色，并显示数值 (0) 而不是字符串。我怀疑代码生成器期望引脚模式的字符串值是 "ALT1"，但收到的却是一个数字。 有人遇到过这个问题吗？PortPin 配置是否应该完全由 .mex 自动生成？还是需要手动配置？如能得到任何指导，将不胜感激。 此外，由于我是 RTD AUTOSAR 的新手，我想知道是否有从头开始学习堆栈的推荐资源 - 教程、示例项目、视频或学习 MCAL 模块（端口、Dio、Adc、Pwm、Can...）的任何建议顺序。我有裸机嵌入式 C 语言的经验，但对 AUTOSAR 却一无所知。 如能得到任何指导，将不胜感激。 谢谢！ Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 我还在努力。我从驱动程序中删除了端口库，但仍然无法正常工作。 PortPinMode 设置为 0，而在你发给我的示例和代码中，它被设置为 GPIO。我不知道如何改变这种状况。 我对工作流程也有些困惑。据我所知 首先，在针脚选择器工具中选择针脚。 然后，在端口模块中配置引脚（底层配置）。 最后，按照 AUTOSAR 原则，使用 DIO 作为封装器/接口，这样应用程序就不会直接依赖于微控制器。 Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 你好@antonio_esal 在打开你创建的示例程序时，我确实发现了一些错误。随函附上我创建的示例程序供你参考。 在您的项目中，无需同时在 MCAL 和 Drivers 中添加"Port" 模块。 Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 是的，我正在这样做，演示示例运行得很好，但当我尝试从一个新项目中做同样的事情时，我做不到。 Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 你好@antonio_esal 您可以参考 RTD 驱动程序包中包含的示例代码开始学习。

有关 MCM-i.MX8M-Plus 上 nnshark 和 NPU 推断的询问 队员们好 我们目前正在Compulab的MCM-i.MX8M-Plus平台上评估NPU的推断和分析。 我们最初向 CompuLab 支持人员提出了这个问题，他们建议我们就 nnshark 的使用和 NPU 验证问题直接联系恩智浦。 我们尝试将 nnshark 集成到镜像中，并验证了配方是否成功构建。但是，目标系统上没有独立的 nnshark 可执行文件，只有 libgstsharktracers.so 和 libgstshark.so 等库文件可用。我们想澄清是否打算仅通过 GStreamer 跟踪器/插件使用 nnshark，或者是否需要一个独立组网 \\(SA\\) 实用程序。 此外，我们使用启用了分析功能的 VX 委托测试了 TensorFlow Lite 推理。虽然委托成功加载，但我们希望得到指导，以验证 NPU 的适当利用率，并了解推理过程中 CPU 的预期使用情况。 我附上了nnshark集成和推理测试的详细程序以供参考。 能否请您帮忙澄清一下： nnshark 的预期使用方法 是否存在支持 nnshark 的参考图像/包 验证 NPU 执行的建议方法 针对 NPU 推荐的 TensorFlow Lite 模型或流水线优化方法 感谢您的支持。 Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 您好， 请查看所附日志文件和 NNShark 截图。最初，我通过在启动期间中断 U-Boot 来更新了 MMC 启动参数。系统启动后，我验证了 电路板支持包 的发布版本，并在通过环境变量启用 NnShark 配置文件后执行了 GStreamer 管道。 谢谢！ Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 你好@cris_m 在使用 TensorFlow Lite VX 委托运行流水线时，日志仍然报告 "accl = cpu"，这让人对推理是否真的被卸载到 NPU 感到困惑。 >>>请共享您的日志文件。包括您用来运行模型的命令和方法。 是否期望 nnshark 提供独立组网 \\(SA\\) 的可执行文件还是仅提供 GStreamer 跟踪库 > > > nnShark 是一款基于 GstShark 的分析工具，用于监测多个管道指标，以评估 SoC 硬件利用率。 > > > 在 i.MX8M Plus 上，nnShark 主要用于通过 GStreamer/NNStreamer 跟踪器对人工智能管道进行实时分析和性能验证。通常是在运行 GStreamer 管道之前设置 GST_TRACERS 和 GST_DEBUG 环境变量。您可以通过以下链接了解更多详情： https://github.com/nxp-imx/nnshark 如何确证推理执行过程中 NPU 的利用率 > > > 你使用的是哪个版本的电路板支持包？ B.R Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 感谢您的回复和分享参考文档。 我想说的是，我已经按照第 8.1 章（对象检测流水线示例）中描述的步骤进行了操作，并在先前所附的 NPU_test.txt 文档中分享了相同的细节，以及 GStreamer 流水线执行的截图/日志。 在使用 TensorFlow Lite VX 委托运行流水线时，日志仍然报告 "accl = cpu"，这让人对推理是否真的被卸载到 NPU 感到困惑。 此外，我之前提出的关于使用 nnshark 的问题也没有得到解决。具体地说，我希望澄清以下问题： 是否期望 nnshark 提供独立组网 \\(SA\\) 的可执行文件还是仅提供 GStreamer 跟踪库 如何使用 nnshark 在 i.mx8M Plus 上进行分析/验证 如何确证推理执行过程中 NPU 的利用率 如果我在设置或测试过程中遗漏了任何步骤，也请告诉我。 能否请您查看所附的程序/日志，并帮助澄清这些问题？ 谢谢！ Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 你好@cris_m 请参阅附件中的第 8 章（使用 NNStreamer 的视觉管道）。您还可以了解如何在使用 NPU 加速的 i.MX 8M Plus 上运行机器学习应用程序。 B.R Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 你好 你能否查看之前分享的日志，与我们联系所遵循的程序是否有任何问题，或者是否需要采取任何其他步骤？ 谢谢！ Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 你好@cris_m 请运行附件 .sh锉刀我已经在我的 imx8mp evk 主板上测试过了，没有任何问题。 B.R Re: Query Regarding nnshark and NPU Inference on MCM-i.MX8M-Plus 是的。 成功了 谢谢。 致以最诚挚的问候

IMX8MP 内联 ECC 亲爱的恩智浦技术支持团队 我目前正在尝试在 IMX8MP 上使用 Inline ECC 功能（按照 AN13566.pdf 和https://community.nxp.com/t5/NXP-Tech-Blog/xxx中的步骤操作）。 ). 根据 IMX8MPRM.pdf 第 9.2.5.1.20.3 节、我尝试将 ecc_region_parity_lock 设置为解锁。 我修改了 lpddr4_timing.c 的内容，将 0x3d400074 寄存器的值设置为 0x780。 struct dram_cfg_param ddr_ddrc_cfg[] = { {0x3d400304, 0x1}, {0x3d400030, 0x1}, {0x3d400000, 0xa3080020}, {0x3d400020, 0x1323}, {0x3d400024, 0x1e84800}, {0x3d400064, 0x7a0118}, {0x3d400070, 0x070277D4}, {0x3d400074, 0x780}, ...... 但是，通过 memtool 工具读取的寄存器值是 0x790。 root@imx8mp-lpddr4-evk:~# /unit_tests/memtool 0x3d400074 1 E Reading 0x1 count starting at address 0x3D400074 0x3D400074: 00000790 我想知道如何正确配置这个寄存器。 提前感谢您的支持。 Re: IMX8MP Inline ECC 感谢您的支持 Re: IMX8MP Inline ECC 你好@James33 请分享您修改后的 RPA 文件。 B.R Re: IMX8MP Inline ECC Hi @James33  你是自己手动修改的寄存器的值吗？ B.R Re: IMX8MP Inline ECC 你好 Re: IMX8MP Inline ECC lpddr4_timing.c 文件由 DDR 工具生成（ * 代码由 DDR 工具 v4.0.0_10-1eade933a 生成）。该寄存器的默认值为 0x790。根据 AN13566 第 3.2.3 节的描述、我想访问 ECC 奇偶校验区，因此手动将其改为 0x780，但没有成功。 /* * Copyright 2026 NXP * * SPDX-License-Identifier: BSD-3-Clause * * Code generated with DDR Tool v4.0.0_10-1eade933a. * DDR PHY FW2020.06 * Part number: NXP LPDDR4 EVK board's default DDR part */ #include #include /* Initialize DDRC registers */ struct dram_cfg_param ddr_ddrc_cfg[] = { {0x3d400304, 0x1}, {0x3d400030, 0x1}, {0x3d400000, 0xa3080020}, {0x3d400020, 0x1323}, {0x3d400024, 0x1e84800}, {0x3d400064, 0x7a0118}, {0x3d400070, 0x7027fd4}, {0x3d400074, 0x790}, {0x3d4000d0, 0xc00307a3}, {0x3d4000d4, 0xc50000}, {0x3d4000dc, 0xf4003f}, {0x3d4000e0, 0x330000}, {0x3d4000e8, 0x660048}, {0x3d4000ec, 0x160048}, {0x3d400100, 0x2028222a}, {0x3d400104, 0x8083f}, {0x3d40010c, 0xe0e000}, {0x3d400110, 0x12040a12}, {0x3d400114, 0x2050f0f}, {0x3d400118, 0x1010009}, {0x3d40011c, 0x502}, {0x3d400130, 0x20800}, {0x3d400134, 0xe100002}, {0x3d400138, 0x120}, {0x3d400144, 0xc80064}, {0x3d400180, 0x3e8001e}, {0x3d400184, 0x3207a12}, {0x3d400188, 0x0}, {0x3d400190, 0x49f820e}, {0x3d400194, 0x80303}, {0x3d4001b4, 0x1f0e}, {0x3d4001a0, 0xe0400018}, {0x3d4001a4, 0xdf00e4}, {0x3d4001a8, 0x80000000}, {0x3d4001b0, 0x11}, {0x3d4001c0, 0x1}, {0x3d4001c4, 0x1}, {0x3d4000f4, 0x799}, {0x3d400108, 0x9121b1c}, {0x3d400200, 0x14}, {0x3d400208, 0x0}, {0x3d40020c, 0x14141400}, {0x3d400210, 0x1f1f}, {0x3d400204, 0x50505}, {0x3d400214, 0x4040404}, {0x3d400218, 0x4040404}, {0x3d40021c, 0xf0f}, {0x3d400250, 0x1705}, {0x3d400254, 0x2c}, {0x3d40025c, 0x4000030}, {0x3d400264, 0x900093e7}, {0x3d40026c, 0x2005574}, {0x3d400400, 0x111}, {0x3d400404, 0x72ff}, {0x3d400408, 0x72ff}, {0x3d400494, 0x2100e07}, {0x3d400498, 0x620096}, {0x3d40049c, 0x1100e07}, {0x3d4004a0, 0xc8012c}, {0x3d402020, 0x1021}, {0x3d402024, 0x30d400}, {0x3d402050, 0x20d000}, {0x3d402064, 0xc001c}, {0x3d4020dc, 0x840000}, {0x3d4020e0, 0x330000}, {0x3d4020e8, 0x660048}, {0x3d4020ec, 0x160048}, {0x3d402100, 0xa040305}, {0x3d402104, 0x30407}, {0x3d402108, 0x203060b}, {0x3d40210c, 0x505000}, {0x3d402110, 0x2040202}, {0x3d402114, 0x2030202}, {0x3d402118, 0x1010004}, {0x3d40211c, 0x302}, {0x3d402130, 0x20300}, {0x3d402134, 0xa100002}, {0x3d402138, 0x1d}, {0x3d402144, 0x14000a}, {0x3d402180, 0x640004}, {0x3d402190, 0x3818200}, {0x3d402194, 0x80303}, {0x3d4021b4, 0x100}, {0x3d4020f4, 0x599}, {0x3d403020, 0x1021}, {0x3d403024, 0xc3500}, {0x3d403050, 0x20d000}, {0x3d403064, 0x30007}, {0x3d4030dc, 0x840000}, {0x3d4030e0, 0x330000}, {0x3d4030e8, 0x660048}, {0x3d4030ec, 0x160048}, {0x3d403100, 0xa010102}, {0x3d403104, 0x30404}, {0x3d403108, 0x203060b}, {0x3d40310c, 0x505000}, {0x3d403110, 0x2040202}, {0x3d403114, 0x2030202}, {0x3d403118, 0x1010004}, {0x3d40311c, 0x302}, {0x3d403130, 0x20300}, {0x3d403134, 0xa100002}, {0x3d403138, 0x8}, {0x3d403144, 0x50003}, {0x3d403180, 0x190004}, {0x3d403190, 0x3818200}, {0x3d403194, 0x80303}, {0x3d4031b4, 0x100}, {0x3d4030f4, 0x599}, {0x3d400028, 0x0}, }; 谢谢您的答复。 Re: IMX8MP Inline ECC Hello！！

Relaying PCIe data between two endpoints via RC on iMX95 FRDM PRO As part of the patches attached with this blog, we will relay the pcie write transaction from Endpoint-A to Endpoint-B connected to iMX95FRDM PRO.   Linux-imx used - lf-6.18.2-1.0.0 Attached are the following files:-   imx95-19x19-frdm-pro-pcie0-ep-dtbs - EP A shall use the dtb built with this dtbs imx95-19x19-frdm-pro-pcie1-ep-dtbs - EP B shall use the dtb built with this dtbs rc_pcie_dma_relay.c - driver used on RC to relay pcie write from EP-A to EP-B conf_pcie0.sh - script to be executed on Endpoints A and B to configure the EPF driver //To build the dtb and relay kernel driver 1. git clone  git clone https://github.com/nxp-imx/linux-imx.git git checkout origin/lf-6.18.y 2. Copy the dtbs to arch/arm64/boot/dts/freescale/ Copy rc_pcie_dma_relay.c to drivers/pci/   3. Make the following changes as per this diff   diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index aa3cfdf1aafc..56e3db653208 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@@ -1205,6 +1205,16 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-8mic-reve.dt  dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb imx95-19x19-frdm-pro-aud-hat.dtb + +dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-pcie0-ep.dtb +dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-pcie1-ep.dtb + +imx95-19x19-frdm-pro-pcie0-ep-dtbs := imx95-19x19-frdm-pro.dtb \ +                      imx95-19x19-frdm-pro-pcie0-ep.dtbo + +imx95-19x19-frdm-pro-pcie1-ep-dtbs := imx95-19x19-frdm-pro.dtb \ +                      imx95-19x19-frdm-pro-pcie1-ep.dtbo +  imx95-19x19-frdm-pro-os08a20-isp-dtbs := imx95-19x19-frdm-pro.dtb \                                          imx95-19x19-frdm-pro-os08a20.dtbo  dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-os08a20-isp.dtb   4. Add the following to drivers/pci/Makefile +obj-m      += rc_pcie_dma_relay.o 5. Trigger the kernel build. You will obtain rc_pcie_dma_relay.ko, imx95-19x19-frdm-pro-pcie0-ep.dtb and imx95-19x19-frdm-pro-pcie1-ep.dtb. 6. We are only using pcie0 M.2 Key M slots of Endpoint A and Endpoint B so you only need to upload this dtb to both the endpoint boards - imx95-19x19-frdm-pro-pcie0-ep.dtb and boot linux with it after passing 'iommu.passthrough=1' at uboot mmcargs. This is to disable smmu for our tests. RC will boot with the default dtb - imx95-19x19-frdm-pro.dtb 7. Connect the Endpoint-A to RC's K1 via M.2 Key M to Key M cable. Similarly connect the other Endpoint-B to other RC's K2 M.2 slot via Key M to Key M cable. 8. Execute this script on both the endpoints - ./conf_pcie0.sh 9. Then reboot the RC iMX95 FRDM Pro and ensure that you see both the endpoints:-   0000:01:00.0 and 0001:01:00.0 are the enumerated endpoints. 10. Upload rc_pcie_dma_relay.ko to the RC board and insert it like this:-  insmod rc_pcie_dma_relay.ko src_phys=0x910100000 dst_phys=0xa10100000 relay_len=0x100000 chunk_len=0x10000 you will observe similar logs on dmesg:-   [ 4949.082087] rc_pcie_dma_relay: init src=0x910100000 dst=0xa10100000 len=1048576 chunk=65536 [ 4949.082150] rc_pcie_dma_relay src_before: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4949.082171] rc_pcie_dma_relay dst_before: [0]=0x00000000 [1]=0x00000000 [2]=0x00000000 [3]=0x00000000 [ 4949.125779] rc_pcie_dma_relay dst_zeroed: [0]=0x00000000 [1]=0x00000000 [2]=0x00000000 [3]=0x00000000 [ 4949.141380] rc_pcie_dma_relay src_after: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4949.141427] rc_pcie_dma_relay dst_after: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4954.272981] rc_pcie_dma_relay: verify OK for 1048576 bytes [ 4954.273000] rc_pcie_dma_relay: DMA relay verify PASSED   11. Finally, via devmem5 on RC, you can verify the data of EP-A transferred to EP-B  ./devmem5 r 0xa10100000 w   IMX95EVK

SJA1110A DSA 上电：100BASE-TX TX 故障和 T1 链路培训问题 你好 我正在使用 Linux DSA 通过 SPI 将一个 SJA1110AEL 交换机连接到 Microchip PolarFire SoC 上 sja1105驱动程序，通过 SPI 将 SJA1110AEL 开关连接到 Microchip PolarFire SoC： https://github.com/linux4microchip/linux/tree/linux-6.12-mchp%2Bfpga/drivers/net/dsa/sja1105 交换机配置为 SPI 启动模式（BOOT_OPTION=11），静态配置上传看起来很成功。 [ 2.546758] sja1105 spi9.0: Probed switch chip: SJA1110A [ 2.546777] sja1105 spi9.0: max_xfer_len = 256 bytes [ 2.549576] sja1105 spi9.0: Config buffer length: 1776 bytes [ 2.549605] sja1105 spi9.0: Config buffer device_id at offset 0: 0x0f0300b7 [ 2.742531] sja1105 status decoded: CONFIGS=1 CRCCHKL=0 IDS=0 CRCCHKG=0 NSLOT=9 [ 2.742563] sja1105 spi9.0: sja1105_static_config_load done [ 2.742579] sja1105 spi9.0: sja1105_clocking done [ 2.742592] sja1105 spi9.0: sja1105_TAS and flower setup done [ 2.743823] sja1105 spi9.0: sja1105_ptp_clock_register done [ 2.888661] sja1105 spi9.0: sja1105_mdiobus_register done [ 2.888699] sja1105 spi9.0: sja1105_devlink_setup done [ 2.902778] sja1105 spi9.0: dsa_tag_8021q_register and rtnl_unlockdone [ 2.904141] sja1105 spi9.0: configuring for fixed/sgmii link mode [ 2.909745] sja1105 spi9.0: Link is Up - 1Gbps/Full - flow control off [ 2.964511] sja1105 spi9.0 rj45 (uninitialized): PHY [spi9.0-base-tx:01] driver [NXP CBTX (SJA1110)] (irq=POLL) [ 2.973125] sja1105 spi9.0 t1-1 (uninitialized): PHY [spi9.0-base-t1:01] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.976322] sja1105 spi9.0 t1-2 (uninitialized): PHY [spi9.0-base-t1:02] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.979382] sja1105 spi9.0 t1-3 (uninitialized): PHY [spi9.0-base-t1:03] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.982622] sja1105 spi9.0 t1-4 (uninitialized): PHY [spi9.0-base-t1:04] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.985855] sja1105 spi9.0 t1-5 (uninitialized): PHY [spi9.0-base-t1:05] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.989002] sja1105 spi9.0 t1-6 (uninitialized): PHY [spi9.0-base-t1:06] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.991420] macb 20110000.ethernet eth0: entered promiscuous mode [ 2.991540] DSA: tree 0 setup [ 2.993156] clk: Disabling unused clocks ############################################## *************** FSW-PIXXEL *************** *************** IN_xPC *************** ############################################## # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever 2: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 4e:0a:f0:7b:bc:e0 brd ff:ff:ff:ff:ff:ff 3: can0: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 4: can1: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 5: eth0: mtu 1536 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 6: eth1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:04:a3:61:cc:6f brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: rj45@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 9: interswitch@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 10: epc2-uplink@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 11: t1-1@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 12: t1-2@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 13: t1-3@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 14: t1-4@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 15: t1-5@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 16: t1-6@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 目前的观察结果： CPU 端口 (SGMII) 启动正常。 我可以从连接到 RJ45 100BASE-TX 端口的笔记本电脑接收 ARP 数据包。 板上的 tcpdump 确认来自笔记本电脑的 ARP 请求。 当从主板发送（ping/arping）时，笔记本电脑不会收到任何东西。 笔记本电脑 tcpdump 未显示来自主板的 RX 数据包。 我的问题是 要使 TX 流量在 SJA1110 DSA 端口上正常工作，是否需要任何额外的运行时 MAC 配置/转发/路由表设置？ 是否可以预期 100BASE-T1 PHY 在此驱动程序树 中仅作为 通用条款 45 PHY 出现 ？ 当前的 Linux 6.12 Microchip 树中是否缺少专用 BASE-T1 PHY 驱动程序？ 为了进行测试，我尝试在两个 T1 端口之间进行直接环回 (T1-1<-> T1-2) 之间的直接环回，方法是连接：（TRX_1_P<->TRX_2_P 和 TRX_2_P<->TRX_2_N ）。 SJA1110 BASE-T1 PHY 是否需要为链路训练进行明确的主/从配置？ 8: rj45@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff inet6 fe80::5c78:8fff:fe24:8653/64 scope link proto kernel_ll valid_lft forever preferred_lft forever 11: t1-1@eth0: mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global t1-1 valid_lft forever preferred_lft forever 12: t1-2@eth0: mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff inet 192.168.10.2/24 scope global t1-2 valid_lft forever preferred_lft forever [ 133.739306] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 133.739364] MACB : HWSTAMP check running [ 133.739414] MACB : HWSTAMP check passed found tsu_clk [ 133.741036] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. [ 133.742794] sja1105 spi9.0 t1-1: configuring for phy/internal link mode [ 149.008075] sja1105 spi9.0 t1-2: configuring for phy/internal link mode [ 543.849763] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 545.889486] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off   硬件表带配置： 全部 PHY_MS引脚均为低电平（从属模式）。 PHY_AUTO_MODE= 高 AUTO_POL_DET= 高电平 PHY 地址从 0x09. 没有 T1 链路的原因会不会是两个 PHY 都绑定为 SLAVE，因此没有用于链路训练的主时钟源？ 有关以下方面的任何指导： 正确的 T1 启动、 主/从配置、 或预期 PHY 驱动程序支持 将不胜感激。 这是用于以太网交换机的 DTSI。 /* MAC0 : DSA master into SJA1110A SGMII4 */ &mac0 { /delete-property/ phy-handle; clocks = <&clkcfg CLK_MAC0>, <&clkcfg CLK_AHB>, <&fabric_fic3_clk>; clock-names = "pclk", "hclk", "tsu_clk"; phy-mode = "sgmii"; status = "okay"; dma-noncoherent; fixed-link { speed = <1000>; full-duplex; }; }; /* * SPI9: SJA1110A Host Access Port (HAP) * CS0 (reg=0) -> SS0_N -> Switch AP endpoint (DSA driver) * CS1 (reg=1) -> SS1_N -> Cortex-M7 uC endpoint (unused) * * BOOT_OPTION=11 (serial SPI boot): * SJA1110A waits for host config at power-on. * DSA driver sends static config tables at probe via CS0. * Cortex-M7 is disabled by driver : CS1/SS1 never used. * * SPI mode: CPOL=1 CPHA=0 (mode 2) : as per sja1105.yaml * SPI mode: CPOL=1 CPHA=1 (mode 3) : as per s32gxxxa-rdb.dtsi */ &spi9 { microchip,motorola-mode = <3>; /* mode 3: CPOL=1 CPHA=1 */ num-cs = <2>; status = "okay"; /* * SJA1110A : DSA switch (mainline driver) * reg=0 -> CS0 -> SS0_N -> switch AP endpoint * ethernet-switch@0 uses reg=<0> (SS0 = switch AP) * sja1110-uc@1 uses reg=<1> (SS1 = uC, disabled here) * * Port map * port@0 RevMII Cortex-M7 uC (disabled by driver) * port@1 100BASE-TX RJ45 diagnostic jack * port@2 RGMII2 inter-switch trunk -> SJA port2 * port@3 SGMII3 EPC-2 MAC1 relay uplink * port@4 SGMII4 EPC-1 MAC0 CPU port (this board) * Confirm is actual physical address needs to be added here * port@5 100BASE-T1 TRX_1 (PHY addr 9 on mdio@0) * port@6 100BASE-T1 TRX_2 (PHY addr 10 on mdio@0) * port@7 100BASE-T1 TRX_3 (PHY addr 11 on mdio@0) * port@8 100BASE-T1 TRX_4 (PHY addr 12 on mdio@0) * port@9 100BASE-T1 TRX_5 (PHY addr 13 on mdio@0) * port@a 100BASE-T1 TRX_6 (PHY addr 14 on mdio@0) */ sja1110a: ethernet-switch@0 { compatible = "nxp,sja1110a"; reg = <0>; spi-max-frequency = <1000000>; interrupt-parent = <&gpio8>; interrupts = <9 IRQ_TYPE_LEVEL_LOW>; mdios { #address-cells = <1>; #size-cells = <0>; mdio_t1: mdio@0 { compatible = "nxp,sja1110-base-t1-mdio"; reg = <0>; #address-cells = <1>; #size-cells = <0>; port5_base_t1_phy: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x01>; }; port6_base_t1_phy: ethernet-phy@2 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x02>; }; port7_base_t1_phy: ethernet-phy@3 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x03>; }; port8_base_t1_phy: ethernet-phy@4 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x04>; }; port9_base_t1_phy: ethernet-phy@5 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x05>; }; port10_base_t1_phy: ethernet-phy@6 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x06>; }; }; mdio_tx: mdio@1 { compatible = "nxp,sja1110-base-tx-mdio"; reg = <1>; #address-cells = <1>; #size-cells = <0>; txphy1: ethernet-phy@1 { reg = <1>; }; }; }; ethernet-ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; status = "disabled"; }; /* ------------------------------------- * RJ45 diagnostic port * ------------------------------------- */ port@1 { reg = <1>; label = "rj45"; phy-mode = "internal"; phy-handle = <&txphy1>; }; port@2 { reg = <2>; label = "interswitch"; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; port@3 { reg = <3>; label = "epc2-uplink"; phy-mode = "sgmii"; fixed-link { speed = <1000>; full-duplex; }; }; /* ------------------------------------- * CPU port * MAC0 <-> SGMII4 <-> port4 * ------------------------------------- */ port@4 { reg = <4>; label = "cpu"; ethernet = <&mac0>; phy-mode = "sgmii"; fixed-link { speed = <1000>; full-duplex; }; }; port@5 { reg = <5>; label = "t1-1"; phy-mode = "internal"; phy-handle = <&port5_base_t1_phy>; }; port@6 { reg = <6>; label = "t1-2"; phy-mode = "internal"; phy-handle = <&port6_base_t1_phy>; }; port@7 { reg = <7>; label = "t1-3"; phy-mode = "internal"; phy-handle = <&port7_base_t1_phy>; }; port@8 { reg = <8>; label = "t1-4"; phy-mode = "internal"; phy-handle = <&port8_base_t1_phy>; }; port@9 { reg = <9>; label = "t1-5"; phy-mode = "internal"; phy-handle = <&port9_base_t1_phy>; }; port@a { reg = <10>; label = "t1-6"; phy-mode = "internal"; phy-handle = <&port10_base_t1_phy>; }; }; }; /* SPIDEV for testing SPI lines using CS1 lines*/ sja110_spidev: spidev@1 { compatible = "microchip,mpfs-spidev"; reg = <1>; status = "okay"; spi-max-frequency = <1000000>; }; }; -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 感谢您一次性分享所有细节。 请在下面找到您问题的答案。 Q1.要使 TX 流量在 SJA1110 DSA 端口上正常工作，是否需要任何额外的运行时 MAC 配置/转发/路由表设置？ A1.是的，请见下文。 Q2.100BASE-T1 PHY 在此驱动程序树中是否只能作为通用第 45 条 PHY 出现？当前的 Linux 6.12 Microchip 树中是否缺少专用 BASE-T1 PHY 驱动程序？ A2.A2. Q3.为进行测试，我尝试在两个 T1 端口（t1-1<-> t1-2）之间直接环回，方法是连接：（TRX_1_P<->TRX_2_P 和 TRX_2_P<->TRX_2_N ）。 A3：是的，没错。 Q4.SJA1110 BASE-T1 PHY 是否需要为链路训练进行明确的主/从配置？ A4.是的，100BASE-T1 需要明确的主/从设置。仅供参考，驱动器中的"AUTO" 选项通常意味着"按照引脚捆绑" 。 要实现有效链接，必须通过硬件捆绑或 PHY 配置，将一个 PHY 配置为 MASTER（主设备），另一个 PHY 配置为 SLAVE（从设备）。 根据日志和 DT，交换机初始化和 PHY 绑定看起来是正确的。 如果 Linux 中没有配置网桥，就会出现 RX 可以工作而 TX 不能工作的情况。在 DSA 中，CPU 端口和用户端口之间不会自动转发流量。 DSA 交换机的行为类似于硬件交换机，但除非显式创建了网桥或 VLAN 配置，否则 Linux 不会在端口之间启用转发功能。 请创建一个网桥，同时连接 CPU 端口（eth0）和用户端口（rj45）： ip link set eth0 up ip link set rj45 up ip link add br0 type bridge ip link set br0 up ip link set eth0 master br0 ip link set rj45 master br0 ip addr add 192.168.1.2/24dev br0 顺祝商祺！ 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 您好， 我试过做同样的事情，但仍然没有看到笔记本电脑从 板上收到任何数据包。以下是我遵循的具体步骤： ------------------- ip link set eth0 up ip link set rj45 up ip link add br0 type bridge ip link set br0 type bridge ip link set br0 up ip link set rj45 master br0 ip addr add 192.168.1.1/24dev br0 ping 192.168.1.2 ------------------- 为了提供更多信息：RJ45 连接器已返工，芯片 TX 对的 P/N 端口与 RJ45 连接错误，这也可能是造成问题的原因。但是，链接总是会出现。 有什么我遗漏的吗？我附上了与 ETH 和 PHY 相关的内核配置。请检查是否有遗漏。 # ------------------------------ # Networking / HSR / QoS / PTP # ------------------------------ CONFIG_HSR=y CONFIG_PTP_1588_CLOCK=y CONFIG_POSIX_TIMERS=y CONFIG_BONDING=y CONFIG_NET_SCHED=y CONFIG_NET_SCH_FIFO=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_FQ_CODEL=y CONFIG_NET_SCH_MQPRIO=y CONFIG_NET_SCH_ETF=y CONFIG_NET_SCH_TAPRIO=y CONFIG_NET_CLS=y CONFIG_NET_CLS_U32=y CONFIG_NET_ACT_MIRRED=y CONFIG_MACB_USE_HWSTAMP=y CONFIG_NETWORK_PHY_TIMESTAMPING=y # ----------------------------- # SJA1110 Ethernet Switch support # ----------------------------- CONFIG_PHYLINK=y CONFIG_PCS_MARVELL=y CONFIG_SWPHY=y CONFIG_BRIDGE_VLAN_FILTERING=y CONFIG_VLAN_8021Q=y CONFIG_NET_DSA=y CONFIG_NET_DSA_TAG_8021Q=y CONFIG_NET_DSA_SJA1105=y CONFIG_NET_DSA_SJA1105_PTP=y CONFIG_NET_DSA_SJA1105_TAS=y CONFIG_NET_SWITCHDEV=y CONFIG_NET_DSA_TAG_OCELOT_8021Q=y CONFIG_MDIO_BUS=y CONFIG_MDIO_DEVICE=y CONFIG_NET_SCH_CBS=y CONFIG_BRIDGE=y CONFIG_OF_MDIO=y CONFIG_MDIO_DEVRES=y CONFIG_NET_DSA_SJA1105_VL=y CONFIG_PHYLIB_10G=y # ----------------------------- # PHY support for direct ETH link (MAC0 - OBC) # Fixed link - no PHY driver needed for MAC0 # MAC1 - SJA1110 also uses fixed link to switch CPU port # ----------------------------- CONFIG_FIXED_PHY=y CONFIG_PHYLIB=y CONFIG_NXP_CBTX_PHY=y CONFIG_NXP_C45_TJA11XX_PHY=y CONFIG_NXP_TJA11XX_PHY=y CONFIG_MARVELL_88Q2XXX_PHY=y CONFIG_AQUANTIA_PHY=y CONFIG_MICREL_PHY=y 我还尝试用 T1-1 和 T1-2 进行 100BASE-T1 环回，将 T1-1 设置为 PHY_MS = 1（主站），T1-2 设置为 PHY_MS = 0（从站）。我调出了两个界面，但链接始终没有出现。这在意料之中吗？我错过了什么？环回是双绞线（P/N）上的简单有线连接。 ------------------- ip link set eth0 up ip link set rj45 up ip link set t1-1 up ip link set t1-2 up ------------------- Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 不知怎么的，你漏了一行： ip link set eth0 up ip link set rj45 up   ip link add br0 type bridge ip link set br0 up   ip link set eth0 master br0 ip link set rj45 master br0   ip addr add 192.168.1.1/24开发周期 内核配置似乎正确。 关于 T1 100BASE-T1 的简单布线连接应该可以正常工作，我一直使用这种连接方式。是否使用 PHY_ADDR* 引脚绑扎？ 请分享： ethtool t1-1 ethtool t1-2 dmesg | grep -iE"t1-|phy|sja1105" 在链接启动之后 顺祝商祺！ 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@PavelL, 感谢您的回答。 将 eth0 连接到 br0 后，当尝试连接 rj45 时，我看到如下错误。 # ip link set eth0 up [ 20.561460] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 20.561554] MACB : HWSTAMP check running # [ 20.561605] MACB : HWSTAMP check passed found tsu_clk [ 20.562612] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. ip link set rj45 up # [ 25.693665] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 27.746002] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off # ip link add br0 type bridge # ip link set br0 up # ip link set eth0 master br0 # [ 43.053547] br0: port 1(eth0) entered blocking state [ 43.053590] br0: port 1(eth0) entered disabled state [ 43.053666] macb 20110000.ethernet eth0: entered allmulticast mode ip link set rj45 master br0 [ 49.972011] br0: port 2(rj45) entered blocking state [ 49.972214] br0: port 2(rj45) entered disabled state [ 49.972288] sja1105 spi9.0 rj45: entered allmulticast mode RTNETLINK answer[ 50.005003] sja1105 spi9.0 rj45: left allmulticast mode s: Invalid argument 关于 T1 端口，请参见以下答复 # ip link set eth0 up [ 305.486294] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 305.486405] MACB : HWSTAMP check running [ 305.486456] MACB : HWSTAMP check passed found tsu_clk [ 305.487476] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. # ip link set rj45 up # [ 311.277622] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 313.313486] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off # ip link set t1-1 up # [ 326.282210] sja1105 spi9.0 t1-1: configuring for phy/internal link mode # ip link set t1-2 up [ 330.126681] sja1105 spi9.0 t1-2: configuring for phy/internal link mode # ethtool t1-1 Settings for t1-1: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Link detected: no # ethtool t1-2 Settings for t1-2: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Duplex: Full Port: MII PHYAD: 2 Transceiver: external Auto-negotiation: off Wake-on: d Link detected: no # [ 365.547745] power_supply bq34z100-0: driver failed to report `time_to_empty_avg' property: -22 dmesg | grep -iE "t1-|phy|sja1105" [ 2.250188] u-dma-buf udmabuf-ddr-c0: phys address = 0x0000000088000000 [ 2.995658] u-dma-buf udmabuf-ddr-nc0: phys address = 0x00000000c8000000 [ 3.012712] u-dma-buf udmabuf-ddr-nc-wcb0: phys address = 0x00000000d8000000 [ 3.081775] sja1105 spi9.0: Probed switch chip: SJA1110A [ 3.081796] sja1105 spi9.0: max_xfer_len = 256 bytes [ 3.233399] sja1105 spi9.0: Probed switch chip: SJA1110A [ 3.233418] sja1105 spi9.0: max_xfer_len = 256 bytes [ 3.236047] sja1105 spi9.0: Config buffer length: 1776 bytes [ 3.236072] sja1105 spi9.0: Config buffer device_id at offset 0: 0x0f0300b7 [ 3.429135] sja1105 status decoded: CONFIGS=1 CRCCHKL=0 IDS=0 CRCCHKG=0 NSLOT=5 [ 3.429165] sja1105 spi9.0: sja1105_static_config_load done [ 3.429181] sja1105 spi9.0: sja1105_clocking done [ 3.429194] sja1105 spi9.0: sja1105_TAS and flower setup done [ 3.430339] sja1105 spi9.0: sja1105_ptp_clock_register done [ 3.572901] sja1105 spi9.0: sja1105_mdiobus_register done [ 3.572938] sja1105 spi9.0: sja1105_devlink_setup done [ 3.586915] sja1105 spi9.0: dsa_tag_8021q_register and rtnl_unlockdone [ 3.588440] sja1105 spi9.0: configuring for fixed/sgmii link mode [ 3.593936] sja1105 spi9.0: Link is Up - 1Gbps/Full - flow control off [ 3.652480] sja1105 spi9.0 rj45 (uninitialized): PHY [spi9.0-base-tx:01] driver [NXP CBTX (SJA1110)] (irq=POLL) [ 3.661033] sja1105 spi9.0 t1-1 (uninitialized): PHY [spi9.0-base-t1:01] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.664058] sja1105 spi9.0 t1-2 (uninitialized): PHY [spi9.0-base-t1:02] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.667342] sja1105 spi9.0 t1-3 (uninitialized): PHY [spi9.0-base-t1:03] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.670592] sja1105 spi9.0 t1-4 (uninitialized): PHY [spi9.0-base-t1:04] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.673818] sja1105 spi9.0 t1-5 (uninitialized): PHY [spi9.0-base-t1:05] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.676972] sja1105 spi9.0 t1-6 (uninitialized): PHY [spi9.0-base-t1:06] driver [Generic Clause 45 PHY] (irq=POLL) [ 311.277622] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 313.313486] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off [ 326.282210] sja1105 spi9.0 t1-1: configuring for phy/internal link mode [ 330.126681] sja1105 spi9.0 t1-2: configuring for phy/internal link mode 是的，我确实使用了 PHY_ADDR 带，PHY_ADDR[4:0] 设置为 5'b010001。( 0x09 至 0x14 ) 与https://github.com/nxp-auto-linux/linux/blob/810f396375526c11989bd1a296d2f9959de9392f/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi#L141和 S32G-VNP-RDB3 原理图相同。 -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 感谢您的更新 - 目前，我认为我们最好从头开始调试，使用最小的确定性设置，因为我们现在有几个相互影响的变量（DSA 拓扑、网桥行为和 PHY 访问路径），我们需要隔离 RJ45 问题是软件（Linux/DSA/网桥/VLAN）问题还是硬件（TX 对/磁性元件）问题。 从你最初的描述中，我们可以看出一个清晰的症状模式： RJ45 RX 正常工作（可以看到来自笔记本电脑的 ARP 请求）。 RJ45 TX 不能（笔记本电脑看不到板上的任何框架）。 100BASE‑T1 仍处于关闭状态，目前我们没有足够的证据来得出结论，这是否与配置/管理路径有关，还是与物理层/训练问题有关。 这是第一步： 第 1 步 - 在不使用任何桥接器的情况下确认 RJ45 上的基本 TX ip link set eth0 up ip link set rj45 up   # 重要：移除其他设备上的 IP 以避免混乱路由 ip addr flush dev eth0 IP 地址 flush dev rj45 IP 地址 flush dev br0 2>/dev/null   # 将 IP 直接接入 RJ45 DSA 端口 ip addr add 192.168.1.1/24dev rj45   # 显示路由和地址以保持理智 ip addr show rj45 ip route show   # 产生流量 arping -I rj45 192.168.1.2 ping -I rj45 192.168.1.2 同时，在板上捕获 tcpdump -i rj45 -e -nn arp 或 icmp 笔记本电脑 tcpdump -i -e -nn arp 或 icmp 顺祝商祺！ 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好， ，我还发现 eth0 链接没有显示 RUNNING，这会是问题之一吗？在进行 PING 时，RJ45 的 txbytes 会增加，但 eth0 发送的所有信息都会被丢弃。 eth0 Link encap:Ethernet HWaddr 92:56:D3:62:3D:60 UP BROADCAST MULTICAST MTU:1536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:10 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:33 rj45 Link encap:Ethernet HWaddr 92:56:D3:62:3D:60 inet6 addr: fe80::9056:d3ff:fe62:3d60/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:796 (796.0 B) # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever 2: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ee:06:ea:10:7f:d4 brd ff:ff:ff:ff:ff:ff 3: can0: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 4: can1: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 5: eth0: mtu 1536 qdisc mq state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 6: eth1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:04:a3:61:cc:6f brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: rj45@eth0: mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff inet6 fe80::9056:d3ff:fe62:3d60/64 scope link proto kernel_ll valid_lft forever preferred_lft forever 9: interswitch@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 10: epc2-uplink@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 11: t1-1@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 12: t1-2@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 13: t1-3@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 14: t1-4@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 15: t1-5@eth0: mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 16: t1-6@eth0: mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 17: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::9056:d3ff:fe62:3d60/64 scope link proto kernel_ll valid_lft forever preferred_lft forever -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 您好 1.)我尝试了同样的测试，还检查了其他一些东西来验证问题。CPU 端口 (p04) 和 RJ45 之间似乎没有编程 L2 转发路径。 以下是整个日志 ////////////////// AFTER BOOT ////////////////// # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 0 p04_n_txbyte: 0 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 0 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 0 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 0 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 # ethtool -S rj45 NIC statistics: tx_packets: 0 tx_bytes: 0 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 ////////////////// Link UP ////////////////// # ip link set eth0 up [ 69.576075] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 69.576204] MACB : HWSTAMP check running # [ 69.576257] MACB : HWSTAMP check passed found tsu_clk [ 69.577736] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. # ip link set rj45 up # [ 73.786469] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 75.841723] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off # ip addr add 192.168.1.1/24 dev rj45 # ip link set rj45 up # ip addr show rj45 8: rj45@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 scope global rj45 valid_lft forever preferred_lft forever inet6 fe80::e4e8:aeff:fe30:6b84/64 scope link proto kernel_ll valid_lft forever preferred_lft forever # ethtool -S rj45 NIC statistics: tx_packets: 10 tx_bytes: 796 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 8 n_rxbyte: 1690 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 8 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 2 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 6 n_rx_mcast: 8 # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 8 p04_n_txbyte: 1722 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 2 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 6 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 8 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 ////////////////// PING BOARD TO Laptop ////////////////// # arping -I rj45 192.168.1.2 ARPING 192.168.1.2 from 192.168.1.1 rj45 ^CSent 9 probe(s) (9 broadcast(s)) Received 0 response(s) (0 request(s), 0 broadcast(s)) # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 8 p04_n_txbyte: 1722 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 2 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 6 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 8 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 # ping -I rj45 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes ^C --- 192.168.1.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 8 p04_n_txbyte: 1722 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 2 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 6 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 8 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 # ethtool -S rj45 NIC statistics: tx_packets: 26 tx_bytes: 1496 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 9 n_rxbyte: 1781 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 9 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 2 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 1 n_rx_bytes_64: 6 n_rx_mcast: 9 ////////////////// PING Laptop TO Board ////////////////// # ethtool -S rj45 NIC statistics: tx_packets: 26 tx_bytes: 1496 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 15 n_rxbyte: 2165 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 9 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 2 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 1 n_rx_bytes_64: 12 n_rx_mcast: 9 2.)在 T1 端口上，我检查错了 T1 端口；T1 端口环回上也出现了链接，但 ping 却无法正常工作。 同样的日志。 ======================================== SJA1110 T1 Loopback Test Thu Jan 1 00:03:16 UTC 1970 ======================================== === Bring Interfaces Up === === Configure IP Addresses === 15: t1-5@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global t1-5 valid_lft forever preferred_lft forever 16: t1-6@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff inet 192.168.10.2/24 scope global t1-6 valid_lft forever preferred_lft forever === Link Status === Settings for t1-5: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 5 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Link detected: yes Settings for t1-6: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 6 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Link detected: yes === VLAN Configuration === port vlan-id === FDB Before Traffic === 33:33:00:00:00:01 dev bond0 self permanent 33:33:00:00:00:01 dev eth0 self permanent 01:00:5e:00:00:01 dev eth0 self permanent 33:33:00:00:00:01 dev eth1 self permanent === Interface Counters BEFORE === 5: eth0: mtu 1536 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 16 0 0 15: t1-5@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 696 8 0 0 0 0 16: t1-6@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 696 8 0 0 0 0 === Ethtool Stats BEFORE === NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 0 p04_n_txbyte: 0 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 0 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 0 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 0 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 NIC statistics: tx_packets: 8 tx_bytes: 696 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 NIC statistics: tx_packets: 8 tx_bytes: 696 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 === ARP Test === ARPING 192.168.10.2 from 192.168.10.1 t1-5 Sent 10 probe(s) (0 broadcast(s)) Received 0 response(s) (0 request(s), 0 broadcast(s)) === Neighbor Table === === Interface Counters AFTER === 5: eth0: mtu 1536 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 26 0 0 15: t1-5@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 1116 18 0 0 0 0 16: t1-6@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 696 8 0 0 0 0 === Ethtool Stats AFTER === NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 0 p04_n_txbyte: 0 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 0 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 0 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 0 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 NIC statistics: tx_packets: 18 tx_bytes: 1116 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 NIC statistics: tx_packets: 8 tx_bytes: 696 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 === FDB After Traffic === 33:33:00:00:00:01 dev bond0 self permanent 33:33:00:00:00:01 dev eth0 self permanent 01:00:5e:00:00:01 dev eth0 self permanent 33:33:00:00:00:01 dev eth1 self permanent === Dmesg Link Events === [ 3.602806] sja1105 spi9.0: Link is Up - 1Gbps/Full - flow control off [ 3.678860] sja1105 spi9.0 t1-5 (uninitialized): PHY [spi9.0-base-t1:05] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.682052] sja1105 spi9.0 t1-6 (uninitialized): PHY [spi9.0-base-t1:06] driver [Generic Clause 45 PHY] (irq=POLL) [ 196.222060] sja1105 spi9.0 t1-5: configuring for phy/internal link mode [ 196.224821] sja1105 spi9.0 t1-5: Link is Up - 100Mbps/Full - flow control off [ 196.229425] sja1105 spi9.0 t1-6: configuring for phy/internal link mode [ 196.231212] sja1105 spi9.0 t1-6: Link is Up - 100Mbps/Full - flow control off Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好 @PavelL 即使在网桥创建之后，我也看到没有字节离开交换机。 # ip link set eth0 up [ 78.263728] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 78.263859] MACB : HWSTAMP check running # [ 78.263911] MACB : HWSTAMP check passed found tsu_clk [ 78.265094] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. ip addr flush dev rj45 # ip link add name br0 type bridge # ip link set br0 type bridge vlan_filtering 0 # ip link set rj45 master br0 [ 119.331341] br0: port 1(rj45) entered blocking state [ 119.331506] br0: port 1(rj45) entered disabled state [ 119.331588] sja1105 spi9.0 rj45: entered allmulticast mode # [ 119.331615] macb 20110000.ethernet eth0: entered allmulticast mode [ 119.339852] sja1105 spi9.0 rj45: entered promiscuous mode ip addr add 192.168.1.1/24 dev br0 # ip link set rj45 up # [ 130.485390] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 132.518207] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off ip link set br0 up # [ 137.057392] br0: port 1(rj45) entered blocking state [ 137.057430] br0: port 1(rj45) entered forwarding state # ethtool -S rj45 | grep -E "n_txfrm|n_rxfrm|n_not_reach" n_rxfrm: 7 n_txfrm: 0 n_not_reach: 7 # ping -c 5 -I br0 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes --- 192.168.1.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss # ethtool -S rj45 | grep -E "n_txfrm|n_rxfrm|n_not_reach" n_rxfrm: 14 n_txfrm: 0 n_not_reach: 14 这是配置问题吗？ -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 感谢您提供的详细日志。请随时纠正我的解释。 您的最新结果非常有用，因为它们表明这很可能不再是一个单纯的桥梁问题。 对于 RJ45 直接 L3 测试（IP 直接分配到 rj45，无网桥），Linux netdev TX 计数器会增加，但 RJ45 端口的硬件交换机出口计数器仍为 0（`n_txfrm = 0`，`n_txbyte = 0`）。同时，RJ45 上的入口计数器也会增加，这表明前端 PHY/链路正在正确接收帧。 T1 回环结果也指向同一方向：两个 T1 端口都成功链接，因此 PHY 培训本身似乎有效，但流量仍无法通过。 这两种情况的共同点是 CPU/主控路径： - `eth0` 保持 `NO-CARRIER` - `eth0` 保持 `state DOWN` - MACB TX/RX 硬件计数器保持为 0 - `eth0` 的 TX 丢弃数据包增加 由此看来，主要问题是 SoC MAC (`eth0`)和 SJA1110 CPU 端口 (p04) 之间的 CPU 导管路径，而不是前 RJ45 或 T1 PHY 端口本身。 换句话说，交换机侧端口可以启动，但面向主机的 SGMII/CPU 端口数据路径似乎无法运行。 在现阶段，我建议将重点放在 SoC MAC / PCS / SGMII 的 "eth0 "配置以及相应的 CPU 端口配置上，而不是进一步进行桥接实验。 请分享： 1. ethtool eth0 2. ip-d link show eth0 3. 连接到交换机 CPU 端口的 SoC MAC/PCS/SGMII 端的完整设备树片段 4. SoC 端任何可用的 PCS/SGMII 链接状态信息 eth0` 从未达到 RUNNING / carrier-up（运行/载波启动）是一个强有力的指标，很可能与流量故障有关。 我再次查看了你的 DT 片段，设备树的 DSA/SJA1110 部分在逻辑上看起来是一致的： -MAC0 配置为 “sgmii”，具有固定的 1 Gbps 全双工链路-SJA1110 CPU 端口也被配置为 “sgmii”，带有固定的 1 Gbps 全双工链路 ——内部 PHY 端口映射看起来也正确 因此，目前我看不出这个片段本身存在明显的 DSA DT 错误。 然而，仅凭这个 DT 片段并不能证明 SoC 端 SGMII/PCS/SerDes 通路确实在运行。根据您的计数器，交换机 CPU 端口在交换机一侧似乎处于活动状态，但 `eth0` 仍处于 `NO-CARRIER` / DOWN 状态，没有真正的 MAC RX/TX 流量。 这表明面向 SoC 的 SGMII/PCS/SerDes 路径（或其低级初始化）存在问题，而不是前面的 RJ45 或 T1 端口。 能否请您分享完整的 MAC0 / PCS / SerDes 相关配置，以及初始化 SGMII 通道的任何引导加载程序/底层配置？ 顺祝商祺！ 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@PavelL 是的，在仔细查看原理图后，我发现从 SoC 到交换机的 SGMII TX P/N 线路被调换了。此外，相同的 SGMII 线路连接到了另一个端点，导致以太网链路无法连接。 我们目前正在修复这些问题，并将向您提供最新结果。 -- 安库尔

TJA1055/3 FT canbus 为了将带有 twai 的 ESP32-P4 连接到容错 canbus 系统，我已经苦恼了一段时间。TJA1055/3 已安装在试验板上并连接起来，我可以测量芯片的 Rx 输出，该输出本应发送到 ESPGPIO，但是看来这个电压输出在 HI 上达到大约 3.2V，LO的电压输出仅达到大约 1.8V，ESP32 GPIO 的 LO 需要看到 0.8V，因此无法解码这些脉冲和读取接收到的数据。我试过在 TJA1055 的 Rx 输出上使用不同大小的上拉电阻，但效果甚微。我还试过改变针脚 8 和针脚 9 与 CAN H 和 CAN L 信号之间的终端电阻，也有一些效果，但还不够。有谁能告诉我如何从芯片中获取可用信号，或者我是否需要在 TJA1055 和 ESP GPIO 之间添加额外的信号调节器？ Re: TJA1055/3 FT canbus 你好，唐纳德-皮特 日安 如下图所示，您可以通过减少 Iol 来降低 Vol 值。 您在 Iol 有什么职位？ 如果需要保持相同的电流且无法降低电流，我建议添加一个 MOSFET 晶体管作为缓冲器，选择最适合您需求的晶体管。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你愉快，好运连连。 Re: TJA1055/3 FT canbus 感谢您的宝贵意见，我将在未来几天内尝试这样做，并向您汇报。我们已经决定使用施密特触发器来调整输出以使其适应需求，但是如果我可以在不添加其他元器件的情况下获得 ESP32 GPIO 的正确输出，那么我会张开双臂拥抱它。我不是电子工程师，而是自动化专家，所以虽然我了解这些事情，但我通常不明白为什么，而且如果文件没有 "一勺烩"，我就会迷失方向。 Re: TJA1055/3 FT canbus 你好，拉法 我对您的建议的理解是否正确？ 谢谢！ 唐纳德-P Re: TJA1055/3 FT canbus 你好，唐纳德-皮特 日安 是的，您的电路图似乎是正确的。试试看，然后告诉我你的结果。 另外需要注意的是：你在 RTH 和 RTL 上的电阻值有点高，但如果这样就能工作，那就继续吧。如果总线上有任何损耗，请尝试降低电阻。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你愉快，好运连连。 Re: TJA1055/3 FT canbus 你好，拉法 所以我又对它进行了基准测试，并背靠背使用了两个 TJA1055/3 芯片，效果非常好，当我回到车辆上时，这个电路中内置的收发器关闭了 Can L 并杀死了所有导致总线故障的脉冲，这促使我再次检查了你对终止电阻器主题和规格表的回应，在那里我发现推荐的尺寸介于 500 到 16K 欧姆之间，但你建议使用 100 欧姆 m 可能太大了，相信那是手指错误，因为规格表中显示的更大的电阻器对我来说是合理的对外部 canbus 段的影响较小。我今天将进行试验，看看结果如何，但希望您能就此发表意见，以防其他地方的其他人也像我一样在考虑这种对话和战斗。 此致问候 唐纳德-P

SE051 OpenSSL 3.0 プロバイダを Node.js で使用する / URI と参照 PEM の受け渡し (チケットのフォローアップ) NXPサポートチームの皆様、こんにちは。 以前のスレッドで提起された同様の問題についてフォローアップしています。https ://community.nxp.com/t5/Secure-Authentication/OpenSSL-doesn-t-handle-refpem-key-correctly-nxp-scheme-is/mp/1866179 そのチケットで、 @Kan_Li は@tksecに .refpem について説明しました。このキーフォーマットは、主に従来のOpenSSLエンジンで使用されます。しかし、OpenSSL 3.0プロバイダーとNode.jsの統合に関する疑問は未解決のままだった。 当社は、#SE051セキュアエレメントを使用したiWaveボード上で開発を行っています。私たちは、Node.jsアプリケーションと最新のOpenSSLプロバイダーを使用して、mTLS（クライアント認証）接続を確立しようとしています。 私たちの環境： セキュアエレメント： SE051バリアントC ミドルウェア／SDK： Plug & Trust MW v4.7.1 ハードウェアプロトコル：バージョン7（SCP03有効） Node.js バージョン: v16.11.1 OpenSSL バージョン: 3.0.x OpenSSL 3.0ではエンジンが非推奨になったため、最新のse05x OpenSSLプロバイダ（libsssProvider.so）を使用する必要があります。従来のe_sssエンジンの代わりに。 根本的な問題:前のスレッドで@tksec が指摘したように、Node.js アプリケーションは PEM_read_bio_PrivateKey のような関数を使用しますが、これらの関数は厳密に標準の PEM 形式の文字列/バッファを期待しています。 最新の OpenSSL 3.0 sssProvider では、キーをダイレクト プロバイダー URI (例: "nxp:0x7D000002" または "nxp:/path/to/tls_client_key_ref.pem") として渡す必要があります。 このURIをNode.jsのhttps.Agentに渡そうとすると、TLSハンドシェイクが始まる前にアプリケーションがクラッシュします。 JavaScript   const https = require('https'); const agent = new https.Agent({ cert: fs.readFileSync('device_cert.pem'), key: "nxp:0x7D000002", // Fails: Node.js expects a raw PEM buffer here rejectUnauthorized: true }); // Error: ERR_OSSL_PEM_NO_START_LINE Node.jsは、キーパラメータをOpenSSLに渡す前に検証します。「nxp:」には -----BEGIN PRIVATE KEY----- ヘッダーがないため、すぐに処理が中断されます。 私たちの質問： Node.jsをアップデート（例えば、OpenSSL 3.0をネイティブに統合したv18/v20にアップデート）すれば、このURI解析の問題は自動的に解決されるのでしょうか？それとも、NodeのTLSレイヤーは依然としてプロバイダURIを拒否するのでしょうか？ この問題を解決するには、NXPプロバイダーの設定を変更する必要がありますか？プロバイダーコードを改善して、従来の.refpemファイルを解析できるようにするための計画や既存の解決策はありますか？ファイルを直接ダウンロードしますか？Node.jsのような高水準言語がダミーのPEMバッファを渡すことを許可すれば、URIクラッシュの問題を完全に回避できるだろう。 お時間とご指導をいただき、ありがとうございました。 オートモーティブ スマートカード スマート・カード Re: Using SE051 OpenSSL 3.0 Provider with Node.js / Passing URIs vs Reference PEMs (Follow-up to Tic v20のリリースノート/変更履歴を見る限り、node.jsはまだOpenSSL 3.0プロバイダーをサポートしていないようです。彼らは現在、ドキュメントでエンジンコンセプトに依存していることを明確にしています（ https://github.com/nodejs/node/pull/53329/changes ）。 当時、私は最終的にnode.jsにキーIDをサポートするパッチを適用することになりました。主にOSSL_STORE API（ https://docs.openssl.org/3.0/man7/ossl_store/ ）を使用することで実現します。https://github.com/nodejs/node/blob/3b19867caaef6b85c65e44dc60274dce2b240d22/src/crypto/crypto_context.cc#L1699の PEM 関数の代わりに。これにより、あらゆる種類のキーを読み込むことが可能になった。 もちろん、データ型などを一致させるために、呼び出し元や設定構造体にもいくつかの変更が必要でした。

使用 SE052F 的 RNG OpenSSL 提供程序 我们需要使用 SE052F 作为符合 FIPS 标准的随机数生成源。我们要求 OpenSSL 使用 SE052F，进而要求所有使用 openssl 库的应用程序使用 SE052F 作为 RNG。 我知道我们必须使用 NXP MW accessManager 和 OpenSSL Provider。 我正在使用SE-PLUG-TRUST-MW_04.07.01 我已按照以下说明进行操作： AN14028.pdf SE-PLUG-TRUST-MW_04.07.01/simw-top/doc/hostlib/hostLib/accessManager/doc/accessManager.html and the README info here (but not using this 仓库): https://github.com/NXPPlugNTrust/se05x-openssl-provider AccessManager 使用以下 cmake 选项构建： NXP_SE_MW_CONF_OPTS += -DWithSharedLIB=OFF -DPTMW_Host=Raspbian -DPTMW_SMCOM=T1oI2C -DPTMW_Applet=SE05X_C \ -DPTMW_FIPS=None -DPTMW_SE05X_Ver=07_02 -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_SCP=SCP03_SSS -DSE05X_EN_PIN=582 -DSE_RESET_LOGIC=0 \ -DPAHO_BUILD_SHARED=FALSE -DPAHO_BUILD_STATIC=TRUE 使用以下 cmake 选项构建的 OpenSSL 提供商： NXP_SE_MW2_CONF_OPTS += -DWithSharedLIB=ON -DPTMW_HostCrypto=OPENSSL -DPTMW_Host=Raspbian -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_SE05X_Auth=None openssl.cnf 修改如下： [provider_sect] nxp_prov = nxp_sect default = default_sect [nxp_sect] identity = nxp_prov module = /usr/lib/libsssProvider.so activate = 1 [default_sect] activate = 1 访问管理器启动： Starting accessManager (Rev.1.1). Protect Link between accessManager and SE: YES. accessManager JRCPv1 (T1oI2C SE side) ****************************************************************************** Server: waiting for connections on port 8040. Server: only localhost based processes can connect. 从命令行使用 openssl 的 RNG 似乎运行正常： # openssl rand -hex 64 sssprov-dbg: Enter - OSSL_provider_init App :INFO :Using PortName='127.0.0.1:8040' (gszSocketPortDefault) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. New client connection from 127.0.0.1. Client ID: 5 Command 0x00 from client 5 DUMMY_ATR=0x01.A0.00.00.03.96.04.03.E8.00.FE.02.0B.03.E8.00.01.00.00.00.00.64.13.88.0A.00.65.53.45.30.35.31.00.00.00. Replacing *_ATR by default (pre-cooked) ATR. ATR=0x3B.FB.18.00.00.81.31.FE.45.50.4C.41.43.45.48.4F.4C.44.45.52.AB. Command 0x01 from client 5 SM_EstablishPlatformSCP03Am (Entry) App :WARN :Using SCP03 keys from:'/tmp/SE05X/plain_scp.txt' (FILE=/tmp/SE05X/plain_scp.txt) SE051 connected. SM_EstablishPlatformSCP03Am (Exit); Status = 0x9000 sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_enable_locking sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_get_ctx_params sssprov-dbg: Enter - sss_rand_generate sssprov-flw: Get random data from SE05x Command 0x01 from client 5 SM_SendAPDUAm: smStatus = 0x9000 5f0f4d63e4ec771b8cfd46dd50c497b7e4e56e203ad5bc6eca9f8c28d23f39aa2d4a807915e3c60cf2e6a833794cb1208554f3e635811354eadd7b2c911c60da sssprov-dbg: Enter - sss_rand_freectx sssprov-dbg: Enter - sss_rand_freectx sssprov-dbg: Enter - sss_teardown Received 0 byte from client 5 (Message Header Phase) . 但是，启动 ssh 守护进程失败了： # /usr/sbin/sshd & sssprov-dbg: Enter - OSSL_provider_init App :INFO :Using PortName='127.0.0.1:8040' (gszSocketPortDefault) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. New client connection from 127.0.0.1. Client ID: 5 Command 0x00 from client 5 ATR=0x3B.FB.18.00.00.81.31.FE.45.50.4C.41.43.45.48.4F.4C.44.45.52.AB. Command 0x01 from client 5 Pre-cooked response (rspAppletSelect) sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_enable_locking sssprov-dbg: Enter - sss_rand_get_ctx_params PRNG is not seeded Received 0 byte from client 5 (Message Header Phase) . [2]+ Done(255) /usr/sbin/sshd 如有任何帮助，我将不胜感激、 Sam Re: OpenSSL Provider with SE052F for RNG 你好@sam123、 我们的提供商目前尚未测试 Openssh 支持。 这需要进一步分析，并可能需要修改。 已为 RnD 创建了内部票据，他们将进行分析。 如果我从那里得到更多信息，我会告诉你的。 感谢您的耐心等待！ 祝您愉快， Kan ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"标记正确" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------

PN7160がLPCDモードに設定されている場合、2×2cmアンテナを使用してLPCDモードから起動することはできません。 「NFCアンテナツール」を使用して、PN7160用の2cm×2cmの搭載アンテナを設計しました。このアンテナはQ値が20、目標インピーダンスが11Ωです。これは小型アンテナであるため、「PN7160 よくある質問 [AN13892]」に従ってPN7160のDPCを有効にしました。 このような条件下では、PN7160のLPCDモードを有効にしない場合、2台のPN7160デバイスはP2Pを介して正常に通信できます。しかし、PN7160のLPCDモードを有効にすると、PN7160はLPCDモードから復帰できなくなります。しかし、同じドライバーを使用すれば、2cm×4cmのアンテナでLPCDモードから起動することも可能です。 2cm×2cmアンテナからのLPCD TRACEメッセージは以下のとおりです。 D (6358097) PN7160_I2C: NCI << 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 D (6358597) PN7160_I2C: NCI << 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 D (6359107) PN7160_I2C: NCI << 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 D (6359617) PN7160_I2C: NCI << 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 アンテナ設計パラメータについては、添付ファイルをご参照ください。 CORE_SET_CONFIG_CMD は次のように設定されています。 uint8_t NxpNci_CORE_CONF_EXTN[]={0x20, 0x02, 0x6B, 0x05, /* CORE_SET_CONFIG_CMD */ 0xA0、0x40、0x01、0x81、/* TAG_DETECTOR_CFG */ 0xA0、0x41、0x01、0x10、/* TAG_DETECTOR_THRESHOLD_CFG */ 0xA0、0x42、0x01、0x0F、/* TAG_DETECTOR_PERIOD_CFG */ 0xA0、0x43、0x01、0x00、/* TAG_DETECTOR_FALLBACK_CNT_CFG */ 0xA0、0x0B、0x57、0xE5、0x05、0x90、0x6E、0x0F、0x4E、/* DPC_CONFIG */ 0x00、0x40、0x95、0xB7、0xAA、0x40、0x9F、0xA7、0x99、 0x53、0x9F、0x97、0x99、0x5D、0x9F、0x97、0x99、0x5F、 0x9F、0x97、0x00、0x68、0x9F、0x07、0x00、0x6A、0x1F、 0x07、0x00、0x74、0x1F、0x07、0x00、0x78、0x1F、0x07、 0x00、0x7F、0x1F、0x07、0x00、0x81、0x1F、0x07、0x00、 0x8B、0x1F、0x04、0x00、0x8C、0x1F、0x04、0x00、0x96、 0x1F、0x04、0x00、0x98、0x1F、0x04、0x00、0xA1、0x1F、 0x02、0x00、0xA9、0x1F、0x00、0x00、0xAF、0x1F、0x00、 0x00、0xB8、0x1F、0x00、0x00、0xC2、0x1F、0x00、0x00 }; この問題はアンテナのマッチングによるものですか、それともレジスタの設定によるものですか？ Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn アンテナのインピーダンスを測定できましたか？ 比較的低いように思われる。 Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn こんにちは。弊社製品にご関心をお寄せいただきありがとうございます。 あなたのシステム構成にはいくつか制限事項がありますので、それについて説明したいと思います。 2cm×2cmのアンテナでも実装は可能ですが、少し大きめのアンテナサイズを使用することをお勧めします。 また、NFC ForumではP2Pは推奨しておらず、代わりにHCEと読み書きモードの使用を強く推奨していることを明確にしておきたいと思います。 イニシエータのアンテナサイズが小さすぎて、ターゲットの同調ずれを引き起こす可能性は非常に高い。 カードのような通常のPICCを使って、LPCDからリーダーを起動しようと試みたことはありますか？その結果はどうなるのでしょうか？ スミスカートと試作品の回路図を、詳細な検討のために共有してください。 Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn ご回答いただき、誠にありがとうございました。 現状では、P2Pの利用は互換性を確保するための妥協策である。アンテナの形状と基板レイアウトを再最適化しましたが、問題は解決していません。添付ファイルの最初の画像はアンテナの回路図で、「NFCアンテナツール」を使用してパラメータを生成したものです。2番目の画像はPN7160とそのペリフェラル回路の回路図です。3番目と4番目の画像はPCBレイアウトの上面図と下面図を示しています。5番目の画像は、NFCアンテナツールに入力したパラメータを示しています。非対称および対称チューニングシナリオの両方について、AN13219（PN7160アンテナ設計およびマッチングガイド）の23ページに従って、Q、目標インピーダンス、fEMCカットオフ、およびL0をそれぞれ20、13Ω、22MHz、および20、11Ω、14.6MHzに設定します。しかし、どちらの場合も、LPCD TRACEからの通知メッセージはそのまま残ります。 D (564760) PN7160_I2C: NCI << 0x6f 0x13 0x04 0x80 0x83 0x80 0x03。 アンテナに近づく際に指を使うか金属製の物体を使うかにかかわらず、測定値は変わらない。 Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn ご返信ありがとうございます。しかし、現在VNA（ベクトルネットワークアナライザ）は持っていません。それでも問題が解決しない場合は、購入することにします。他に何か提案はありますか？ Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn また、「PN7160アンテナ設計およびマッチングガイド」を参照し、プログラムを使用してAGC値を読み取りました。 void Get_AGC ( SemaphoreHandle_t Semaphore_PN7160_IRQ ) {     uint8_t get [] = { 0x2F , 0x3D , 0x04 , 0x02 , 0xC8 , 0x60 , 0x03 };     uint8_t Answer [ 255 ];     uint16_t AnswerSize ;     （ １ ）​     {         printf ( " \n " );           NxpNci_HostTransceive ( Semaphore_PN7160_IRQ , get , sizeof ( get ), Answer , sizeof ( Answer ), & AnswerSize );         if (( Answer [ 0 ] != 0x4F ) || ( Answer [ 1 ] != 0x3D ) || ( Answer [ 3 ] != 0x00 )) ヤージュ             printf ( "エラー、パラメータ値を取得できません\n " );      }         それ以外 ヤージュ             printf ( " \n " );             printf ( "測定されたAGC値（LSB）= %.2X h" , Answer [ 4 ]);             printf ( " \n " );             printf ( "測定されたAGC値（MSB）= %.2X h" , Answer [ 5 ]);             printf ( " \n " );      }    } }   しかし、得られた結果は奇妙でした。それは、文書UM11495のTEST_ANTENNA_RSPの戻り値リストには記載されていません。読み取った値は0x06です。 (7600) PN7160_I2C: NCI >> 0x2f 0x3d 0x04 0x02 0xc8 0x60 0x03 D (7600) PN7160_I2C: NCI << 0x4f 0x3d 0x01 0x06 しかし、UM11495では考えられる結果が4つしか示されていません。 0x00: STATUS_OK 0x01: テスト実行が拒否されました（PN7160の状態が不正です） 0x04: STATUS_TEST_EXEC_FAILED 0x09: STATUS_INVALID_PARAM その他：RFU

S32K3使用技巧汇总_skill_experience Hi,  一些经验汇总如附件。包含主题如下： S32K3 Cortex-M7的DSP能力(Liek Li).docx S32K3 GCC版本与RTD版本的对应支持关系_Box Li 202312.docx S32K3 HSE_B资源汇总及获取流程(Liek Li).docx S32K3 MaxQFP的生产检测建议（Mike Cao).txt S32K3 NXP代理商关于S32K3的参考设计汇总(Seth Wang).docx S32K3 NXP关于S32K3的参考设计和资料汇总(Seth Wang).docx S32DS的版本管理及对应的RTD下载及安装_Box Li 202312.docx S32K3 JTAG加密及调试_JayceYang.pptx S32K3 LifeCycle的使用建议_JayceYang.docx S32K3 PN与HSE_B FW版本映射关系_JayceYang.pptx S32K3 sBAF与HSE_B FW的版本关系_JayceYang.pptx S32K3 TCM使用建议_(Box Li).docx S32K3 XRDC的使用场景及技巧(Liek Li) .docx S32K3+SBC的使用建议(Alvin Liu).pdf S32K3_LinkerFile_JayceYang.docx S32K3功能安全文档的获取及开发流程_WeoWang.docx S32K3在BMS应用的软硬件资源汇总_WeoWang.docx S32K3基于外设的培训资料汇总及样例(Seth Wang).docx S32K3的ETH应用(Liek Li).docx S32K3的Hardfault问题分析步骤(Alvin Liu).pdf S32K3的HSE_B FW安装 (Alvin Liu).pdf S32K3的RTD软件架构及使用建议(Seth Wang).docx S32K3的SAF(SPD)获取及集成建议(Ives CHENG).pdf S32K3的sBAF更新办法(Alvin Liu).pdf S32K3的SCST获取使用建议(Ives CHENG).pdf S32K3的“EB+命令行开发”环境搭建及实验(Alvin Liu).pdf S32K3的中断机制_Box Li 202312.docx S32K3的使用技巧_AHB总线上QSPI的使用建议_(Oliver TIAN).txt S32K3的使用技巧_ISELED应用上的PN选取及开发建议_(Oliver TIAN).txt S32K3的使用技巧_S32DS工程和iAR工程的相互迁移_(Jacky TAN).txt S32K3的使用技巧_S32K3 OTA的实现_(Jacky TAN).txt S32K3的使用技巧_S32K3的bootloader_(Jacky TAN).txt S32K3的使用技巧_S32K3的FEE ECC处理机制_(Jacky TAN).txt S32K3的使用技巧_S32K3的低功耗管理及唤醒样例汇总_(Jacky TAN).txt S32K3的使用技巧_S32K3的启动性能分析_(Jacky TAN).txt S32K3的功能安全开发流程及资料_Box Li 202312.docx S32K3的启动过程讲解_Box Li 202312.docx S32K3的多核调试建议及示例_(Ives CHENG).docx S32K3的时钟配置建议(Seth Wang).docx S32K3的电机控制基础及资料_WeoWang.docx S32K3硬件设计检查建议_WeoWang.docx S32K3调试中ETM的使用展示(Ives CHENG).docx S32K3问题发生后的信息搜集(Charles Zhao).docx S32K3 Security名词解释(Charles Zhao).docx S32K3 阅读勘误手册注意事项(Charles Zhao).docx 希望能够有所帮助  Oliver Re: S32K3使用技巧汇总_skill_experience 太干了 感谢楼主 Re: S32K3使用技巧汇总_skill_experience 谢谢！ 能否提供英文版？ 回复： S32K3使用技巧汇总_skill_experience 下载了，感谢感谢 Re: S32K3使用技巧汇总_skill_experience 原文的最后有下载压缩包 Re: S32K3使用技巧汇总_skill_experience 有示例代码吗 Re: S32K3使用技巧汇总_skill_experience 在哪下载，你更新在哪啊 Re: S32K3使用技巧汇总_skill_experience 已更新下载包链接 回复： S32K3使用技巧汇总_skill_experience 已更新下载包链接 回复： S32K3使用技巧汇总_skill_experience 请问怎么能获取下载连接 Re: S32K3使用技巧汇总_skill_experience 怎么获取下载链接 Re: S32K3使用技巧汇总_skill_experience Hi Oliver,      怎么获取到下载连接？ Re: S32K3使用技巧汇总_skill_experience 请欣赏这些纸张！ 奥利弗

T1040 板上的 PCI 内存分配（BAR 寄存器） 你好， 我的问题很简单，PCI 没有在 t10420 主板上分配内存。 以下是 “dmesg” 消息和 u-boot 消息。 PCI：探测 PCI 硬件 fsl-pci ffe250000.pcie：PCI 主机桥接到总线 0001:00 pci_bus 0001:00：根总线资源 [io 0xf1050000-0xf105ffff]（总线地址 [0x0000-0xffff]）pci_bus 0001:00：根总线资源 [mem 0xc100000000-0xc1fffff]（总线地址 [0xe0000000-0xefffff]）pci_bus 0001:00：根总线资源 [mem 0xc1000000-0x1fffff]（总线地址 [0xe0000000-0xefffff]） pci_bus 0001:00：根总线资源 [mem 0xcbus 0001:00：根总线资源 [bus 00-ff] pci_bus 0001:00：busn_res：[bus 00-ff] 结束已更新为 ff pci 0001:00:00.0： [1957:0820] type 01 class 0x060400 pci 0001:00:00.0：reg 0x10: [mem 0xff000000-0xffffffffff] pci 0001:00:00.0：支持 D1 D2 pci 0001:00:00.0：从 D0 D1 D2 D3hot D3cold 支持 PME# fsl-pci ffe250000.pcie：从 iommu 组 19 移除 pci 0001:00:00.0：添加到 iommu 组 21 pci 0001:01:00.0：[1002:6987] type 00 class 0x030000 pci 0001:01:00.0：reg 0x10: [mem 0xc10000000-0xc1fffffff 64bit pref] pci 0001:01:00.0：reg 0x18: [mem 0x1000ffe00000-0x1000ffffffff 64bit pref] pci 0001:01:00.0：reg 0x20: [io 0xf1051100-0xf10511ff] pci 0001:01:00.0：reg 0x24: [mem 0xfffc0000-0xffffffffff] pci 0001:01:00.0：reg 0x30: [mem 0xfffe0000-0xffffffff pref] pci 0001:01:00.0：启用扩展标记 pci 0001:01:00.0：支持 D1 D2 pci 0001:01:00.0：D1 D2 D3hot D3cold pci 0001:01:00.0 支持 PME#：可用 PCIe 带宽为 4.000 Gb/s，在 0001:00:00.0 时受 5.0 GT/s PCIe x1 链接限制（使用 8.0 GT/s PCIe x8 链接可达到 63.008 Gb/s） pci 0001:01:00.0：添加到 iommu 组 21 pci 0001:01:00.1：[1002:aae0] type 00 class 0x040300 pci 0001:01:00.1：reg 0x10: [mem 0x1200ffffc000-0x1200ffffff 64bit] pci 0001:01:00.1：启用扩展标记 pci 0001:01:00.1：支持 D1 D2 pci 0001:01:00.1：添加到 iommu 组 21 pci 0001:00:00.0：PCI 桥接到 [总线 01-ff] pci 0001:00:00.0：bridge window [io 0xf1051000-0xf1051fff] pci 0001:00:00.0：桥接窗口 [mem 0xc100000000-0xc1fffff] pci_bus 0001:01：busn_res：[总线 01-ff] 末端更新为 01 p ci_bus 0001:00：busn_res：[总线 00-ff] 端已更新为 01 PCI：无法分配设备 0001:00:0 的资源区域 0，将重新映射 PCI：无法分配设备 0001:00:0 的资源区域 2 01:00.0，将重新映射 PCI：无法分配设备 0001:01:00.0 的资源区域 5，将重新映射 PCI：无法分配设备 0001:01:00.0 的资源区域 6，将重新映射 PCI：无法分配设备 0001:01:00.1 的资源区域 0，将重新映射 pci 0001:00:00.0：BAR 0: no space for [mem size 0x01000000] pci 0001:00:00.0：BAR 0：分配失败 [内存大小 0x01000000] pci 0001:00:00.0：BAR 9：无空间 [内存大小 0x00200000 64 位前缀] pci 0001:00:00.0：BAR 9：分配失败 [内存大小 0x00200000 64 位前缀] pci 0001:01:00.0：BAR 2: no space for [mem size 0x00200000 64bit pref] pci 0001:01:00.0：BAR 2：分配失败 [内存大小 0x00200000 64 位前缀] pci 0001:01:00.0：BAR 5: no space for [mem size 0x00040000] pci 0001:01:00.0：BAR 5：分配失败 [内存大小 0x00040000] pci 0001:01:00.0：BAR 6: no space for [mem size 0x00020000 pref] pci 0001:01:00.0：BAR 6：分配失败 [内存大小 0x00020000 pref] pci 0001:01:00.1：BAR 0: no space for [mem size 0x00004000 64bit] pci 0001:01:00.1：BAR 0：分配失败 [内存大小 0x00004000 64 位] pci 0001:00:00.0：PCI 桥接到 [总线 01] pci 0001:00:00.0：bridge window [io 0xf1050000-0xf105ffff] pci 0001:00:00.0：桥接窗口 [mem 0xc1000000-0xc1fffff] pci_bus 0001:00：部分 PCI 设备资源未分配，尝试使用 pci=realloc pci_bus 0001:00 启动：资源 4 [io 0xf105000000-0xf105ffff] pci_bus 0001:00：资源 5 [mem 0xc100000000-0xc1fffff] pci_bus 0001:00：资源 5 [mem 0xc100000000-0xc1fffff] pci_b us 0001:00：资源 5 [mem 0xc100000000-0xc1fffff] pci_bus fff] pci_bus 0001:01：资源 0 [io 0xf1050000-0xf105fff] pci_bus 0001:01：资源 1 [mem 0xc1000000-0xc1fffff] HugeTLB 注册了 4.00 MiB 页面大小，预先分配 0 页 HugeTLB 注册了 64.0 MiB 页面大小大小，预计 已分配 0 页 HugeTLB 注册了 256 MiB 页面大小，预先分配 0 页 HugeTLB 注册了 1.00 GiB 页面大小，预先分配 0 页 飞思卡尔 Elo 系列 DMA 驱动程序以下是内核 dts pci1：pcie@ffe250000 { reg =<0xf 0xfe250000 0 0x10000>; ranges =<0x02000000 0 0xe0000000 0xc 0x10000000 0 0x10000000 0x01000000 0 0xf 0xf8010000 0 0x00010000>; pcie@0 { ranges =<0x02000000 0 0xe0000000 0x02000000 0 0xe0000000 0 0x10000000 0x01000000 0 0x00000000 0x01000000 0 0x00000000 0 0x00010000>; }; }； Re: PCI memory allocation (BAR Registers) on T1040 Board GPU 的 BAR 2 请求 0x1000ffe00000 - 这是一个 64 位可预取 BAR ，试图使用 ~163 Terabytes 的地址 。这完全超出了 32 位 PCI 窗口。 T1040 是 32 位 PowerPC e5500 内核 ，通过 MMU 拥有 36 位物理地址空间 。 0x1000ffe00000 而 T1040 硬件不可能提供 48 位地址空间。 您的地址 0x1000ffe00000 在 40 多位的范围内，完全超出了 T1040 的寻址空间。 Re: PCI memory allocation (BAR Registers) on T1040 Board 是的，它是 E9171 AMDGPU Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955 你连接到 T1040 的端点设备是什么？这是 GPU 吗？ Re: PCI memory allocation (BAR Registers) on T1040 Board 你好 谢谢你的回复 没什么变化 PCI 主机桥 /pcie @ffe250000 范围： MEM 0x0000000c100000000... 0x0000000c2fffff-> 0x00000000e000000e0000000 IO 0x00000000... 0x0000000ff105fff-> 0x00000000000000 /pcie @ffe250000：PCICSRBAR @ 0xdf000000 setup_pcie ci_atmu：动态随机存取存储器(DRAM) 80000000 平台的终结 ff6000000 .qman-portal： 添加到 iommu 组 0 platform ff6004000.qman-portal：添加到 iommu 组 1 platform ff6008000.qman-portal：添加到 iommu 组 2 平台 ff600c000.qman-portal：添加到 iommu 组 3 platform ff6010000.qman-portal：添加到 iommu 组 4 platform ff6014000.qman-portal：添加到 iommu 组 5 platform ff6018000.qman-portal：添加到 iommu 组 6 平台 ff601c000.qman-portal：添加到 iommu 组 7 platform ff6020000.qman-portal：添加到 iommu 组 8 平台 ff6024000.qman-portal：添加到 iommu 组 9 平台 ffe100300.dma：添加到 iommu 组 10 平台 ffe101300.dma：添加到 iommu 组 11 平台 ffe114000.sdhc：添加到 iommu 组 12 平台 ffe210000.usb：添加到 iommu 组 13 平台 ffe211000.usb：添加到 iommu 组 14 平台 ffe220000.sata：添加到 iommu 组 15 平台 ffe221000.sata：添加到 iommu 组 16 platform ffe318000.qman：添加到 iommu 组 17 平台 ffe31a000.bman：添加到 iommu 组 18 fsl-pci ffe250000.pcie：添加到 iommu 组 19 平台 ffe140000.qe：添加到 iommu 组 20 software IO TLB: tearing down default memory pool PCI: Probing PCI hardware fsl-pci ffe250000.pcie：PCI 主机桥接到总线 0001:00 pci_bus 0001:00：根总线资源 [io 0xf1050000-0xf105ffff]（总线地址 [0x0000-0xffff]）pci_bus 0001:00：根总线资源 [mem 0xc100000000-0xc2ffffff]（总线地址 [0xe0000000-0xffffff]）pci_bus 0001:00：根总线资源 [mem 0xc1000000-0xc2ffffff]（总线地址 [0xe0000000-0xffffff]） pci_bus 0001:00：根总线资源 [mem bus 0001:00：根总线资源 [bus 00-ff] pci_bus 0001:00：busn_res：[bus 00-ff] 结束已更新为 ff pci 0001:00:00.0： [1957:0820] type 01 class 0x060400 pci 0001:00:00.0：reg 0x10: [mem 0xdf000000-0xdfffffff] pci 0001:00:00.0：支持 D1 D2 pci 0001:00:00.0：从 D0 D1 D2 D3hot D3cold 支持 PME# fsl-pci ffe250000.pcie：从 iommu 组 19 移除 pci 0001:00:00.0：添加到 iommu 组 21 pci 0001:01:00.0：[1002:6987] type 00 class 0x030000 pci 0001:01:00.0：reg 0x10: [mem 0xc10000000-0xc1fffffff 64bit pref] pci 0001:01:00.0：reg 0x18: [mem 0x1000ffe00000-0x1000ffffffff 64bit pref] pci 0001:01:00.0：reg 0x20: [io 0xf1051100-0xf10511ff] pci 0001:01:00.0：reg 0x24: [mem 0xc2ffc0000-0xc2fffffff] pci 0001:01:00.0：reg 0x30: [mem 0xc2ffe0000-0xc2fffffff pref] pci 0001:01:00.0：启用扩展标记 pci 0001:01:00.0：支持 D1 D2 pci 0001:01:00.0：D1 D2 D3hot D3cold pci 0001:01:00.0 支持 PME#：可用 PCIe 带宽为 4.000 Gb/s，在 0001:00:00.0 时受 5.0 GT/s PCIe x1 链接限制（使用 8.0 GT/s PCIe x8 链接可达到 63.008 Gb/s） pci 0001:01:00.0：添加到 iommu 组 21 pci 0001:01:00.1：[1002:aae0] type 00 class 0x040300 pci 0001:01:00.1：reg 0x10: [mem 0x1200ffffc000-0x1200ffffff 64bit] pci 0001:01:00.1：启用扩展标记 pci 0001:01:00.1：支持 D1 D2 pci 0001:01:00.1：添加到 iommu 组 21 pci 0001:00:00.0：PCI 桥接到 [总线 01-ff] pci 0001:00:00.0：bridge window [io 0xf1051000-0xf1051fff] pci 0001:00:00.0：桥接窗口 [mem 0xc100000000-0xc1fffff] pci_bus 0001:01：busn _res：[总线 01-ff] 末端更新为 01 pci_bus 0001:00：busn_res：[总线 00-ff] 端已更新为 01 PCI：无法分配设备 0001:00:0 的资源区域 0，将重新映射 PCI：无法分配设备 0001:00:0 的资源区域 2 01:00.0，将重新映射 PCI：无法分配设备 0001:01:00.0 的资源区域 6，将重新映射 PCI：无法分配设备 0001:01:00.1 的资源区域 0，将重新映射 pc i 0001:00:00.0： BAR 0: no space for [mem size 0x01000000] pci 0001:00:00.0：BAR 0：分配失败 [内存大小 0x01000000] pci 0001:00:00.0：BAR 9：无空间 [内存大小 0x00200000 64 位前缀] pci 0001:00:00.0：BAR 9：分配失败 [内存大小 0x00200000 64 位前缀] pci 0001:01:00.0：BAR 2: 已分配 [mem 0xc20000000-0xc201fffff 64bit pref] pci 0001:01:00.0：BAR 6: 已分配 [mem 0xc20200000-0xc2021ffff pref] pci 0001:01:00.1：BAR 0: 已分配 [mem 0xc20220000-0xc20223fff 64bit] pci 0001:00:00.0：PCI 桥接到 [总线 01] pci 0001:00:00.0：bridge window [io 0xf1050000-0xf105ffff] pci 0001:00:00.0：桥接窗口 [mem 0xc100000000-0xc2fffff] pci_bus 0001:00：部分 PCI 设备资源未分配，尝试使用 pci=realloc pci_bus 0001:00 启动：资源 4 [io 0xf105000000-0xf105ffff] pci_bus 0001:00：资源 5 [mem 0xc100000000-0xc2fffff] pci_b us 0001:00：资源 5 [mem 0xc100000000-0xc2fffff fff] pci_bus 0001:01：资源 0 [io 0xf1050000-0xf105fff] pci_bus 0001:01：资源 1 [mem 0xc1000000-0xc2fffff] HugeTLB 注册了 4.00 MiB 页面大小，预先分配 0 页 HugeTLB 注册了 64.0 MiB 页面大小大小，预计 已分配 0 页 HugeTLB 注册了 256 MiB 页面大小，预先分配 0 页 H ugeTLB 注册了 1.00 GiB 页面大小，预先分配 0 页飞思卡尔 Elo 系列 DMA 驱动程序 fsl-elo-dma ffe100300.dma： #0 (fsl,eloplus-dma-channel), irq 28 fsl-elo-dma ffe100300.dma：#1 (fsl,eloplus-dma-channel), irq 29 fsl-elo-dma ffe100300.dma：#2 (fsl,eloplus-dma-channel), irq 30 fsl-elo-dma ffe100300.dma：#3 (fsl,eloplus-dma-channel), irq 31 fsl-elo-dma ffe100300.dma：#4 (fsl,eloplus-dma-channel), irq 76 fsl-elo-dma ffe100300.dma：#5 (fsl,eloplus-dma-channel), irq 77 fsl-elo-dma ffe100300.dma：#6 (fsl,eloplus-dma-channel), irq 78 fsl-elo-dma ffe100300.dma：#7 (fsl,eloplus-dma-channel), irq 79 fsl-elo-dma ffe101300.dma：#0 (fsl,eloplus-dma-channel), irq 32 fsl-elo-dma ffe101300.dma：#1 (fsl,eloplus-dma-channel), irq 33 fsl-elo-dma ffe101300.dma：#2 (fsl,eloplus-dma-channel), irq 34 fsl-elo-dma ffe101300.dma：#3 (fsl,eloplus-dma-channel), irq 35 fsl-elo-dma ffe101300.dma：#4 (fsl,eloplus-dma-channel), irq 80 fsl-elo-dma ffe101300.dma：#5 (fsl,eloplus-dma-channel), irq 81 fsl-elo-dma ffe101300.dma：#6 (fsl,eloplus-dma-channel), irq 82 fsl-elo-dma ffe101300.dma：#7（fsl，eloplus-dma-channel），irq 83 iommu：默认功能域类型：已翻译 iommu：DMA 功能域 TLB 失效政策：严格模式 pci 0001:01:00.0:vgaarb：已添加 VGA 设备：decodes=io+mem，owns=无，locks=none pci 0001:01:00.0： vgaarb: 桥接控制可能 pci 0001:01:00.0：vgaarb：设置为引导设备（VGA 旧版资源不可用） Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955，你能用这个 dts 更改试试吗？:- pci1：pcie@ffe250000 { reg =<0xf 0xfe250000 0 0x10000>; ranges =<0x02000000 0x0 0xe0000000 0xc 0x10000000 0x0 0x20000000 /* 512MB */ 0x01000000 0x0 0x000000 0xf 0xf1050000 0x0 0x00010000> ；/* 64KB I/O */ pcie@0 { ranges =<0x02000000 0x0 0xe0000000 0x02000000 0x0 0xe0000000 0x0 0x20000000 0x01000000 0x0 0x00000000 0x01000000 0x0 0x00000000 0x0 0x00010000>; }; }； Re: PCI memory allocation (BAR Registers) on T1040 Board 嗨 @gaurav_sharma 谢谢你的回复，这个 E9171 AMDGPU 能在 T2080 主板上运行吗？ Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 我尝试了这些命令，但得到了相同的错误信息"无效 PCI ROM 头签名：预计为 0xaa55，结果为 0xadde" Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 谢谢你的回复， ，我在配置文件中做了一些改动，就能实现 64 位内核了。现在正在分配内部 BAR（包括 32 位和 64 位）。 但在加载 AMDGPU 驱动程序时，我收到了以下错误信息 root@t1042d4rdb:~# insmod /amdgpu.ko [drm] amdgpu 内核模式设置已启用。 [drm] 初始化内核模式设置（POLARIS12 0x1002:0x6987 0x1787:0x2389 0x80）。 amdgpu 0001:01:00.0：amdgpu：不支持可信内存区域 (TMZ) 功能 [drm] 寄存器 mmio 基础：0x80000000 [drm] 寄存器 mmio 大小：262144 [drm] 不支持 PCIE 原子操作 [drm] 添加 ip 区块编号 0 [drm] 添加 ip 区块编号 1 [drm] 添加 ip 区块编号 2 [drm] 添加编号为 3 的 ip [drm] 添加 ip 区块编号 4 [drm] 添加 ip 区块编号 5 [drm] 添加 ip 区块编号 6 [drm] 添加 ip 区块编号 7 [drm] 添加 ip 区块号 8 amdgpu 0001:01:00.0：无效的 PCI ROM 标头签名：期待 0xaa55，得到 0xadde amdgpu 0001:01:00.0：PCI ROM 标头签名无效：期待 0xaa55，得到 0xadde amdgpu 0001:01:00.0：amdgpu：找不到 BIOS ROM amd gpu 0001:01:00:0 00.0：amdgpu：GPU 初始化期间出现致命错误 amdgpu 0001:01:00.0：amdgpu：amdgpu： amdgpu：amdgpu：amdgpu：am 精加工设备。 尝试在 0x0000000000000000 amdgpu 处取消映射早期的螺栓映射：0001:01:00.0 的探测失败，错误 -22 更新后的设备树如下所示： pci1: pcie@ffe250000 { reg =<0xf 0xfe250000 0 0x10000> ； ranges =<0x02000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000 /* 512MB nonref */ 0x43000000 0xc 0x10000000 0xc 0x10000000 0x0 0x40000000 /* 1GB 64 位前缀 ← 键更改 */ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000> ； pcie@0 { }; }; uBoot 变更： #if! 已定义 (CONFIG_DM_PCI) #define CONFIG_FSL_PCI_INIT /* 使用常用的 FSL 初始化代码 */ #define CONFIG_SYS_PCIE1_MEM_BUS 0xe0000000 #define CONFIG_SYS_PCIE1_MEM_SIZE 0x00000000 CONFIG_SYS_PCIE1_BUS 0x00000000 #define CONFIG_SYS_PCIE1_BUS 0x00000000 CONFIG_SYS_PCIE1_BUS 0x00000000 CONFIG_SYS_PCIE1_IO_BUS PCIE1_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_SYS_PCIE2_MEM_BUS 0xe0000000 #define CONFIG_SYS_PCIE2_MEM_ SIZE 0x100000000 /* 256M */ #define #define CONFIG_SYS_PCIE2_IO_BUS 0x00000000 #define CONFIG_SYS_PCIE2_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_SYS_PCIE3_MEM_BUS #define CONFIG_SYS_PCIE3_IO_BUS CONFIG_SYS_PCIE3_IO_BUS CONFIG_SYS_PCIE3_IO_BUS CONFIG_SYS_PCIE3_IO_BUS 0x00000000 #define CONFIG_SYS_PCIE3_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_SYS_PCIE4_MEM_ BUS 0xe0000000 #define #define CONFIG_SYS_PCIE4_MEM_SIZE 0x100000000 /* 256M */ #define CONFIG_SYS_PCIE4_IO_BUS 0x00000000 #define CONFIG_SYS_PCIE4_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_PCI_INDIRECT_BRIDIGE #endif #define CONFIG_PCI_SCAN_SHOW /* 启动时显示 pci 设备 */ #endif /* CONFIG_PCI */ 对于你的问题，以下是答 案： 1。设备树和 uBoot 中的更改如上所述。 2.附上 pci=realloc 的日志 3.内存大小 = 2GB Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955我想纠正一下之前的说法：- "你的地址 0x1000ffe00000 在 40 多位的范围内，完全超出了 T1040 的寻址空间。" -- 事实并非如此。SOC 的设计适用于高达 64GB 寻址内存空间的大型物理地址空间。假设运行的是 64 位内核 GPU请求的不是地址，只是大小/类型。Linux/ 固件通过对 BAR 编程来分配地址，而你看到的值（如 0x1000ffe00000 ）只是当前编程的基数--通常是固件设置错误或 DT 解析错误，直到 Linux 重新分配。 我正在检查为什么会出现这种情况。同时， 1. 你能告诉我除了 dts 之外你在固件/uboot/linux 中是否还有其他与 pcie 相关的更改吗？ 2. 你能不能用 pci=realloc 启动一次然后分享日志。 3. 你的主板上的 RAM 大小是多少？ Re: PCI memory allocation (BAR Registers) on T1040 Board 当您执行 setpci -s 0001:01:00.0 30.l 时，rom bar 地址编程是否会粘连？执行上述操作后，当您执行以下操作时， :- 。 lspci -vv -s 0001:01:00.0 | grep -i"Expansion ROM" 你看到了什么？ 另外，在连续读取多个 devmem 之后：- devmem 0x80040000 16 devmem 0x80040000 16 执行：- lspci -vv -s 0001:00:00.0 | egrep -i"Secondary status|UESta|CESta|AER" dmesg | tail -200 | egrep -i"pcie|aer|abort|error" 你在 dmesg 中观察到任何错误日志吗？ Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma ，请查看以下结果， root@t1042d4rdb:~# setpci -s 0001:01:00.0COMMAND=0007 root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l=80040001 root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l 80040001 root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb：~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb：~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb：~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l 80040001 root@t1042d4rdb:~# lspci -vv -s 0001:01:00.0 | grep -i"Expansion ROM" Expansion ROM at 80040000 [size=128K] root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb：~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb：~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# lspci -vv -s 0001:00:00.0 | egrep -i"Secondary status|UESta|CESta|AER" Secondary status：66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort- UESta：DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- CESta：RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- AERCap：第一个错误指针：00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- root@t1042d4rdb:~# dmesg | tail -200 | egrep -i"pcie|aer|abort|error" [ 2.151844] EXT4-fs (mmcblk0p2): warning: mounting fs with errors, running e2fsck is recommended. Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 请查看以下日志 root@t1042d4rdb:~# lspci 0001:00:00.0PCI 桥接器：飞思卡尔半导体公司设备 0820（修订版 10）0001:01:00.0 兼容 VGA 的控制器：Advanced Micro Devices, Inc. [AMD/ATI] Lexa [Radeon 540X/550X/630/RX 640/E9171 MCM]（修订版 80） 0001:01:00.1 音频设备：高级微设备公司 [AMD/ATI] Baffin HDMI/DP 音频 [Radeon RX 550 640SP/RX 560/560X] root @t1042d4rdb ~# root @t1042d4rdb：~# root @t1042d4rdb：~# lspci-vv-s 0001:01:00.0 0001:01:00.0兼容 VGA 的控制器：Advanced Micro Devices, Inc. [AMD/ATI] Lexa [Radeon 540X/550X/630/RX 640/E9171 MCM]（修订版 80）（prog-if 00 [VGA 控制器]） 子系统：高科技信息系统有限公司设备 2389 控制：I/O+ Mem+ BusMaster+ SpecCycle-memwinv-vgasNoop-ParerR-步进 SERR-FastB2b-disintX-状态：Cap+ 66MHz-UDF-FastB2b-Parerr-devsel=Fast > tabort-< tabort- SERR-SERR- < PERR-INTX- 延迟：0，缓存行大小：32 字节 中断：引脚 A 路由到 IRQ 41 IOMMU 组：21 区域 0：c1000000 处的内存（64 位，可预取）[size=256M] 区域 2：c200000（64 位，可预取）的内存 [size=256] 区域 4：1100 的 I/O 端口 [size=256] 区域 5：内存在 80000000（32 位，不可预取）[size=256K] 扩展 ROM 为 80040000 [已禁用] [size=128K] 功能：[48] 供应商特定信息：Len=08 <？ > 功能：[50] 电源管理单元 版本 3 标志：pmeClk-DSI-D1+ D2+ auxcurrent=0mA PME（D0-、D1+、D2+、d3Hot+、d3Hot+、d3Cold+） 状态：D0 nosoftRST+ PME-enable-dsel=0 pme- 功能：[58] Express (v2) 传统端点，MSI 00 DevCa p：maxPayload 256 字节，PhantFunc 0，延迟 l0s < 4us，L1 无限制 extTag+ attnBtn-attnn-attnnInd-pwrind-RBE+ flreset-devCtl：correrr-nonFatalerr-Fatalerr-Unsuperq-rlxDord+ extTag+ phantFunc-auxPWR-noSnoop+ maxPayload 128 字节，maxReadReq 512 字节 devSta：correrr+ nonfatalerr-Fatalerr-Unsupreq+ auxPWR-TransSpend-LnkCap：端口 #0，速度 8GT/s，宽度 x8，ASPM L1，退出延迟 L1 < 1us clockPM+ 惊喜-llactrep-bwnot-aspmoptComp + lnkCt l：ASPM 禁用；RKCtl：ASPM 已禁用；CB 64 字节，禁用-commCLK-extSynch-clockPM-autWiddis-bwint-AutbWint-lnkSta：速度 5GT/s（降级），宽度 x1（降级）trerr-Train-slotCLK+ dLActive-bwint-devCap2：完成超时：不支持， Timeoutdis-nroprp-LTR+ 10bittagComp-10bittagReq-OBFF 不支持，extFMT+ eetlpPrefix+、maxeetLPPrefix+ 1 不支持紧急 功率降低，紧急降电init-FRS-AtomicopsCap：32 位+ 64 位+ 128 bitcas-d evctl2：完成超时：50 us 到 50 毫秒，TimeoutDis-LTR-OBFF 已禁用，At omicopSCTL：reqen-lnkCap2：支持的链路速度：2.5-8GT/ s，Crosslink-重定时器-2重定时器-DRS-lnkCtl2：目标链路速度：8GT/s，EnterCompanial-SpeedDis-传输余量：正常工作范围， 进入修改后的合规性-合规性操作系统-合规性减重：-6dB Lnksta2：当前去加重级别：-6dB，均衡完成- 均衡阶段 1-均衡阶段 2-均衡阶段 3-LinkEqualizationRequest-重定时器-2 重定时器-Crosslinkres：不支持的功能：[a0] MSI：启用-计数 =1/1 可屏蔽-64 位 + 地址：0000000000000000 数据：0000 能力：[100 v1] 供应商特定信息：ID=0001 Rev=1 Len=010 功能：[150 v2] 高级错误报告 uestA：DLP-SDES-TLP-FCP-cmplto-cmplto-cmplt-unxcmplt-rxof-MalftLP-ECRC-Unsupreq-acsviol-uemsk：DLP-SDES-TLP-FCP-cmpltto-cmplt-unxcmplt-ECRC-Unsupreq-acsviol- uemsk：DLP-SDES-TLP-FCP-cmpltto-cmpltbrt-unxcmplLP-ECRC-Unsupreq-acsviol-uesVRT：DLP+ SD ES+ TLP-FCP+ cmplto-cmplto-cmplt-rxOf+ malftLP+ ECRC-Unsupreq-acsViol-cesta：rxerr-badtlp-baddlp-baddLPLP-Timeout-rxof+ malftLP+ ECRC-Unsupreq-acsViol-cesta：rxerr-badtlp-baddllp-rolver-Timeout-advnonFatalerr+ AerCap：第一个错误 指针：00，ecrcgencap+ ecrcGenenen-ecrcchken+ ecrcchken-multhDrrecca p-multhDrrecen-tlppfxPres-HdrlogCap-He aderLog：00000000 00000000 00000000 能力：[200 v1] 物理大小可调整的 BAR 0：当前大小：256MB 512MB 1GB 2GB 4GB 容量：[270 v1] 辅助 PCI Express lnkCtl3：lnkequintrrupten-PerformeQu-LaneerrStat：0 功能：[2b0 v1] 地址映射 服务 (ATS) atsCap：无效队列深度：00 atsCTL：启用-，最小转换单位：00 功能：[2c0 v1] 页面请求接口 (PRI) pr icTL：启用-RESET-p rista：RF-UPRGI-Stoped+ 页面请求容量：00000020，页面请求分配：00000000 功能：[2d0 v1] 进程地址空间 ID (PASID) p asidCap：Exec+ Priv+，最大 PASID宽度：10 pasidCtl：启用-执行-Priv-功能：[320 v1] 延迟容差报告最大监听延迟：0 ns 最大无窥探延迟：0 ns 功能：[328 v1] 替代 路由 ID 解释 (ARI) ariCap：MFVC-ACS-，下一个函 数：1 aricTL： MFVC-ACS-，功能组：0 能力：[370 v1] L1 PM Substates L1subcap：PCI-PM_L1.2+ PCI-PM_L1.1+ASPM_L1.2+ASPM_L1.1+L1_PM_Substates+ PortCommonModeRestoreTime=0us PortTPowerOnTime=170us L1SubCtl1：PCI-PM_L1.2-PCI-PM_L1.1-ASPM_L1.2-ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2：T_PwrOn=10us 内核模块：amdgpu root@t1042d4rdb:~# lspci -vv -s 0001:00:00.0 0001:00:00.0PCI 桥接器：飞思卡尔半导体公司设备 0820（修订版 10）（prog-if 00 [正常解码]） 设备树节点：/sys/固件/devicetree/base/pcie @ffe250000 /pcie @0 控制：I/O+ Mem+ BusMaster+ SpecCycle-memware-Vgasnoop-Parerr-Steping-Serr+ FastB2b-disintX-状态：Cap+ 66MHz-UDX-UDCLE-memware-VGasnoop-Parerr-Steping-Serr+ FastB2b-disintX-状态：Cap+ F-fastB2b-Parerr-devsel=Fast > taBort-< taBort- SERR-< PERR-intX- 延迟：0，缓存行大小：32 字节 中断：引脚？路由到 IRQ 21 IOMMU 组：21 区域 0：已忽略 （32 位，不可预取） 总线：primary=00，secondary=01，subordinate=01，sec-latency=0 I/O behind bridge: 00000000-0000ffff [size=64K] Memory behind bridge: 80000000-8fffffff [size=256M] Prefetchable memory behind bridge: 0000000c10000000-0000000c4fffffff [size=1G] Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >RESET- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] 电源管理单元 version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [4c] Express (v2) Root Port (Slot-), MSI 00 DevCap: MaxPayload 256 字节, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr+ FatalErr+ UnsupReq+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 字节, MaxReadReq 512 字节 DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s, Exit Latency L0s <2us ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 字节, Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s (ok), Width x1 (downgraded) TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt+ RootCap: CRSVisible- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- DevCap2: Completion Timeout: Range ABC, TimeoutDis+ NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- AtomicOpsCtl: ReqEn- EgressBlck- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 RootCmd: CERptEn- NFERptEn- FERptEn- RootSta: CERcvd- MultCERcvd- UERcvd- MultUERcvd- FirstFatal- NonFatalMsg- FatalMsg- IntMsg 0 ErrorSrc: ERR_COR: 0000 ERR_FATAL/NONFATAL: 0000 Kernel driver in use: pcieport root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l fffe0000 Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955请粘贴这些命令的输出结果： - lspci-vv -s 0001:01:00.0 lspci -vv -s 0001:00:00.0 setpci -s 0001:01:00.0 30.l Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955 lspci 日志显示：- 扩展 ROM： 80040000 [禁用] 大小 128KB（Linux 根据 BAR 类型/大小分配资源） Linux 打算让 ROM 在 0x80040000 的低非前置窗口中运行，这是件好事，也是众望所归。这表明 ROM 在已编程窗口的范围内。 "root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l fffe0000" -- 这看起来像一把冒烟的枪。 0xfffe0000 正是探测 128KB ROM BAR 时得到的大小掩码（128KB = 0x20000；掩码清除低 17 位 → 0xfffe0000 ）。这是在写入所有 1 以检测 ROM 大小后通常读回的值。 它不包含有效地址，而是包含 "大小探测掩码"。 因此，ROM BAR 编程/启用路径存在问题。 看来是固件（uboot）或早期的 pci 代码在探测内存大小，而没有恢复内存条基数。 您能否尝试对 ROM 条形底座进行强制编程，并通过执行以下操作启用它：- # 确保 MEM 解码已启用 setpci -s 0001:01:00.0命令=0007   # 现在我们知道 linux 分配的 ROM 地址是 0x80040000 setpci-s 0001:01:00.0 30.l=80040001 然后使用以下方法读取字节：-d evmem 0x8004000 0 16 有效的 rom 应以字节 55 aa 开头，这是我们期望从上面观察 到的。 如果有效，您可以再次尝试 sysfs rom dump：- echo 1 > /sys/bus/pci/devices/0001:01:00.0/rom dd if=/sys/bus/pci/devices/ 0001:01:00.0 /rombs=1 count=16 2>/dev/null | hexdump -C echo 0 > /sys/bus/pci/devices/0001:01:00.0/rom Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 我得到的结果如下， root@t1042d4rdb:~# setpci -s 0001:01:00.0COMMAND=0007 root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l=80040001 root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD