RW612 输出时钟到引脚 你好， 我正在寻找一个软件示例，说明如何通过引脚输出时钟信号，以便可以用示波器进行测量。 我认为可以用CLKOUT信号实现这一点（参见下图），但我没能正确设置。 用户手册的这一部分提到，CLKOUT 必须通过 IOMUX 路由到引脚，但我无法在MCI_IO_MUX->FSEL 寄存器中找到该功能的字段。 产品：WiFi RW6XX Re: RW612 output clock to pin MCUXpresso 可能有助于生成时钟信号 Re: RW612 output clock to pin 你好@Niwo ， 要添加 CLKOUT 配置，我建议使用MCuxpresso 配置工具。该工具允许您配置MCU的时钟树和引脚，并自动在clock_config.c中生成相应的API。pinmux.c，和 pinmux.h文件。 如果您不熟悉此工具，我建议您查看MCUXpresso 配置工具快速入门指南以开始使用。您可能还会发现 MCUXpresso 配置工具 26.09 文档中的“引脚/内部信号选择入门指南”和“时钟工具”部分对配置引脚和时钟很有帮助。 如果您还有其他问题，请告诉我。 BR 哈比卜

ZSDK BLEホスト認定に関するリファレンスは古くなっているようです nxp-zsdkのリリースノートに記載されているBLEホストの認定情報は、非常に古い認定情報に基づいています。 例:nxp-zsdk 4.4の状態; BLE ホスト、DN#: Q305748、リンク *: ホスト資格 BLEコントローラ、DN#:Q380314、リンク*:コントローラ資格 *: BLE SIGアカウントが必要です。 このホスト資格はBLE 5.4のサポートを指定しています。 コントローラはBLE 6.1サポートを指定しています。 コントローラのすべての機能をサポートするには、ホストは同じBLEレベルまたはそれ以上のレベルが必要です。 SO、リリースノートの参照が間違っていると思いますが、正しい参考文献を教えてもらえますか? 敬具 トニー

MKW38 BLEスキャンが長時間テスト時に動作しない クリスティン・リー様、NXPチームの皆様   ご支援ありがとうございます   以前ご報告したBLEスキャンに関する問題について、長期テストから得られた追加の分析結果を共有し、いくつか質問をしたいと思います。     1. 要約 連続スキャン中、コントローラは時折LE広告レポートをホストに届けなくなることがあります。 この期間中、LLレジスタはスキャンがまだアクティブであることを示していますが（SCAN_STATUS.Scan_on = 1）、パケットは全く受信されません。PKT_RSSI_STATUSとCH_ADDRは変更されません。 ほとんどの場合、コントローラは1秒から2.5分以内に自動的に回復します。あるケースでは、ログが終了するまで8時間以上回復 しませんでした 。 SDKは2.6.916であると知らされましたこの問題は解決します。 しかし、 SDK 2.6.916のライブラリで約1週間以内に問題が再発しました。 テスト条件   単位数／期間：約5単位それぞれ14.6日、テスト中にMCUリセットなし コントローラーライブラリ: 2023年4月にインポート、2.6.615以降(Controller_SetPeripheralDiscThreshold(を含む);正確なバージョンは不明) lib_ble_kw38a4_controller_gcc.a、617,384バイト、MD5プレフィックス 50417a8d65 別個テスト: SDK 2.6.916図書館 – 約1週間以内に同じ症状が再現 スキャンパラメータ： アクティブスキャン、インターバル0x0011（10.625ms）、ウィンドウ0x0008（5ms） フィルタポリシー: 全て許可、重複フィルタリング無効 連続スキャン（gGapScanContinuously_d）、拡張スキャン（PHYレジスタ0x14E = 0x0005をスキャン） スキャン開始/停止:起動後に一度開始。テスト中はスキャン停止/開始なし。 環境:約通常動作時、毎秒75～110件の広告レポート アプリケーション側のレジスタアクセス: LLレジスタの読み取り専用ポーリングを1秒ごとに実行します（0x01C、0x01E、0x064、0x0C4、0x0D2、0x0D4、0xF28）。 診断のために、180秒ごとにINIT_SCN_ADV_RX_FIFO（0x4008007C）の16ビット読み取りを1回実行します。 アプリケーションによってLLレジスタは書かれません 3. 問題の検出方法 各レイヤーにおける広告レポート数を毎秒カウントしています。 L1: LE(拡張)広告レポートイベント情報がコントローラーからホストへ渡されます。Controller_Init() に登録された Ble_HciRecv() のラッパー内でカウントされます。 L2: gDeviceScanned_c / gExtDeviceScanned_c アプリケーションコールバックに届けられます。 L4: アプリケーションタスクによって処理されるレポート。 この問題が発生すると、すべてのカウンターがL1で停止します。コントローラは広告レポートの生成を停止します。ホストとアプリケーションは関与していません: その時点では、Ble_HciRecv() はエラーを報告していません。 アプリケーションメッセージの割り当ては失敗しません。 アプリケーションキューが空です。 4. 統計 (5単位、約14.6日） ユニット#1:8回の失速イベント情報、8回の回収(持続時間11〜35秒) ユニット#2:9回の失速イベント情報、8回回復(持続時間11〜159秒);最後のイベント未回収(>8時間) ユニット#3:7回の失速イベント情報、7回の回収(持続時間11〜78秒) ユニット#4:失速2イベント情報、回収2イベント情報(持続時間11〜30秒) ユニット#5:失速3回、回収3回(持続時間12〜14秒) 合計:29回の失速イベント情報、28回の回復 （所要時間には、検出時間である10秒が含まれます。） 重要な観察事項： 28件 の回収されたイベント情報のうち、失速前に最後に受信したパケットは 二次広告チャネルに送られていました。CH_ADDR RX インデックスは、0x06、0x0A、0x0C、0x0E、0x10、0x12、0x14、0x16、0x1E、0x22、0x26、0x28、0x2A、0x30、0x3E、0x4A のいずれかでした。ほとんどの場合、PKT_PAYLOAD_STATUS = 0x0007、すなわち7バイトのペイロードです。これは、AUXパケットを受信した直後に停止現象が発生することを示唆している。 回復されなかったイベントでは、最後に受信されたパケットはプライマリチャンネル37にありました(CH_ADDR = 0x0018、PKT_PAYLOAD_STATUS = 0x0025)。 5. 未回復イベントのレジスタスナップショット(ユニット#2) -SCAN_STATUS(0x01C) = 0x0900 (Scan_on = 1、保留中の割り込みなし) -SCAN_NEXT_INSTANT(0x01E) = 0xB4B7 -REF_CLK(0x064) = 0xB4AD -CH_ADDR(0x0C4) = 0x0018 -PKT_PAYLOAD_STATUS(0x0D2) = 0x0025 -PKT_RSSI_STATUS(0x0D4) = 0x3FB3 -SCAN_SYNC_RX_PKT_CNT(0xF28) = 0x0000   SCAN_STATUS、CH_ADDR、PKT_RSSI_STATUS、およびSCAN_SYNC_RX_PKT_CNTは8時間以上変化しませんでした。この期間中、L1レポートカウンターも一定のままだった。 6. リリースノートのレビュー SDK 2.6.212で唯一のスキャン関連項目– 2.6.916 は 2.6.815 に含まれています。リンクレイヤーのバージョン別修正/変更点： 2.6.212(ble_controller 1.6.11.1):変更なし 2.6.415(2022年5月1日、6月14日):ホスト側の修正のみ 2.6.615(2023-02、1.6.14.1):ACLの早期終了オプション（Controller_SetPeripheralDiscThreshold） 2.6.715(2023-03、1.6.14.3):MDビット処理 2.6.815(2023-05、1.6.14.4):チャネルマップ修正; 「一部のケースで広告が見逃されていたスキャンの問題を修正しました。」 2.6.915(2023年9月、1.6.14.5):拡張通知の配置修正。自律長さ手順が無効化されました。 2.6.916(2023-10、1.6.14.6):EnhancedNotification でマッピングされていない ChannelNumber を返します (アルゴリズム #1) 7. 質問 これはKW38 BLEコントローラーの既知の問題でしょうか?2.6.815に関連していますか？「広告が表示されない原因となっているスキャン問題」を修正しますか？もしそうなら、修正された正確な状態を教えていただけますか? 拡張スキャン(AUXポインタをセカンダリチャネルに追い込む)で、LLスキャナーをSCAN_STATUS中はどのチャネルでも受信できなくなる状態にすることはできますか ?Scan_on 1のままですか? SDK 2.6.916で再発された問題ですが、新しいコントローラーライブラリやパッチはありますか? アプリケーションレベルでこの状態を検出し回復する推奨方法は何でしょうか?例えば： Gap_StopScanning() / Gap_StartScanning() で十分でしょうか？ コントローラのリセットが必要でしょうか(例:HCIリセットまたはLL SOFT_RESETコマンド）？ 確認すべきLLステータス登録簿はありますか？ 拡張スキャン（従来型スキャンのみ）を無効にすることで、この問題は回避できるでしょうか？ 診断用のアプリケーションからINIT_SCN_ADV_RX_FIFO(0x4008007C)を読み取ることは許されていますか?この読み取り値がコントローラのFIFOハンドリングに影響を与える可能性はありますか? Re: MKW38 BLE Scan not working when long time test 主な観察事項：[修正済み] - 28回の回収されたイベント情報のうちは、最後に受信したパケットは二次広告チャネルにあり、ほとんどの場合PKT_PAYLOAD_STATUS = 0x0007(7バイトのペイロードで、AuxPtrを搭載した拡張広告PDUに典型的)でした。これは、スキャナがAUXポインタを追跡している間にこれらの停止が発生することを示唆している。 - 回復されていないイベント(ユニット#2)は異なるシグネチャを持ちます。最後に受信されたパケットはプライマリチャンネル37にあり、37バイトのペイロード(PKT_PAYLOAD_STATUS = 0x0025)で、つまりおそらくレガシー広告PDUです。この件で広告の長期関与の兆候は見つかりませんでした。失速中INIT_SCN_ADV_RX_FIFO 3分ごとに0と表示され、コントローラは8時間以上回復しませんでした。 Re: MKW38 BLE Scan not working when long time test 注:以前のファームウェアでは、アプリケーションが定期的に0xFFFFをSCAN_INTR_CLEAR(0x4008001C)に書き込みていました。 そのファームウェアでは、INIT_SCN_ADV_RX_FIFOがデータを保持しているにもかかわらずSCAN_SYNC_RX_PKT_CNTが0になっているという、別の種類の停止現象が観測されました。J-Link経由で0x4008007Cを一度読み取ると、すぐにスキャンが回復しました。 その後、その書き込みは削除しました。このレポートの統計情報は、現在のファームウェアに基づいています。このファームウェアでは、FIFOは停止中に0を読み取り、その読み取りは復旧に影響を与えません。 Re: MKW38 BLE Scan not working when long time test こんにちは、 @JungkyuHan1 新しいCASEを作り出してくれてありがとう。 詳細情報を確認し、できるだけ早く最新情報をお知らせします。 BR、 Christine。 Re: MKW38 BLE Scan not working when long time test こんにちは、 @JungkyuHan1 返信までもう少しお時間をください。 社内チームにいくつか確認事項があります。 BR、 Christine。 Re: MKW38 BLE Scan not working when long time test こんにちは、 @JungkyuHan1 私の理解が正しければ、私はあなたから「 SDK 2.6.916 を使ってBLEスキャンテストを実施しました。かなりうまく動作しています。8日以上スキャンエラーはありませんでした。「2025年12月のことです。」 しかし今、あなたはこの問題に直面しています:「しかし、この問題は約1週間以内にSDK 2.6.916ライブラリで再現されました。" これらのOKとNOKのCASEの間にテストの違いはありますか? 違いが分かれば、今後の追跡調査に非常に役立つだろう。 ご質問は下記までお問い合わせください。 これはKW38 BLEコントローラーの既知の問題でしょうか?2.6.815に関連していますか？「広告が表示されない原因となっているスキャン問題」を修正しますか？もしそうなら、修正された正確な状態を教えていただけますか? ==>[クリスティン]: 先ほどお伝えした通り、はい、それは既知の問題です。そしてご存知のとおり、 私が知っているのは2.6..916のバージョンで、少なくとも回避策があればスキャンの問題に役立つと思います。私の知る限り、スキャンの問題はスキャンFIFOの競合が原因で、スキャンFIFOをフラッシュする必要があります。  拡張スキャン(AUXポインタをセカンダリチャネルに追い込む)で、LLスキャナーをSCAN_STATUS中はどのチャネルでも受信できなくなる状態にすることはできますか ?Scan_on 1のままですか? SDK 2.6.916で再発された問題ですが、新しいコントローラーライブラリやパッチはありますか? ==>[Christine]:すみません、この問題を解決した新しいSDKsリリースはSDKs 2.6.916以外ありません。 アプリケーションレベルでこの状態を検出し回復する推奨方法は何でしょうか?例えば： Gap_StopScanning() / Gap_StartScanning() で十分でしょうか？ コントローラのリセットが必要でしょうか(例:HCIリセットまたはLL SOFT_RESETコマンド）？ 確認すべきLLステータス登録簿はありますか？ ==>[クリスティン]: 回避策として、アプリケーションコードに以下のように手動で追加する必要がある場合があります。 ll_flush_adv_rx_fifo() という関数が必要です。この関数のコードはアプリケーションコードには存在しないので、「extern」を使い宣言する必要があります。この関数を外部化すると、入力パラメータと戻り値は両方ともvoidになり、その後、次のように呼び出されます。 1.スキャンを停止する前に毎回電話してください 2. デバイスが長時間スキャンされない場合は、スキャンを停止して再度呼び出し、スキャンを開始します。 拡張スキャン（従来型スキャンのみ）を無効にすることで、この問題は回避できるでしょうか？ 診断用のアプリケーションからINIT_SCN_ADV_RX_FIFO(0x4008007C)を読み取ることは許されていますか?この読み取り値がコントローラのFIFOハンドリングに影響を与える可能性はありますか? ==>[クリスティン]:これらの2つの質問については、もう少し調べてからお答えします。   BR、 Christine。 Re: MKW38 BLE Scan not working when long time test こんにちは、クリスティンさん。 ご返信よろしくお願いします。 OK CASE(2025年12月)とNOK CASEの違いについて: SDK 2.6.916に誤りがあることを発見しました移住。現在、正しいSDK 2.6.916で再テストを行っています図書館。 テスト設定も異なっていた。 前回のテスト（OK）：アンテナなしの3ユニット（サンプルユニット2台と開発ユニット1台）。 現在のテスト：アンテナを搭載した新型量産ユニット5台。 他にもいくつか質問があります。 2.6.815は「一部のケースで広告が見逃されるスキャン問題を修正しました」という修正方法を、SDK 2.6.916のスキャンFIFOロックアップ回避(ll_flush_adv_rx_fifo())と同じ修正ですか? フラッシュ後、従来のSTART_SCANコマンド（0x42）を使用してスキャンが再開されます。拡張スキャンを有効にした場合、この再起動後にAUX(セカンダリチャネル)の受信は正しく再開しますか? コントローラISRが動作している間に、アプリケーションタスクから直接ll_flush_adv_rx_fifo()を呼び出すのは安全ですか?コントローラのスキャン割り込み処理に並行性や同期の問題はありますか? SDK 2.6.615においてコントローラライブラリ、ll_self_device_data[18]のビット0とはどういう意味ですか?(2.6.615で同じフラッシュを手動で適用することを検討しています。) よろしくお願いします、 ハン・ジョンギュ Re: MKW38 BLE Scan not working when long time test こんにちは、 @JungkyuHan1 情報ありがとうございます。 ご質問への回答を得るため、現在社内チームに確認中です。 何か新しい情報があれば、お知らせします。 BR、 Christine。 Re: MKW38 BLE Scan not working when long time test こんにちは、 @JungkyuHan1 参考までに、弊社の社内チームからの回答を以下に記載いたします。 1. 拡張スキャン（従来型スキャンのみ）を無効にすることで、この問題は回避できますか？ [NXP]: 答えはノーです。このCASEは検証しませんが、拡張スキャンとは関係ないはずです。 診断のためにアプリケーションからINIT_SCN_ADV_RX_FIFO(0x4008007C)を読み取ることは 2.Is 可能でしたか?この読み取り値がコントローラのFIFOハンドリングに影響を与える可能性はありますか? [NXP]: アプリケーション側からはいつでも読み取るのは避けたほうがいいです。まずスキャンを止めてから読み取り、またスキャンを始めることができます 3.2.6.815は「一部のCASEで広告が見逃されるスキャン問題を修正しました」という修正方法を、SDK 2.6.916のスキャンFIFOロックアップ回避(ll_flush_adv_rx_fifo())と同じ修正ですか? [NXP]:今のところはわかりません。調査に時間が必要です。 4.フラッシュ後、従来のSTART_SCANコマンド（0x42）を使用してスキャンが再開されます。拡張スキャンを有効にした場合、この再起動後にAUX(セカンダリチャネル)の受信は正しく再開しますか? [NXP]: はい。ただし、この手順に従う必要があります。スキャンを停止 > ll_flush_adv_rx_fifo() > 再度スキャンを開始します。 コントローラISRが動作している間にアプリケーションタスクから直接ll_flush_adv_rx_fifo()を呼び出すのは安全 5.Is ですか? [NXP]: 前述の通り、スキャンを止めるときはll_flush_adv_rx_fifo()と呼ぶべきです コントローラのスキャン割り込み処理に並行性や同期の問題はありますか?6.Is [NXP]: 並行性や同期の問題とはどういう意味ですか?もう少し詳しく教えてもらえますか?上記の通りにスキャンを停止してフラッシュし、スキャンを再開すれば、並行性や同期の問題は起きないと思います。 7. 拡張スキャン(AUXポインタをセカンダリチャネルに追い込む)で、LLスキャナーがSCAN_STATUS中はどのチャネルでも受信できなくなる状態にすることはありますか?Scan_on 1のままですか? [NXP]:これまでのところ、そのような問題は見られていません。 BR、 Christine。

S32K312 FlexCAN – AEN有効化時のTXメッセージバッファアボートとRTD 7.0.1を使用したバスオフリカバリ NXPチームの皆様、こんにちは。 私はS32K3 RTD 7.0.1(AUTOSAR 4.9.0)を用いてNXP S32K312評価ボードを操作しています。RTD API FlexCAN_Ip_Send()およびFlexCAN_Ip_AbortTransfer()を使ってFlexCANのメッセージバッファ中止送信機能をテストしています 。 私のテストでは、中止機能が期待どおりに動作していません。参考資料として、プロジェクトファイル、MEX設定ファイル、およびテストコードを添付しました。 以下の3点について、ご指導いただければ幸いです。 1. 複数の送信メッセージバッファの中止 最初のテストでは、複数のメッセージバッファを使用してメッセージを送信し、その後、それらすべてのバッファに対して中止要求を発行します。テストコードは以下のとおりです。 /* Transmit messages using MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_Send( INST_FLEXCAN_0, lMb_u8, &tx_info, 0x123U, &dummyData[0] ); } /* Request abort for MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_AbortTransfer( INST_FLEXCAN_0, lMb_u8 ); } すべての送信要求は同じCAN ID 0x123を使用しますが、メッセージバッファのインデックスは0から39まで変動します。 MCR [AEN]ビットは1に設定されており、アボートメカニズムが有効になっています。しかし、メッセージバッファに対してアボート要求を発行しているにもかかわらず、PCAN-Viewにはすべてのメッセージが表示されてしまいます。 私の予想では、送信がまだ保留中のメッセージは中止されるべきであり、すでに送信が完了したメッセージは中止できないはずです。 以下の点を明確にしていただけますか? 複数のメッセージバッファで送信を行い、その後保留中の送信をすべて中止する場合、推奨される手順はありますか？ 2. 単一のメッセージバッファを使用して送信を中止する 問題を切り分けるために、メッセージバッファ8のみを使用する2つ目のテストを作成しました。 順序は次のとおりです。 MB8の場合はFlexCAN_Ip_Send()を呼び出してください。 FlexCAN_Ip_GetTransferStatus()を使用して転送ステータスを確認します。 送信が成功し、転送ステータスがFLEXCAN_STATUS_BUSYの場合は、 MB8 に対してFlexCAN_Ip_AbortTransfer()を呼び出します。 転送ステータスを再度読み取り、ハードウェアレジスタを検査してください。 送信APIはFLEXCAN_STATUS_SUCCESSを返し、中止前のステータスチェックではFLEXCAN_STATUS_BUSYが報告されます。しかし、中止APIはFLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS （ 0x5 ）を返します。 RTD実装のデバッグ中に、戻りステータスがFlexCAN_AbortTxTransfer()内の以下の条件から発生していることがわかりました。 FlexcanMbConfig = *FlexcanMb; /* Check if the MBs have been safely inactivated */ if ((uint32)FLEXCAN_TX_INACTIVE == ((FlexcanMbConfig & FLEXCAN_IP_CS_CODE_MASK) >> FLEXCAN_IP_CS_CODE_SHIFT)) { /* Transmission has occurred */ Result = FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS; } 現在の構成では、メッセージバッファはメモリブラウザーの0x40304100にあります。中止要求後、 CODEフィールドには、期待される中止コード0x9ではなく、非アクティブ/送信済み状態に対応する0x8が表示されます。 また、 FlexCAN_AbortTxTransfer()内の次のステートメントにブレークポイントを設定しました。 TimeStart = OsIf_GetCounter( FLEXCAN_IP_SERVICE_TIMEOUT_TYPE ); この時点で、 IFLAG1[8]が設定されます。 現在のRTD実装では、アボートシーケンスはメッセージバッファのCODEフィールドにFLEXCAN_TX_ABORT （ 0x9 ）を書き込み、対応するメッセージバッファの割り込みフラグをポーリングします。フラグは、アボートヘルパーが戻った後、FlexCAN_Ip_AbortTransfer()内のFlexCAN_ClearMsgBuffIntStatusFlag( )によってクリアされます。 私が懸念しているのは、中止要求が発行される前に、既に完了した送信によって割り込みフラグが設定されている可能性があることです。もしそうであれば、ポーリングループは新たな中止完了イベントを待つことなく即座に終了できます。しかし、これが私の問題の原因であるかどうかはまだ確認できていません。 3. 自動復旧が無効になっている場合のバスオフ復旧 別のテストでは、自動バスオフリカバリーを無効にし、アプリケーションでリカバリーを処理しようとしています。 バスオフ条件が発生した場合、現在の方法はFlexCANドライバを初期化解除し再初期化することです。しかし、このシーケンスの後、その後のFlexCAN_Ip_Send()呼び出しはメッセージを送信できません。 自動バスオフ回復が無効化された場合の推奨回収手順についてアドバイスいただけますか? 具体的には： 初期化解除と再初期化だけで、FlexCANコントローラをバスオフから復元できますか? 初期化解除前に、未処理のTXメッセージバッファをすべて中止または明示的にクリアする必要がありますか？ 再初期化後、送信前にメッセージバッファを再度設定または初期化する必要がありますか？ コントローラが再び送信する前に、ESR1ステータス、MCR、CTRL1[BOFFREC]、割り込みフラグ、またはRTD内部転送状態に関わる必要な手順はありますか? バスオフ状態からの復旧において、古いTX転送やメールボックスの状態が後続の送信を妨げないようにするための推奨手順は何ですか？ テストプロジェクト、MEXの設定、関連するソースコードを添付して、設定やAPIの使用状況を確認しています。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 こんにちは@Yogs あなたの3つの質問に対する回答を以下にまとめました。 （内容がかなり多く、フォーマットも少し乱雑です。） Q1。「フレックスカン・アボート」に関する質問について。 まず、FlexCANのアボートメカニズムは、保留状態にあるTXメッセージバッファ（MB）に対してのみ有効であることを理解する必要があります。 最初のテストについて： MB0が最初に起動されます。 FlexCANはスキャンを開始し、MB0の内容を送信します。 一方、CPUはMB1、MB2、…、MB39の構成を続行します。 CPUが最終的に2回目のループに到達する頃には、最初のMB群はすでに送信を完了している可能性が高い。 低バス負荷、ACK受信の成功、そしてクラシックCAN特有の8バイトペイロードなどの条件下では、 40フレームの送信は非常に速く完了できます。 2回目のテストについても同様で、バスがアイドル状態であれば、FlexCANはすでに送信を完了している可能性があります。 CPUが中止コマンドを実行する前に。 したがって、あなたの2つのテストはいずれも何も証明していません。 中止操作を適切に検証するには、CPUの実行速度に頼るのではなく、意図的に明確な「保留」期間を作成する必要があります。 例： 別のCANノードに、より優先度の高いIDでバスを継続的に占有するように設定し、ターゲットメッセージバッファ(MB)を保留状態に保ち、その後アボートをトリガーします。 Q2: なぜシングルMBテストは最初はBUSYで返却されるのに、中止リクエスト時にNO_TRANSFER_IN_PROGRESS戻るのでしょうか? 両者の間で短時間の状態不一致が生じることがあります: 「FlexCAN_Ip_Send()」はRTD(ランタイムドライバー)の状態を「BUSY」に設定します。 ハードウェアが送信を開始します。 フレームの送信が完了すると、ハードウェアはMB（メッセージバッファ）CODEを`0x8`に更新し、`IFLAG`を設定します。 TX IRQ ハンドラがまだ実行されていない場合、またはブレークポイント デバッグ中にシステムが一時停止されている場合、RTD 状態構造は `BUSY` のままになる可能性があります。 この時点で「中止」操作が呼び出されます。 内部的には、`Abort`関数はMB CODEを読み取り、それが既に`0x8`であることを確認します。 `FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS` を返します。 したがって、`GetTransferStatus() = BUSY` かつ `FlexCAN_Ip_AbortTransfer() = NO_TRANSFER_IN_PROGRESS` となります。 それらは必ずしも矛盾するものではない。 前者はソフトウェアの簿記を反映している場合があり、後者は実際のハードウェアコードを確認するものです。 Q3。バス離脱回収 CANモジュールを再初期化することで「バスオフ」状態から回復することは十分に可能です。 手動で「バスオフ」復旧を行うには、アプリケーション層がまずデータ伝送を停止し、保留中の送信(TX)リクエストをすべてキャンセルまたは破棄しなければなりません(中止)。 その後、コントローラは完全な初期化解除と再初期化を受けなければなりません。 その後、アプリケーション層受信(RX)メッセージバッファ(MB)を再構成し、古いメッセージバッファフラグ、エラーフラグ、ソフトウェア伝送状態をクリアする必要があります。 送信を再開する前に、アプリケーション層はコントローラが「フリーズ」または「準備不足」状態を解除したことを確認し、送信メッセージバッファ(TX MB)や「送信準備完了」(RTD)の状態が「混雑」状態に残っていないことを確認する必要があります。 テストが失敗したとおっしゃっていたので、おそらく上記の手順を見落としていたのでしょう。添付ファイルにはバス離脱の復旧手順に関する情報は見つかりませんでした。まだ疑問があれば、テストプロジェクトを私に共有してください。確認のために確認します。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 Q1について、私の試験条件を明確にしたいと思います。 CANボーレート は 500 kbps で 、8バイトのペイロードを持つクラシックCANフレームはバス 上で約 300μs の送信時間を要します。 私のテストでは、まずそれぞれのTXメッセージバッファを通してメッセージを送信し、その後すぐに中止関数を実行します。中止関数は対応するメッセージバッファを順に処理し、それぞれのバッファに対してFlexCAN_AbortTxTransfer()を呼び出します。 したがって、アボート要求は送信リクエストの直後にそれぞれのメッセージバッファに対して発行されており、意図的に遅延しているわけではありません。 最初の数通のメッセージは、中止ループが到達する前に送信が完了している可能性があることを理解しています。しかし、おおよその送信時間と送信されたメッセージ数を考慮すると、後続のメッセージバッファの一部は、中止要求が発行された時点でまだ送信待ちの状態になっていると予想されます。 保留中のメッセージが中止されるのを防ぐ他のハードウェア条件やタイミング要因があるのか、教えていただけますか? Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 こんにちは@Yogs これは、コード内の「abort MB」のデフォルトのシーケンスです。 for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,lMb_u8); } 「40 - 1Mb_u8」に変更しました。 for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,40 - lMb_u8); } 以下は私のテスト結果です。 受信したデータは2フレームのみで、その他のMBはすべて正常に中断されました。 この検証結果は、私が以前立てた仮説を裏付けるのに十分です。つまり、あなたが「MBの中止」操作を実行する前に、現在のMBは既に正常に送信されていたということです。

NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hello, I am using an NTAG X DNA with a Raspberry Pi 4B and an Adafruit PN532. I am trying to change the application AppMasterKey from the factory default AES-128 all-zero key to an AES-256 key using ChangeKey under an authenticated EV2 secure-messaging session. According to the datasheet revision, the intended AppMasterKey update is as follows: Authenticate with AppMasterKey 0x00 using AuthenticateEV2First Send ChangeKey in CommMode.Full Set KeyNo[7:6] to 11b for KeyType.AES256 Encrypt KeyData = NewKey || KeyVer (since the target key is the AppMasterKey ). This should be a 32-byte AES256 key + 1-byte version Apply ISO/IEC 9797-1 method-2 padding: 33-byte plaintext -> 48 bytes Append the 8 even-numbered bytes of the EV2 CMAC The APDU has the expected 57-byte data field but the tag return 0x917e error, which is a LENGTH_ERROR.  We have tried changing the AppMasterKey from the factory key AES128 default to a non-zero value and it succeeds. It also doesn't appear to be a transport size limit of the PN532 as it authenticates CryptoRequest commands with payloads up to 100 bytes and it succeeds. Additionally, the mutual authentication and EV2 session key derivation succeed before the failed ChangeKey command.  Finally, the Tag identifies itself as an NTAG X DNA via the GetVersion command. Could you please advise on the best approach to this? Are there any limitations/known issues with changing the keys to AES256 on the NTAG X DNA Series?  Thanks in advance. Regards, N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hi, Could you please repeat the test using Extended Length fields for Lc and Le? For example: 90 C4 00 00 00 00 39 C0 <48-byte encrypted data> <8-byte CMAC> 00 00 Regards, Eduardo. Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hello @EduardoZamora , Thanks a lot for your prompt reply.  The APDU we are trying to send is:  90c4000039c054d419618197a659d7346b7f7869b0a9972216d077258b6a58320d65019663e3695d16e265f93f594d131818ee9d889c7feb8ac85cb442b400 We are trying to simply change K0 from an all-zero AES128 to an all-zero AES256. Hope this helps. Please let me know if you need any additional information. Thanks again. Regards, N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hello @n_s Hope you are doing well. The overall procedure looks good. Still, the complete full raw APDU is important; could you please share the full frame you are trying to send? Regards, Eduardo.

TRIGMUX+eMIOSを用いたBLDCモータの方向測定 説明：私はNXPが推奨する6ステップ整流方式を使用してBLDCモーターを駆動しています。 アプリノート「 https://community.nxp.com/t5/S32M-Knowledge-Base/S32M276-Hall-sensor-based-6-step-BLDC-motor-control/ta-p/2035021#jump_PwmAndTriggers 」によると ホールセンサーの出力はTRIGMUXに送られ、その後LCUに送られ、整流や速度信号の計算にも使われます。この記事では運動方向の測定方法については触れていません。 NXP社製のモーター回転方向測定ソリューションはありますか？私の理解では、方向を測るには入力キャプチャユニットを使って3つのホールセンサー出力すべてをキャプチャする必要があるようです。 eMIOSチャネルを以下のように設定することは可能でしょうか? CH0 - TRIGMUXを介してLCUから速度信号を受信する入力キャプチャモード。 CH1 - Hall1を受信するための入力キャプチャモード。 CH2 - Hall2を受信するための入力キャプチャモード。 CH3 - Hall3を受信するための入力キャプチャモード。 もう少し詳しく説明してください。

