[不正使用] 投稿者: @JohnKlug / ボード: imx-processors / 報告者: hcrpcn hcrpcn は、 @JohnKlug が投稿した 「Could not invoke dnf for external kernel module in Yocto kirkstone」という 投稿について、以下の理由で報告しました。 理由:その他 詳細： 投稿リンク: https://community.nxp.com/t5/i-MX-Processors/Could-not-invoke-dnf-for-external-kernel-module-in-Yocto/mp/1627964#M203740 投稿者: @JohnKlug |メール著者 報告者: hcrpcn |メールレポーター 報告された投稿には 2 件の返信があります。

[不正使用] 投稿者: @JohnKlug / ボード: imx-processors / 報告者: cxcegzqe cxcegzqe は、 @JohnKlug が投稿した 「Could not invoke dnf for external kernel module in Yocto kirkstone」という 投稿について、以下の理由で報告しました: 理由:誤解を招く、または虚偽の情報 詳細： 投稿リンク: https://community.nxp.com/t5/i-MX-Processors/Could-not-invoke-dnf-for-external-kernel-module-in-Yocto/mp/1627964#M203740 投稿者: @JohnKlug |メール著者 報告者: cxcegzqe |メールレポーター 報告された投稿には 2 件の返信があります。

意外的 VLAN 标记 - 需要您的建议 您好， 我遇到了一个奇怪的 L2 行为，希望能得到您的帮助。 背景信息 端口-0：MAC 66:66:66:xx:xx:xx，VLAN 0（访问）。 端口-1：PHY、动态 MAC、VLAN 0（接入） 端口-4：MAC ba:43:60:ee:9d:81，双模 VLAN 0 + VLAN 100（中继） 预期规则 从 66:66:66:xx:xx:xx 到 ba:43:60:ee:9d:81 的任何内容都必须以 VLAN 100 标记离开端口-4。 从 ba:43:60:ee:9d:81 到 66:66:66:xx:xx:xx 的返回流量必须在到达端口-0 之前删除 VLAN 0 标记。 从 66:66:66:66: xx: xx: xx 或 ba: 43:60: ee: 9d: 81 到 Port-1 上的 Dynamic-Mac 设备的任何帧都必须在未加标签的情况下到达。 症状 源于 66:66:66:xx:xx:xx 并以 ba:43:60:ee:9d:81 为目标的 UDP 数据包在端口-4 上正确地标记了 VLAN 100。 完全相同流量的 TCP 数据包到达端口-4 时没有VLAN 100 标记。 L2 转发不应该关心 L4 协议，因此这种差异令人费解。 当前交换机是 SJA1105Q；未配置任何参考第 4 层类型的手动 ACL 或 QoS 我的。 您能否帮助我 a) 理解为什么 UDP 和 TCP 的标记行为不同，以及 b) 建议正确的 VLAN/端口配置，以保证从 66:66:66:xx:xx 到 ba:43:60:ee:9d:81 的所有流量都始终通过 VLAN 100 发送出去？ 如果需要，我可以共享数据包捕获或运行配置。 感谢您抽出宝贵时间！ 顺祝商祺！   SJA1105PQRS Re: Unexpected VLAN-tagging – need your advice 你好@engorge4556、 感谢您分享配置和细节。在审阅了剧本和您的描述之后，以下是要点和建议： 澄清 VLAN ID 确认一下：您配置中的 VLANID = 0x100 值对应的是 VLAN 256，而不是 VLAN 100。如果您的目标是 VLAN 100，正确的十六进制值应该是 0x64。既然您明确选择了 0x100，我就假定您要使用的是 VLAN 256。 建议 NO_MGMT_LEARN = 1 目前，您的脚本设置了 NO_MGMT_LEARN = 0，允许在管理（CPU/HOST）端口上进行 MAC 学习。当 CPU 端口看到流量时，这会无意中影响转发数据库 (FDB) 并覆盖静态规则。 对于确定性配置（静态 TCAM 规则和 VLAN 重标记应始终适用），我建议设置"NO_MGMT_LEARN": 1 这将禁用 CPU 端口上的学习功能，防止管理流量导致转发行为发生意外变化。 两个关键更改可实现一致的 VLAN 行为 启用静态 L2 规则 更改："use_static": 1 这可确保静态 TCAM 规则（含 RETAG/MIRRVLAN）先于动态学习的 MAC 条目应用。如果不这样做，动态学习就会覆盖你打算进行的 VLAN 重标记。 纠正 L2 地址查询中的 DESTPORTS 在当前规则中，DESTPORTS 包括入口和出口端口。只能指定出口端口。例如 规则为：ba:43:60:ee:9d:81 → DESTPORTS = (1<< 4) 返回 66:66:66:xx:xx:xx 的流量规则 → DESTPORTS = (1<< 0) 端口-1 上 PHY 的流量规则 → DESTPORTS = (1<< 1) 这样可以防止意外复制，并确保帧只从正确的端口退出。 为什么 UDP 和 TCP 在您的原始设置中表现不同 交换机不检查 L4 协议，因此差异不是由于 UDP 与 TCP 造成的。结果是 第一个数据包（通常是 UDP 测试）会因为目标 MAC 未知而泛滥。VLAN 标记会如期工作，因为帧会通过 VLAN 查找和标记逻辑。 在 TCP 握手或双向通信后，交换机会动态学习 MAC（将 VLAN 0 作为入口 PVID）。由于 USE_STATIC = 0，动态 FDB 条目优先，因此在不应用重标记规则的情况下转发帧，从而在中继上产生无标记流量。 启用 USE_STATIC 并更正 DESTPORTS 后，就可以消除这种不一致性。 建议书 prio_queue 根据最近的经验，请考虑调整 prio_queue* 设置（第 134-141 行），使其与 sja1105QS.py 中使用的配置相匹配。 这一更改为优先级定义了更小、分布均匀的队列范围（而不是一个大队列和七个空队列）。这样做的好处是，在大负载或高吞吐量测试（如 iperf）期间，可以将流量分散到多个队列中，而不是拥堵在一个队列中，从而减少丢帧的数量。 顺祝商祺！ 帕维尔

nxpimage ahab update-keyblob を使用してセカンダリ AHAB コンテナー セットの DEK blob を更新できません。 デバイス： mimx9352 （i.MX93）。 SPSDK バージョン: spsdk 3.4.0 ブートイメージレイアウト: 2 つの AHAB イメージ コンテナー セットを含むブート可能なイメージ: プライマリ セット: コンテナ 0 (ELE)、コンテナ 1 (SPL DDR)。 セカンダリ セット: コンテナー 0 -> イメージ 0 (BL31)、イメージ 1 (U-Boot)、イメージ 2 (TEE)。 DEK: 256ビット、 key_identifier: 0。 DEK blob が YAML ファイルで提供されている場合、ビルドは正常に機能します。flash.bin上の運用時のahab update-keyblobは SPL のみを更新します。 https://spsdk.readthedocs.io/en/latest/examples/ahab/imx93/imx93_signed_ahab_uboot.htmlを参考にしました。 update-keyblob でセカンダリセット/コンテナーを選択するにはどうすればよいですか？このコマンドは、複数のセットのブート可能イメージをサポートしていますか？完全な再構築を行わずにセカンダリセットの BLOB を更新するための推奨ワークフローはありますか？ ありがとう、 ウダイ Re: Unable to update DEK blob for secondary AHAB container set using nxpimage ahab update-keyblob. こんにちは@udayMouli 最新の SPSDK ツール v3.5.0 をご利用いただいてもよろしいでしょうか? https://github.com/nxp-mcuxpresso/spsdk/releases Zhiming_Liu_0-1765779000637.png update-keyblob コマンドの使用方法: https://spsdk.readthedocs.io/en/latest/apps/nxpimage.html#nxpimage-ahab-update-keyblob update-keyblob の一般的な使用法: https://spsdk.readthedocs.io/en/latest/images/ahab.html#ahab-update-keyblob よろしくお願いします、 志明

S32K344のFCCU入力ピンの使い方 例えばS32K344 100ピンパッケージには、これらの機能を備えた72ピンのGPIO[3]があります。 「FCC_ERR_IN」信号の機能と内部動作は何ですか?外部 IC 障害出力に接続して FCCU 入力ピンに「デイジー チェーン」接続するために使用できますか?   S32K344-WB #FCCU #S32K3 優先度: 高 SAFETY_SW 出典: 直接お客様 Re: How to use FCCU Input Pins on S32K344 フィードバックありがとうございます。HW デザインチームに連絡します。 Re: How to use FCCU Input Pins on S32K344 こんにちは@YukoKintoさん、 RM にはそのピンの使用法に関する情報がこれ以上ありません。使用法を明確にするには、HW 設計チームの担当者にお問い合わせください。 お客様がこのピン機能を使いたいとおっしゃるのは初めてですが、S32 セーフティマニュアルには写真のように使用するための情報が記載されていません。 SAF では、FOM テスト モードと呼ばれるものがサポートされています。 SO、EOUT ピンが正しく動作するかどうかをテストするには、eMcem 関数を利用できます。 eMcem_EnterTestFOM() eMcem_WriteErrorOutput() eMcem_ReadErrorOutput() eMcem_ExitTestFOM() しかし、これは EOUT ピンをテストするためのものであり、外部 IC 障害の検出のためのものではありません。 FCCU_IN_ERR ピンがアサートされた場合に DCMROD ビット (および最終的には何らかの FCCU 障害) を発生させるものがあるかどうか、DCMROD レジスタをチェックしましたが、そのようなものは見つかりませんでした。 ただし、RM の説明は明確ではない可能性があるため、HW 設計で確認する必要があります。 敬具、 ラドスラフ

i.MX RT1064 高スループット RX バースト中のパケット損失 (Raw イーサネット) こんにちは、皆さん 私は現在、NXP i.MX-RT1064 マイクロコントローラを使用して Raw イーサネット実装（レイヤー2、TCP/IPなし） に取り組んでおり、高トラフィックバースト時にパケット損失の問題が発生しています。 私のシステム構成と私が観察している具体的な動作は次のとおりです。 セットアップ MCU:すべてのノードでi.MX-RT1064 ネットワーク:マスター 1 台とスレーブ 10 台。 トポロジ: すべてのノードは管理対象スイッチを介してコネクテッドされています。 プロトコル: カスタム レイヤー 2 Raw イーサネット。 メカニズム:マスターがブロードキャスト要求を送信します。10 台のスレーブすべてがこれを処理し、すぐにユニキャスト応答を送信します。 問題マスターはブロードキャスト要求を正常に送信するものの、10 個の応答の完全なセットを受信できません。 Wireshark (スイッチのポートミラーリングを使用) 経由でトラフィックを分析しているときに、ドロップされたパケットのタイムスタンプが他の成功したパケットとナノ秒単位まで同一であることが多いことに気付きました。2 台以上のスレーブが同時に応答すると、マスターはフレームの 1 つ (または両方) をドロップするようです。 現在の理論 RX 記述子:トラフィックの「爆発」により、マスターの ENET ペリフェラルが圧倒されています。この瞬間的なバースト中に、DMA が記述子を十分な速度で移動できず、RX リング バッファーをクリアできない可能性はありますか? 質問: このアーキテクチャでこのタイプのトラフィックの爆発を処理するためのベスト プラクティスは何ですか? RT1064 ENET モジュールに関する洞察や構成のヒントがあれば、ぜひ教えてください。 よろしくお願いします！ i.MXRT 106x Re: i.MX RT1064 Packet Loss during High-Throughput RX Burst (Raw Ethernet) NVIC_SetPriority 関数を呼び出して、ENET 割り込み優先度を上げてください。 Re: i.MX RT1064 Packet Loss during High-Throughput RX Burst (Raw Ethernet) こんにちは@mayliu1さん、 ご返答とご提案ありがとうございます。 ご指摘に基づいて設定を見直しました。詳細は次のとおりです。 SDK とドライバ: MCUXpresso SDK バージョン (例: 2.11.0) と、それに付属する ENET ドライバ (fsl_enet_driver 2.5.3) を使用しています。 バッファの場所: 私の ENET バッファは、ENET_RXBD_NUM が 32 に設定された DTCM にあります (キャッシュ不可能であることを確認するために、画像で参照したのと同じマクロを使用しています)。 割り込み: ENET 初期化中に enet_config_t で設定されたコールバック関数を使用しています。 そして、提案に従って最新の SDKs バージョンに更新し、テスト後に結果を報告します。 感謝と敬意を込めて、 カルティーク Re: i.MX RT1064 Packet Loss during High-Throughput RX Burst (Raw Ethernet) こんにちは@kartheek4B7さん、 弊社の製品にご興味をお持ちいただき、またコミュニティをご利用いただき誠にありがとうございます。 1: 現在使用しているMCUXpresso SDKのバージョンとENETドライバはどれですか？ MCUXpresso SDKの最新リリースバージョンを使用してください。 2: ENET バッファは現在 OCRAM または DTCM に配置されていますか? RX/TX リングとデータ バッファをキャッシュ不可能なメモリに設定することをお勧めします。 3: RX リング バッファーの深度を増やしてください。 以下に例を挙げます。 mayliu1_0-1765334967971.png 4: ENET RX 割り込み優先度を上げて、ISR の作業負荷を最小限に抑えてください。 お役に立てれば幸いです。 まだ質問がある場合は、お気軽にご連絡ください。 よろしくお願いします メイリュー Re: i.MX RT1064 Packet Loss during High-Throughput RX Burst (Raw Ethernet) こんにちは@mayliu1 このアーキテクチャには、バースト サイズと記述子数に関する一般的なルールがありますか?具体的には、フレームバーストの場合、パケット損失を防ぐために記述子の数をバースト サイズに一致させることが必須ですか? Re: i.MX RT1064 Packet Loss during High-Throughput RX Burst (Raw Ethernet) こんにちは@kartheek4B7さん、 記述子数がバースト サイズと一致するという厳密な要件はないと思います。 ただし、バースト サイズが利用可能な記述子を超えると、パケット損失が発生する可能性があります。 SO、記述子数を予想されるバースト サイズと同じか、わずかに上回る値に設定することを検討することをお勧めします。 よろしくお願いいたします。 メイリュー

KW45の起動時間を短縮 KW45 MCUで開発しています。NVIC_SystemReset() の開始から ResetISR() のエントリまでの期間は約 140 ミリ秒であることがわかりました。KW45 の GPIO ピンのレベルを交互に変化させることで時間を測定します。 起動時間の分析方法と、起動に時間がかかる理由を教えてください。ありがとう。 Re: Shorten KW45 Boot time Hello KW45B41Z-EVK を使用しているか、カスタム KW45 ボードを使用しているか確認していただけますか? KW45 リファレンス・マニュアルの図 23 にはトップレベルのブート フローが示されています。これは、シーケンスを解釈して、なぜその時間がかかるのかの理由を理解するのに役立ちます。 また、表57と表58のブート構成では、使用可能な電力とクロックを設定するためのブート速度について説明します。クロック[32 MHz]の通常ブートまたはクロック[96 MHz]の高速ブートを使用します。 よろしくお願いいたします。 ルイス Re: Shorten KW45 Boot time こんにちは、ルイス。 ご返信とご指導ありがとうございます。 私はカスタム KW45 ボードを使用していますが、カスタム ボードをリセットするのに 141 ミリ秒が必要な理由をまだ理解中です。 KW45B41Z-EVK でも同じ操作を試しました。 PIN PTD1の出力レベルをLOWに設定する __NVIC_SystemReset() を呼び出す ResetISR()の開始時にPIN PTD1の出力レベルをHIGHに設定する わずか17ミリ秒程度かかります。 David0406_0-1765273498129.png よろしくお願いいたします。 デビッド Re: Shorten KW45 Boot time こんにちは、 両方のボードで同じ例をテストしているかどうか確認していただけますか?SDK の例を使用してテストし、どの例がどの SDK からのものであったかを教えてください。 カスタム KW45 ボードを使用しているため、設計が NXP の推奨ガイドラインに従っているかどうかを確認できるようにしていただけますか。KW45 (オートモーティブ) または K32W1/MCXW71 (IoT/インダストリアル) を使用して初めて PCB を正しく構築する最善の方法という投稿を確認することをお勧めします。この投稿には、 KW45 ハードウェア設計推奨事項公開での推奨事項など、KW45 カスタム ボードに必要な全体的な特性が含まれています。これらのコンポーネントやその他の推奨資料を変更すると、起動時間に影響する可能性があります。 カスタム ボードで使用されているクロックの詳細を教えていただけますか? 敬具、ルイス Re: Shorten KW45 Boot time こんにちは、ルイス。 ご返信とさらなるご支援を誠にありがとうございます。 両方のボードで同じコードを実行すると、次のアクションが実行されます。 __NVIC_SystemReset() を呼び出す直前に GPIO ピンの出力レベルを低く設定し、ResetISR() の開始時にピンを高く設定します。 結果は同じです: EVK では約 17 ミリ秒、カスタム ボードでは 140 ミリ秒かかります。 一時的にファームウェア レイヤーに留まり、ハードウェアの違いに加えて、カスタム ボードでデュアル イメージ ブートが有効になっているためにブート時間が異なる理由を調べてみます。問題が複雑化する可能性があるとの懸念から、この情報はこれまで提供されていませんでした。 カスタム ボードの回路デザインを確認するための詳細なガイドラインを提供していただき、ありがとうございます。これにより、根本原因を特定するための追加の指示が得られます。 よろしくお願いいたします。 デビッド Re: Shorten KW45 Boot time こんにちは、 情報を共有していただきありがとうございます。 KW45 リファレンス マニュアルによると、デュアル イメージ ブート プロデュースを使用してセカンダリ イメージからのブートを試行すると、カスタム ボードに反映される時間差に影響します。この情報は、図 25 のフロー図に示されています。 デュアルイメージブートの詳細については、15.2.3.1章を参照してください。 敬具、ルイス Re: Shorten KW45 Boot time こんにちは、 KW45 の起動時間に関する統計はありません。 必要に応じて、リファレンス・マニュアルの15.2.3.1章に配置されたアドレスを含むCASE例を使用する手順が記載されています。 敬具、ルイス Re: Shorten KW45 Boot time こんにちは、ルイス。 有益なご返信をありがとうございます。 私たちはまださらに研究を続けており、ブートプロセスを追跡する方法を探しています。 デュアル イメージが有効になっている KW45 の起動時間に関する統計情報はありますか? よろしくお願いします、 デビッド