i.MX95 19x19 EVK 搭配 JODY-W263-00B：在 Android 15 / Linux 6.12.23 系统上 WiFi 固件激活超时 标题：i.MX95 19x19 EVK with JODY-W263-00B：Android 15 / Linux 6.12.23 上的 WiFi 固件激活超时 您好，NXP团队， 我正在调试以下配置下的 WiFi 初始化： 板：NXP i.MX95 19x19 EVK WiFi模块：u-blox JODY-W263-00B Android 版本：AOSP 15（Android 属性验证待定） 运行内核：6.12.23-android16-5-maybe-dirty-4k NXP Android 电路板支持包的具体版本/标签：尚未确认 WiFi 驱动程序：mlan/moal (MWLAN) 选定的固件：sduart8987_combo.bin SDIO 设备：mmc2:0001:1 运行内核信息： 检测到 SDIO 设备，驱动程序报告“固件下载完成”。但是，固件在超时时间内没有激活，WiFi SDIO 探测失败。 相关命令：adb shell uname -a Linux 本地主机 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT Thu Jan 1 00:00:00 UTC 1970 aarch64 Toybox t 日志： [ 10.845985] mlan: loading out-of-tree module taints kernel. [ 10.961712] wlan: Loading MWLAN driver [ 10.973277] wlan: Register to Bus Driver... [ 11.016613] Attach moal handle ops, card interface type: 0x105 [ 11.070275] sta_name=wlan [ 11.086277] uap_name=wlan [ 11.086294] fw_name=sduart8987_combo.bin [ 11.168031] Enable moal_recv_amsdu_packet [ 11.168086] Attach mlan adapter operations.card_type is 0x105. [ 11.257673] wlan: Enable TX SG mode [ 11.257679] wlan: mpa_tx.buf_size=65280 [ 11.257682] wlan: Enable RX SG mode [ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156 [ 17.279039] FW failed to be active in time! [ 17.286246] wlan_dnld_fw fail ret=0xffffffff [ 17.296825] WLAN: Fail download FW with nowwait: 0 [ 17.502477] woal_request_fw failed [ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 [ 17.547534] wlan: Register to Bus Driver Done [ 17.553159] wlan: Driver loaded successfully 卸载并重新加载驱动程序后，我还观察到： [ 4051.080660] fw_name=sduart8987_combo.bin [ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0 [ 4056.079262] FW failed to be active in time! [ 4056.084697] wlan_dnld_fw fail ret=0xffffffff [ 4056.089909] WLAN: Fail download FW with nowwait: 0 [ 4056.250548] woal_request_fw failed [ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 我找到了这个相关的社区讨论： https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/88W8801-LILY-W131-WiFI-SDIO-chip-not-responding-after-FW/m-p/1986943 讨论的是基于 Nvidia AGX Orin 的 88W8801 芯片，因此它属于不同的模块/平台。作者报告称，移除no-sd配置并将总线宽度从 4 改为 1 后，性能有所提升，之后恢复到原始配置后运行正常。我尚未在我的主板上测试这些更改。 请问您能否帮忙澄清一下： sduart8987_combo.bin是JODY-W263-00B 的正确固件吗？对于这种 Android/内核组合，推荐使用哪个固件版本和 mlan/moal 驱动程序版本？ 对于 i.MX95 19x19 EVK 上的此模块，推荐的 SDIO 设备树设置是什么？特别是总线宽度、最大频率、引脚控制、电源、RESET GPIO 和电源时序延迟？ 测试 总线宽度是否等于 1<1> 或降低 SDIO 时钟频率有助于诊断此超时问题吗？移除 no-sd 参数 对于此平台是否相关或推荐？ 驱动程序报告固件下载完成后，固件激活超时可能是什么原因造成的？下载次数为0是否意味着在重试之前需要对模块进行完全断电重启或硬件RESET？ 针对这种板/模块/内核组合，是否存在已知问题或需要打补丁？ 为了区分固件/驱动程序兼容性问题与 SDIO 通信或电源/RESET时序问题，我应该收集哪些额外的调试设置、SDIO 寄存器转储或日志？ 确认后，我可以提供完整的启动日志、相关的设备树节点、 wifi_mod_para.conf以及确切的 电路板支持包/驱动程序版本。 谢谢！ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 您好，NXP团队， 我们已经收集了关于 i.MX95 19x19 EVK（JODY-W263-00B）固件激活超时的进一步诊断证据。 硬件模式验证 两次寄存器读取均成功： WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0 WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0 WIFI_DIAG: magic=0x24 strap=0x0 WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selection 根据我们的驱动程序来源，带掩码的表带表示 SD-UART 模式，这与配置的固件名称一致。 下载循环退出已确认 WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100 WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16 Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 在 100 次轮询尝试中，请求长度寄存器始终为零，导致下载循环退出。 固件二进制检查 利用源文件的 16 字节FWHeader布局和命令长度规则，离线解析在偏移量 619140 处识别出一条 CMD4 记录，该记录在 619156 处结束——与下载计数器完全匹配。源文件将 CMD4 定义为FW_HAS_LAST_BLOCK 。 此记录之后还有 9044 个字节。我们尚未确定其用途，也未确认这些解析规则是否完全描述了 SDIO 引导加载程序格式。因此，我们并不认为仅凭反差就能证明下载不完整。 其他详情： MOAL/MLAN 版本： 537.p9 嵌入式固件字符串： w8987o-V0、RF878X、FP92、16.92.21.p151.4 固件大小：628200 字节 安全散列算法(SHA)-256： db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 之前已验证过 50 MHz 下的实际 1 位 SDIO 操作，超时时间相同。 最新的诊断测试以 4 位、50 MHz 的频率运行。 预期固件 READY 状态为0xfedc ；观察到的状态仍为0xf005 。 未创建 Wi-Fi 网络接口。 NXP 电路板支持包的具体版本/标签仍在确认中。 请问您能否澄清一下： 对于这张特定的图像，在 CMD4 边界（偏移量 619156）处停止是否符合预期？剩余的 9044 字节有什么用途？ SD8987固件激活过程中， 0xf005表示什么？ 固件版本号为16.92.21.p151.4的固件是否支持 JODY-W263-00B 的驱动程序537.p9 ？我们应该使用哪个 电路板支持包 和固件/驱动程序软件包？ 针对此故障，建议检查哪些模块的电源/RESET时序、供电和参考时钟？ 哪些额外的寄存器或诊断信息可以区分固件启动失败与通信或硬件初始化问题？ 固件二进制文件保持不变。我们的源代码修改增加了诊断日志记录，并且提供了完整的启动日志和源代码差异。 谢谢！ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 关于失败阶段，有一点需要特别说明： 处理器通过 SDIO 检测到 SD8987 Wi-Fi 设备，固件下载例程报告“固件下载完成”。但是，在随后的激活检查期间，驱动程序期望SDIO_FIRMWARE_READY = 0xfedc ，而报告的状态为0xf005 。 因此，固件初始化和 SDIO 探测失败，并且没有创建 Wi-Fi 网络接口。在验证了 50 MHz 下实际的 1 位 SDIO 操作后，结果仍然不变。 请问在此阶段， 0xf005对于 SD8987 代表什么？还有哪些寄存器值或日志可以帮助确定固件为何无法达到 READY 状态？ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 您好，NXP团队， 继我最初的报告之后，我们完成了额外的检查和受控 SDIO 总线宽度实验。Wi-Fi 初始化在固件激活阶段仍然失败。 1. 已确认的设备和软件详情 板/模块：i.MX95 19x19 EVK，带 JODY-W263-00B Android 指纹： Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys 内核： 6.12.23-android16-5-maybe-dirty-4k NXP 电路板支持包的具体发布版本/标签：仍在确认中 SDIO 设备： mmc2:0001:1 SDIO ID： 02DF:9149 ，在驱动程序源中映射到 SD8987 主机控制器：USDHC3， mmc@428b0000 moal和mlan都报告了版本537.p9 MOAL 源版本： 358C14898F4DDF4EB40AB03 源代码库修订： nxp-mwifiex： 9630752ea1d9e28d9956adf27c652f40399e85ad IMX 固件： 34faa4b3008bf9c6f814b5767cacbc3857cdc49b 这两个提交的主题都是“MA-23689-1 [Android-15]WCS Q2 版本补丁集成”。目前仍在验证这些源代码版本与已安装模块构建的映射关系。 2. 固件身份验证已验证 选定的固件为/vendor/firmware/sduart8987_combo.bin ，大小为628200 字节。 源拷贝和已安装板拷贝具有相同的 SHA-256 值： db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 这证实了副本匹配；固件与模块的兼容性仍需确认。 3. 实际 1 位 SDIO 测试完成 最初，实时设备树报告总线宽度 = <1> ，但/sys/kernel/debug/mmc2/ios仍然显示 4 位操作。 在我们的源代码中， mmc_of_parse()不会清除总线宽度 = <1>的现有 4 位功能，而通用的 SDHCI 设置会添加MMC_CAP_4_BIT_DATA，除非设置了SDHCI_QUIRK_FORCE_1_BIT_DATA 。 因此，我们在sdhci-esdhc-imx.c中，紧接在mmc_of_parse()错误检查之后，添加了一个诊断块： { u32 bus_width; if (!of_property_read_u32(np, "bus-width", &bus_width) && bus_width == 1) { host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; host->mmc->caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA); } } 在重新构建并部署修改后的内核和 DT 配置后，我们验证了以下几点： Live DT bus-width: 00 00 00 01 clock: 50000000 Hz bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) 然而，同样的问题依然存在： Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 未显示Wi-Fi网络接口。 配置的最大频率为 100 MHz，但实际运行频率保持在 50 MHz。因此，我们没有进行低频测试。此外，所审查的 USDHC3 配置中缺少no-sd 选项，因此未执行移除操作。 4. 仅支持 WLAN 的固件重载测试 我们临时将sd8987_wlan.bin挂载到配置的固件路径，并重新加载了 MOAL。驱动程序读取了备用文件大小，但报告如下： firmwarelen=416836 downloaded 0 firmwarestat=0xf005 FW failed to be active in time! 由于这是在之前初始化失败后重新加载，因此我们认为结果不确定。它无法确定仅 WLAN 固件的兼容性或传输是否成功。 重启后，临时绑定挂载被移除，原始的 628200 字节组合固件再次得到验证。 5. 当前调查 我们正在moal_sdio_mmc.c中准备诊断日志记录，以捕获： 原始芯片信息和主机链路寄存器值。 两次寄存器读取的返回状态。 面具魔法和表带价值。 源文件定义了CHIP_MAGIC_VALUE = 0x24和CARD_TYPE_SD_UART = 0。现有的启动日志并未记录这些值。此日志记录更改尚未部署。 firmwarestat=0xf005的确切含义以及固件大小与下载计数器之间反复出现的9044 字节差异仍然未得到解决。我们不将完成消息视为固件已激活的证据。 请问您能否就以下问题提供建议？ 此固件/驱动程序代码包，软件包是否适用于此 BSP/内核上的 JODY-W263-00B？如何从二进制或软件包中确定具体的固件版本？ 对于这种固件格式，下载 619156个文件（对应 628200 字节的组合映像）是否正常，还是表示下载提前终止？ SD8987 在初始化期间固件状态0xf005代表什么含义？ 上述诊断主机驱动程序更改是否适合强制执行 1 位测试，或者是否有更推荐的 电路板支持包 机制？ 我们应该收集哪些寄存器/日志来验证基于表带的固件选择，显式fw_name是否会覆盖该选择？ 此次故障后，重试前需要执行怎样的电源/RESET顺序？您建议接下来进行低时钟频率测试还是进行其他针对性实验？ 我们可以提供完整的启动日志、DT/overlay 更改、主机驱动程序差异和wifi_mod_para.conf 。 谢谢！ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， 感谢您的咨询。 我看到你的 WiFi 模块使用的是uSDHC3接口，i.MX95-EVK 支持 M.2 KEY E 连接器上的 uSDHC3，所以我假设你使用的是基于 88W8987 的 M.2 WiFi 模块 JODY-W263-00B。 在 M.2 KEY E 连接器上启用 SDIO WiFi 时，我们需要明确以下步骤。 -- uSDHC3 IO 级别由 NVCC_WAKEUP 决定 NVCC_WAKEUP 为 1.8V（来自 VDD_1V8_S）。 --M.2 电源，VCC_KE_3V3 默认禁用 电源由 NX5P2924DUK 产生，M2_KE_PWREN 控制其启用。 3. 什么软件可以做到 （1）向 imx95-19x19-evk.dts 添加 uSDHC3 节点 默认情况下没有uSDHC3节点，需要手动添加。 [注意] 您可以参考 imx95-15x15-evk.dts 的添加它的 usdhc3 代码。 请注意不同的GPIO。 --启用电源GPIO --将 M.2 接口的 W_DISABLE1# 和 W_DISABLE2 引脚上拉。 --SDIO_WAKE# 和 SDIO_RST# 引脚 （3）Android 15 SDIO WiFi 电源启用 请检查 i.MX95 的 hardBoardConfig.mk 文件，确认是否已支持 pwrseq_simple.ko，如果未支持，请添加。或许像下面这样： ...... $(KERNEL_OUT)/net/wireless/cfg80211.ko \ $(KERNEL_OUT)/drivers/mmc/core/pwrseq_simple.ko \ ...... （3）启用 imx95-19x19_gki.fragment（名称可能不同，请确认。） ...... CONFIG_PWRSEQ_SIMPLE=m ...... （4）禁用 pcie1 节点（在imx95-19x19-evk.dts 中） ...... &pcie1 { pinctrl-0 = <&pinctrl_pcie1>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_slot_pwr>; 状态 = "已禁用"; }; ...... （5）BoardConfig.mk 可以直接支持 8987。 您可以将默认 WiFi 固件文件的名称更改为 88W8987 的名称。 好的，请试试。 谢谢！ 此致， 卫东 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 感谢您的指导。 我测试了以下配置更新，但固件初始化仍然失败： 已在imx95-19x19-evk.dts中禁用pcie1 。保留了现有的 uSDHC3 配置。 更新了BoardConfig.mk和SharedBoardConfig.mk中的 Wi-Fi 配置标签和模块参数文件名。 更新了evk_95.mk中的固件配置目标名称。 内核片段中已存在 CONFIG_PWRSEQ_SIMPLE=m。pwrseq_simple.ko 的运行时加载以及DTS电源序列连接仍需验证。 最新启动版本使用： moal.mod_para=wifi_mod_para_sd8987.conf 报告显示该模块为JODY-W263-00B，基于 NXP 88W8987 ，Wi-Fi 驱动程序版本为537.p9 。 当前固件版本： Path: /vendor/firmware/sduart8987_combo.bin Size: 628200 bytes SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 启动日志： SD8987: init module param from usr cfg card_type: SD8987, config block: 0 fw_name=sduart8987_combo.bin Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 之前，我还测试过来自lf-6.18.20_2.0.0分支的替换固件： Size: 644352 bytes SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823 其部署的哈希值已验证，但仍然出现相同的firmwarestat=0xf005激活失败。 能否提供或推荐一个适用于 JODY-W263-00B / 88W8987 且与驱动程序 537.p9 兼容的已验证的sduart8987_combo.bin 文件？请提供固件版本、仓库提交/标签、安全散列算法(SHA)-256 值以及推荐的模块参数。如果需要其他驱动程序版本，请指定匹配的驱动程序-固件组合。 作为参考，我们的源文件修订如下： Driver: 9630752ea1d9e28d9956adf27c652f40399e85ad Original firmware repository: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b 请告知0xf005代表什么，以及需要进行哪些额外的状态寄存器捕获或电源/RESET检查才能帮助确定问题原因。电气测量和完整的RESET序列验证仍在进行中。 问候， 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， 谢谢你的更新。 >>>关于 0xf005 代码 0xf005 表示驱动程序在轮询超时时间内未检测到固件达到就绪/活动状态。这是一个固件激活状态，而不是具体的硬件故障代码。但是，SDIO 通信、电源、RESET 或时钟等硬件问题仍然可能导致这种状态。 >>关于切换到 lf-6.18.20_2.0.0 分支： 正确的做法是使用该分支中完整且匹配的 Wi-Fi 驱动程序和固件。我们不应该只更换固件，因为驱动程序和固件版本必须兼容并保持同步。 所以您可以尝试将 Wi-Fi 驱动程序和固件更新到最新版本。 我有一个问题和一个建议： 一定要用Android 15吗？由于i.MX95比较新，最好使用最新的电路板支持包版本。你可以将 Android 16.0.0_2.0.0 与 L6.18.20_2.0.0 电路板支持包。一起使用。 我建议首先验证 Linux 电路板支持包。 上的 Wi-Fi 硬件、驱动程序和固件。一旦 Wi-Fi 模块在 Linux 上正常工作，就可以将该解决方案迁移到 Android 16。这种方法可以降低 Android 特定配置的复杂性，并使调试更加高效。 谢谢！ 此致， 卫东 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 谢谢你的解释。我们必须保留内核版本为 6.12.23 的 AOSP 15；升级到 Android 16 是不可行的。 请问能否推荐一款适用于 JODY-W263-00B / 88W8987 的 Wi-Fi 驱动程序-固件组合？据报告，我们当前的驱动程序为 537.p9。 如果您推荐lf-6.18.20_2.0.0中的驱动程序对，请确认该驱动程序是否支持内核 6.12.23，以及是否需要任何集成补丁。 请提供确切的驱动程序和固件提交/标签、匹配的sduart8987_combo.bin版本/校验和以及推荐的模块参数。 问候， 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 在查阅2025 年 10 月 14 日发布的 Android Automotive 版本说明 (RN00227)，版本号为 automotive-15.0.0_2.1.0 时，我注意到第 4 节表 2 — 连接 Wi-Fi 部分列出了适用于 i.MX95 的PCIe9098 / u-blox JODY-W3 。我已附上该条目的屏幕截图。 我们的设备使用： 板： i.MX95 19×19 EVK 模块： u-blox JODY-W263-00B / 88W8987 over uSDHC3 SDIO 电路板支持包。： Android Automotive 15.0.0_2.1.0 内核版本： 6.12.23 检测到 SDIO 设备并报告固件传输完成，但固件激活失败，固件状态为0xf005 。 请问您能否澄清一下： 是否已JODY-W263-00B / SDIO8987在此 电路板支持包。 上得到验证，或者除了之前建议的更改之外，是否还需要额外的集成？ 如果支持，能否提供匹配的驱动程序-固件版本以及所需的 DTS、电源/RESET和模块参数配置？ JODY-W3 / PCIe9098 是否是 此版本推荐的模块？如果建议更换，请提供模块/载板的准确部件号和所需的电路板配置。 我们必须保留 Android 15 和内核 6.12.23。请告知此配置支持的路径。 问候， 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， i.mx95 专为汽车应用而设计。 车载安卓系统支持Wi-Fi模块AW693和PCIe 88Q9098，我已经测试过AW693模块，没有问题。 我正在构建 L6.12.49 linux 电路板支持包，我想在 i.mx95 上测试 88W8987。 最佳阅读， 卫东 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 感谢您的详细解释。 我们了解到0xf005表示驱动程序在轮询超时时间内未观察到固件达到就绪/活动状态，并且它不是特定的硬件故障代码。 在我们的 i.MX95 19x19 EVK 上，使用 u-blox JODY-W263-00B (88W8987)，SDIO 检测和固件下载完成，但激活仍然超时，状态为0xf005 。 我们目前的平台是 Android 15，内核版本为 6.12.23，MOAL/MLAN 驱动程序版本为 537.p9。软件电源/RESET 检查和启动时 RESET 序列更改已完成，但问题仍然存在。物理电压、RESET 和时钟测量仍在进行中。 根据您的建议，我们计划首先使用完整的、匹配的驱动程序和固件对在 Linux 上验证 Wi-Fi。我们正在内部调查是否可以迁移到 Android 16。如果 Android 15 仍然是强制性的，我们将评估在保留内核 6.12.23 的情况下向后移植匹配的内核对。 请您确认以下事项？ 之前的测试结果：您在 i.MX95 上使用 JODY-W263-00B 进行 L6.12.49 测试的结果如何？ 已验证版本：此模块是否已在搭载 L6.18.20_2.0.0 和 Android 16.0.0_2.0.0 的 i.MX95 19x19 EVK 上进行过验证？ Linux 设置：请提供清单分支和 XML 文件名、机器、发行版。、镜像名称以及官方版本/刷写说明。 匹配的 Wi-Fi 对：请提供驱动程序仓库和版本号、固件包名和版本号、正确的固件文件名以及所需的模块配置。sduart8987_combo.bin 是否适用于此模块的 SD-UART 配置？ Android 设置：请确认相应的 Android 版本和清单文件，包括汽车版本（如果适用）。 其他诊断：是否需要任何特定的设备树设置、电源/复位时序、补丁或寄存器转储来调查此激活超时问题？ Linux 验证完成后，我们将分享启动日志、驱动程序/固件版本、固件 安全散列算法\(SHA\)-256 和可用的硬件测量数据。 此致， 拉凯什·塔库尔 Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 卫东您好， 根据您的建议，我们集成了来自lf-6.18.20_2.0.0的匹配 Wi-Fi 驱动程序和固件对。但是，固件激活失败的问题仍然存在。 在进行进一步更改之前，我们需要确认我们已安装的 Wi-Fi 模块所支持的驱动程序-固件包，以及其下载来源和支持所有者。 1. 硬件和软件设置 元器件详情 电路板 NXP i.MX95 19×19 EVK 已安装Wi-Fi模块 u-blox JODY-W263-00B Wi-Fi芯片组 NXP 88W8987 Wi-Fi接口 SDIO 预期的蓝牙接口 UART Android BSP 汽车版 Android 15.0.0_2.1.0 内核基 2023年6月12日 检测到 SDIO 设备 mmc2:0001:1 我们安装的模块使用 SDIO 接口连接 Wi-Fi，而不是默认 EVK 设置中使用的 PCIe Wi-Fi 配置。请您根据JODY-W263-00B / 88W8987 在 SD-UART 模式下的配置提出建议。 2. 原始驱动程序和更新的驱动程序-固件对 元器件原始设置 更新设置 驱动程序版本 537.p9 543.p18 固件嵌入式版本 16.92.21.p151.4 16.92.21.p156.2 固件文件名 sduart8987_combo.bin sduart8987_combo.bin 固件大小 628200 字节 644352 字节 结果 激活超时，错误代码0xf005 相同的激活超时错误， 0xf005 更新后的组件对选自lf-6.18.20_2.0.0 ，并已移植到我们现有的Android 15 / 内核 6.12.23环境中。我们尚未执行完整的 Android 16 / Linux 6.18 电路板支持包。迁移。 选定的参考，引用文献修订： Driver: 2e481212d262758cbd4d0fc7ea95a2ad5f704bc3 Firmware: cc78ca8b1ee28ff741bcc160246f61b008f6c89f 3. 整合与部署证据 更新后的驱动程序编译和 MODPOST 测试通过。 图片打包和本地AVB验证均已通过。 刷机后，已验证加载的驱动程序版本为543.p18 。 板模块和固件哈希值与包装件相符。 SDIO枚举成功。 首次刷写固件后启动以及冷启动测试期间均出现相同的激活失败情况。 我们还直接检查了集成源中的更新固件： Filename: sduart8987_combo.bin Size: 644352 bytes Embedded identification: $Id: w8987o-V0, RF878X, FP92, 16.92.21.p156.2 $ SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823 4. 失败证据 原装一对： SD8987: init module param from usr cfg card_type: SD8987, config block: 0 fw_name=sduart8987_combo.bin Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 更新后的配对： Wlan: FW download over, firmwarelen=644352 downloaded 635356 Fail to poll firmware status: firmwarestat=0xf005 Firmware Init Failed probe with driver wlan_sdio failed with error -1 驱动程序检测到模块并报告固件传输完成，但固件激活失败。目前来看，这并未指向明显的检测故障或固件文件加载故障。但是，我们并不声称该驱动程序已完全验证，也不声称固件不兼容是已确认的根本原因。 5. 具体确认和代码包，软件包要求 请回答以下关于JODY-W263-00B / 88W8987的问题： 上述两对驱动固件是否都支持此模块的 SD-UART 模式？请分别确认每对驱动固件。 现有驱动程序是否适用，只需更换固件即可？还是必须使用另一套匹配的驱动程序-固件组合？请明确指出支持的具体组合。 我们可以在哪里获取该软件包？请提供官方下载链接、代码仓库/分支和提交记录，或者申请访问权限的流程。 负责提供和确认相关信息的是恩智浦半导体（NXP）还是优布洛克（u-blox）？如果需要优布洛克（u-blox）的支持，请说明相应的支持途径以及我们需要索取的软件包信息。 NXP 88W8987 通用固件是否适用于 JODY-W263-00B，还是该模块需要 u-blox 认证的软件包或额外的模块特定文件/配置？ 确认该模块对能否在 Android 15 / 内核 6.12.23 上运行？如果需要其他补丁，请注明。如果该平台不受支持，请指定一个受支持的电路板支持包。以及该模块已知的可用配置。 推荐此次驱动程序更新的具体依据是什么？是537.p9和固件16.92.21.p151.4存在已知问题，还是此建议旨在建立一个一致的版本基线？ 我们何时可以收到兼容性确认信息以及推荐软件包的获取途径？如果需要工程审核，请提供预计的响应时间。 如果更新后的配对对于此模块来说已经是正确的，请明确说明，并确定针对0xf005激活失败的下一个目标诊断检查。 本地还纠正了另一个 Binder 模块封装不匹配的问题；这些已纠正的图像仍需重新测试电路板。尚未确定其与 Wi-Fi 故障的关系。 我们目前的请求是确认特定模块的正确驱动程序和固件、其官方来源、负责的供应商以及预期时间表，以便从已验证的基线开始进行进一步的测试。 谢谢！ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， 请暂时不要担心。Yocto 电路板支持包。仍在版本中，服务器速度有点慢。我预计下周会拿到一些检测结果。     谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 请确认驱动程序537.p9 + 固件 16.92.21.p151.4和驱动程序543.p18 + 固件 16.92.21.p156.2是否支持JODY-W263-00B / 88W8987 在 SD-UART 模式下的固件组合。对于后一种组合，请同时确认其在Android 15 / 内核 6.12.23上的兼容性，包括所需的补丁或配置。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 根据您的建议，我们现在已经将lf-6.18.20_2.0.0中的完整匹配 Wi-Fi 驱动程序和固件对集成到我们的 i.MX95 19×19 EVK 上，并测试了JODY-W263-00B / 88W8987 。 必须保留 Android 15 和内核 6.12.23。 综合修订： 驱动程序： 2e481212d262758cbd4d0fc7ea95a2ad5f704bc3 固件： cc78ca8b1ee28ff741bcc160246f61b008f6c89f 已加载 MLAN/MOAL 版本： 543.p18 固件： sduart8987_combo.bin ，644352 字节 编译和图像打包均已完成。在板上，我们根据软件包中的工件验证了预期的内核、加载的驱动程序版本以及模块/固件哈希值。Android启动和SDIO枚举成功。 然而，无论是首次刷写固件后的启动还是冷启动测试，都出现了相同的激活失败情况： Wlan: FW download over, firmwarelen=644352 downloaded 635356 Fail to poll firmware status: firmwarestat=0xf005 Firmware Init Failed probe with driver wlan_sdio failed with error -1 未创建 WLAN 接口。因此，将匹配对从537.p9更新到543.p18并未解决此故障。 软件电源/RESET顺序更改已生效。实物供应、RESET和时钟测量仍待进行。之前在 50 MHz 下进行的 1 位 SDIO 测试也出现了同样的超时现象。 此外，我们发现rust_binder存在内核/系统模块不匹配的问题，并使用匹配的模块重新构建了镜像。对修正后的镜像集进行板级重新测试正在进行中；其与 Wi-Fi 故障的关系尚未确定。 您能否帮助我们确定下一步工作的优先顺序？ 您的Linux测试：您计划在i.MX95上使用88W8987芯片进行L6.12.49测试，结果如何？请确认所使用的具体模块/载板、驱动固件版本以及DTS配置。 Android 15 支持： 543.p18这个固件对是否适用于 6.12.23 内核？是否需要任何兼容性补丁，或者您是否推荐其他经过验证的固件对？ 针对性诊断：我们了解到0xf005表示未能达到 READY 状态。您的 Wi-Fi 团队能否解读此特定的 SD8987 状态，并提供调查启动失败所需的确切寄存器、地址和捕获步骤？ 下一个受控实验：鉴于配对积分和 1 位测试已经完成，我们接下来应该执行哪个单软件实验，采用什么设置，预期结果是什么？ 硬件验证：请提供此板/模块组合所需的供电水平、RESET时序、时钟要求和已确认的测量点。 如果 JODY-W263-00B 尚未在此 Android 版本上进行验证，请明确说明，并推荐受支持的集成或替换路径。 提供完整的启动日志、源代码差异、哈希值和镜像验证记录。 问候， 拉凯什·塔库尔 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 谢谢你的更新。我们将在下周等待您的检测结果。 请确认您的测试装置是否使用了带有SDIO Wi-Fi功能的u-blox JODY-W263-00B / NXP 88W8987模块？ 分享结果时，请提供确切的 电路板支持包。 版本、驱动程序版本、固件版本/文件和所需的电路板配置。如果测试成功，请告知我们可以在哪里获得相同的驱动程序-固件对。 这将有助于我们重现您的工作设置，并将其与我们的 Android 15 / 内核 6.12.23 集成进行比较。 谢谢，并致以最诚挚的问候！ 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 我们现在已经完成了对配备 JODY-W263-00B / 88W8987 的 i.MX95 19×19 EVK 的以下三项测试： 原始配置：车载安卓系统版本15.0.0_2.1.0 ，内核版本6.12.23 ，驱动版本537.p9 ，固件版本16.92.21.p151.4 。应用您建议的 DTS 和电源/RESET配置更改后，激活失败的问题仍然存在。 向后移植的设置：集成了来自 Linux 版本lf-6.18.20_2.0.0的匹配驱动程序543.p18和固件16.92.21.p156.2 ，保留了 Android 15 和内核 6.12.23。同样的故障仍然存在。 Linux 验证：已构建、刷写并测试 Linux 电路板支持包。L6.18.20_2.0.0，运行内核 6.18.20-2.0.0-g88cb92741827。出现同样的故障。 在所有三种配置中，固件激活均超时，并显示firmwarestat=0xf005 错误，且未创建任何 WLAN 接口。附件截图显示了 Linux 系统下的结果。 因此，我们已尝试了您推荐的驱动程序-固件匹配更新和 Linux 电路板支持包。 验证。能否请您建议下一步的针对性调试方法，并分享您计划进行的 L6.12.49 测试？物理电源/复位/时钟测量仍待完成。   问候， 拉凯什 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 嗨卫东， 感谢您分享成功的 W603C 测试和 DTS。 我们 在 i.MX95 19×19 EVK 上 使用 u-blox JODY-W263-00B (88W8987) 。固件下载完成，但激活失败，错误代码为 0xf005 。我们的最终目标是 Android 15.0.0_2.1.0 / 内核 6.12.23。 在测试您的更改之前，请您澄清以下几点： 此配置是否也适用于 JODY-W263-00B？W603C 是必须更换的模块，还是只是用于测试的模块？ 描述中提到了 P0_5，而 DTS 使用的是偏移量 4 (P0_4)，GPIO_ACTIVE_HIGH。请确认RESET和正常运行期间正确的 GPIO 和所需的物理电平，特别是对于 W_DISABLE2#。 请分享驱动程序版本、固件二进制文件/哈希值、wifi_mod_para.conf 文件以及所使用的确切 电路板支持包。 清单/构建配置。 我们计划将您的 DTS 与我们的设置进行比较，并在我们现有的 JODY 模块上测试适用的更改。 此致， 拉凯什 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 尊敬的@Rakesh_Kumar-Thakur ， 我在Linux平台上启用了88W8987 M.2模块。 --L6.12.49_2.2.0 --模块：Amphenol W603C（基于 88W8987） 0. i.MX95-EVK 硬件上的控制流。 =================================================== 1. Linux 平台上的 Wi-Fi 加载机制。 因此，Wi-Fi驱动程序将在Linux启动期间加载。 2. 调整设备树 - 添加 usdhc3 节点和相关的 GPIO 控制。 （1）PCAL6524HEAZ.P2_4 -- 输出高 -- 启用 VCC_KE_3V3，默认情况下由 imx95-19x19-evk.dts 支持。 reg_m2_pwr：regulator-m2-pwr { 兼容 = "稳压器固定"； 稳压器名称 = "M.2-power"; 调节器最小微伏 = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&i2c7_pcal6524 20 GPIO_ACTIVE_HIGH>; 启用高电平有效； /* * 只有在所有电源操作完成后，才能启用 M.2 设备（W_DISABLE1#）。 * 电源轨达到其最低工作电压（PCI Express M.2） * 规范 r5.1 3.1.4启动时机）。 * 在此处设置一个等于 Tsettle 最大值的延迟。 */ 启动延迟-us = <5000>; }; (2) 上拉 SDIO_RST# 引脚 PCAL6524HEAZ.P2_3 & P0_5 - 输出高电平 - 启用 Wi-Fi/蓝牙模块。 由 usdch3 节点的 'mmc-pwrseq' 直接加载。   usdhc3_pwrseq: usdhc3_pwrseq { 兼容 = "mmc-pwrseq-simple"; pinctrl-names = "default"; reset-gpios = <&i2c7_pcal6524 19 GPIO_ACTIVE_LOW>, <&i2c7_pcal6524 4 GPIO_ACTIVE_HIGH>; /* W_DISABLE2# */ }; (3)将 W_DISABLE1# 引脚上拉以启用 WiFi PCAL6524HEAZ.P0_6 - 输出高电平 - 启用 Wi-Fi。 由 usdch3 节点的 ‘vmmc-supply’ 直接加载。 reg_usdhc3_vmmc：regulator-usdhc3 { 兼容 = "稳压器固定"； 调节器名称 = "WLAN_EN"; 调节器最小微伏 = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&reg_m2_pwr>; gpio = <&i2c7_pcal6524 6 GPIO_ACTIVE_HIGH>; /* * IW612 WiFi芯片比其他WiFi芯片需要更长的延迟才能完成加载 * 上电后进行主机接口初始化，否则 * IW612的内部状态可能不稳定，导致故障 * SDIO3.0 开关电压。 */ 启动延迟-us = <20000>; 启用高电平有效； }; （4）usdhc3 引脚控制 pinctrl_usdhc3: usdhc3grp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe >; }; （5）禁用 M.2 上的 PCIe0（可选的，由于未使用，因此禁用它） &pcie0 { pinctrl-0 = <&pinctrl_pcie0>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_pcie0>; 支持-clkreq； 状态 = "已禁用"; }; （6）添加usdhc3节点 &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; pinctrl-3 = <&pinctrl_usdhc3>; mmc-pwrseq = <& usdhc3_pwrseq >; vmmc-supply = <& reg_usdhc3_vmmc >; 总线宽度 = <4>; 保持电源处于挂起状态； 不可拆卸； 唤醒源； 状态 = "正常"; }; 3. 运行 Linux 电路板支持包。并收到 Wi-Fi 消息 这表明，从硬件平台的角度来看，i.MX95-EVK 上的 M.2 SDIO 接口完全支持 SDIO Wi-Fi 设备，没有任何问题。   附件是我使用的dts文件。在这里和大家分享一下。 请测试一下。   谢谢！ 顺祝商祺！ 卫东 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 尊敬的@Rakesh_Kumar-Thakur ， 谢谢你的更新。 >>此配置是否也适用于 JODY-W263-00B？W603C 是必需的替换件，还是仅仅是您测试时使用的模块？ --此配置是否也适用于 JODY-W263-00B？ 是的，完全一样。因为 M.2 Key E 是 Wi-Fi 卡的标准规格。 --W603C 是必需的替换模块，还是仅仅是您测试时使用的模块？ 不需要。 因为目前的测试结果只能表明 i.mx95-evk M.2 对于 SDIO Wi-Fi 没有问题。 这并不意味着 JODY-W263-00B 有问题。 >>说明中提到的是 P0_5，而 DTS 使用的是偏移量 4 (P0_4)，GPIO 为 ACTIVE_HIGH。请确认 RESET 和正常运行期间的正确 GPIO 和所需的物理电平，特别是 W_DISABLE2#。 是的，应该是 P0_4，我的错。 >>请分享驱动程序版本、固件二进制文件/哈希值、wifi_mod_para.conf 文件以及所使用的确切电路板支持包。清单/版本配置。 这是司机分支的链接。 https://github.com/nxp-imx/mwifiex/tree/lf-6.12.49_2.2.0 但请记住，您遇到的问题并非由驱动程序引起。不要尝试更改WiFi驱动程序。没用。 下周，我将准备 Android 15 的源代码并尝试启用它。 您使用的安卓电路板支持包。是汽车版还是标准安卓电路板支持包。？ 谢谢！ 顺祝商祺！ 卫东 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 嗨卫东， 感谢您确认该配置适用于 JODY-W263-00B，无需更换 W603C，并且正确的 GPIO 为 P0_4。 我们使用的是汽车级 Android 电路板支持包。 ，其基线如下： 板： i.MX95 19×19 EVK 模块： u-blox JODY-W263-00B / 88W8987，SDIO 电路板支持包。：汽车 Android 15.0.0_2.1.0 清单文件： imx-automotive-15.0.0_2.1.0.xml 版本目标： evk_95_car-nxp_stable-userdebug 内核版本： 6.12.23 我们最终的要求是在上述 Android 15 / 内核 6.12.23 基线上启用此模块。 我们已完成计划中的万用表和示波器检查，检查范围包括模块电源、RESET、W_DISABLE1#/PDn 和 SDIO CLK/CMD/DATA0–3。测量结果和波形捕获已记录在案。固件下载仍然完成，但随后出现相同的激活超时，固件状态码为 0xf005。 根据您的建议，我们将停止进一步的驱动程序版本更改，并将重点放在剩余的配置和排序检查上。 我们也查看了您分享的驱动程序分支。该分支将驱动程序版本标识为540.p33 ，当前分支 HEAD 地址为84ca65c9ff935d7f2999af100a82531c22c65234 。该仓库包含固件文件名引用，但不包含固件二进制文件、实际的模块参数配置或板级 DTS。 请问您能否帮忙解决以下问题？ P0_4 / W_DISABLE2# 时序：请确认上电、RESET 置位、RESET 释放和正常运行期间所需的物理高/低电平。您的 DTS 将 P0_4 列为RESET GPIO的GPIO_ACTIVE_HIGH，并将 P2_3 / 偏移量 19 列为GPIO_ACTIVE_LOW。这种组合对于 JODY-W263-00B 是否是预期的？上电序列完成后，每个引脚的物理电平应该是什么？ 测试固件及参数：请提供您在成功测试 W603C 时使用的确切固件二进制文件，包括文件名、版本和 安全散列算法\(SHA\)-256 哈希值，或者提供下载链接和确切的仓库提交信息。请确认是否应将相同的固件用于 JODY-W263-00B。此外，请提供实际使用的 wifi_mod_para.conf文件，或者如果没有使用配置文件，请提供确切的模块加载命令和参数。 Linux 参考测试成功：请确认您的测试是否使用了上述驱动程序提交，以及是否应用了任何其他驱动程序补丁。为了使用我们现有的 JODY 模块复现您的 L6.12.49_2.2.0 测试，请提供最终的板级 DTS/补丁以及完整的电路板支持包。清单、MACHINE、发行版。和镜像配置。您是否建议在进行 Android 测试之前进行此对比？如有合适的预构建镜像，也请提供。 计划进行 Android 15 测试：请您使用与我们的基准版本一致的 Automotive Android 15.0.0_2.1.0 / 内核 6.12.23 版本。同时，请确认您将使用 W603C 还是 JODY-W263-00B 进行测试。测试完成后，请提供启用补丁、固件详细信息和初始化日志，以便我们重现测试结果。 我们可以提供硬件验证报告、波形捕获、当前 DTS 和完整的启动/驱动程序日志以供比较。如果您需要任何其他针对性测量或寄存器转储，请与我们联系。 我目前正在全力以赴地进行此次启动工作，您对剩余要点的澄清将有助于我继续进行接下来的测试。如果可以的话，我希望您能尽早回复，特别是关于 GPIO 时序和测试固件/配置方面的回复，以便我可以在您准备 Android 15 设置的同时继续进行验证。 感谢您一直以来的支持。 此致， 拉凯什 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 尊敬的@Rakesh_Kumar-Thakur ， 实际上，只要它是基于 NXP 88Q9098、AW693 M.2 Key E 模块的，它就能工作。所以，你选择 u-blox 模块是没问题的。 我修改了适用于 Auto Android 15_2.1.0 的代码。针对88W8987，本周将有测试结果。如果您的应用是为汽车用途而设计的，那么您确实需要使用专为汽车功能域设计的 NXP 88Q9098、AW693 Wi-Fi 芯片。   谢谢！ 顺祝商祺！ 卫东 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 嗨卫东， 在购买支持的 Wi-Fi 网卡之前，请您确认在搭载汽车 Android 15.0.0_2.1.0 系统的 i.MX95 19×19 EVK 上测试的网卡的确切制造商和完整的 M.2 订购部件号。/ 内核 6.12.23？ 我们正在考虑： M2-JODY-W377-00C — 基于 NXP 9098 的 PCIe Wi-Fi / UART 蓝牙模块 M2-JODY-W683-00C — 基于 NXP AW693 的 请确认您推荐的具体显卡型号、芯片组编号，以及它是否与已发布的 电路板支持包。兼容，还是需要额外的补丁/配置。如果可以，请分享购买链接。 此致， 拉凯什 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 嗨卫东， 感谢您确认默认支持 88Q9098 和 AW693。 我们已在 DigiKey 和 Mouser 上查询过这些 M.2 卡，但目前两家都无库存： M2-JODY-W377-00C — 基于 9098 M2-JODY-W683-00C — 基于 AW693 我们需要在短短一周内演示 i.MX95 19×19 EVK（搭载 Automotive Android 15.0.0_2.1.0 系统）的 Wi-Fi 功能。/ 内核 6.12.23。您能否推荐其他供应商、购买链接或可用的兼容 M.2 卡？提供评估样本也会有所帮助。 是否有其他 Wi-Fi 模块在搭载 Android Automotive 15、Android 16 或其他电路板支持包。版本的 i.MX95 上成功测试过？如果属实，请提供 M.2 卡的确切部件号、芯片组、已测试的 电路板支持包。/内核版本以及购买来源。我们的最终目标仍然是 Android 15 / 内核 6.12.23，因此请说明这些替代方案是否需要为我们的目标进行额外的集成。 同时，我们现有的 JODY-W263-00B / 88W8987 固件激活仍然失败，错误代码为0xf005 。能否请您优先提供帮助，并分享任何可用的启用补丁、匹配的驱动固件包以及您的 Linux 和 Android 测试结果？ 您提到我们可以把我们的模块寄给您进行测试。我们的办公室位于印度马哈拉施特拉邦浦那市。您能否协助安排与诺伊达NXP团队进行联合调试？或者，如果 NXP 在浦那设有办事处或合适的技术支持团队，请与我们联系。 我可以在本周内带着模块和（如有必要）我们的 EVK 进行访问，最好是在 10 月 29 日星期四之前，具体取决于团队的空闲时间。您的协调和持续参与将有助于当地团队在已完成的调查基础上继续开展工作。 请与我们联系，告知此事是否可以安排，以及我们应该联系谁。如果无法进行本地测试，请告知我们如何安排将模块寄送给您。 此致， 拉凯什 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 尊敬的@Rakesh_Kumar-Thakur ， 感谢您提供如此详细的信息。 >> P0_4 / W_DISABLE2# 时序：该引脚应上拉至高电平，用于启用蓝牙。使用外部上拉电阻将其拉高到高电平没有问题。有些 M.2 模块使用 PIN 码来控制蓝牙软件 RESET，但有些模块不使用 PIN 码。W603C 使用了它。 >>JODY-W263-00B。 我手头没有 M.2 模块，但我有 AW-CM358-SUR（M.2 模块），我明天也会在 Linux 平台上测试一下。 >>>在 Android 15-2.1.0 自动上启用。 是的，我计划在 电路板支持包版本下启用 8987 模块。你知道安卓源代码的仓库同步需要很长时间。所以我需要一些时间。 默认情况下，汽车安卓电路板支持包仅支持 88Q9098 和 AW693，它们是汽车 Wi-Fi 产品。对于其他 Wi-Fi 芯片，我们需要做一些额外的工作才能启用它。 [注意] 如果 W603C 或 AW-CM358-SUR M.2 模块在我这边可以正常工作，而JODY-W263-00B 仍然无法工作，您可以考虑寄一个 JODY-W263-00B 给我，让我在我的平台上测试一下。 谢谢！ 顺祝商祺！ 卫东 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 嗨卫东， 固件大小差异是否与我们的初始化失败有关？ 固件文件大小为 628,200 字节，但驱动程序报告只下载了 619,156 字节——相差 9,044 字节。我们的诊断日志显示，该设备在偏移量 619,156 处停止请求进一步数据。离线解析发现最后一个块记录以相同的偏移量结束，但剩余字节的用途仍未确定。 这是该固件映像的预期行为吗？还是说这表示传输不完整，导致后续出现0xf005激活超时？ 我们使用 JODY-W263-00B / 88W8987，驱动程序版本为 537.p9，固件版本为 16.92.21.p151.4，运行在车载 Android 15.0.0_2.1.0 系统上。/ 内核 6.12.23。 此致， 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， 当我尝试启用基于 88W8987 的 AW-CM358MA 模块时，我遇到了和你一样的问题。 ================================= 固件状态轮询失败：firmwarestat=0xf005 SDIO 功能0： 43 03 02 02 03 00 00 02 03 00 SDIO 功能1： (0x5c) 0d (0x60) 01 (0x64) 10 SDIO 功能1： 05 f0 00 00 00 00 00 00 24 14 70 ... ================================= 让我们按照以下步骤解决问题： 1. 88W8987 GPIO[8]引脚。（参见数据手册） 该引脚有 2 个功能：时钟配置和 UART_SOUT。 启动 88W8987 时，引脚应为低电平以选择 38.4MHz 时钟。 但是，如果主机 UART_RXD 引脚配置为上拉，则 88W8987 UART_SOUT 也将上拉。 这意味着选择的是 26MHz 时钟，而不是 38.4MHz 时钟。实际上大多数模块使用38.4MHz时钟。 所以我们应该将 LPUART5_RXD PAD 配置更改为下拉。 2. 更改LPUART5_RXD 焊盘配置 ...... IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e ...... 3. 向您分享我的完整设备树。 请查看附件。 请试一试。 顺祝商祺！ 卫东 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， 我已在 i.mx95-evk 和 auto android 15_2.1.0 上启用了 AW-CM358MA 模块bsp。让我来告诉你具体步骤。 ========================================== 1. android_build/设备/nxp/imx9/evk_95/evk_95.mk # nxp 9098 WiFi 和蓝牙组合固件 PRODUCT_COPY_FILES += \ 供应商/nxp/imx-firmware/nxp/FwImage_IW416_SD/sduartiw416_combo.bin：供应商/固件/sduartiw416_combo.bin \ 供应商/nxp/imx-firmware/nxp/FwImage_9098_PCIE/pcieuart9098_combo_v1.bin：供应商/固件/pcieuart9098_combo_v1.bin \ vendor/nxp/imx-firmware/nxp/FwImage_IW612_SD/sduart_nw61x_v1.bin.se:vendor/firmware/sduart_nw61x_v1.bin.se \ 供应商/nxp/imx-firmware/nxp/FwImage_AW693_PCIE/pcieuartaw693_combo_v1.bin.se：供应商/固件/pcieuartaw693_combo_v1.bin.se \ 供应商/nxp/imx-firmware/nxp/FwImage_8987/sduart8987_combo.bin：供应商/固件/sduart8987_combo.bin \ 供应商/nxp/imx-firmware/nxp/android_wifi_mod_para.conf：供应商/固件/wifi_mod_para.conf \ hardware/nxp/libbt/conf/nxp/evk_95/bt_vendor.conf:/vendor/etc/bluetooth/bt_vendor.conf 2. android_build/hardware/nxp/libbt/conf/nxp/evk_95/bt_vendor.conf # 禁用默认设置 #mchar_port = /dev/ttyLP4 #baudrate_fw_init = 3000000 # # 将设置更改为 88W8987 蓝牙 mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 baudrate_bt = 3000000 3. android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/启动/dts/freescale/imx95-19x19-evk.dts LPUART5_RX 引脚 /*将其设置为下拉（连接到 88W8987 的 GPIO[8]/UART_SOUT）。GPIO[8] 用于选择主时钟，0--38.4MHz，1--26MHz，大多数模块使用 38.4MHz 晶体。*/ pinctrl_uart5：uart5grp { fsl,pins = < IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e >; }; 在 M.2 连接器上添加 GPIO 控制 /* M.2 模块电源使能 */ reg_m2_pwr：regulator-m2-pwr { 兼容 = "稳压器固定"； 稳压器名称 = "M.2-power"; 调节器最小微伏 = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&i2c7_pcal6524 20 GPIO_ACTIVE_HIGH>; 启用高电平有效； 启动延迟-us = <5000>; }; /* M.2 接口上的 SD3 使能引脚、SDIO RESET# 引脚、PCAL6524HEAZ.P2_3 和 PCAL6524HEAZ.P0_4 - 输出高电平，由 usdch3 节点的 'mmc-pwrseq' 消耗 */ usdhc3_pwrseq: usdhc3_pwrseq { 兼容 = "mmc-pwrseq-simple"; pinctrl-names = "default"; reset-gpios = <&i2c7_pcal6524 19 GPIO_ACTIVE_LOW>, <&i2c7_pcal6524 4 GPIO_ACTIVE_HIGH>; /* W_DISABLE2# */ }; /* 将 W_DISABLE1# 引脚上拉以启用 WiFi，PCAL6524HEAZ.P0_6 - 输出高电平 */ reg_usdhc3_vmmc：regulator-usdhc3 { 兼容 = "稳压器固定"； 调节器名称 = "WLAN_EN"; 调节器最小微伏 = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&reg_m2_pwr>; gpio = <&i2c7_pcal6524 6 GPIO_ACTIVE_HIGH>; /* * IW612 WiFi芯片比其他WiFi芯片需要更长的延迟才能完成加载 * 上电后进行主机接口初始化，否则 * IW612的内部状态可能不稳定，导致故障 * SDIO3.0开关电压。 */ 启动延迟-us = <20000>; 启用高电平有效； }; 添加 usdhc3 节点和引脚控制 /* 添加 uSDHC3 引脚控制 */ pinctrl_usdhc3: usdhc3grp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe >; }; /* 添加 usdhc3 节点 */ &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; pinctrl-3 = <&pinctrl_usdhc3>; mmc-pwrseq = <&usdhc3_pwrseq>; vmmc-supply = <&reg_usdhc3_vmmc>; 总线宽度 = <4>; 保持电源处于挂起状态； 不可拆卸； 唤醒源； 状态 = "正常"; }; 禁用 PCIe 0 节点 /* 禁用 M.2 接口的 PCIe 0 插槽 - 仅使用 SDIO Wi-Fi */ &pcie0 { pinctrl-0 = <&pinctrl_pcie0>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_pcie0>; 状态 = "已禁用"； }; 4. 测试结果 ============================================= 谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 感谢您分享 AW-CM358MA 测试成功和 Android 启用步骤。为了重现您的设置并明确我们的模块选择，请您确认以下四点： 已测试的模块和 电路板支持包。版本 您之前的 Linux 测试使用了 Amphenol W603C 芯片，内核版本为 L6.12.49_2.2.0；而您最新的 Automotive Android 15.0.0_2.1.0 测试使用了 AW-CM358MA 芯片。请确认每次测试所用 M.2 卡的制造商、完整型号、芯片组以及实际内核版本。您之前还提到过 AW-CM358-SUR，请问这是同一款卡还是不同的型号？ 匹配软件包 为了确保 Android 测试成功，请提供完整的电路板支持包。 清单/标签、驱动程序版本、固件版本/哈希值以及 wifi_mod_para.conf 文件。是否使用了 6.12.23 内核？除了您最新回复中提到的内容之外，是否还有其他更改？ 将解决方案应用于 JODY-W263-00B 我们能否使用版本电路板支持包。驱动程序和固件为我们的 JODY-W263-00B 应用这些更改？请确认将 LPUART5_RX 下拉电阻更改为 0x51e 是否足以满足时钟同步的要求，或者是否需要修改外部电阻。此外，上电后 P0_4/W_DISABLE2# 是否应保持物理高电平？ 备选卡 对于 M2-JODY-W377-00C 和 M2-JODY-W683-00C，请区分一般兼容性和实际验证。NXP 或其模块合作伙伴在哪些 Linux 和 Automotive Android 电路板支持包。/内核版本上测试过这些卡？请提供任何可用的参考资料，并确认是否需要针对我们的目标平台打额外的补丁。 我们所需的基准版本仍然是 i.MX95 19×19 EVK B0，汽车 Android 15.0.0_2.1.0内核版本为 6.12.23。 此致， 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 嗨卫东， 感谢您分享 AW-CM358MA 的启用步骤。 我们将相应的更改应用到了搭载 u-blox JODY-W263-00B (88W8987) 的 i.MX95 19×19 EVK 上，该芯片运行的是 Automotive Android 15.0.0_2.1.0 系统。/ 内核 6.12.23。 我们在实时设备树中验证了以下内容： LPUART5_RX 焊盘配置：0x51e。 RESET GPIO：19 个 ACTIVE_LOW 和 4 个 ACTIVE_HIGH。 M.2/WLAN 启用延迟：5 毫秒和 20 毫秒。 SDIO引脚控制状态和唤醒源。 PCIe0 和 PCIe1 已禁用。 蓝牙设置也已更新。重新刷写修正后的图像集后，mlan 和 moal 会自动加载。SDIO 在 SDR104 模式下枚举正常，但固件激活仍然失败： WLAN：固件下载完成，固件长度=628200，已下载619156 固件状态轮询失败：firmwarestat=0xf005 FW未能及时激活！ 固件初始化失败 请问接下来的步骤可以详细说明一下吗？ 您的成功设置是否需要任何硬件更改、电阻器的安装/移除、跳线更改或 UART/JTAG DIP 开关设置？请提供具体的设置和元器件参考信息。 JODY-W263-00B 与您测试过的 AW-CM358MA 相比，是否需要任何不同的设置，特别是对于 W_DISABLE1#、W_DISABLE2#、电源/RESET 序列或时钟选择？ 对于 GPIO[8]/UART_SOUT 时钟带，何时进行电平采样？Linux DTS 下拉是否足够，还是需要更早的 U-Boot/上电配置？ 请确认此腕带的预期启动电压以及方便测量的测量点。我们已经验证了 DTS 配置，但尚未确认采样时的物理带级。 请提供您测试过的驱动程序版本、固件版本/安全散列算法\(SHA\)-256 以及 wifi_mod_para.conf 文件。以及任何参考启动波形。 请告知您建议首先进行哪项测量或对照测试。我们可以提供完整的 dmesg 日志和实时设备树。 问候， 拉凯什 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 尊敬的@Rakesh_Kumar-Thakur ， 请看下方内容。 > > 1.已测试的模块和电路板支持包版本 --Android 15.0.0_2.1.0电路板支持包。，跟你的一样。 --电路板支持包。版本中的默认 Wi-Fi 驱动程序。我没有使用其他WiFi驱动程序。 https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/android-automotive-os-for-i-mx-applications-processors:ANDROID-AUTO 2.匹配软件包 从上面的截图中可以看出，Android 电路板支持包。 版本使用的是LF_v6.12.20 电路板支持包。，而我们版本的 Android 15.0.0_2.1.0 电路板支持包。 没有使用L6.12.23 。 3.将解决方案应用于 JODY-W263-00B 是的，我也这么认为。因为我在使用 AW-CM358MA 时也能重现您遇到的同样问题。 我认为可以使用 JODY-W263-00B。i.MX95 LPUART5_RXD 引脚只需在 DTS 中配置一个下拉电阻即可。 > > 4.备选卡 M2-JODY-W377-00C 和 M2-JODY-W683-00C 分别基于 9098 和 AW693，是的，您可以选择它们用于您的应用。 [注意] 我建议按照我的步骤来启动并运行 JODY-W263-00B。     谢谢！ 此致， 卫东

IMX8QXP OTA 更新：通过 OTA 更新创建和调整分区大小的可行性 大家好， IMX8QXP - 斯卡思间隙 - L 6.6.52   当当前软件目标的分区布局与 OTA 包的分区布局略有不同时，是否可以在软件更新 (OTA) 过程中创建新分区和调整现有分区的大小？ 我们想了解 OTA 更新机制是否可以动态处理分区布局变更，包括分区创建、调整大小和更新相应的分区信息，而无需人工干预。 请分享您对可行性、局限性和推荐方案的看法。 谢谢，此致敬礼！ VKS i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project

寻找适用于 PQ2 Pro (MPC830x) 的 DDR2 寄存器参数架构 (RPA) 计算器 NXP 网站上的 MPC830x 页面有很多设计文档，但我听说里面还有某种计算器（电子表格？）。这有助于计算 DDR2 寄存器设置，可能命名为： MPC830x_DDR2_RPA.xls 或者类似的表达。即使是其他 PowerQuicc 2（例如虽然不是使用 DDR2 的 MPC830x，但它可能有用。 有没有可能它被保存在档案馆里或者评估委员会的资料中？ 谢谢！ Re: Looking for DDR2 Register Parameter Architecture (RPA) Calculator for PQ2 Pro (MPC830x) 嗨@mrand ， 由于 MPC830x 系列产品已经停产三年多了，因此请求的文件或下载链接不再可用。 有关 DDR 寄存器编程指南，请参阅 AN3369。 谢谢。   顺祝商祺！ 六月

S32K328 HyperRAM read write errors at low temperatures Hello NXP Community, we are using an NXP S32K328 with an Infineon S27KL0642DPBHB023 64-Mbit HyperRAM connected through the QuadSPI interface. The interface operates with the following basic configuration:   HyperRAM voltage = 3.3 V   QuadSPI clock = 120 MHz   Interface mode = Octal DDR   Clock mode = Single-ended CK   Read-data strobe = External RWDS   Latency mode = Fixed latency   Normal memory access = Memory-mapped AHB At room temperature, the HyperRAM interface appears to work correctly. At low temperatures, down to −40 °C, we observe read/write comparison errors. The problem appears to be related mainly to the temperature of the S32K328. Cooling the S32K328 can reproduce the errors, while cooling the HyperRAM alone has a much smaller effect. The relevant S32K328 QuadSPI settings are: DDR_EN = 1   DQS_EN = 1   External DQS/RWDS = selected   DQS_OUT_EN = 1   VAR_LAT_EN = 0   FLSHCR.TCSS = 4   FLSHCR.TCSH = 7   FLSHCR.TDH = 1 The current DLL configuration is:   SLV_DLL_BYPASS = 0   SLAVE_AUTO_UPDT = 1   SLV_EN = 1   SLV_DLY_COARSE = 0   FREQEN = 1   DLL_CDL8 = 0   DLLRES = 8   DLL_REFCNTR = 2   SMPR.FSPHS = 0   SMPR.FSDLY = 0   SMPR.DLLFSMPFA = 0 We tested all available combinations of:   SLV_DLY_OFFSET = 0 to 7   SLV_FINE_OFFSET = 0 to 15 At low temperatures, failures occur across all tested DLL configurations. The sweep shows differences between the configurations, but it does not provide a completely error-free operating range or a clearly optimal DLL parameter set. Therefore, we are currently not sure whether the problem is caused by the DLL configuration itself or by another temperature-dependent part of the S32K328 QuadSPI interface. Could you please help us with the following questions? Is the S32K328 QuadSPI configuration shown above suitable for HyperRAM operation at 120 MHz? Are the selected DLL parameters correct for this frequency and the full temperature range? Which values should be used for FREQEN, DLL_CDL8, DLLRES and DLL_REFCNTR at 120 MHz? Which DLL status flags should be monitored to verify correct operation? Should both DLLA_LOCK and SLVA_LOCK be checked before accessing the HyperRAM? How should DLLA_RANGE_ERR or FINE_UNDERFLOW be handled? Could the QuadSPI DLL or external-DQS path operate outside its valid range at low temperatures? Does the DLL configuration affect only read-data sampling, or can it also affect write timing? Are FLSHCR.TCSS = 4, FLSHCR.TCSH = 7 and FLSHCR.TDH = 1 suitable for 120 MHz HyperRAM operation? Which pad settings are recommended for CK, CS#, DQ[7:0] and RWDS at 120 MHz Octal DDR? Are there any known S32K328 errata or RTD issues related to QuadSPI, external DQS or operation at low temperatures? Is there a validated S32K328 HyperRAM initialization example or register configuration for 120 MHz operation? Any guidance on additional S32K328 registers or status information that should be checked would be very helpful. Thank you.

MCAL 需要源代码以进行代码生成。 您好，NXP技术支持， MCAL 版本：SW32K3_S32M27x_RTD_4.4_4.0.0_P24 当我重命名以下 .h 文件时如果文件格式为 .hh，ADC 生成将会失败。 为什么在代码生成过程中需要生成的源代码？ 我问这个问题是因为我的工作场所没有本地源代码策略，我只能在本地电脑上安装 ARXML 等非源代码配置。 BR/熊本熊 Re: MCAL expects source code for code generation 嗨@kumamon 配置生成不一定仅基于 ARXML。在生成过程中，MCAL 配置工具还需要作为已安装的 RTD/MCAL 软件包的一部分提供的文件，包括包含生成器所需的定义或信息的头文件。 因此，如果其中一个预期的 .h 文件存在，则如果文件重命名为 .hh，生成器可能无法再找到或处理该依赖项，这可能会导致代码生成失败。 BR，VaneB

S32K328 HyperRAM 在低温下出现读写错误 NXP社区的各位朋友，大家好！ 我们使用NXP S32K328 ，并通过 QuadSPI 接口连接Infineon S27KL0642DPBHB023 64-Mbit HyperRAM 。 该接口采用以下基本配置运行：   HyperRAM 电压 = 3.3 V   QuadSPI 时钟频率 = 120 MHz   接口模式 = 八进制 DDR   时钟模式 = 单端 CK   读取数据选通 = 外部 RWDS   延迟模式 = 固定延迟   普通内存访问 = 内存映射 AHB 在室温下，HyperRAM 接口似乎工作正常。 在低至-40 °C 的温度下，我们观察到读/写比较错误。问题似乎主要与 S32K328 的温度有关。冷却 S32K328 可以重现这些错误，而单独冷却 HyperRAM 的效果则小得多。 S32K328 QuadSPI 的相关设置如下： DDR_EN = 1   DQS_EN = 1   外部 DQS/RWDS = 已选择   DQS_OUT_EN = 1   VAR_LAT_EN = 0   FLSHCR.TCSS = 4   FLSHCR.TCSH = 7   FLSHCR.TDH = 1 当前 DLL 配置为：   SLV_DLL_BYPASS = 0   SLAVE_AUTO_UPDT = 1   SLV_EN = 1   SLV_DLY_COARSE = 0   频率 = 1   DLL_CDL8 = 0   DLLRES = 8   DLL_REFCNTR = 2   SMPR.FSPHS = 0   SMPR.FSDLY = 0   SMPR.DLLFSMPFA = 0 我们测试了所有可能的组合：   SLV_DLY_OFFSET = 0 到 7   SLV_FINE_OFFSET = 0 到 15 在低温下，所有测试的 DLL 配置都会出现故障。扫描结果显示了不同配置之间的差异，但并未提供完全无错误的运行范围或明显最优的 DLL 参数集。 因此，我们目前还不确定该问题是由 DLL 配置本身引起的，还是由 S32K328 QuadSPI 接口中其他与温度相关的部分引起的。 请问您能否协助我们解答以下问题？ 上述 S32K328 QuadSPI 配置是否适合 120 MHz 的 HyperRAM 运行？ 所选的 DLL 参数是否适用于此频率和整个温度范围？ 在 120 MHz 时，FREQEN、DLL_CDL8、DLLRES 和 DLL_REFCNTR 应该使用哪些值？ 应该监测哪些 DLL 状态标志来验证其运行是否正确？ 访问 HyperRAM 之前是否应该同时检查 DLLA_LOCK 和 SLVA_LOCK？ 应该如何处理 DLLA_RANGE_ERR 或 FINE_UNDERFLOW 错误？ QuadSPI DLL 或外部 DQS 路径在低温下是否会在其有效范围之外运行？ DLL 配置是否仅影响读取数据采样，还是也会影响写入时序？ FLSHCR.TCSS = 4、FLSHCR.TCSH = 7 和 FLSHCR.TDH = 1 是否适用于 120 MHz HyperRAM 运行？ 对于 120 MHz 八进制 DDR，CK、CS#、DQ[7:0] 和 RWDS 的推荐焊盘设置是什么？ 是否存在与 QuadSPI、外部 DQS 或低温运行相关的已知 S32K328 勘误或 RTD 问题？ 是否有经过验证的适用于 120 MHz 运行的 S32K328 HyperRAM 初始化示例或寄存器配置？ 任何关于需要检查的其他 S32K328 寄存器或状态信息的指导都将非常有帮助。 谢谢！

i.MX95 19x19 EVK with JODY-W263-00B:Android 15 / Linux 6.12.23でのWiFiファームウェアの有効化タイムアウト タイトル:i.MX95 19x19 EVK with JODY-W263-00B:Android 15 / Linux 6.12.23におけるWiFiファームウェアの有効化タイムアウト NXPチームの皆様、こんにちは。 以下の構成でWiFiの初期化に関するデバッグを行っています。 ボード: NXP i.MX95 19x19 EVK WiFiモジュール：u-blox JODY-W263-00B Androidビルド:AOSP 15(Androidプロパティ認証待ち) 実行中のカーネル: 6.12.23-android16-5-maybe-dirty-4k 正確なNXPのAndroid BSPリリース/タグ:まだ確定していません WiFiドライバ:mlan/moal(MWLAN) 選択されたファームウェア: sduart8987_combo.bin SDIOデバイス: mmc2:0001:1 カーネル情報の実行: SDIOデバイスが検出され、ドライバが「FWダウンロードオーバー」と表示します。しかし、ファームウェアはタイムアウト時間内にアクティブにならず、WiFi SDIOプローブが失敗します。 Relevant boo$ adb shell uname -a Linux localhost 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT 1970年1月1日木曜日 00:00:00 UTC aarch64 Toybox tログ: [ 10.845985] mlan: loading out-of-tree module taints kernel. [ 10.961712] wlan: Loading MWLAN driver [ 10.973277] wlan: Register to Bus Driver... [ 11.016613] Attach moal handle ops, card interface type: 0x105 [ 11.070275] sta_name=wlan [ 11.086277] uap_name=wlan [ 11.086294] fw_name=sduart8987_combo.bin [ 11.168031] Enable moal_recv_amsdu_packet [ 11.168086] Attach mlan adapter operations.card_type is 0x105. [ 11.257673] wlan: Enable TX SG mode [ 11.257679] wlan: mpa_tx.buf_size=65280 [ 11.257682] wlan: Enable RX SG mode [ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156 [ 17.279039] FW failed to be active in time! [ 17.286246] wlan_dnld_fw fail ret=0xffffffff [ 17.296825] WLAN: Fail download FW with nowwait: 0 [ 17.502477] woal_request_fw failed [ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 [ 17.547534] wlan: Register to Bus Driver Done [ 17.553159] wlan: Driver loaded successfully ドライバをアンロードして再ロードした後、次のことも観察しました: [ 4051.080660] fw_name=sduart8987_combo.bin [ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0 [ 4056.079262] FW failed to be active in time! [ 4056.084697] wlan_dnld_fw fail ret=0xffffffff [ 4056.089909] WLAN: Fail download FW with nowwait: 0 [ 4056.250548] woal_request_fw failed [ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 関連するコミュニティの議論を見つけました。 https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/88W8801-LILY-W131-WiFI-SDIO-chip-not-responding-after-FW/m-p/1986943 議論はNvidia AGX Orin上の88W8801に関するもので、異なるモジュール/プラットフォームです。著者はノーSDを除去しバス幅を4から1に変更し、元の構成で正常に動作した結果改善を報告しています。これらの変更を自分のボードでまだテストしていません。 もう少し詳しく教えていただけますか: Is sduart8987_combo.bin JODY-W263-00Bの正しいファームウェアですか?このAndroid/カーネルの組み合わせには、どのファームウェアリリースとMLAN/MOALドライバのリビジョンが推奨されますか? i.MX95 19x19 EVK 上のこのモジュールについて、推奨される SDIO デバイスツリー設定は何ですか？特に、バス幅、最大周波数、pinctrl、電源、リセット GPIO、および電源シーケンス遅延について教えてください。 バス幅=<1> やSDIOクロックを低くすることで、このタイムアウトの診断に役立つ でしょうか?このプラットフォームにおいて、 無SD の除去は 重要または推奨されますか? ドライバがファームウェアのダウンロード完了を報告した後、ファームウェアのアクティベーションタイムアウトが発生する原因は何でしょうか?ドライバ再ロード後にダウンロード0になるということは、再試行前にモジュールの完全な電源サイクルやハードウェアリセットが必要だということを示しているのでしょうか? このボード／モジュール／カーネルの組み合わせに関して、既知の問題や必要なパッチはありますか？ ファームウェアやドライバの互換性問題とSDIO通信や電源・リセットシーケンスの問題を区別するために、どの追加のデバッグ設定、SDIOレジスタダンプ、ログを集めるべきでしょうか? 確認され次第、完全なブートログ、関連するデバイスツリーノード、wifi_mod_para.conf、そして正確なBSP/ドライバのリビジョンも提供できます。 よろしくお願いします。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 NXPチームの皆様、こんにちは。 JODY-W263-00Bを搭載したi.MX95 19x19 EVKにおけるファームウェアのアクティベーションタイムアウトに関する、さらなる診断証拠を収集しました。 ハードウェアモード検証 両方のレジスタ読み取りが成功しました。 WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0 WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0 WIFI_DIAG: magic=0x24 strap=0x0 WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selection マスクされたストラップは、ドライバーソースによるとSD-UARTモードを示しており、設定されたファームウェア名と一致しています。 ダウンロードループからの脱出が確認されました WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100 WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16 Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 要求された長さのレジスタが100回のポーリング試行中ずっとゼロのままであるため、ダウンロードループが終了します。 ファームウェアバイナリ検査 ソースの 16 バイトのFWHeaderレイアウトとコマンド長ルールを使用してオフライン解析を行うと、オフセット 619140 から 619156 で終了する CMD4 レコードが特定され、ダウンロードカウンタと完全に一致します。ソースでは、CMD4 をFW_HAS_LAST_BLOCKとして定義しています。 このレコードの後に9044バイトの空きがあります。これらの解析ルールの目的はまだ明らかにされておらず、また、これらのルールがSDIOブートローダーのフォーマットを完全に記述しているかどうかも確認されていません。したがって、カウンターの差額だけでは、ダウンロードが不完全であったことの証明とはみなしません。 その他詳細： MOAL/MLAN バージョン: 537.p9 組み込みファームウェア文字列: w8987o-V0、RF878X、FP92、16.92.21.p151.4 ファームウェアサイズ：628200バイト SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 実際の1ビットSDIO動作は、以前に50MHzで同じタイムアウト値で検証済みである。 最新の診断テストは、4ビット、50MHzで実行されます。 期待されるファームウェアのREADYステータスは0xfedcですが、観測されたステータスは0xf005のままです。 Wi-Fiネットワークインターフェースは作成されません。 NXP BSPの正確なリリース/タグは現在確認中です。 もう少し詳しく教えていただけますか: この特定の画像において、CMD4境界（オフセット619156）で停止することは想定されている動作でしょうか？残りの9044バイトの目的は何ですか？ SD8987ファームウェアのアクティベーション中に、 0xf005は何を示していますか？ バージョン文字列16.92.21.p151.4を含むファームウェアは、JODY-W263-00Bのドライバ537.p9でサポートされていますか?どのBSPとファームウェア/ドライバーパッケージを使うべきでしょうか? この不具合に対して推奨されるモジュール電源/リセットタイミング、電源供給、および基準クロックのチェック項目はどれですか？ ファームウェアの起動失敗と、通信またはハードウェアの初期化の問題を区別するために、他にどのようなレジスタや診断情報を使用すればよいでしょうか？ ファームウェアのバイナリファイルは変更されていません。ソースコードの変更により診断ログ機能が追加され、完全なブートログとソースコードの差分が利用可能になりました。 よろしくお願いします。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 失敗段階に関する重要な補足事項： プロセッサはSDIO経由でSD8987のWi-Fiデバイスを検出し、ファームウェアダウンロードルーチンでは「FW download over」と報告されます。しかし、その後のアクティベーションチェックでは、ドライバはSDIO_FIRMWARE_READY = 0xfedcを期待し、報告された状態は0xf005とされています。 そのため、ファームウェアの初期化とSDIOプローブが失敗し、Wi-Fiネットワークインターフェースは作成されません。50MHzでの実際の1ビットSDIO動作を確認した後も、この結果は変わりません。 この段階でSD8987 0xf005が何を示しているのか、またファームウェアがREADYステータスに到達しない理由を特定するのに役立つ追加のレジスタ値やログについて説明していただけますか? Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 NXPチームの皆様、こんにちは。 前回の報告に続き、追加の検証と、制御されたSDIOバス幅実験を完了しました。Wi-Fiの初期化は、ファームウェアの有効化段階で依然として失敗します。 1. 確認されたデバイスおよびソフトウェアの詳細 ボード/モジュール: i.MX95 19x19 EVK (JODY-W263-00B搭載) Android fingerprint: Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys カーネル: 6.12.23-android16-5-maybe-dirty-4k NXP BSPの正確なリリース/タグ：現在確認中 SDIOデバイス: mmc2:0001:1 SDIO ID: 02DF:9149、ドライバーソースではSD8987にマッピングされています ホストコントローラー:USDHC3、 mmc@428b0000 moalとmlanはどちらもバージョン537.p9を報告している。 MOAL ソースバージョン: 358C14898F4DDF4EB40AB03 ソースリポジトリのリビジョン: nxp-mwifiex: 9630752ea1d9e28d9956adf27c652f40399e85ad imx ファームウェア: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b 両方のコミットの件名は「MA-23689-1 [Android-15]WCS Q2 release patch integrate」となっています。これらのソースコードのリビジョンをインストール済みのモジュールビルドにマッピングする作業は、現在も検証中です。 2. ファームウェアの識別情報を確認しました 選択されたファームウェアは/vendor/firmware/sduart8987_combo.binで、サイズは628200 バイトです。 ソースコピーとインストール済みボードコピーのSHA-256ハッシュ値は同じです。 db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 これにより、コピーが一致していることが確認されました。ただし、モジュールとのファームウェアの互換性については、まだ確認が必要です。 3. 実際の1ビットSDIOテストが完了しました 当初、ライブデバイスツリーはbus-width = <1>と報告していましたが、 /sys/kernel/debug/mmc2/iosでは依然として 4 ビット動作が表示されていました。 ソースコードでは、 mmc_of_parse() は バス幅 = の既存の 4 ビット機能をクリアしませんが <1>、汎用 SDHCI 設定では、 SDHCI_QUIRK_FORCE_1_BIT_DATA が設定されてい ない限り、 MMC_CAP_4_BIT_DATA が追加されます 。 そこで、 sdhci-esdhc-imx.cのmmc_of_parse()エラーチェックの直後に診断ブロックを追加しました。 { u32 bus_width; if (!of_property_read_u32(np, "bus-width", &bus_width) && bus_width == 1) { host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; host->mmc->caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA); } } 変更したカーネルとDT構成を再構築およびデプロイした後、以下のことを確認しました。 Live DT bus-width: 00 00 00 01 clock: 50000000 Hz bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) しかし、同じ失敗が続いた。 Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 Wi-Fiネットワークインターフェースは一切表示されません。 設定された最大周波数は100 MHzですが、実際の動作は50 MHzのままです。したがって、低クロックのテストは完了していません。また、 レビューしたUSDHC3構成にはSDが含まれていなかったため、削除は行われませんでした。 4. WLAN専用ファームウェアのリロードテスト 設定済みのファームウェアパスに一時的にsd8987_wlan.binをバインドマウントし、MOALを再読み込みました。ドライバーは代替ファイルサイズを読み取りましたが、次のように報告しました: firmwarelen=416836 downloaded 0 firmwarestat=0xf005 FW failed to be active in time! これは以前の初期化失敗後の再読み込みであったため、結果は決定的なものではないと判断します。これは、WLAN専用ファームウェアの互換性や正常な転送を保証するものではありません。 再起動により一時的なバインドマウントが解除され、元の628200バイトのコンボファームウェアが再度検証されました。 5. 現在の調査 moal_sdio_mmc.cで診断ログを準備し、以下の情報をキャプチャします。 生のチップマジックとホストストラップレジスタの値。 両方のレジスタ読み取りの戻りステータス。 仮面魔法とストラップの価値。 ソースコードでは、 CHIP_MAGIC_VALUE = 0x24 、 CARD_TYPE_SD_UART = 0と定義されています。既存のブートログではこれらの値は公開されていませんでした。このログ記録の変更はまだ展開されていません。 firmwarestat=0xf005 の正確な意味 、およびファームウェアサイズとダウンロードカウンタの 差が9044バイト 繰り返される現象 については、未解決のままです。完了メッセージをファームウェアがアクティブであることの証明とはみなしていません。 以下の点についてアドバイスいただけますか? このファームウェア/ドライバーパッケージは、このBSP/カーネル上のJODY-W263-00Bに適していますか?バイナリやパッケージから正確なファームウェアリリースをどうやって特定できますか? 628200バイトのコンボイメージに対して619156バイトがダウンロードされたのは、このファームウェア形式では想定されるサイズなのでしょうか、それとも予期せぬ終了を示しているのでしょうか？ SD8987の初期化中にファームウェアステータス0xf005が表示されるのはどういう意味ですか？ 上記の診断ホスト・ドライバの変更は1ビットテストを強制するのに適切でしょうか、それとも推奨されるBSPメカニズムがありますか? ストラップベースのファームウェア選択を検証するために、どのレジスタ/ログを収集すべきでしょうか？また、明示的なfw_nameを指定すると、その選択は上書きされますか？ この障害発生後、再試行する前に必要な電源投入／リセット手順は何ですか？次に推奨する実験は、クロック周波数を低く設定するテストでしょうか、それとも別の対象を絞った実験でしょうか？ 完全なブートログ、DT/オーバーレイの変更、ホストドライバーの違い、wifi_mod_para.confも提供可能です。 よろしくお願いします。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 お問い合わせありがとうございます。 WiFiモジュールに uSDHC3 インターフェースを使っていると聞きました。i.MX95-EVKはM.2 KEY EコネクタでuSDHC3をサポートしています。ですので、M.2 WiFiモジュール、JODY-W263-00B(88W8987ベース)を使っているのだと思います。 M.2 KEY EコネクタでSDIO WiFiを有効にする際の以下の手順を明確にする必要があります。 -- uSDHC3 IO レベルは NVCC_WAKEUP によって決定されます NVCC_WAKEUPは1.8V（VDD_1V8_Sから）です。 --M.2電源、VCC_KE_3V3はデフォルトで無効になっています 電力はNX5P2924DUKによって生成され、M2_KE_PWRENイネーブルメントを制御しています。 3. ソフトウェアが何をするか （１）imx95-19x19-evk.dtsにuSDHC3ノードを追加する デフォルトではuSDHC3ノードは存在しないため、手動で追加する必要があります。 [注] imx95-15x15-evk.dtsを参照できますそれを追加するためのusdhc3コード。 異なるGPIOに注意してください。 --電源GPIOを有効にする --M.2のW_DISABLE1#ピンとW_DISABLE2ピンをプルアップします --SDIO_WAKE# および SDIO_RST# ピン (3)Android 15 SDIO WiFi パワーエンイブルメント i.MX95 の haredBoardConfig.mk ファイルを確認し、pwrseq_simple.ko がサポートされているかどうかを確認してください。サポートされていない場合は、追加してください。おそらく以下のような感じでしょう。 ...... $(KERNEL_OUT)/net/wireless/cfg80211.ko \ $(KERNEL_OUT)/drivers/mmc/core/pwrseq_simple.ko \ ...... （３）imx95-19x19_gki.fragment を有効化します（名前が異なる場合もありますので、ご確認ください）。 ...... CONFIG_PWRSEQ_SIMPLE=m ...... （4）pcie1ノードの無効化（ imx95-19x19-evk.dts内） …… &pcie1 { pinctrl-0 = <&pinctrl_pcie1>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_slot_pwr>; ステータス = "無効"; }; ...... (5) BoardConfig.mk が8987を直接サポートできる デフォルトのWiFiファームウェアファイル名を88W8987に変更できます。 わかりました、試してみてください。 ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん ご指導ありがとうございました。 以下の設定更新をテストしましたが、ファームウェアの初期化は依然として失敗します。 imx95-19x19-evk.dtsでpcie1を無効化しました。既存の uSDHC3 の設定は保持されています。 BoardConfig.mk と SharedBoardConfig.mk でWi-Fi設定ラベルとモジュールパラメータファイル名を更新しました。 evk_95.mk内のファームウェア構成の宛先名を更新しました。 カーネルフラグメント内にCONFIG_PWRSEQ_SIMPLE=mが既に存在していることが確認されました。pwrseq_simple.koの実行時ロードとDTSパワーシーケンス接続については、引き続き検証が必要です。 最新のブートでは以下が使用されます。 moal.mod_para=wifi_mod_para_sd8987.conf モジュールはNXP 88W8987をベースにしたJODY-W263-00Bと報告されており、Wi-Fiドライバーのバージョンは537.p9です。 現在のファームウェア： Path: /vendor/firmware/sduart8987_combo.bin Size: 628200 bytes SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 ブートログ: SD8987: init module param from usr cfg card_type: SD8987, config block: 0 fw_name=sduart8987_combo.bin Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 以前にも、 lf-6.18.20_2.0.0ブランチからの代替ファームウェアをテストしました。 Size: 644352 bytes SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823 デプロイされたハッシュは検証されましたが、同じfirmwarestat=0xf005アクティベーション失敗が発生しました。 ドライバ537.p9と互換性のあるJODY-W263-00B / 88W8987の検証済みsduart8987_combo.binを教えていただけませんか?ファームウェアのバージョン、リポジトリコミット/タグ、SHA-256および推奨モジュールパラメータを記載してください。別のドライバリリースが必要な場合は、対応するドライバとファームウェアの組み合わせを指定してください。 参考までに、弊社のソースコードの改訂履歴は以下のとおりです。 Driver: 9630752ea1d9e28d9956adf27c652f40399e85ad Original firmware repository: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b 0xf005が何を示しているのか、また、原因特定に役立つ追加のステータスレジスタキャプチャや電源/リセットチェックがあれば教えてください。電気的測定とリセットシーケンスの完全な検証はまだ実施中です。 よろしくお願いいたします。 ラケシュ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 最新情報のご提供ありがとうございます。 0xf005について コード0xf005は、ドライバがポーリングタイムアウト中にファームウェアがReady/Active状態に到達したことを観察しなかったことを意味します。これはファームウェアの有効化状態を示すものであり、特定のハードウェア障害コードではありません。しかし、SDIO通信、電源、リセット、クロックの問題など、ハードウェアの問題によってもこの状態が発生する可能性があります。 >> lf-6.18.20_2.0.0 ブランチへの切り替えについて： 正しい方法は、そのブランチから完全で一致するWi-Fiドライバとファームウェアを使うことです。ファームウェアだけを交換すべきではありません。 ドライバとファームウェアのバージョンは互換性があり、同期を保つ必要があります。 ですので、Wi-Fiのドライバとファームウェアを最新のブランチにアップデートしてみてください。 質問が1つと提案が1つあります。 Android 15を使う必要がありますか?i.MX95は比較的新しいので、最新のBSPバージョンを使うのが良いでしょう。Android 16.0.0_2.0.0をL6.18.20_2.0.0 BSPで使うこともできます。 まずLinux BSPのWi-Fiハードウェア、ドライバ、ファームウェアを確認することをお勧めします。Wi-FiモジュールがLinuxで正常に動作したら、Android 16に移行できます。このアプローチはAndroid固有の構成の複雑さを軽減し、デバッグの効率化を可能にします。 ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん ご説明いただきありがとうございます。AOSP 15とカーネル6.12.23は維持しなければなりません。Android 16へのアップグレードは選択肢にありません。 このセットアップに対応しているJODY-W263-00B / 88W8987対応のWi-Fiドライバとファームウェアペアをおすすめしていただけますか?現在のドライバーは537.p9と報告されています。 lf-6.18.20_2.0.0のペアを推奨する場合は、そのドライバーがカーネル6.12.23をサポートしているか、また統合パッチが必要かどうかを確認してください。 正確なドライバとファームウェアのコミット/タグ、一致するバージョン/チェックサムsduart8987_combo.bin、推奨モジュールパラメータを教えてください。 よろしくお願いいたします。 ラケシュ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 i.mx95はオートモーティブ用途向けに設計されています。 Wi-Fiモジュール、AW693 & PCIe 88Q9098はオートモーティブAndroidでサポートされています。AW693モジュールもテストしましたが問題ありません。 私はL6.12.49のLinux BSPを構築しており、i.mx95で88W8987をテストしたいと思っています。 よろしくお願いいたします、 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん While reviewing Android Automotiveリリースノート(RN00227年)、2025年10月14日付のrev. automotive-15.0.0_2.1.0を確認していると、セクション4、表2 — コネクティビティWi-Fiにi.MX95用のPCIe9098 / u-blox JODY-W3が記載されていることに気づ きました。このエントリのスクリーンショットを添付しました。 私たちのシステムでは以下を使用しています。 ボード: i.MX95 19×19 EVK モジュール: u-blox JODY-W263-00B / 88W8987 (uSDHC3 SDIO経由) BSP: Android オートモーティブ 15.0.0_2.1.0 カーネル: 6.12.23 SDIO デバイスが検出され、ファームウェア転送完了が報告されますが、ファームウェアのアクティベーションが firmwarestat=0xf005 で失敗します。 もう少し詳しく教えていただけますか: JODY-W263-00B / SDIO8987 はこの BSP 上で検証済み ですか ？それとも、以前推奨された変更以外に追加の統合が必要ですか？ 対応可能であれば、ドライバとファームウェアのリビジョンや必要なDTS、電源/リセット、モジュールパラメータ構成を提供できますか? JODY-W3 / PCIe9098は 、このリリースで推奨されるモジュール ですか ？交換が推奨される場合は、正確なモジュール/キャリアの部品番号と必要なボード構成を指定してください。 Android 15とカーネル6.12.23は維持しなければなりません。この設定でサポートされているパスを教えてください。 よろしくお願いいたします。 ラケシュ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん 詳しい説明をありがとうございました。 0xf005、これはドライバがポーリングタイムアウト中にファームウェアがReady/Active状態に到達したことを観測しておらず、特定のハードウェア故障コードではないことを理解しています。 u-blox JODY-W263-00B (88W8987) を搭載した i.MX95 19x19 EVK では、SDIO の検出とファームウェアのダウンロードは完了しますが、アクティベーションはステータス0xf005でタイムアウトします。 現在のプラットフォームはAndroid 15で、カーネルは6.12.23、MOAL/MLANドライバは537.p9です。ソフトウェアの電源/リセットチェックと起動時リセットのシーケンス変更は完了しましたが、問題は残っています。物理的な電圧、リセット、クロックの測定はまだ未定です。 ご提案に従い、まずLinux上で完全で一致するドライバとファームウェアペアを用いてWi-Fiの検証を行う予定です。Android 16への移行が可能かどうか、社内で確認しています。Android 15が必須のままであれば、カーネル6.12.23を維持しつつ、対応ペアのバックポートを検討します。 以下の点を確認いただけますか? 以前のテスト結果： i.MX95上でJODY-W263-00Bを使用したL6.12.49テストの結果はどうでしたか？ 検証済みリリース: このモジュールはi.MX95 19x19 EVKのL6.18.20_2.0.0とAndroid 16.0.0_2.0.0で検証されていますか? Linuxセットアップ:マニフェストブランチとXMLファイル名、MACHINE、DISTRO、イメージ名、公式のビルド/フラッシュ手順をご提供ください。 Wi-Fiペアのマッチング:ドライバーリポジトリとピン留めされたリビジョン、ファームウェアパッケージとリビジョン、正しいファームウェアファイル名、必要なモジュール設定を教えてください。 このモジュールのSD-UART構成sduart8987_combo.bin正しいですか? Androidセットアップ: 対応するAndroidのリリースとマニフェスト、該当する場合はオートモーティブ版も確認してください。 追加の診断情報：このアクティベーションタイムアウトを調査するために、特定のデバイスツリー設定、電源/リセットタイミング、パッチ、またはレジスタダンプが必要ですか？ Linux検証後、ブートログ、ドライバ/ファームウェアバージョン、ファームウェアSHA-256、利用可能なハードウェア測定値を共有します。 よろしくお願いします、 ラケシュ・タクール Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 ドライバ537.p9 + ファームウェア16.92.21.p151.4およびドライバ543.p18 + ファームウェア16.92.21.p156.2が、SD-UARTモードでJODY-W263-00B / 88W8987でサポートされている組み合わせかどうかも確認してください。2つ目のペアについては、Android 15 / カーネル6.12.23のサポート(必要なパッチや設定を含む)も確認してください。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん ご提案に従い、現在、i.MX95 19×19 EVKにJODY-W263-00B / 88W8987を搭載したlf-6.18.20_2.0.0のWi-Fiドライバとファームウェアペアを完全に統合・テストしました。 Android 15とカーネル6.12.23は保持しなければなりません。 統合改訂： ドライバ: 2e481212d262758cbd4d0fc7ea95a2ad5f704bc3 ファームウェア: cc78ca8b1ee28ff741bcc160246f61b008f6c89f ロードされたMLAN/MOALバージョン: 543.p18 ファームウェア: sduart8987_combo.bin 、644352バイト コンパイルとイメージパッケージングは合格しました。ボード上で、意図されたカーネル、ロードされたドライババージョン、モジュール/ファームウェアのハッシュをパッケージ化されたアーティファクトと照らし合わせました。AndroidブートとSDIO列挙は成功しました。 しかし、フラッシュ後の最初の起動と電源投入直後のテストの両方で、同じアクティベーション失敗が発生した。 Wlan: FW download over, firmwarelen=644352 downloaded 635356 Fail to poll firmware status: firmwarestat=0xf005 Firmware Init Failed probe with driver wlan_sdio failed with error -1 WLANインターフェースは作成されていません。したがって、マッチングペアを537.p9から543.p18に更新しても故障は解決しませんでした。 ソフトウェアの電源/リセットシーケンスの変更は実施されています。物理的な供給、リセット、およびクロック測定は保留中です。以前に検証された50MHzでの1ビットSDIOテストでも、同じタイムアウトが発生しました。 それとは別に、 rust_binderに影響を与えるカーネル/システムモジュールの不一致を特定し、一致するモジュールを使用してイメージを再構築しました。修正後のイメージセットのボード再テストは現在保留中です。Wi-Fi障害との関連性はまだ確認されていません。 次のステップの優先順位を一緒に決めていただけませんか? Linuxテスト: i.MX95上で88W8987を使った予定のL6.12.49テストの結果はどうですか?正確なモジュール/キャリア、ドライバとファームウェアの改訂、DTS構成を確認してください。 Android 15のサポート: この 543.p18 ペアはカーネル6.12.23に適していますか?互換性パッチは必要ですか?それとも別の検証済みペアを推奨しますか? ターゲット診断:0xf005はREADYに到達できないことを示すことを理解しています。Wi-Fiチームはこの特定のSD8987状態を解釈し、起動失敗を調査するために必要な正確なレジスタ、アドレス、キャプチャ手順を提供できますか? 次の管理実験: マッチングペア積分と1ビットテストがすでに完了している中で、次にどの単一のソフトウェア実験を行い、どのような設定と期待される結果で行うべきでしょうか? ハードウェア検証：このボード／モジュールの組み合わせに必要な電源レベル、リセットタイミング、クロック要件、および確認済みの測定ポイントを提供してください。 もしJODY-W263-00BがこのAndroidリリースで検証されていない場合は、それを明示し、サポートされている統合または置き換えパスを推奨してください。 完全なブートログ、ソースコードの差分、ハッシュ値、およびイメージ検証記録が利用可能です。 よろしくお願いいたします。 ラケシュ・タクール Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 今は気にしないでください。Yocto BSPはまだ開発中で、サーバーは少し遅いです。来週には検査結果が出る見込みです。     ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん 最新情報のご提供ありがとうございます。来週、あなたの検査結果をお待ちしています。 テスト環境が u-bloxのJODY-W263-00B / NXP 88W8987モジュールとWi-Fi over SDIO を使っているか確認いただけます か? 結果を共有する際は、正確なBSPバージョン、ドライバーのリビジョン、ファームウェアのバージョン/ファイル、必要な基板構成を必ず記載してください。テストが成功した場合は、同じドライバとファームウェアの組み合わせを入手できる場所も教えてください。 これにより、あなたの動作するセットアップを再現し、Android 15 / カーネル6.12.23の統合と比較できます。 ありがとうございます。よろしくお願いいたします。 ラケシュ Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ 魏東さん、こんにちは。 ご提案に従い、lf-6.18.20_2.0.0のWi-Fiドライバとファームウェアペアを統合しました。しかし、ファームウェアのアクティベーション失敗は依然として存在します。 さらなる変更を進める前に、インストール済みWi-Fiモジュールの対応ドライバ・ファームウェアパッケージ、ダウンロードソースおよびサポートの所有権を確認する必要があります。 1. ハードウェアおよびソフトウェアのセットアップ コンポーネントの詳細 ボード NXP i.MX95 19×19 EVK Wi-Fiモジュールをインストールしました u-blox JODY-W263-00B Wi-Fiチップセット NXP 88W8987 Wi-Fiインターフェース SDIO 意図されたBluetoothインターフェース UART Android BSP オートモーティブ Android 15.0.0_2.1.0 カーネルベース 2023年6月12日 SDIOデバイスを検出しました mmc2:0001:1 弊社がインストールしたモジュールは、デフォルトのEVK設定で説明されているPCIe Wi-Fi構成ではなく、SDIOを使用してWi-Fi接続を行います。推奨事項は、特にSD-UARTモードのJODY-W263-00B / 88W8987に基づいて作成してください。 2. オリジナルおよび更新されたドライバ–ファームウェアペア コンポーネント 元の設定 更新された設定 ドライバーバージョン 537.p9 543.p18 ファームウェア組み込みバージョン 16.92.21.p151.4 16.92.21.p156.2 ファームウェアファイル名 sduart8987_combo.bin sduart8987_combo.bin ファームウェアサイズ 628200バイト 644352バイト 結果 アクティベーションタイムアウト、 0xf005 同じアクティベーションタイムアウト、 0xf005 更新されたペアは lf-6.18.20_2.0.0 から選ばれ、既存の Android 15 / カーネル6.12.23 環境 にバックポートされました 。Android 16 / Linux 6.18のBSPへの完全な移行はまだ実施していません。 選択された参照改訂版： Driver: 2e481212d262758cbd4d0fc7ea95a2ad5f704bc3 Firmware: cc78ca8b1ee28ff741bcc160246f61b008f6c89f 3. 統合と展開の証拠 ドライバーコンパイルとMODPOSTは更新されました。 イメージパッケージングとローカルAVB検証に合格しました。 フラッシュ後、ロード済みドライバーバージョンが543.p18であることが確認されました。 ボードモジュールとファームウェアのハッシュはパッケージされたアーティファクトと一致していました。 SDIOの列挙に成功しました。 フラッシュ後の最初の起動時と、電源投入直後のテスト時にも、同様のアクティベーション失敗が発生しました。 統合ソース内の更新されたファームウェアも直接検査されました。 Filename: sduart8987_combo.bin Size: 644352 bytes Embedded identification: $Id: w8987o-V0, RF878X, FP92, 16.92.21.p156.2 $ SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823 4. 失敗の証拠 オリジナルペア： SD8987: init module param from usr cfg card_type: SD8987, config block: 0 fw_name=sduart8987_combo.bin Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 更新されたペア: Wlan: FW download over, firmwarelen=644352 downloaded 635356 Fail to poll firmware status: firmwarestat=0xf005 Firmware Init Failed probe with driver wlan_sdio failed with error -1 ドライバーはモジュールを検出し、ファームウェアの移行完了を報告しますが、ファームウェアのアクティベーションは失敗します。これは現時点では、明らかな検出エラーやファームウェアファイルの読み込みエラーを示しているわけではありません。しかし、ドライバが完全に検証されているとか、ファームウェアの互換性が根本原因であるとは主張していません。 5. 具体的な確認およびパッケージの要求 JODY-W263-00B / 88W8987 に関して、以下の点にご回答ください 。 上記のドライバとファームウェアの組み合わせは、このモジュールのSD-UARTモードでサポートされていますか? それぞれのペアを別々に確認してください。 既存のドライバが適しており、異なるファームウェアだけでよいのか、それとも異なる対応するドライバとファームウェアの組み合わせを入手する必要があるのか? サポートされている正確な組み合わせを特定してください。 そのパッケージはどこで入手できますか? 公式のダウンロードリンク、リポジトリ/ブランチ、コミット、またはアクセス申請の手順を教えてください。 供給と確認の責任はNXPかu-bloxか? もしu-bloxのサポートが必要な場合は、適切なサポートルートと依頼すべきパッケージ情報をご確認ください。 汎用版NXP 88W8987ファームウェアはJODY-W263-00Bに適していますか?それともこのモジュールはu-blox対応のパッケージや追加のモジュール固有のファイルや構成が必要ですか? 確認済みのペアはAndroid 15 / カーネル6.12.23で動作可能ですか? 追加のパッチが必要な場合は、その内容を特定してください。このプラットフォームがサポートされていない場合は、対応するBSPと動作する既知の構成を指定してください。 ドライバ更新を推奨した具体的な根拠は何だったのでしょうか?537.p9とファームウェア16.92.21.p151.4に既知の問題があったのか、それとも一貫したリリース基準を確立するための推奨だったのでしょうか? 互換性の確認や推奨パッケージへのアクセスはいつ頃期待できますか? エンジニアリングレビューが必要な場合は、予想される対応期間をご提供ください。 更新されたペアが既にこのモジュールに対して正しい場合は、その旨を明記し、 0xf005アクティベーション失敗に対する次の対象診断チェックを特定してください。 また、別のバインダーモジュールのパッケージの不一致も現地で修正されました。ただし、修正されたイメージについては、ボードの再テストが必要です。Wi-Fi障害との関連性は確認されていない。 直ちにお願いしたいのは、正しいドライバとファームウェア、公式な出典、責任サプライヤー、そして予想されるスケジュールの確認であり、検証済みのベースラインからさらなるテストを進めることです。 よろしくお願いします。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん JODY-W263-00B / 88W8987を搭載したi.MX95 19×19 EVKで、以下の3つのテストを完了しました。 元のセットアップ:オートモーティブのAndroid 15.0.0_2.1.0、カーネル6.12.23、ドライバ537.p9 、ファームウェア16.92.21.p151.4。推奨されたDTSおよび電源/リセット設定の変更を適用しても、同じアクティベーション失敗が残りました。 バックポートセットアップ:Linuxリリースlf-6.18.20_2.0.0の対応ドライバ543.p18とファームウェア16.92.21.p156.2を統合し、Android 15とカーネル6.12.23を保持しました。同じ不具合が続きました。 Linux検証: Linux BSP L6.18.20_2.0.0 を ビルド、フラッシュ、テストし 、カーネル 6.18.20-2.0.0-g88cb92741827 を実行し ました。同じ失敗が発生しました。 3つのセットアップすべてで、firmwarestat=0xf005でファームウェアのアクティベーションタイムアウトがあり、WLANインターフェースは作成されません。添付のスクリーンショットはLinuxの結果を示しています。 そのため、ご提案いただいたドライバ・ファームウェアの更新とLinux BSPの検証の両方を試しました。次のターゲットを絞ったデバッグ方法を提案し、計画中のL6.12.49の結果を共有していただけますか テスト?物理的な電源/リセット/クロックの測定はまだ保留中です。   よろしくお願いいたします。 ラケシュ Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ @Rakesh_Kumar-Thakur様、 Linuxプラットフォームで88W8987 M.2モジュールを有効にしました。 --L6.12.49_2.2.0 --モジュール：Amphenol W603C（88W8987ベース） 0. i.MX95-EVK ハードウェア上の制御フロー。 =================================================== 1. Linuxプラットフォーム上のWi-Fi読み込み機構。 つまり、Wi-FiドライバはLinuxの起動時に読み込まれます。 2. デバイスツリーの調整 - usdhc3 ノードと関連する GPIO コントロールを追加します。 (1) PCAL6524HEAZ.P2_4 -- 出力ハイ -- VCC_KE_3V3 を有効にする。imx95-19x19-evk.dts でデフォルトでサポートされています。 reg_m2_pwr: regulator-m2-pwr { compatible = "regulator-fixed"; レギュレータ名 = "M.2-power"; レギュレーター-ミニ-マイクロボルト = <3300000>; レギュレーター最大マイクロボルト=<3300000>; GPIO = <&i2c7_pcal6524 20 GPIO_ACTIVE_HIGH>; 有効-アクティブ-高; /* * M.2デバイスのみ有効化可能です(W_DISABLE1#) Power * レールは最低動作電圧に達します(PCI Express M.2 * 仕様 r5.1 3.1.4電源投入タイミング）。 * ここで、Tsettle の最大値と同じ遅延時間を設定します。 */ 起動遅延時間（us）= <5000>; }; （２）SDIO_RST#ピンをプルアップする PCAL6524HEAZ。P2_3 & P0_5 - 出力ハイ - Wi-Fi/Bluetoothモジュールを有効にする。 usdch3ノードの「mmc-pwrseq」によって直接ロードされました。   usdhc3_pwrseq: usdhc3_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; reset-gpios = <&i2c7_pcal6524 19 GPIO_ACTIVE_LOW>, <&i2c7_pcal6524 4 GPIO_ACTIVE_HIGH>; /* W_DISABLE2# */ }; （３） W_DISABLE1# PINをプルアップしてWiFiを有効にする PCAL6524HEAZ.P0_6 - 出力高 - Wi-Fi を有効にする。 usdch3ノードの「vmmc-supply」によって直接ロードされます。 reg_usdhc3_vmmc: regulator-usdhc3 { 互換 = 「レギュレーター固定」; レギュレーター名 = 「WLAN_EN」; レギュレーター-ミニ-マイクロボルト = <3300000>; レギュレーター最大マイクロボルト=<3300000>; VIN-SUPPLY = <&reg_m2_pwr>; GPIO = <&i2c7_pcal6524 6 GPIO_ACTIVE_HIGH>; /* * IW612 Wi-Fi チップは他の Wi-Fi チップよりも遅延が必要です * 電源投入後のホストインターフェースの初期化、そうでなければ * IW612の内部状態が不安定であり、その結果 * SDIO3.0スイッチ電圧。 */ 起動遅延時間（US）= <20000>; アクティブハイを有効にする。 }; （４）usdhc3ピン制御 pinctrl_usdhc3: usdhc3grp { fsl、pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { fsl、pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { fsl、pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe >; }; （５）M.2のpcie0を無効にする（オプション。使用していない場合は無効にする） &pcie0 { pinCtrl-0 = <&pinctrl_pcie0>; pinCtrl-names = "default"; reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; VPCIE-supply = <&reg_pcie0>; supports-clkreq; status = 「disabled」; }; （６）usdhc3ノードの追加 &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; pinctrl-3 = <&pinctrl_usdhc3>; mmc-pwrseq = <& usdhc3_pwrseq >; vmmc-supply = <& reg_usdhc3_vmmc >; バス幅 = <4>; 電源供給を一時停止する。 取り外し不可。 ウェイクアップソース; ステータス = "正常"; }; 3. Linux BSPを実行し、Wi-Fiのメッセージを受け取る これは、ハードウェアプラットフォームの観点から、i.MX95-EVKのM.2 SDIOインターフェースがSDIO Wi-Fiデバイスを問題なく完全にサポートしていることを示しています。   添付ファイルは私が使用しているdtsファイルです。ここで皆さんと共有します。 試してみてください。   ありがとうございます よろしくお願いいたします。 維東 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ こんにちは、ウェイドンさん W603Cのテスト成功とDTSの情報を共有していただき、ありがとうございます。 i.MX95 19×19 EVKには u-blox JODY-W263-00B(88W8987) を使用しています 。ファームウェアのダウンロードは終了しますが、0xf005でアクティベーションが失敗します 。最終ターゲットはAndroid 15.0.0_2.1.0 / カーネル6.12.23です。 変更をテストする前に、以下の点を明確にしていただけますか: この設定はJODY-W263-00Bにも適用されますか？W603Cは必須の交換部品ですか、それとも単にテストに使用したモジュールですか？ 説明ではP0_5と記載されていますが、DTSではオフセット4（P0_4）、GPIO_ACTIVE_HIGHを使用しています。リセット時および通常動作時、特にW_DISABLE2#の場合、正しいGPIOと必要な物理レベルを確認してください。 ドライバのリビジョン、ファームウェアのバイナリ/ハッシュ、wifi_mod_para.conf、そして使用している正確なBSPマニフェスト/ビルド構成を共有してください。 貴社のDTSを弊社のシステムと比較し、既存のJODYモジュールに適用可能な変更点をテストする予定です。 よろしくお願いします、 ラケシュ Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ @Rakesh_Kumar-Thakur様、 最新情報のご提供ありがとうございます。 >>この構成はJODY-W263-00Bにも適用されますか？W603Cは必須の交換部品ですか、それとも単にテストに使用したモジュールですか？ この設定はJODY-W263-00Bにも適用されますか？ はい、全く同じです。M.2 Key EはWi-Fiカードの標準規格だからです。 W603Cは必須の交換部品ですか、それとも単にテストに使用したモジュールですか？ 必要なし。 現在のテスト結果のみが示すのはi.mx95-evkで、SDIO Wi-FiではM.2が問題ないということです。 それはJODY-W263-00Bに問題があるという意味ではありません。 >>説明文ではP0_5と記載されていますが、DTSではオフセット4（P0_4）、GPIO_ACTIVE_HIGHを使用しています。リセット時および通常動作時、特にW_DISABLE2#について、正しいGPIOと必要な物理レベルをご確認ください。 はい、正しくはP0_4です。私の間違いでした。 >>ドライバのリビジョン、ファームウェアのバイナリ/ハッシュ、wifi_mod_para.conf、そして使用した正確なBSPマニフェスト/ビルド構成を共有してください。 こちらがドライバのリンクです。 https://github.com/nxp-imx/mwifiex/tree/lf-6.12.49_2.2.0 ただし、あなたが遭遇した問題はドライバが原因ではないことを念のためお伝えください。WiFiドライバの変更はやめてください。助けにならない。 来週、Android 15のソースコードを準備して有効化に挑戦します。 あなたが使っているAndroid BSPはオートモーティブ版ですか、それとも標準的なAndroid BSPですか? ありがとうございます よろしくお願いいたします。 維東 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ こんにちは、ウェイドンさん JODY-W263-00Bにこの構成が適用されること、W603Cの交換が不要であること、そして正しいGPIOがP0_4であることをご確認いただき、ありがとうございます。 私たちは以下の基準でオートモーティブ Android BSPを使用しています。 ボード: i.MX95 19×19 EVK モジュール: u-blox JODY-W263-00B / 88W8987、SDIO BSP: オートモーティブAndroid 15.0.0_2.1.0 マニフェスト:imx-オートモーティブ-15.0.0_2.1.0.xml ビルドターゲット: evk_95_car-nxp_stable-userdebug カーネル: 6.12.23 最終要件は、上記のAndroid 15/カーネル6.12.23ベースライン上でこのモジュールを有効にすることです。 モジュール電源、リセット、W_DISABLE1#/PDn、およびSDIO CLK/CMD/DATA0–3を対象とした、計画されたマルチメータとオシロスコープのチェックが完了しました。測定値と波形キャプチャは文書化されています。ファームウェアのダウンロードは完了しますが、その後、同じアクティベーションタイムアウトが発生し、 firmwarestat=0xf005となります。 ご助言に従い、今後のドライバーバージョン変更は中止し、残りの設定とシーケンスチェックに注力します。 また、あなたが共有したドライバーブランチも確認しました。ドライバリリースは540.p33で、現在のブランチヘッドは84ca65c9ff935d7f2999af100a82531c22c65234となっています。リポジトリにはファームウェアのファイル名参照は含まれますが、ファームウェアのバイナリや実際のモジュールパラメータ設定、ボードDTSは含まれていません。 以下の点について助けていただけませんか? P0_4 / W_DISABLE2# シーケンス:電源投入時、リセットアサート時、リセットリリース時、および通常動作時の必要な物理HIGH/LOWレベルを確認してください。DTSでは、P0_4がリセットGPIOのGPIO_ACTIVE_HIGHとして、P2_3 / オフセット19がGPIO_ACTIVE_LOWとして含まれています。この組み合わせはJODY-W263-00Bにとって意図的なものですか？また、電源シーケンス完了後、各ピンの物理レベルはどのくらいになるべきですか？ テスト済みファームウェアとパラメータ： W603Cのテストが成功した際に使用したファームウェアバイナリ（ファイル名、バージョン、SHA-256ハッシュを含む）、またはダウンロードリンクとリポジトリのコミット情報を共有してください。JODY-W263-00Bでも同じファームウェアを使用する必要があるかどうかを確認してください。また、実際に使用したwifi_mod_para.confファイル、または設定ファイルが使用されなかった場合は、正確なモジュールロードコマンドとパラメータも共有してください。 成功したLinux参照: テストが上記のドライバーコミットを使用していたかどうか、また追加のドライバーパッチが適用されていないかを確認してください。既存のJODYモジュールでL6.12.49_2.2.0テストを再現するには、最終的なボードDTS/パッチと正確なBSPマニフェスト、MACHINE、ディストリビューション、イメージ構成を共有してください。Androidテスト前にこの比較をおすすめしますか?適切な既製品イメージがあれば、それも役立ちます。 計画中のAndroid 15テスト:当社の基準に合わせたAutomotiveのAndroid 15.0.0_2.1.0 / カーネル6.12.23を使用していただけますか?また、W603CかJODY-W263-00Bでテストするかも確認してください。利用可能になり次第、イネーブルパッチ、ファームウェアの詳細、初期化ログを共有していただければ、結果を再現いたします。 ハードウェア検証レポート、波形キャプチャ、現在のDTS、完全なブート/ドライバーログを比較するために提供可能です。追加のターゲット測定やレジスタダンプが必要な場合はお知らせください。 現在、この立ち上げ作業に専念しており、残りの点についてご説明いただければ、次のテストを進める上で大変助かります。可能であれば、特にGPIOのシーケンスやテスト済みのファームウェア・設定について早期の回答をいただけるとありがたいです。そうすれば、Android 15のセットアップ準備を進める間、検証を続けられます。 引き続きご支援いただきありがとうございます。 よろしくお願いします、 ラケシュ Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ こんにちは、ウェイドンさん 88Q9098とAW693のデフォルトサポートを確認していただきありがとうございます。 DigiKeyとMouserでこれらのM.2カードの在庫状況を確認しましたが、どちらも現在在庫切れです。 M2-JODY-W377-00C — 9098 ベース M2-JODY-W683-00C — AW693ベース i.MX95 19×19 EVK搭載のオートモーティブAndroid 15.0.0_2.1.0でWi-Fi動作を実証する締め切りは1週間あります/ カーネル 6.12.23。他のサプライヤーや購入リンク、または対応可能なM.2カードをおすすめしてもらえますか?評価用のサンプルもあれば助かります。 Android オートモーティブ 15、Android 16、または他のBSPリリースでi.MX95で成功裏にテストされた他のWi-Fiモジュールはありますか?もしそうなら、正確なM.2カードの部品番号、チップセット、テスト済みのBSP/カーネルバージョン、購入元の情報を教えてください。最終的なターゲットはAndroid 15 / カーネル6.12.23のままですので、これらの代替案がターゲットに追加の統合を必要とするかどうかを明確にしてください。 一方で、既存のJODY-W263-00B / 88W8987は0xf005でファームウェアのアクティベーションに失敗しています。支援を優先し、利用可能なイネーブルメントパッチやドライバとファームウェアパッケージの一致、LinuxおよびAndroidテストの結果を共有していただけますか? モジュールをテスト用に送ってもいいとおっしゃっていましたね。当社のオフィスはインドのマハラシュトラ州プネにあります。ノイダのNXPチームとの共同デバッグの手配を手配してもらえますか?また、もしNXPがプネーにオフィスや適切な技術サポートチームを持っている場合は、ぜひお知らせください。 今週中にモジュールと必要に応じてEVKを訪問できます。できれば10月29日木曜日までに、チームの都合次第です。あなたの協力と継続的な関与は、現地チームが既に完了した捜査をさらに進める上で役立つでしょう。 この件が手配可能か、また誰にお問い合わせすればよいか教えてください。現地での検査ができない場合は、モジュールの送付方法をご案内いたします。 よろしくお願いします、 ラケシュ Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ @Rakesh_Kumar-Thakur様、 実際、NXP 88Q9098、AW693 M.2 Key Eモジュールをベースにしていれば、動作します。ですので、U-Bloxモジュールの選択は問題ありません。 車載 Android 15_2.1.0のコードを修正しました88W8987については、今週中にテスト結果が出る予定です。もしあなたのアプリケーションがオートモーティブ用途向けに設計されている場合、確かにオートモーティブ分野向けに設計されたNXP 88Q9098、AW693 Wi-Fiチップを使用する必要があります。   ありがとうございます よろしくお願いいたします。 維東 Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ こんにちは、ウェイドンさん 対応Wi-Fiカードを購入する前に、i.MX95 19×19 EVKおよびオートモーティブ Android 15.0.0.0_2.1.0でテストされた正確な製造元とM.2ご注文部品番号を必ず確認していただけますか/ カーネル 6.12.23? 私たちは以下のことを検討しています。 M2-JODY-W377-00C — NXP 9098ベース、PCIe Wi-Fi / UART Bluetooth M2-JODY-W683-00C — NXP AW693ベース 推奨するカードの具体的な機種名、チップセット番号、そしてリリース済みのBSPで動作するか、追加のパッチや設定が必要かをご確認ください。可能であれば、購入リンクを共有してください。 よろしくお願いします、 ラケシュ Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ こんにちは、ウェイドンさん ファームウェアのサイズの違いは初期化の失敗に関連しているのでしょうか? ファームウェアのファイルサイズは628,200バイトですが、ドライバはダウンロードしたものが619,156バイトと報告しており、差は9,044バイトです。診断ログによると、デバイスはオフセット619,156でそれ以上のデータ要求を停止しています。オフライン解析により、同じオフセットで終了する最終ブロックレコードが特定されたが、残りのバイトの用途はまだ確認されていない。 このファームウェアイメージはこれで予想されるのでしょうか?それともその後の0xf005アクティベーションタイムアウトに関連する転送が不完全であることを示しているのでしょうか? 私たちはオートモーティブのAndroid 15.0.0_2.1.0でJODY-W263-00B / 88W8987、ドライバー537.p9、ファームウェア16.92.21.p151.4を使用しています/ カーネル 6.12.23。 よろしくお願いします、 ラケシュ Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ @Rakesh_Kumar-Thakur様、 詳細な情報ありがとうございます。 >> P0_4 / W_DISABLE2# シーケンス:このピンは HIGH にプルアップする必要があります。これは Bluetooth を有効にするために使用されます。外部プルアップ抵抗器を使用してHIGHにプルアップすることは問題ありません。一部のM.2モジュールはPINを使ってBluetoothソフトウェアのリセットを制御しますが、一部のモジュールはPINを使いません。W603Cはそれを使用しています。 JODY-W263-00B。 M.2モジュールは手元にありませんが、AW-CM358-SUR(M.2モジュール)は持っています。明日Linuxプラットフォームでテストする予定です。 >>車載Android 15-2.1.0で有効にしてください。 はい、bsp のバージョンで 8987 モジュールを有効にする予定です。Androidのソースコードをリポジトリ同期するのに長い時間がかかるのはご存知でしょう。SO、少し時間が必要です。 デフォルトでは、車載AndroidのBSPは88Q9098とAW693、つまりオートモーティブWi-Fi製品のみをサポートしています。他のWi-Fiチップの場合は、有効化するために追加の作業が必要になります。 [注] もしW603CまたはAW-CM358-SUR M.2モジュールが通常は私の側で動作し、JODY-W263-00Bがまだ動作しない場合は、JODY-W263-00Bを私に送っていただき、私のプラットフォームで試してみることを検討してください。 ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 88W8987をベースにしたAW-CM358MAモジュールを有効にしようとしたところ、あなたと同じ問題が発生しました。 ================================= ファームウェアステータスのポーリングに失敗しました: firmwarestat=0xf005 SDIO Func0: 43 03 02 02 03 00 00 02 03 00 SDIO機能1: (0x5c) 0d (0x60) 01 (0x64) 10 SDIO機能1: 05 f0 00 00 00 00 00 00 24 14 70 ... ================================= 以下の手順に従って問題を解決しましょう。 1. 88W8987 GPIO[8]ピン。（データシートを参照） このピンには、クロック設定とUART_SOUTの2つの機能があります。 88W8987を起動する際、38.4MHzクロックを選択するには、ピンをLOWにする必要があります。 ただし、HOST UART_RXD ピンがプルアップに設定されている場合、88W8987 UART_SOUT もプルアップされます。 つまり、38.4MHzではなく、26MHzのクロックが選択されているということです。実際、ほとんどのモジュールは38.4MHzのクロックを使用しています。 だからLPUART5_RXD PADの設定をプルダウンに変更すべきです。 2. LPUART5_RXD PAD構成の変更 ...... IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e ...... 3. 私のデバイスツリー全体をあなたと共有します。 添付ファイルをご覧ください。 ぜひ試してみてください。 よろしくお願いいたします。 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 i.mx95-evkでAW-CM358MAモジュールを有効にし、Android 15_2.1.0の車載も有効にしましたbsp。手順をご説明しましょう。 ========================================== 1. android_build/device/nxp/imx9/evk_95/evk_95.mk # NXP 9098 Wi-FiおよびBluetoothコンボファームウェア PRODUCT_COPY_FILES += \ ベンダー/nxp/imx-firmware/nxp/FwImage_IW416_SD/sduartiw416_combo.bin:vendor/firmware/sduartiw416_combo.bin \ ベンダー/nxp/imx-firmware/nxp/FwImage_9098_PCIE/pcieuart9098_combo_v1.bin:vendor/firmware/pcieuart9098_combo_v1.bin \ vendor/nxp/imx-firmware/nxp/FwImage_IW612_SD/sduart_nw61x_v1.bin.se:vendor/firmware/sduart_nw61x_v1.bin.se \ ベンダー/nxp/imx-firmware/nxp/FwImage_AW693_PCIE/pcieuartaw693_combo_v1.bin.se:vendor/firmware/pcieuartaw693_combo_v1.bin.se \ ベンダー/nxp/imx-firmware/nxp/FwImage_8987/sduart8987_combo.bin:vendor/firmware/sduart8987_combo.bin \ ベンダー/nxp/imx-firmware/nxp/android_wifi_mod_para.conf:vendor/ファームウェア/wifi_mod_para.conf \ hardware/nxp/libbt/conf/nxp/evk_95/bt_vendor.conf:/vendor/etc/bluetooth/bt_vendor.conf 2. android_build/hardware/nxp/libbt/conf/nxp/evk_95/bt_vendor.conf # デフォルト設定を無効にする #mchar_port = /dev/ttyLP4 #baudrate_fw_init = 3000000 # # 設定を88W8987 Bluetoothに変更 mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 ボーレート_bt = 3000000 3. android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts LPUART5_RXピン /*プルダウン設定(GPIO[8]/UART_SOUT of 88W8987にコネクテッド)GPIO[8]はメインクロック選択に使われ、0--38.4M、1--26M、ほとんどのモジュールは38.4MHzのサイタル*/ pinctrl_uart5: uart5grp { fsl、pins = < IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e >; }; M.2コネクタにGPIO制御を追加する /* M.2モジュール電源有効化 */ reg_m2_pwr: regulator-m2-pwr { compatible = "regulator-fixed"; レギュレータ名 = "M.2-power"; レギュレーター-ミニ-マイクロボルト = <3300000>; レギュレーター最大マイクロボルト=<3300000>; GPIO = <&i2c7_pcal6524 20 GPIO_ACTIVE_HIGH>; 有効-アクティブ-高; startup-delay-us = <5000>; }; /* SD3 on M.2 Enable, SDIO RESET# ピン、PCAL6524HEAZ。P2_3 & PCAL6524HEAZ。P0_4 - 出力ハイ、usdch3ノードの「mmc-pwrseq」に消費される */ usdhc3_pwrseq: usdhc3_pwrseq { 互換 = 「MMC-PWsEq-Simple」; pinCtrl-names = "default"; reset-gpios = <&i2c7_pcal6524 19 GPIO_ACTIVE_LOW>、 <&i2c7_pcal6524 4 GPIO_ACTIVE_HIGH>; /* W_DISABLE2# */ }; /* プルアップ W_DISABLE1# PINでWiFiを有効にする、PCAL6524HEAZ。P0_6 - 出力ハイ */ reg_usdhc3_vmmc: regulator-usdhc3 { 互換 = 「レギュレーター固定」; レギュレーター名 = 「WLAN_EN」; レギュレーター-ミニ-マイクロボルト = <3300000>; レギュレーター最大マイクロボルト=<3300000>; VIN-SUPPLY = <&reg_m2_pwr>; GPIO = <&amp;i2c7_pcal6524 6 GPIO_ACTIVE_HIGH>; /* * IW612 Wi-Fi チップは他の Wi-Fi チップよりも遅延が必要です * 電源投入後のホストインターフェースの初期化、そうでなければ * IW612の内部状態が不安定であり、その結果 * SDIO3.0電圧を切り替えてください。 */ 起動遅延時間（US）= <20000>; アクティブハイを有効にする。 }; usdhc3ノードとピン制御を追加 /* uSDHC3 Pinctrlを追加 */ pinctrl_usdhc3: usdhc3grp { fsl、pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { fsl、pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { fsl、pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe >; }; /* usdhc3ノードを追加 */ &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; pinctrl-3 = <&pinctrl_usdhc3>; mmc-pwrseq = <&usdhc3_pwrseq>; vmmc-suppl = <&reg_usdhc3_vmmc>; バス幅 = <4>; 電源供給を一時停止する。 取り外し不可。 ウェイクアップソース; ステータス = "正常"; }; pcie0ノードを無効化 /* M.2 の pcie0 を無効化 - SDIO Wi-Fi のみを使用する */ &pcie0 { pinctrl-0 = <&pinctrl_pcie0>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-suppl = <&reg_pcie0>; ステータス = "無効"; }; 4. 試験結果 ============================================= ありがとうございます よろしくお願いいたします。 維東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん AW-CM358MAテストとAndroidの有効化ステップを共有してくださりありがとうございます。あなたのセットアップを再現し、モジュール選択を明確にするために、この4点を確認していただけますか? テスト済みモジュールとBSPバージョン 以前のLinuxテストではAmphenol W603CをL6.12.49_2.2.0で使用し、最新のオートモーティブ版Android 15.0.0_2.1.0テストではAW-CM358MAを使用していました。各テストごとにメーカー、完全なM.2カードの部品番号、チップセット、実際のカーネルバージョンを確認してください。先ほどAW-CM358-SURについても言及されていましたが、これは同じカードですか、それとも別のバリアントですか? マッチングソフトウェアパッケージ Androidテストが成功した場合は、正確なBSPマニフェスト/タグ、ドライバーリビジョン、ファームウェアバージョン/ハッシュ、wifi_mod_para.confを共有してください。カーネル6.12.23が使われていましたか?また、最新の返信での変更点以外に何か変更はありますか? JODY-W263-00Bへの解の適用 これらの変更は、リリースされたBSPドライバとJODY-W263-00Bのファームウェアを使って適用できますか?LPUART5_RXプルダウンを0x51eに変更するだけでクロックストラップに十分か、外部抵抗の改造が必要か確認してください。また、電源シーケンス後もP0_4/W_DISABLE2#は物理的にHIGHのままであるべきでしょうか? 代替カード M2-JODY-W377-00CおよびM2-JODY-W683-00Cについては、一般的な互換性と実際の検証を区別してください。これらのカードはNXPまたはモジュールパートナーによって、どのLinuxおよびオートモーティブのAndroid BSP/カーネルバージョンでテストされたのでしょうか?利用可能な参考文献を共有し、ターゲットに追加パッチが必要かどうかを確認してください。 当社の必要な基準はi.MX95 19×19 EVK B0、オートモーティブAndroid 15.0.0_2.1.0です。カーネルバージョンは6.12.23です。 よろしくお願いします、 ラケシュ Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 @Rakesh_Kumar-Thakur様、 下記をご覧ください。 ＞＞１．テスト済みのモジュールとBSPバージョン --Android 15.0.0_2.1.0bsp、あなたと同じです。 --BSPバージョンのデフォルトのWi-Fiドライバ。他のWi-Fiドライバは使っていません。 https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/android-automotive-os-for-i-mx-applications-processors:ANDROID-AUTO ＞＞２．マッチングソフトウェアパッケージ 上のスクリーンショットを見ると、Android BSPのバージョンは LF_v6.12.20 BSPを使用していますが、私たちがリリースしたAndroid 15.0.0_2.1.0 bspは L6.12.23を使用しませんでした。 ＞＞３．JODY-W263-00Bにソリューションを適用する はい、そう思います。AW-CM358MAを使うとあなたと同じ問題を再現できるからです。 JODY-W263-00Bが使えると思います。i.MX95のLPUART5_RXDピンは、DTS内でプルダウン抵抗を設定するだけで済みます。 ＞＞４．代替カード M2-JODY-W377-00CとM2-JODY-W683-00Cはそれぞれ9098とAW693をベースにしています。はい、アプリケーションに合わせて選択できます。 [注] JODY-W263-00Bを正常に動作させるには、私の手順に従うことをお勧めします。     ありがとうございます よろしくお願いいたします。 魏東 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 こんにちは、ウェイドンさん AW-CM358MAの有効化ステップを共有してくださりありがとうございます。 対応する変更は、u-blox JODY-W263-00B (88W8987)、オートモーティブ Android 15.0.0_2.1.0を搭載したi.MX95 19×19 EVKにも適用しました/ カーネル 6.12.23。 ライブデバイスツリーで以下の項目を確認しました。 LPUART5_RXパッド構成: 0x51e。 GPIOをリセットします：19番ピンはACTIVE_LOW、4番ピンはACTIVE_HIGHです。 M.2/WLAN有効化遅延：5msと20ms。 SDIO pinctrl の状態とウェイクアップソース。 PCIe0とPCIe1は無効になっています。 Bluetoothの設定も更新されました。修正済みのイメージセットを再フラッシュすると、mlanとmoalが自動的にロードされます。SDIOはSDR104モードで列挙されるが、ファームウェアのアクティベーションは依然として失敗する。 WLAN: ファームウェアのダウンロード完了、ファームウェア長=628200、ダウンロード済み619156 ファームウェアステータスのポーリングに失敗しました: firmwarestat=0xf005 FWが時間内にアクティブ化できませんでした！ ファームウェアの初期化に失敗しました 次のステップを明確にしていただけますか? 成功したセットアップにはハードウェアの変更、抵抗の割り当て・除去、ジャンパーの変更、UART/JTAGのディップ・スイッチ設定などが必要でしたか?正確な設定とコンポーネントの参照情報をお知らせください。 JODY-W263-00Bは、テスト済みのAW-CM358MAと比べて、特にW_DISABLE1#、W_DISABLE2#、電源/リセットシーケンス、またはクロック選択に関して、何か異なる設定が必要ですか？ GPIO[8]/UART_SOUTクロックストラップの場合、レベルはいつサンプリングされますか？Linux DTSのプルダウンで十分でしょうか、それとも初期のU-Boot/電源オン設定が必要ですか? このストラップの想定起動電圧と、測定可能な測定ポイントをご確認ください。DTS構成は検証済みですが、サンプリング時の物理的なストラップレベルはまだ確認できていません。 テスト済みのドライバの正確なバージョン、ファームウェアバージョン/SHA-256、wifi_mod_para.confをぜひ教えてください。参照起動波形も併せて含める。 どの測定方法または対照試験を最初に行うべきか、ご提案ください。完全なDMESGおよびライブデバイスツリーを提供できます。 よろしくお願いいたします。 ラケシュ

MCALはコード生成のためにソースコードを必要とします。 こんにちは、NXPサポートの皆さん、 MCALバージョン: SW32K3_S32M27x_RTD_4.4_4.0.0_P24 以下の.hファイルの名前を変更するとファイルを.hhに変換すると、ADC生成が失敗します。 コード生成時に生成されたソースコードが必要なのはなぜですか？ 私の職場にはローカルソースポリシーがなく、ARXMLのような非ソースコードの設定しかローカルPCに入れられないので質問しました。 BR/くまモン Re: MCAL expects source code for code generation こんにちは、 @kumamon さん。 構成生成は必ずしもARXMLのみに基づいて行われるわけではない。生成プロセス中、MCAL設定ツールはインストールされたRTD/MCALパッケージの一部として、定義やジェネレーターに必要な情報を含むヘッダーファイルも提供する必要があります。 したがって、期待される .h のいずれかがファイル名が.hhに変更されると、ジェネレーターがその依存関係を特定・処理できなくなる可能性があり、コード生成が失敗することがあります。 BR、VaneB

PQ2 Pro(MPC830x)用のDDR2レジスタパラメータアーキテクチャ(RPA)カリキュレータを探しています NXPのMPC830xページには多くの設計ドキュメントがありますが、何らかのカリキュレータ(スプレッドシート?)があると聞いています。これはDDR2レジスタ設定の計算に役立ち、おそらく次のような名前が付けられます。 MPC830x_DDR2_RPA.xls あるいは、そのバリエーション。たとえそれが他の PowerQuicc 2 (つまり、DDR2 を使用した MPC830x と全く同じではありませんが、役に立つかもしれません。 アーカイブや評価ボードの資料と一緒に保管されている可能性はありますか? ご回答をお待ちしています。 Re: Looking for DDR2 Register Parameter Architecture (RPA) Calculator for PQ2 Pro (MPC830x) こんにちは、 @mrand さん。 MPC830xファミリーは3年以上前に終了しているため、リクエストされたファイルやダウンロードリンクはもはや利用できません。 DDRレジスタのプログラミングに関するガイダンスについては、AN3369を参照してください。 ありがとう。   よろしくお願いいたします。 6月

使用 TRIGMUX+eMIOS 进行 BLDC 电机方向测量 描述：我正在使用 NXP 推荐的 6 步换向解决方案来驱动我的 BLDC 电机。 根据应用笔记“ https://community.nxp.com/t5/S32M-Knowledge-Base/S32M276-Hall-sensor-based-6-step-BLDC-motor-control/ta-p/2035021#jump_PwmAndTriggers ” 霍尔传感器的输出信号送至 TRIGMUX，然后送至 LCU 进行换向，并用于计算速度信号。本文并未提及如何测量电机旋转方向。 NXP是否有测量电机方向的解决方案？我的理解是，要测量方向，我们需要使用输入采集单元捕获所有 3 个霍尔传感器的输出。 我的 eMIOS 通道是否可以按如下方式配置？ CH0 - 输入捕获模式，通过 TRIGMUX 从 LCU 接收速度信号。 CH1 - 输入捕获模式，用于接收 Hall1。 CH2 - 输入捕获模式，用于接收 Hall2。 CH3 - 输入捕获模式，用于接收 Hall3。 请提供一些说明。

NTAG X DNA AES-128 转 AES-256 AppMasterKey ChangeKey 返回 0x917E 你好， 我正在使用NTAG X DNA开发板，搭配树莓派4B和Adafruit PN532开发板。我正在尝试使用 ChangeKey 在经过身份验证的 EV2 安全消息会话下，将应用程序 AppMasterKey 从出厂默认的 AES-128 全零密钥更改为 AES-256 密钥。 根据数据表修订版，AppMasterKey 的预期更新如下： 使用 AuthenticateEV2First 和 AppMasterKey 0x00 进行身份验证 在 CommMode.Full 模式下发送 ChangeKey 将 KeyNo[7:6] 设置为 11b，密钥类型为 AES256 Encrypt KeyData = NewKey || KeyVer (因为目标密钥是 AppMasterKey )。这应该是一个 32 字节的 AES256 密钥 + 1 字节版本 应用 ISO/IEC 9797-1 方法 2 填充：33 字节纯文本 -> 48 字节 附加 EV2 CMAC 的 8 个偶数字节。 APDU 包含预期的 57 字节数据字段，但标签返回 0x917e 错误，即长度错误 (LENGTH_ERROR)。 我们尝试将 AppMasterKey 从出厂默认的 AES128 密钥更改为非零值，并且成功了。这似乎也不是 PN532 的传输大小限制，因为它能够验证有效负载高达 100 字节的 CryptoRequest 命令，并且验证成功。此外，在ChangeKey命令失败之前，相互认证和EV2会话密钥派生均已成功。 最后，该标签通过 GetVersion 命令将自身标识为 NTAG X DNA。请问最佳方案是什么？将 NTAG X DNA 系列的密钥更改为 AES256 是否存在任何限制或已知问题？ 提前致谢。 此致， 否 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 您好， 请您使用 Lc 和 Le 的扩展长度字段重复测试吗？ 例如：90 C4 00 00 00 00 39 C0<48-byte encrypted data><8-byte CMAC> 00 00 问候， 爱德华多。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 你好@EduardoZamora ， 非常感谢您的及时回复。 我们尝试发送的 APDU 为：90c4000039c054d419618197a659d7346b7f7869b0a9972216d077258b6a58320d65019663e3695d16e265f93f594d131818ee9d889c7feb8ac85cb442b400 我们只是想把 K0 从全零 AES128 改为全零 AES256。 希望这能帮到你。如果您需要任何其他信息，请告诉我。 再次感谢。 此致， 否 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 你好@n_s 希望你一切都好。 整个流程看起来不错。 不过，完整的原始 APDU 文件仍然很重要；能否请您分享一下您想要发送的完整帧？ 问候， 爱德华多。

NTAG X DNA AES-128からAES-256へのAppMasterKey ChangeKeyの返0x917E こんにちは、 私はNtag X DNAにRaspberry Pi 4BとAdafruit PN532を使っています。認証済みEV2のセキュアメッセージングセッション下で、ChangeKeyを使って、AppMasterKeyの工場出荷時のAES-128オールゼロキーからAES-256キーに変更しようとしています。 データシートの改訂によると、AppMasterKeyの予定されているアップデートは以下のとおりです。 AuthenticateEV2Firstを使用してAppMasterKey 0x00で認証します。 通信モードをフルに設定してChangeKeyを送信します。 KeyType.AES256 の KeyNo[7:6] を 11b に設定します。 KeyData = NewKey || KeyVer を暗号化します（ターゲットキーは AppMasterKey であるため）。これは32バイトのAES256キーと1バイトのバージョンで構成されるはずです。 ISO/IEC 9797-1方法2の適用:33バイト平文-> 48バイト EV2 CMACの偶数バイト8個を追加する APDUには期待通りの57バイトのデータフィールドが含まれているが、タグは0x917eエラー（LENGTH_ERROR）を返した。 AppMasterKeyを工場出荷時のデフォルトキーであるAES128からゼロ以外の値に変更してみたところ、成功しました。また、PN532の転送サイズ制限が原因ではないようです。なぜなら、最大100バイトのペイロードを持つCryptoRequestコマンドの認証に成功しているからです。さらに、相互認証とEV2セッション鍵の導出は、失敗したChangeKeyコマンドよりも先に成功します。 最後に、タグはGetVersionコマンドを通じてNTAG X DNAとして自己認識します。この件について最善の方法についてアドバイスいただけますか?NTAG X DNAシリーズのキーをAES256に変更することに制限や既知の問題はありますか? 前もって感謝します。 よろしくお願いいたします。 N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは、 LicとLeの拡張長フィールドを使ってテストをもう一度行ってもらえますか? 例：90 C4 00 00 00 00 39 C0<48-byte encrypted data><8-byte CMAC> 00 00 よろしくお願いいたします。 エドゥアルド。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは@n_s あなたの調子が良いといいのですが。 全体的な手順は良好に見える。 それでも、完全な生のAPDUは重要です。送ろうとしているフルフレームをぜひ共有していただけますか? よろしくお願いいたします。 エドゥアルド。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは、 @EduardoZamora さん、 迅速なご返信、ありがとうございました。 送信しようとしている APDU は次のとおりです: 90c4000039c054d419618197a659d7346b7f7869b0a9972216d077258b6a58320d65019663e3695d16e265f93f594d131818ee9d889c7feb8ac85cb442b400 私たちは、K0をすべてゼロのAES128からすべてゼロのAES256に変更しようとしています。 お役に立てば幸いです。他に何か情報が必要な場合はお知らせください。 再度、感謝します。 よろしくお願いいたします。 N

S32 Design Studioのライセンスが切れました こんにちは、NXPサポートの皆さん。このメッセージがあなたの元に無事届くことを願っています。私のS32DSライセンスが期限切れになり、現在の開発作業が妨げられています。延長を手伝ってもらえますか? 私の認証ID： 406C-B408-57DB-0C62 製品:ARM v2.2用のS32 Design Studio。 ご返信よろしくお願いします。 SDK

S32 Design Studio License Expired Hello NXP Support, I hope this message finds you well. My S32DS license has expired, and it’s blocking my current development work. Could you kindly help extend it? My Activation ID : 406C-B408-57DB-0C62.  Product : S32 Design Studio for ARM v2.2. Thank you very much. SDKs