Freemaster3.2 检测不到 S32K144EVB 我在 S32 Design Studio 3.6.4 中有一个项目希望使用 Freemaster 3.2 调试它。我使用的是 S32K144EVB。应通过 LPUART 1 与 PTC6 和 PTC7 连接。如图所示，我手动添加了 freemaster 驱动程序，并在 freemaster_cfg.h 中将 LPUART 0 更改为 LPUART 1。 但是 Freemaster 无法检测到板... 原因可能是什么？ FBre99_0-1764924012769.png FBre99_1-1764924377396.png Re: Freemaster3.2 don't detect S32K144EVB 您好@FBre99， 您能否确认： -在主源文件中包含"freemaster.h" -使用"FMSTR_Init() 初始化 FreeMASTER 驱动程序" -定期调用 "FMSTR_Poll()" 例程。 如果使用中断模式： #define FMSTR_LONG_INTR 1 或 #define FMSTR_SHORT_INTR 1 中断由"FMSTR_Isr()"处理。 快速检查以确认配置是否正确： 1. 切换到轮询模式 - #define FMSTR_POLL_DRIVEN 1 2. 添加调试宏 - #define FMSTR_DEBUG_TX 1 3. 打开串行终端（例如 putty）并连接到通信端口。 如果成功，你应该看到从板发送的持续调试消息 " +@W "。 Re: Freemaster3.2 don't detect S32K144EVB 你好@FBre99, 看来是 LPUART 配置不正确，或者你使用的是自定义波特率--我在你的 putty 终端上只看到了无法打印的符号。此外，您是否调用了外设初始化例程 -Lpuart_Uart_Ip_Init()？ 请注意 FreeMASTER 驱动程序不会配置 LPUART，您需要在FMSTR_Init() 之前使用 RDT API 对其进行初始化。 我附上了一个示例项目，你可以用作参考。 在该项目中，我包含了最新版本的 FreeMASTER 驱动程序（我从 S32K3 中获取了它，因为我们没有计划对 S32K1 进行任何更新）。它允许您使用所有最新的 FreeMASTER（甲板停止工具）功能。 希望对您有所帮助， Iulian Re: Freemaster3.2 don't detect S32K144EVB 你好@iulian_stan、 我添加了调试宏，并将通信端口连接到 Putty。EVB 发送调试信息。但是，当我删除调试宏并尝试将 EVB 连接到 Freemaster 时，Freemaster 仍然无法找到 EVB。 我下载了 main.c 和 freemaster_cfg.h 文件。 FBre99_0-1765287336825.png    Re: Freemaster3.2 don't detect S32K144EVB 嗨，@iulian_stan、 该示例项目与 freemaster 的连接是有效的。 谢谢。

相机模块 v2 (IMX219) 与 i.MX93 FMDR 兼容 你好，恩智浦支持人员。 我需要您的意见来澄清。我最近购买了一块i.MX93 FMRD板用于人工智能开发。通过使用恩智浦提供的预构建 Debian 映像（桌面），可以观察到固件中包含了 IMX219（Raspberry Pi 的摄像头模块 v2）。但是，将相机与板连接后，没有输出。 我能问一下我们有什么方法可以直接将板与 IMX219 传感器连接吗？或者我们需要从恩智浦购买额外的适配器？ 谢谢 FRDM-i.MX93

RT685 CTimer0 回调延迟 我修改了适用于 MIMXRT685-AUD-EVK 的 SDK 25.9 中的 mimxrt685audevk_lpadc_dma_cm33 示例，创建了这个链：CTIMER0-> ADC-> DAC-> PingPongBuffer 在 RAM 中。 CTIMER0：32kHz；toggleBit on match_ch_3 ADC0：在触发信号 5 上启动；每 16 个样本为 DMA 创建中断（FIFO 水印 = 15）DMA0：PingPong；启动硬件触发信号 24 我在回调中添加了设置/清除引脚，以便调试。 从引脚日志中可以看出，当触发信号 DMA 时，CTimer0 回调似乎会延迟，即使 DMA 的执行时间与 CTimer 时序不重叠。 谁能告诉我为什么会出现这种情况？ i.MX RT600 Re: RT685 CTimer0 callBack delayed 你好@katte82、 非常感谢您关注我们的产品并使用我们的社区。 我建议仔细检查以下几点： 1：设置 NVIC 优先级，尝试为 CTIMER0 分配比 DMA 和 ADC 更高的优先级，然后再次测试。 2：确认传输类型已设置为 kDMA_PeripheralToMemory。 mayliu1_0-1764831075550.png 顺祝商祺！ MayLiu Re: RT685 CTimer0 callBack delayed 1) 设置优先级可以解决问题。但我不明白为什么要这样做。理论上，硬件拥有处理 DMA 回调所需的全部时间。 2) 我试了很多次，但如果切换到 PeripheralToMemory，就会发生奇怪的事情，什么也做不了。ADC 仍处于中断状态，DMA 从未调用回调。也许 PeripheralToMemory 无法正确处理设置为 15 的水印？ 谢谢。 谢谢。 Re: RT685 CTimer0 callBack delayed 你好@katte82、 感谢您提供的最新信息。 答 1：这是必要的，因为回调在中断服务例程 (ISR) 中运行，而 NVIC 优先级决定谁先运行。 DMA/ADC ISR 抢占了 CTIMER0，因此 CTIMER0 回调被延迟。 答 2：我建议您参考 SDK 演示"evkmimxrt685_lpadc_dma_cm33" 顺祝商祺！ MayLiu Re: RT685 CTimer0 callBack delayed 1) 我仍然不明白为什么 ctimer 中断需要更高的优先级。DMA 回调后有许多"free usec" 。 2) 在示例中，数据流由软件处理。 我正试图配置 CPU，让它自己完成所有繁重的工作。 谢谢并致以最崇高的敬意。 Re: RT685 CTimer0 callBack delayed 我认为，如果ctimer 的优先级较低，其执行可能会延迟，从而影响计时精度和实时性能。

实践研讨会：i.MX RT1170 跨界微控制器系列 我需要这段视频的英文版，如何获取？ Re: Hands-On Workshop: i.MX RT1170 Crossover MCU Family 你好@amitwarbhe、 感谢您关注动手研讨会：i.MX RT1170 跨界微控制器系列。目前，我们还没有正式的英文版视频。 但是，我将与您分享一个包含演示文稿的链接，如果需要，您可以将其已翻译成英文。   https://www.nxp.com/design/design-center/training/TIP-IMX-RT1170-CROSSOVER-MCU-FAMILY-HANDS-ON?ticket=ST-9509-AufpW5TOMl-EQWPZOCMo3Ler-dU-nxp mayliu1_0-1764815719027.png 顺祝商祺！ MayLiu

多唤醒源的pad keeping配置问题 Hello， S2K342，配置了3个GPIO唤醒源，其中1个是上升沿唤醒，2个是下降沿唤醒。 现在三个通道都可以正常唤醒（极性都正确）。 但是不管使用哪一个通道唤醒后，两个下降沿唤醒通道的WISR对应位都为1。 配置参考了《S32K3 常见问题检查列表Check List》： STANDBY模式下勾选了“DCM_GPR Under MCU Control”和“Global Padkeeping Enable”； 3个引脚都勾选了“PortPin Pull Keeper”（非Active pins in Standby mode）； 上升沿唤醒引脚：Pull Select: Pull down/Pullup Enable: Disable/Initial Value: Low/Pad keep enable: Enabled; 下降沿唤醒引脚1：Pull Select: Pull up/Pullup Enable: Enable/Initial Value: High/Pad keep enable: Enabled; 下降沿唤醒引脚2：Pull Select: Pull down/Pullup Enable: Disable/Initial Value: Low/Pad keep enable: Enabled; 下降沿唤醒引脚1与下降沿唤醒引脚2的配置不同，但是结果一样。 是我遗漏了某些配置吗？还是我的配置有误？ Re: 多唤醒源的pad keeping配置问题 嗨，@zt17、 是的，这与常见问题文档中解释的问题相同。 客户读取的唤醒源和实际所需的唤醒源振荡都是由 Padkeeping 功能引起的。 一位同事在另一个社区帖子中对此进行了解释：已解决：S32K312 从快速待机模式唤醒后 WISR_64 不正确 - NXP Community： "只要项目中有 GPIO 唤醒，MCU 就能被唤醒，因此必须启用 Pad_keeping 功能。原因是如果在待机前没有启用 Pad_Keeping，一旦 MCU 唤醒并调用初始化，所有 GPIO 都处于高阻抗状态，相应的 MCU GPIO 内部电路会产生下降沿，因此会错误地导致 WISR_64 或 WISR 在唤醒时被置 1；一般情况下，建议客户启用 Pad_Keeping 功能，然后在唤醒后首先读取 WISR_64 和 WISR 的值，然后禁用 Pad_Keeping 功能。" 致以最诚挚的问候， Julián

Does the SW32K3_IPCF_4.2.0_D2412 support the S32K328 chip _0-1764664238042.png Based on S32DS 3.6.3 and using the SW32K3_IPCF_4.2.0_D2412 package, I encountered the issue shown above when configuring IPCF on the S32K328 chip: the core type and core index cannot be configured. Could you please explain what is causing this? Are there any other IPCF software packages that support the #S32K328 chip Re: Does the SW32K3_IPCF_4.2.0_D2412 support the S32K328 chip Hello, Looking at release notes, it does not support S32K328 directly. petervlna_0-1764669786577.png But I see no issue to use S32K358 instead. I have also check the IPCF_S32K3_4.2.0_ReleaseNotes_Updated_D2502.pdf, but the result is the same. Since the only difference is lockstep I see no issue going with S32K358 instead. I have no info what is the reason S32K328 is not supported directly in IPCF releases. Best regards, Peter Re: Does the SW32K3_IPCF_4.2.0_D2412 support the S32K328 chip Is there any version of the IPCF software package that supports the S32K328? If not, and if a project is fully configured for the S32K324, can it run on an S32K328-based project? Re: Does the SW32K3_IPCF_4.2.0_D2412 support the S32K328 chip Hello, Use direct derivative which is S32K358 for S32K328 to keep compatibility. Best regards, Peter

从堆栈中运行代码 您好， 我想知道是否有哪位聪明人能告诉我如何加载堆栈并从那里运行代码。 我知道如何使用链接器脚本文件从内存中运行代码。 我说的是堆栈。我很早以前就见过其他人这样做，我知道这是可以做到的。 请不要给我"堆栈是用来保存机器状态" 和诸如此类的东西。 谢谢！ 库罗什-哈贾尼 Re: running code out of the stack HI 这些我都知道。 我的问题是/现在是专门关于函数运行时堆栈耗尽的问题。 谢谢！ Re: running code out of the stack 你好、 在我看来，直接从堆栈运行某些函数是一种很不寻常的方式，而且效果也不好。首先需要分配本地内存，然后将"函数实现" 复制到闪存中分配的内存中，之后就可以调用函数指针了。 最简单的方法就是从 RAM 中调用函数（你已经调用过了）。S32K1xx SDK 中有一个从 RAM 运行函数的宏，下面是一个简单的例子： START_FUNCTION_DECLARATION_RAMSECTION void CCIF_Callback(void) END_FUNCTION_DECLARATION_RAMSECTION 希望这对你有帮助。 Jiri  Re: running code out of the stack 嗨，斯坦、 我只需要从 RAM 运行一个函数。这是关于在程序闪存 IFR 中读取/写入 "程序一次 "的启动命令。 我使用链接器脚本文件实现了这一点。我见过其他人使用堆栈从 RAM 运行，但那是很久以前的事了。 我想知道是否有哪位聪明人有办法!!!!！ 谢谢！ Koorosh Re: running code out of the stack 您好， 您能更详细地描述一下您想通过这种结构达到什么目的吗？ 谢谢！ Stan

使用版本 6.12.20-2.0.0 的 optee 启动 imx8mm 大家好 我目前在使用u-boot和内核版本6.12.20.2.0.0以及optee-os运行自己的 imx8mm 板的正确设置方面遇到了问题。 简而言之，我要么被卡在 BL31 中，输出结果如下： NOTICE: BL31: Initializing BL32 或者使用输出启动内核时： [ 6.919247] optee: probing for conduit method. 到目前为止，我还没有找到任何可以让它工作的线索。 更具体地说，我将这些存储库用于我的电路板支持包： YOCTO-SDK：仓库 init -u https://github.com/nxp-imx/imx-manifest-b imx-linux-walnascar -m imx-6.12.20-2.0.0.xml Linux:https://github.com/nxp-imx/linux-imx/tree/lf-6.12.20-2.0.0 U-Boot：https://github.com/nxp-imx/uboot-imx/tree/lf-6.12.20-2.0.0 ATF:https://github.com/nxp-imx/imx-atf/tree/lf-6.12.20-2.0.0 OPTEE-OS:https://github.com/nxp-imx/imx-optee-os/tree/lf-6.12.20-2.0.0 mkimage:https://github.com/nxp-imx/imx-mkimage/tree/lf-6.12.20-2.0.0 首先，我创建了 OPTEE-OS，生成了一个 tee.bin 和一个 tee-raw.bin 文件。当我尝试使用 tee.bin 文件启动 u-boot 时，它总是会卡在 NOTICE: BL31: Initializing BL32 当我使用 tee-raw.bin 时、u-boot 似乎运行良好。 所以第一个问题是：tee-raw.bin 是正确的二进制文件吗？ 我使用 ddr4-evk 设置作为 u-boot 版本的基础。根本区别在于内存，因为我只用了 1 GB 而不是 2 GB。DDR 时序已完成，运行正常。当我尝试在 optee 版本期间进行更改时，例如 CFG_DDR_SIZE=0x4000000 我在使用 tee-raw.bin 进行 BL32 初始化时也卡住了。 u-boot 中的其余更改仅影响我的硬件更改的 dts/dtsi。不过，我已经在不带 optee-os 的 5.4 版本中使用过这一部分。 我没有对 Linux 部分的 optee-os 做任何改动。据我所知，u-boot 在后台现有的 Linux DTS 中插入了一些额外的 optee 设置部分。 输出 [ 6.919247] optee: probing for conduit method. 它似乎在尝试启动，但是 Linux 和 u-boot 之间的 optee 部分不适合。 那么我的第二个问题是：我需要在 Linux 或 u-boot 中进行哪些更改才能使其正常工作？ 我已经阅读了所有关于使用optee的手册，但是没有关于如何在没有YOCTO的情况下手动构建这个部分的详细信息。 如果有人能帮我解决这个问题，请告诉我！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 安全 Re: Boot imx8mm with optee with version 6.12.20-2.0.0 你好 你遇到的启动失败可能是由于与 OP-TEE 相关的内存配置问题造成的。当使用 1GB 内存配置而不是默认的 2GB 内存配置时，需要正确调整 OP-TEE 设置。 以下是解决问题的关键点： 1. 关于 tee.bin 与 tee-raw.bin： - tee-raw.bin 是在 u-boot 中使用的正确二进制。tee.bin 文件包含其他头信息，这些信息可能会导致您的配置出现兼容性问题。 2. 对于内存配置问题： - 由于你使用的是 1GB 内存而不是默认的 2GB 内存，你需要调整 OP-TEE 内存设置。默认 OP-TEE 配置基于 2GB 内存大小，这导致了不匹配。 3. 要修复这个问题，你有两个选择： 选项 1：完全禁用 OP-TEE - 如果你不特别需要 OP-TEE 功能，最简单的解决方案是在你的版本中将其禁用。 - 对于手动版本（非 Yocto），你需要修改 u-boot 配置以移除 OP-TEE 支持。 选项 2：修改 1GB 内存的 OP-TEE 配置 - 在 optee-os 版本中，你需要调整内存映射参数： - 修改平台配置中的 CFG_TZDRAM_START 和 CFG_TZDRAM_SIZE - 确保 BL32_BASE 值与你的 1GB 内存布局兼容 你看到的错误表明 OP-TEE 预期的内存布局与实际硬件配置不匹配。既然你提到 DDR 计时已经完成并且运行良好，问题尤其在于如何根据你的内存大小配置 OP-TEE。 对于在 Yocto 之外的手动版本，你需要确保所有元器件（u-boot、ATF、OP-TEE）使用适合您的 1GB 配置的一致内存寻址参数。 此致 Re: Boot imx8mm with optee with version 6.12.20-2.0.0 你好，@Bio_TICFSL、 感谢您快速而有益的回复。 停用方案 1 不可取。如今，系统网络安全变得越来越重要。这是我们将电路板支持包从不使用 optee 的 5.4 更新到使用 optee 的 6.x 的主要原因之一。 对于方案 2，关键点在于 CFG_TZDRAM_START 值。我不得不将其从 0xBE000000 改为 0x7E000000 (0x40000000 - 0x02000000 + MEMORY_SIZE)。我以为这将在版本过程中在后台计算。 我不明白为什么要修改 CFG_TZDRAM_SIZE。 为什么要将该值从 32 MB (0x1E00000) 改为 32 MB？有什么原因吗？ 我只是通过设置 CFG_DDR_SIZE=0x40000000 更改了 optee 内存大小。 因此，解决方案似乎是使用以下设置： OPTEE 版本：cfg_tzdram_start=0x7e000000 cfg_ddr_size=0x40000000 ATF 版本：bl32_base=0x7e000000 致以最诚挚的问候， Cedric Re: Boot imx8mm with optee with version 6.12.20-2.0.0 你好 32 MB 的 RAM 空间分配给 OP-TEE：28 MB 由 TZASC 映射为安全内存（OP-TEE RAM），最后 4 MB 映射为非安全内存（共享内存）。该安全内存的起始地址和大小是硬编码：CFG_TZDRAM_START 和 CFG_TZDRAM_SIZE。这些值由 OP-TEE OS 在初始化后添加到设备树中 您可以查看更多 i.MX 移植指南 此致

HABv4 密钥管理 大家好 在第三方需要能够独立签署软件版本的情况下，你会如何建议管理密钥？ 即我们需要给某人一把钥匙才能签名，是否应该给他一把 SRK？或者只是"IMG" 键？他们只用 IMG 密钥就能签名吗？ 据我所知，我们只能撤销 SRK，而不能撤销单个 IMG 密钥。这是否意味着，如果我们和外部合作伙伴使用相同的 SRK，我们将无法撤销他们的 SRK？ 我在文档中找不到任何关于多个 IMG 密钥或密钥管理的信息。 谢谢！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 安全 Re: HABv4 key management 你好 当第三方需要独立签署软件版本时，我将回答你关于管理密钥的问题。 在 HABv4 中，只能撤销 SRK（超级根密钥）密钥，而不能撤销单个 IMG（图像）密钥。该系统采用严格的分级信任模式设计。 与第三方合作进行签名时： 1.SRK 密钥是信任的根源，通常由设备所有者管理。应仔细保护这些密钥，因为它们是您的网络安全模型的基础。 2.如果给第三方一个 SRK 密钥，他们将拥有根级别的完整签名权限。 3. 一般不建议这样做，因为这会授予他们广泛的权限。您可以向第三方提供您的 SRK 下的 IMG 密钥。这允许他们在您保持对根密钥控制的同时对图像进行签名。 4。第三方无法仅使用 IMG 密钥独立签名——他们需要完整的证书链，该证书链可以追溯到设备熔丝中的 SRK。 5。为实现密钥隔离，建议对不同的签名实体使用不同的 SRK。例如，您可以将 SRK1 用于内部版本，将 SRK2 用于外部合作伙伴。 6.你说得对，只有 SRK 可以撤销（不能撤消单个 IMG 密钥），这是在 HABv4 的熔丝层面上完成的。如果您和您的伴侣使用同一个 SRK，您不能有选择性地撤销他们的签署能力而不同时撤销您自己的签署能力。 建议采用的方法是为不同的签名实体分配不同的 SRK，以便在需要撤销时，可以撤销它们的 SRK 而不影响自己的签名能力。 此致 Re: HABv4 key management 您好， 是的，这是可能的，但如果你能做到的话，只要一个就够了。 此致 Re: HABv4 key management 1) 是否有人可以只用 IMG 密钥签署软件，还是需要 SRK？ 2) 为什么有人需要一个以上的 IMG 密钥？ 谢谢。 Re: HABv4 key management 您好，感谢您的详细答复。 您在第 3 点中提到 [] IMG 密钥......允许他们签署图像 但关于第 4 点 第三方不能仅使用 IMG 密钥进行独立签名 我感到困惑的是，是否有人可以用我们链中的 IMG 密钥签署图像，还是必须使用整个 SRK。是哪一个？ 如果共享整个 SRK 是必要的，而一个 IMG 密钥还不够，那么能够生成多个 IMG 密钥的用例是什么（如果我对文档的理解正确，这似乎是可能的）？ 谢谢！

PCIレガシー割込みはPCIeでどのようにエミュレートされ、Linuxカーネルでどのように処理されるのですか？ PCIの世界では、PCIのレガシー割込みは過去のものとなりました。PCI Expressではより効率的なMSI割込みが導入され、様々なアプリケーションで広く利用されています。しかし、これらは主に下位互換性と起動サポートのために依然として使用されています。 レガシー割込み[INTx]はPCIでは物理信号として扱われていましたが、PCIeデバイスには物理的なINTxピンがありません。そのため、PCIeはこれらのレガシー割込みをサポートするために、それらを論理的にエミュレートします。これは、仮想INTxメカニズムのようなものです。このガイドでは、開発者や愛好家が実践形式で動作を確認できるよう、これらの割込みがPCI Expressでどのように実現されているかを見ていきます。このブログのテーマは以下のとおりです。      1. PCIe のレガシー INTx スタイルの割込みについて考慮する必要があるのはなぜですか？ システム概要 INTxレガシー割込みはPCIeでどのように実現されますか？ iMX8MMでのINTxエミュレーションの有効化とテスト なぜPCIeのレガシーINTxスタイルの割込みにこだわる必要があるのですか？ 今現在に至るまで、レガシー INTx割込みを理解することが重要な理由は以下のとおりです。 多くのオペレーティングシステム、ドライバ、およびアプリケーションは、もともとPCI用に設計されており、INTxスタイルの割込みについては想定済みですが、MSI/MSIXをサポートしていない可能性があります。 PCIeデバイスをレガシーPCIの動作が想定されるシステムで使用しても、INTxエミュレーションにより、デバイスは古い方法で引き続き割込みを通知できます。これにより、MSI/MSI-Xをサポートしていない古いソフトウェアスタックが壊れることがなくなります。 （リソースの制約や構成の問題により）MSI/MSI-Xを割り当てられない場合、フォールバックメカニズムとして、INTXエミュレーションが役立つことが証明されています。 システム概要   Figure. 1図1   テスト対象のシステムには以下のコンポーネントがあります。 ハードウェア・コンポーネント： iMX8MM EVKボード - i.MX 8Mミニ評価キット | NXP Semiconductors iMX95 19x19 EVK - i.MX 95アプリケーション・プロセッサ・ファミリ | NXP Semiconductors ソフトウェア・コンポーネント： GitHub - nxp-imx/linux-imx: i.MX Linux kernel iMX95 RC上のLinux BSP - 6.6.3 iMX8MM EP上のLinux BSP - 6.1.55 図1で示されている通り、システムではiMX8MM EVKとiMX95 19x19 EVKがM.2 Key E PCIeブリッジを介して並べて接続されています。 iMX8MM EVKはPCIeエンドポイントとなり、iMX95 EVKはPCIeルートコンプレックスとして機能します。 iMX95<------> iMX8MM [RC] [EP] 上記の構成でセットアップするには、こちらのブログをご参照ください。 iMX95 torradexボードとiMX8MM EVK上でのPCIeエンドポイント・フレームワークの有効化 - NXPコミュニティ この後、PCIエンドポイント・テストフレームワークを使用して、iMX8MMとiMX95 EVKの間でPCIeトランザクションをトリガーできるようになります。 このセットアップを使用して、PCIe EP[iMX8MM EVK]がPCIe RC[iMX95 EVK]にレガシーINTx割込みを送信する方法を示します。また、linux-imxソースコード上のLinuxドライバにおけるこれらの割込みの発生源も追跡します。 INTx レガシー割り込みは PCIe でどのように実現されますか？ PCI Expressは、PCIローカルバス仕様で定義されているPCI割込みをサポートします。これには、PCIコンフィグレーション・スペースの割込みピン・レジスタと割込みライン・レジスタが含まれます。PCIeデバイスは下位互換性を確保するため、これらのレジスタをサポートします。したがって、実際のシグナル割込みは物理ピンを使用するのではなく、インバンドメッセージを使用します。 PCIeでは、仕様に従って2種類のメッセージが定義されています。 PCI INTxシグナルのエミュレーションのためのAssert_INTxとDeassert_INTx x -> A/B/C/D これらのメッセージはリンク間でのシグナル割込みの「仮想ワイヤー」として機能します。これら「仮想ワイヤー」の形式のメッセージは「ルート・コンプレックス」に到達し、その後システム割込みコントローラにマッピングされます。つまり、RCはこれらインバンドの「仮想ワイヤー」メッセージを受信すると、それを適切なハードウェア割込みに変換してCPUに送ります。 注：PCI Express IntXエミュレーションのシステム割込みへのマッピングは、実装によって異なります。物理的なシグナル割込みと同様に、INTxエミュレーション・メカニズムは疑似割込みを引き起こす可能性があります。これはシステム・ソフトウェアによって処理する必要があります。 iMX8MMでのINTxエミュレーションの有効化とテスト 公式のLinuxファクトリーカーネルでは、レガシー割込みはまだサポートされていません。このブログには、PCIeのレガシー割込みを有効にするためのパッチを含むZIPファイルが添付されています。以下の3つのファイルがあります。       1.legacy_intx_tested_imx8mm_patch_1 legacy_intx_tested_imx8mm_patch_2 README パッチの適用方法は、READMEファイルに記載されています。何か問題がありましたら、お気軽にDMを送信してください。 LinuxでPCIe INTxエミュレーションを有効にする手順を簡潔にまとめると、以下の通りです。 1. ボード上でデフォルトのiMX8MM 6.1.55 wicイメージをフラッシュし、Linuxで起動することを確認します。 2. linux-imxリポジトリを取得[ブランチlf-6.1.yをチェックアウト]します。 3. Linuxのソースコードにパッチを適用します。 4.カーネルとscp「arch/arm64/boot/Image」をボードにビルドします。この「Image」と「imx8mm-evk-pcie-ep.dtb」でボードを起動します。 問題が発生した場合は、次のブログを参考にしてください：iMX95 torradexボードとiMX8MM EVK上でのPCIeエンドポイント・フレームワークの有効化 この時点で、PCIe EP iMX8MM上で動作するカーネルは、PCIe RC [iMX95]にINTx割込みを送信できます。テスト方法は以下のとおりです。 1. iMX95 RCがM.2経由でiMX8MM EPに接続されていることを確認します。どちらも起動しており、iMX8MMはiMX95のPCIeエンドポイントとして表示されます。iMX95で「lspci」を実行すると、「割り当てられていないクラス」というエントリが表示されます。 2. iMX95EVK RC上で、以下の2つのコマンドを実行して、INTxエミュレーションをテストします。 a. pcitest -i 0 b.pcitest -l コンソール出力：- root@imx95evk:~# pcitest -i 0 IRQタイプをレガシーに設定：OK root@imx95evk:~# pcitest -l レガシーIRQ：OK 「pcitest・i 0」は、レガシーINTx割込みを処理するようにRCを設定します。この結果、ioctlコールは「PCITEST_SET_IRQTYPE」となります。 drivers/misc/pci_endpoint_test.cでは以下のように処理されます。     Figure. 2図2 IRQ_TYPE_LEGACYのargは0です。 以下のスニペットでは、すべてがどこから始まるのかを示しています。   Figure. 3図3 pci_endpoint_test_release_irqの内部   Figure. 4図4   test->num_irqs=16の場合、エンドポイントでは以下のようになります。 echo 16 > functions/pci_epf_test/func1/msi_interrupts pci_irq_vectorは、MSI割込み0から16に対応するLinux IRQ番号を返します。 その後、devm_free_irqを使ってこれらのirqを解放し、再び割り当てられるようにします。 free_irqはこの関数内で使用され、割込みハンドラを削除します。 そして、割り込みラインがどのドライバによっても使用されていない場合、それは無効化されます。 共有IRQでは、呼び出し元はこの関数を呼び出す前に、駆動するカード上で割込みが無効になっていることを確認する必要があります。   pci_endpoint_test_free_irq_vectorsの内部 pci_free_irq_vectors［driver/pci/msi/api.c］を呼び出し、以下を行います。 pci_alloc_irq_vectors_affinity()またはpci_alloc_irq_vectors()によって以前に行われた割込みベクタの割り当てとデバイスMSI/MSI-Xのイネーブルメントを元に戻します。 注：PCIエンドポイント・テストドライバでは、IRQベクタを割り当て、レガシーINTx割込みを要求する前に、既に割り当てられたMSI割込みを解放し、それに関連付けられたベクタを解放する必要があります。その過程で、MSI割込みは無効化されます。これはPCIeの仕様上、MSIとINTxが互いに排他的であるためです。MSIとINTxの両方を有効にするとどうなるかテストしてみると面白いでしょう。テストの結果何が起こったかをコメント欄から教えてください。   pci_endpoint_test_alloc_irq_vectorsの内部 Figure. 5図5   pci_alloc_irq_vectorsは、従来のintx割込みに割込みベクタを割り当てます。これにより、内部深くに、CPUコア0のCPUアフィニティ・マスクが作成され、pci_intxが呼び出され、PCIe構成スペースの読み取りと書き込みによってレガシー割込みが有効になります。 Figure. 6図6   pci_endpoint_test_request_irqの内部 Figure. 7図7   pci_irq_vectorは、 devm_request_irq -> devm_request_threaded_irq に渡されるLinux IRQ番号を割り当てます。 Linuxカーネルのdevm_request_irqはデバイス管理型リソース割り当てAPIの一部です。このAPIの主な役割は、IRQリソースのライフサイクルを自動的に管理することで、デバイス・ドライバの割り込みリクエスト処理を簡素化することです。また、IRQ番号の割込みハンドラを登録し、IRQリソースをデバイスのライフサイクルに結びつけます。デバイスが切り離されるか、ドライバがアンロードされると、カーネルは自動的にIRQを開放します。 IRQF_SHAREDフラグを持つハンドラ「pci_endpoint_test_irqhandler」が渡されます。このハンドラはINTx割込みを着信したときに呼び出されます。 IRQF_SHARED -- 割込み回線を複数のデバイスと共有できます。 注：Linux IRQサブシステムについてはこのブログの範囲外です。カーネルAPIの一部に戸惑っても、今後のブログで取り上げる予定ですのでご安心ください。 ここまでで、PCIeでINTxを有効にすると裏で何が起こるかが少しわかったと思います。 「pcitest -l」がトリガーするIRQテストでは、すべてがうまくいった場合「OKAY」を、そうでない場合は「NOT OKAY」を返します。 上記のテストを実行すると、PCIe RCはpcie link上のiMX8MM EPにコマンド「COMMAND_RAISE_LEGACY_IRQ」を送信します。このコマンドをハンドラ「pci_epf_test_cmd_handler」の一部として受け取ったEPは「pci_epf_test_raise_irq」を呼び出します。   Figure. 8図8   Figure. 9図9 pci_epc_raise_irqは、最終的にパッチの__dw_pcie_ep_raise_intx_irqを呼び出します。 Figure. 10図10 これはPCI_CODE_ASSERT_INTAメッセージを送信し、その後遅延を挟んでからPCI_CODE_DEASSERT_INTAを送信します。これらのメッセージはどちらもPCI_MSG_ROUTING_LOCALというルーティングタイプで、同じデバイス内の特定の機能またはスイッチにルーティングされることを意味します。メモリトランザクションがターゲットアドレスを必要とするのとは異なり、INTxメッセージには宛先アドレスがありません。 簡単に言うと、「これを私のローカルルートコンプレックスにルーティングしてください」ということです。   Figure. 11図11 その後、ルート・コンプレックスiMX95に到達し、そこから、共有ペリフェラル優先割込みを使用して、割込みコントローラ[GICv3]に到達します。GICは、割込みを処理するよう、CPUコアのいずれかに通知します。ここでは、アフィニティをCPU 0に設定しているため、CPU 0がこれを処理します。最後に、RCのエンドポイント・テストフレームワークでpci_endpoint_test_irqhandlerが呼び出されます。 Figure. 12図12 割込みがGICに到達した後のシーケンスは以下のとおりです。   Figure. 13図13   JTAGをiMX95EVKボードに接続すると、LinuxでレガシーINTx IRQが処理される際に呼び出しを追跡できます。   Figure. 14図14 imx95上のGICにルーティングされた割込みは、「pcitest -l」を使用してレガシー割込みテストをトリガーするたびに、 「cat /proc/interrupts」 を実行することで確認できます。 INTAの場合、「cat /proc/interrupts」の出力に次のように表示されます。 Figure. 15図15   [割込みを処理した]CPU0に表示されている数字の「3」は、レガシー割込みテストをトリガーするたびに増加することがわかります。これは、CPUコアのIRQ番号に対していくつの割込みが生成されたかを示します。 レベル：割込みタイプ 「224」は割込み要求番号です。 //INTA、INTB、INTC、INTDのテスト 単一機能デバイスでサポート可能なINTx割込みの数は1つのみです[PCIeの場合はエミュレートされます] INTB、INTC、またはINTDを使用するには drivers/pci/controller/dwc/pcie-designware-ep.c内部   Figure. 16図16   __dw_pcie_ep_raise_intx_irq関数の第3引数 0 = INTA 1 = INTB 2 = INTC 3 = INTD 上記のマッピングに従って変更します。 drivers/pci/endpoint/functions/pci-epf-test.c内部   Figure. 17図17   test_headerのinterrupt_pinメンバを変更できます。 PCI_INTERRUPT_INTA = INTA PCI_INTERRUPT_INTB = INTB PCI_INTERRUPT_INTC = INTC PCI_INTERRUPT_INTD = INTD -- INTAの割込みのモニタリング Figure. 18図18 -- INTBの割込みのモニタリング Figure. 19図19   -- INTCの割込みのモニタリング Figure. 20図。20   -- INTDの割込みのモニタリング Figure. 21図21 上記のスニペットから、コア0のみがIntX IRQを処理していることがわかったはずです。これは、CPUアフィニティ・マスクが「1」に設定されることで、CPUコアが「0」になるためです。 kernel/irq/affinity.cの内部   Figure. 22図22 レガシー割込みのiRQマスクは「1」に設定されているため、コアは「0」になります。 このブログはここで終了です。細かいところまで詳述したため、かなり長くなりました。情報の多さに圧倒されそうでも大丈夫。PCIEとIRQ Linuxサブシステムでの作業を始めれば、次第に理解できるでしょう。この件についてご質問があればお知らせください。DMでもメールでもお気軽にどうぞ。また次回お会いしましょう。   PCIの世界では、PCIのレガシー割り込みは過去のものとなりました。PCI Expressではより効率的なMSI割り込みが導入され、様々なアプリケーションで広く利用されています。しかし、これらは主に下位互換性と起動サポートのために依然として使用されています。 レガシー割り込み[INTx]はPCIでは物理信号として扱われていましたが、PCIeデバイスには物理的なINTxピンがありません。そのため、PCIeはこれらのレガシー割り込みをサポートするために、それらを論理的にエミュレートします。これは、仮想INTxメカニズムのようなものです。このガイドでは、開発者や愛好家が実践形式で動作を確認できるよう、これらの割り込みがPCI Expressでどのように実現されているかを見ていきます。このブログのテーマは以下のとおりです。 1. PCIe のレガシー INTx スタイルの割り込みについて考慮する必要があるのはなぜですか? 2. システム概要 3. PCIeでINTxレガシー割り込みはどのように実現されるのか? 4. iMX8MMでのINTxエミュレーションの有効化とテスト IMX95EVK

LWIPのPFEデモがビルドされない 従うガイド: https://www.nxp.com/document/guide/getting-started-with-the-s32g-reference-design-board-3-for-vehicle-network-processing:GS-S32G-VNP-RDB3?section=enable-pfe-ethernet-interface-with-lwip-and-freertos-on-the-s32gvnprdb3s-s32g274a-armsupregsup-cortexsupregsupm7-core ボード： S32G3 ゴールドボックス IDEs: S32 Design Studio for S32 Platform バージョン: 3.6.4 ビルドID: 250929 問題の概要: このガイドに従って、 PFE デモ コードをダウンロードし、インストーラーを実行しました。 ガイドにはどのフォルダをインポートすればよいか記載されていませんが、lwip_s32g274a をインポートしました [正確なフォルダを明示的に指定するようにガイドを修正してください] インポート後、プロジェクトを右クリックして「ビルド」を選択しました。ガイド通りならエラーなくビルドできるはずですが、実際にはそうではありませんでした。コンソールに以下のビルドエラーが表示されています。 ビルディングファイル: ../stacks/tcpip/lwip/src/netif/ppp/polarssl/md5.c ビルディングファイル: ../stacks/tcpip/lwip/src/netif/ppp/polarssl/des.c ビルディングファイル: ../stacks/tcpip/lwip/src/netif/ppp/ccp.c 呼び出し: 標準 S32DS C コンパイラ arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.args"-MMD -MP -MF"スタック/tcpip/lwip/src/netif/ppp/polarssl/sha1.d"-MT"スタック/tcpip/lwip/src/netif/ppp/polarssl/sha1.o"-o "stacks/tcpip/lwip/src/netif/ppp/polarssl/sha1.o"「../stacks/tcpip/lwip/src/netif/ppp/polarssl/sha1.c」 呼び出し: 標準 S32DS C コンパイラ arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.args"-MMD -MP -MF"stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.d"-MT「スタック/tcpip/lwip/src/netif/ppp/polarssl/arc4.o」-o "スタック/tcpip/lwip/src/netif/ppp/polarssl/arc4.o"「../stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.c」 呼び出し: 標準 S32DS C コンパイラ arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.args"-MMD -MP -MF"スタック/tcpip/lwip/src/netif/ppp/polarssl/des.d"-MT"スタック/tcpip/lwip/src/netif/ppp/polarssl/des.o"-o "スタック/tcpip/lwip/src/netif/ppp/polarssl/des.o"「../stacks/tcpip/lwip/src/netif/ppp/polarssl/des.c」 呼び出し: 標準 S32DS C コンパイラ 呼び出し: 標準 S32DS C コンパイラ arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.args"-MMD -MP -MF"stacks/tcpip/lwip/src/netif/ppp/polarssl/md5.d"-MT"スタック/tcpip/lwip/src/netif/ppp/polarssl/md5.o"-o "stacks/tcpip/lwip/src/netif/ppp/polarssl/md5.o"「../stacks/tcpip/lwip/src/netif/ppp/polarssl/md5.c」 arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.args"-MMD -MP -MF"stacks/tcpip/lwip/src/netif/ppp/polarssl/md4.d"-MT"スタック/tcpip/lwip/src/netif/ppp/polarssl/md4.o"-o "stacks/tcpip/lwip/src/netif/ppp/polarssl/md4.o"「../stacks/tcpip/lwip/src/netif/ppp/polarssl/md4.c」 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/polarssl/arc4.c:41 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ コンパイルが終了しました。 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 呼び出し: 標準 S32DS C コンパイラ D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 呼び出し: 標準 S32DS C コンパイラ arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/auth.args"-MMD -MP -MF"stacks/tcpip/lwip/src/netif/ppp/auth.d"-MT「スタック/tcpip/lwip/src/netif/ppp/auth.o」-o "スタック/tcpip/lwip/src/netif/ppp/auth.o"「../stacks/tcpip/lwip/src/netif/ppp/auth.c」 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 ビルディングファイル: ../stacks/tcpip/lwip/src/netif/ppp/chap-md5.c D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/polarssl/sha1.c:41 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/auth.args"-MMD -MP -MF"スタック/tcpip/lwip/src/netif/ppp/ccp.d"-MT「スタック/tcpip/lwip/src/netif/ppp/ccp.o」-o "スタック/tcpip/lwip/src/netif/ppp/ccp.o"「../stacks/tcpip/lwip/src/netif/ppp/ccp.c」 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ コンパイルが終了しました。 作成: *** [stacks/tcpip/lwip/src/netif/ppp/polarssl/subdir.mk:32:スタック/tcpip/lwip/src/netif/ppp/polarssl/arc4.o]エラー1 make: *** 未完了のジョブを待機しています.... D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/polarssl/des.c:42 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 呼び出し: 標準 S32DS C コンパイラ D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 arm-none-eabi-gcc "@stacks/tcpip/lwip/src/netif/ppp/auth.args"-MMD -MP -MF"stacks/tcpip/lwip/src/netif/ppp/chap-md5.d"-MT「スタック/tcpip/lwip/src/netif/ppp/chap-md5.o」-o "スタック/tcpip/lwip/src/netif/ppp/chap-md5.o"「../stacks/tcpip/lwip/src/netif/ppp/chap-md5.c」 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/polarssl/md5.c:41 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ コンパイルが終了しました。 作成: *** [stacks/tcpip/lwip/src/netif/ppp/polarssl/subdir.mk:32:スタック/tcpip/lwip/src/netif/ppp/polarssl/sha1.o]エラー1 コンパイルが終了しました。 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/polarssl/md4.c:42 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ 作成: *** [stacks/tcpip/lwip/src/netif/ppp/polarssl/subdir.mk:32:スタック/tcpip/lwip/src/netif/ppp/polarssl/md5.o]エラー1 作成: *** [stacks/tcpip/lwip/src/netif/ppp/polarssl/subdir.mk:32:スタック/tcpip/lwip/src/netif/ppp/polarssl/des.o]エラー1 コンパイルが終了しました。 作成: *** [stacks/tcpip/lwip/src/netif/ppp/polarssl/subdir.mk:32:スタック/tcpip/lwip/src/netif/ppp/polarssl/md4.o]エラー1 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/auth.c:71 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ コンパイルが終了しました。 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/ccp.c:31 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ メイク: *** [stacks/tcpip/lwip/src/netif/ppp/subdir.mk:92:スタック/tcpip/lwip/src/netif/ppp/auth.o]エラー1 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/arch.h:48からインクルードされたファイルでは、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/debug.h:40 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/lwip/opt.h:52 から、 D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/lwip/src/include/netif/ppp/ppp_opts.h:31 から、 ../stacks/tcpip/lwip/src/netif/ppp/chap-md5.c:31 から: D:/disrupt/PFE-demo/RTD_PFE_DEMO/source/lwip_s32g274a/stacks/tcpip/code/ports/プラットフォーム/generic/gcc/setting/arch/cc.h:37:10: 致命的なエラー: Devassert.h:そのようなファイル、又はディレクトリはありません 37 | #include "Devassert.h" | ^~~~~~~~~~~~~ コンパイルが終了しました。 コンパイルが終了しました。 メイク: *** [stacks/tcpip/lwip/src/netif/ppp/subdir.mk:92:スタック/tcpip/lwip/src/netif/ppp/ccp.o]エラー1 メイク: *** [stacks/tcpip/lwip/src/netif/ppp/subdir.mk:92:スタック/tcpip/lwip/src/netif/ppp/chap-md5.o]エラー1 「make -j8 all」は終了コード 2 で終了しました。ビルドが不完全である可能性があります。 12:23:54 ビルドに失敗しました。エラー 17 件、警告 0 件。（1秒417ミリ秒かかりました） ここ 3 日間、M7 の LWIP に苦労していますが、動作するデモ例が見つからず、非常にイライラしています。 正しい方向を指し示す手助けをしてください。すぐに使える特定のリンク/ドキュメント/ソースが必要です。S32G3 の M7 コアの LWIP サンプルを実行するだけです。 Re: PFE demo for LWIP does not build こんにちは、 @rizwan_at_disruptdotcom ご返信ありがとうございます。 PFE を絶対に使用する必要がない場合は、S32G の GMAC インターフェースに基づく LwIP の例があり、最新のソフトウェア リリースをサポートしています。 もしそれがあなたの要件を満たすことができれば、NXPからS32DSにプロビジョニングされたLwIPとFreeRTOSパッケージをインストールしてみてください。その例が見つかります。 chenyin_h_0-1764556654206.png お役に立てれば幸いです。 BR チェイン Re: PFE demo for LWIP does not build 参考までに、バンドルから SDK をインストールすることも試しました: https://www.nxp.com/app-autopackagemgr/automotive-software-package-manager:AUTO-SW-PACKAGE-MANAGER?customSelectionID=31485 Re: PFE demo for LWIP does not build 返信ありがとうございます。 S32G3 M7 で LWIP + FreeRTOS をテストするための適切なリソースを教えていただけますか? S32 DS 環境で動作するデモ/例が必要です。 Re: PFE demo for LWIP does not build こんにちは、 @rizwan_at_disruptdotcom ご投稿ありがとうございます。 あなたが試したデモは古くなっており、非常に古いバージョンの S32DS と対応する RTD/PFE コードに基づいているため、使用した S32DS と互換性がありません。 このデモを使用する場合は、おそらく S32DS3.4 が必要です。 BR チェイン Re: PFE demo for LWIP does not build こんにちは、 @chenyin_h 引き続きのサポートをよろしくお願いいたします。 S32G TCP STACK の例があるようですが、私のセットアップにはそれがありません。 ソフトウェア バンドルのリンクまたはアップデート サイトを教えていただけますか? Re: PFE demo for LWIP does not build こんにちは、 @rizwan_at_disruptdotcom ご返信ありがとうございます。 S32DS にどのバージョンの RTD をインストールしたか教えていただけますか? BR チェイン Re: PFE demo for LWIP does not build こんにちは@chenyin_hさん、 示された TCIP の例に基づいて、 NXP ソフトウェア パッケージ マネージャーで SW32G_TCPIP_STACK_2.0.0_D2511_DesignStudio_updatesite.zip を検索してダウンロードしました。 私はリアルタイム・ドライバ バージョン 5.0.0 QLP03を使用しています この設定で構築された例。 サポートありがとうございます。

i.mx8ULP 上的 OV5648 — 连续捕获期间帧变黑（文件大小不变，日志类似） 你好， 我们正在使用集成到基于 i.MX8 ULP 的定制板中的 OV5648 摄像头传感器。基本的相机功能运行良好，我们可以毫无问题地捕获图像。 但是，我们在连续图像捕获时遇到了问题。运行一段时间后（约 1-2 小时），相机仍能提供图像，但图像会完全变黑。重要细节 捕获的图像文件保持与有效图像相同的大小。 工作状态和非工作状态下的内核和驱动程序日志完全相同。 V4L2 或 CSI 日志中未报告明显错误。 相机只有在完全 RESET 系统后才能恢复（简单地重新启动捕获应用程序无济于事）。 我附上了工作状态和非工作状态的日志。 建议采取哪些步骤来调试和确定问题是来自 OV5648 传感器、MIPI-CSI 接口还是 i.MX8ULP 上的 ISI/V4L2 管线？ 如能提供与此行为相关的指导或已知问题，将不胜感激。 提前谢谢！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano i.MX8ULP Linux Yocto Project Re: OV5648 on i.MX8ULP — Frames Turn Black During Continuous Capture (File Size Constant, Logs Simil 你介意把工作和非工作的登记册都扔掉吗？有区别吗？ Re: OV5648 on i.MX8ULP — Frames Turn Black During Continuous Capture (File Size Constant, Logs Simil 您文件中的地址是偏移地址，对吗？基址是什么？我不知道你转储的是什么登记册 Re: OV5648 on i.MX8ULP — Frames Turn Black During Continuous Capture (File Size Constant, Logs Simil 这是一个真实的寄存器，我也与数据表进行了核对。 Re: OV5648 on i.MX8ULP — Frames Turn Black During Continuous Capture (File Size Constant, Logs Simil 我指的不是 ov5648 寄存器，我没有 ov5648 摄像头，无法重现这种情况，对于 ov5648 端，您需要自己检查我需要的 imx8ulp 寄存器，如果您有 ov5640 进行测试，我可以在我这边重现这种情况。 Re: OV5648 on i.MX8ULP — Frames Turn Black During Continuous Capture (File Size Constant, Logs Simil 我们已经在 HDMI 显示器上播放 OV5640，没有发现任何黑框问题。 Re: OV5648 on i.MX8ULP — Frames Turn Black During Continuous Capture (File Size Constant, Logs Simil 是的，我知道这一点，DFAE已经告诉我所有关于ov5640和ov5695的情况，我需要更详细的信息，我向DFAE发送了我的请求，请提供，如果你还没有收到我的请求，请让我知道它，我们可以专注于该案件

S32N55: RTD Netc_Eth_Ip_ReadFrame 関数のホスト理由 RTDチームの皆さん、こんにちは。 お客様はSW32N_RTD_R21-11_1.8.0_CD05を使用します。RTU R コアの VSI1 を使用してフレームを受信し、受信タイムスタンプを取得したいと考えています。タイムスタンプ機能が有効になっています。 しかし、受信タイムスタンプを取得するには、以下のスクリーンショットのコードに示すように、フレームのホスト理由が NETC_ETH_IP_HOSTREASON_SW_PTP (マクロは 😎 である必要があることがわかりました。 ただし、Rx BD のホスト理由は 0 です。 NECT のドキュメントと RTD ユーザー マニュアルを確認しましたが、ホスト理由を 8 に設定する方法が見つかりませんでした。RTD チームは、Rx BD でホスト理由を 8 に設定する方法についてガイダンスを提供してもらえますか? ご返信よろしくお願いします。 よろしくお願いします、 ブリジット RTD Re: S32N55: host reason in RTD Netc_Eth_Ip_ReadFrame function こんにちは@Bridget 、 スイッチ ポットのホスト理由を設定する場所が 1 か所だけ見つかりましたが、デフォルトでは値 0 に設定されていました。SWチームが休暇から戻ったら聞いてみます。 よろしくお願いいたします。 ニ Re: S32N55: host reason in RTD Netc_Eth_Ip_ReadFrame function こんにちは@Bridget 、 SW は、ホスト理由を EthSwt で設定する必要があると応答し、関数 ReadFrame でホスト理由ステータスを返します。 これらのパラメータの説明については、EthSwt パッケージに添付されている RTD_ETHSWT_43_NETC_UM.pdf をお読みください。 よろしくお願いいたします。 ニ Re: S32N55: host reason in RTD Netc_Eth_Ip_ReadFrame function こんにちは@Bridget 、 このプロジェクトを送っていただけますか？ よろしくお願いいたします。 ニ Re: S32N55: host reason in RTD Netc_Eth_Ip_ReadFrame function こんにちは、Nhiさん ご説明いただきありがとうございました。 もう一つ質問があります。GrayVIP CRS プロジェクトでは、EthSwtMgmtHostReason が常に 0 に設定されていることに気付きました。ただし、このプロジェクトで gPTP の例を実行すると、Netc_Eth_Ip_ReadFrame() で gPTP フレームのホスト理由が 8 であることがわかりました。そこで質問なのですが、おっしゃるとおり、EthSwtMgmtHostReason 以外に、ホスト理由の値に影響を与える可能性のある場所は他にありますか? よろしくお願いいたします。 ブリジット Re: S32N55: host reason in RTD Netc_Eth_Ip_ReadFrame function こんにちは@Bridget 、 はい、その通りです。申し訳ありませんが、再確認しませんでした。パラメーターは EthSwtIngressPortFilterHostReason になります。 よろしくお願いいたします。 ニ Re: S32N55: host reason in RTD Netc_Eth_Ip_ReadFrame function こんにちは@Bridget 、 ここに例を添付しました。 よろしくお願いいたします。 ニ