PCF85063TP/1Z RTC 中的时间漂移 我们在温度记录仪产品中使用 PCF85063TP/1Z RTC，用于在温度数据记录期间保持时间戳。在测试期间，我们观察到多个电路板上的时间偏移问题，其中每个电路板随时间推移显示出不同的偏移量。 在当前的硬件设计中，我们使用的是 12.5 pF 负载电容晶体。在此基础上，我们更新了 RTC 寄存器的设置，将 CAP_SEL 位配置为 "1"，以满足晶体负载电容要求。 更改配置后，我们在实时运行中仍能观察到大约 2 秒钟的漂移。 我们想了解 PCF85063TP/1Z 是否会出现这种程度的漂移。 是否有建议的寄存器配置或校准方法来提高 RTC 的精度。 PCB 布局、晶体选择或其他硬件考虑因素是否会导致观察到的板之间的差异。 请就如何在此应用中提高 RTC 计时精度提出建议和指导。 Re: Time Drift in PCF85063TP/1Z RTC 你好 请参阅应用笔记 AN11247 使用外部温度传感器使用 PCF85063、PCF8523 和 PCF2123 提高计时精度 希望对您有所帮助！

Is Jellytide Legit Trying? A 2026 Review Jellytide is becoming one of the most talked-about preparedness systems in 2026 because it focuses on realistic blackout survival strategies instead of Hollywood-style fear tactics. Created by combat veteran Daniels, the program combines practical guides, step-by-step videos, and military-inspired planning to help families prepare for long-term power outages, cyber threats, and emergency situations. Jellytide Ready to go What makes it stand out is its beginner-friendly approach. Rather than pushing expensive bunkers or complex survival gear, the system focuses on affordable, practical actions like water storage, backup power, food security, EMP protection, and home preparedness. Many users appreciate that the guide breaks everything into simple weekend projects that ordinary households can actually implement. In 2026, with growing concerns around grid instability, severe weather, and supply chain disruptions, preparedness has shifted from a niche hobby to a mainstream conversation. Jellytide taps directly into this trend by offering a structured survival roadmap for families who want peace of mind without becoming extreme “doomsday preppers.”  Is it worth buying? For people looking for a practical preparedness blueprint, the answer appears to be yes. The value comes from the organization, simplicity, and real-world focus of the system. However, the guide only works if users actually apply the strategies. It is best suited for those willing to take gradual action to improve their household resilience and emergency readiness. See More https://tinyurl.com/2epyz5wu

Ethernet Pin Conflict on S32K344 Mini-EVB Hello Team, i am using S32K344 Mini-EVB for ethernet bring up activity. From its user manual i can see that pin no PTD16 for MDC and PTD17 for MDIO. But when i am doing ethernet pin configuration in S32DS i can see PTD16 can be only routed to MDIO and PTD17 is routed to MDC and also i verified it from S32K344_IOMUX from that excel also i can see that PTD16 --> MDIO and PTD17 --> MDC. So is there any mistake in user manual documentation if yes will it affect the ethernet communication. Re: Ethernet Pin Conflict on S32K344 Mini-EVB Hello @MySterio_1 , Yes, you are right. Pins MDC and MDIO were swapped. I've already reported that - it will be fixed in the next release of UM12406 - the release date is not known yet. Feel free to refer to my lwIP example related to this board: Example S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0    Best regards, Pavel

LLCE CAN 我创建了样例工程Can_Llce_DS_Loopback_S32G274A_M7，已经能够和外部CAN盒进行通信，通信使用的是LLCE CAN0。后续我对该工程的配置进行了修改只保留了我想要的五路LLCE CAN,配置详情如下： 在配置的过程中我只删除了对应出错的地方，配置完成后在在配置界面只有一个时钟的警告，但是这个警告本身在能通信的那个版本就是有的所以不是问题。我已上传了我修改后的工程，麻烦帮我看下是什么问题导致的不能通信。 Re: LLCE CAN 你好，@JACK_Q、 对不起，我的回复晚了。我会用英语写信，但你可以用中文回复，社区会自动为我已翻译消息。当你提到新版本无法通信时，你看到电路板上有任何 CAN 信号吗？程序是正常运行还是在执行过程中的某个阶段卡住了？ 感谢你提供的信息。 Re: LLCE CAN 我改完配置后，尝试过debug，单步运行至发送接口can_retval = Can_43_LLCE_Write( CanHO_Config1_TX0, &CanMessage[u8CtrlIdx]);接口的返回值是E_OK也就是0 按照接口说明来看就是写命令已完成，并且程序还是在一直轮询执行CAN发送,但我的接收端CAN盒显示无数据，使用CAN盒软件自带的波特率侦测也检测不到（这个波特率侦测我同样在原来的例程中试过是可以检测的）。                      

S32K328 MCUの電力推定ツールについて 私のアプリケーションでは、機能用MCUとしてS32K328を、安全用MCUとしてS32K341を使用しています。これらのICに対応した電力推定ツールがあるかどうか知りたいです。 もしそうであれば、私の用途に合ったものをどこで入手できるか教えてください。 ありがとう。 Re: Regarding power estimation tool for S32K328 MCU こんにちは、 @Abhinavv_007 さん。 現時点では、 S32K電力推定ツール（PET）を参照してください。 対応機器の数は限られているが、役に立つ可能性はある。S32K3X8デバイスに関する予備情報について、コミュニティのプライベートメッセージでもお送りしました。 最後に、S32K3XXのデータシートの第6.7章（供給電流）をご参照ください。そこには、スタンバイ時、低速動作時、および動作時の供給電流が記載されています。これは参考情報として役立つかもしれません。 よろしくお願いします、 ジュリアン

#S32K144 Cache write Test ##S32K144 support modifying cache values? Why is it that after I modify a value, reading the same address still returns the original value? Additionally, can the cache's parity bit be tested？thanks Re: #S32K144 Cache write Test Hi @joshua9264, It is technically possible to change the cache value through the LMEN registers. Let me create a simple test project. BR, Daniel Re: #S32K144 Cache write Test Hi @joshua9264, Have a look at this example: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K142-LMEM-Cache-v1-0-S32DS3-6-RTD300/ta-p/2368498 Regards, Daniel

LS1012Aの自動起動が開始されない こんにちは、私はls1012aボードを問題なく使用していました。 起動時に、先ほどの画像のような状態になりません。 何が問題なのか知りたい。

Problem in changing fps from 30 to 60 fps for mx95mbcam with imx95 I am using imx95 with mx95mbcam camera module with gmsl maixm serdes. The default working driver is running with 1920*1280@30 fps, I wanted to run it with  1920*1280@60 fps. I made the changes in the 0x03c10 sensor register, but the maximum I was able to achieve was 47fps. After that, I was not able to get a video feed. Is there any limitation with Maxim SerDes or any other problem? Re: Problem in changing fps from 30 to 60 fps for mx95mbcam with imx95 This may be a bandwidth issue. How many cameras you connect to the Maxim DES? By default, it should run at 1.5Gbps * 4lanes. Re: Problem in changing fps from 30 to 60 fps for mx95mbcam with imx95 connected 4 cameras, but running only 1 cam. 1920*1280 resolution. raw 16-bit PWL output from sensor.

i.MXRT1062 - Bus Hang when using LPI2C with eDMA On a Teensy (MXRT1062) I've bypassed the Zephyr I2C drivers and am using the NXP SDK provided by Zephyr SDK version 0.17.4 (mcux-sdk-ng) directly. I.e. the functions implemented in: modules/hal/nxp/mcux/mcux-sdk-ng/drivers/..: .. /edma/fsl_edma.c .. /dmamux/fsl_dmamux.c .. /lpi2c/fsl_lpi2c.c .. /lpi2c/fsl_lpi2c_edma.c ... etc. The Teensy LPI2C master talks to several (types of) slave devices. In 'blocking'/'synchronous' mode I can run this setup for days without a problem - LPI2C transactions occuring in the 100's of Hz. When I setup the same LPI2C transactions (and same hardware) to use the eDMA engine ... things run normally for about 10 minutes to an hour before hanging. Even when I slow the DMA frame rate down to a fraction of the 'synchronous' mode rate, the bus hangs in relatively short order. This happens using multiple (types) of slave devices, even when the bus is reduced to just one slave device. The hang is initiated by a kStatus_LPI2C_PinLowTimeout event received by the EdmaCompletionCallback (registered with LPI2C_MasterCreateEDMAHandle(...)). Once that happens, I can't seem to do anything short of power-cycling the system to get back to normal. A 'soft reset' routine that consists of : * clearing MIER, MDER * calling LPI2C_MasterTransferAbortEDMA(), EDMA_AbortTransfer(), LPI2C_MasterReset(), LPI2C_MasterClearStatusFlags() * flushing FIFOs in MCR * and re-initializing with LPI2C_MasterInit() is called whenever the DMA completion callback is not called by its deadline. The 'soft reset' routine has absolutely no effect. No more completion events occur after the first kStatus_LPI2C_PinLowTimeout event. In the LPI2C.MSR, the BBF bit (bus busy flag) is permanently set. The Teensy reset button does not reset this state - a power cycle is required in order to talk to the slave(s) again. Hoping someone can provide some insights: * Is there a bug in the mcux-sdk-ng SDK that someone might have patch for? * Why do the same rock-solid synchronous transactions fail under eDMA control? * Is there some eDMA setup I can do that prevents the kStatus_LPI2C_PinLowTimeout from happening (increasing pinLowTimeout_ns doesn't help)? Clock stretching has been disabled for all slaves. * Is there a quick recovery approach I can apply - short of wiggling the SDA line 9 times or whatever? Thanks for any support! --George i.MXRT 106x Re: i.MXRT1062 - Bus Hang when using LPI2C with eDMA Hi @zeebrog , Thank you so much for your interest in our products and for using our community. Q1:* Is there a bug in the mcux-sdk-ng SDK that someone might have patch for? A1: No. Based on available documentation, there is no reported erratum for LPI2C + eDMA on RT1060. Q2* Why do the same rock-solid synchronous transactions fail under eDMA control? A2: Blocking mode is more robust because the CPU services the FIFO directly. In eDMA mode, FIFO handling depends on DMA timing, which can increase the chance of TX underrun or RX overrun, causing the bus to stall. Q3:* Is there some eDMA setup I can do that prevents the kStatus_LPI2C_PinLowTimeout from happening (increasing pinLowTimeout_ns doesn't help)? Clock stretching has been disabled for all slaves. A3：Not directly, The PINLOW timeout only affects when the timeout flag is triggered, not the root cause of the bus being stuck. Q4* Is there a quick recovery approach I can apply - short of wiggling the SDA line 9 times or whatever? A4：A recommended method is to first abort or disable the LPI2C master and reset its internal state( for example by clearing MCR[MEN] or asserting MCR[RST] ). If the bus remains physically stuck low after that,  in practice, manually pulsing SCL while leaving SDA released may be used as a generic I2C bus-recovery workaround to let a slave complete an unfinished transfer and release the bus. Best Regards May

集成 CAN 上的 UDS 引导加载器和 J1939 堆栈   说明： 嗨，团队、 我在 S32K344 上使用 S32DS 3.6.5 和 RTD 3.0.0。 目前正在实施： FlexCAN CAN 通信 通过 ISO-TP 的 UDS 引导加载程序 J1939 应用通信 GCC 编译器 AUTOSAR RTD 驱动器 我需要有关以下方面共存的指导： UDS 诊断（ISO14229） ISO-TP 传输层 J1939 通信栈 如何在 S32k344 中通过软件选择 CAN 终端电阻配置？ 解释如何在收发器和 MCU 中设计 CAN 终端 问题 在同一个 CAN 控制器上同时运行 UDS 和 J1939 的推荐架构是什么？ 是否建议为 UDS 和 J1939 使用不同的 CAN 报文缓冲器？ 如何配置 CAN ID 过滤？ 恩智浦是否有以下参考示例： UDS 引导加载程序 J1939 堆栈 共享使用 FlexCAN RTD 3.0 在这种使用情况下有什么已知限制吗？ 控制器： S32K344 RTD 3.0 S32DS 3.5 谢谢。

LX2160ARDBボードへのPMDドライバのインストールと使用 Yoctoレシピを使用してインストールする方法を教えてください。bitbake dpdkコマンドを使用してdpdkをインストールしましたが、デフォルトではcrypto_dpaa2_sec PMDのみが使用されます。ユーザーガイドには、Yoctoを使った明確な手順が記載されています。 以下のコマンドで検証しているとき： dpdk-test-crypto-perf -c 0x3 --log-level=3 -- --devtype crypto_dpaa2_sec というコマンドでは意味のある結果が表示されますが、devtype crypto_armv8/crypto_openssl/crypto_null など他のコマンドでは「USER1: 要求された暗号化デバイスタイプの初期化に失敗しました」と表示されます。添付ファイルを参照してください。 Re: Installing and using PMD drivers in LX2160ARDB boards DPDKのレシピに以下の行を追加してください   EXTRA_OEMESON:append = " \ -Denable_drivers=crypto/dpaa2_sec,crypto/armv8,crypto/openssl,crypto/null \ 」   bitbake -e dpdk | grep enable_drivers bitbake -c clean dpdk bitbake dpdk   dpdk-test-crypto-perf --list

i.MXRT1062 - LPI2CとeDMAを使用した場合のバスハング Teensy (MXRT1062) では、Zephyr I2C ドライバをバイパスし、Zephyr SDK バージョン 0.17.4 (mcux-sdk-ng) が提供する NXP SDK を直接使用しています。つまり、以下の機能に実装されています。 modules/hal/nxp/mcux/mcux-sdk-ng/drivers/..: .. /edma/fsl_edma.c .. /dmamux/fsl_dmamux.c .. /lpi2c/fsl_lpi2c.c .. /lpi2c/fsl_lpi2c_edma.c …など Teensy LPI2Cマスターは、複数の（種類の）スレーブデバイスと通信します。 「ブロッキング」/「同期」モードでは、この設定を何日も問題なく実行できます。LPI2Cトランザクションは数百Hzの頻度で発生します。 同じ LPI2C トランザクション (および同じハードウェア) を使用して eDMA エンジンを設定すると、約 10 分から 1 時間ほどは正常に動作しますが、その後ハングアップします。 DMAのフレームレートを「同期」モードのレートのほんの一部まで下げても、バスは比較的短時間でハングアップしてしまう。 これは、バスが1つのスレーブデバイスのみに縮小された場合でも、複数の（種類の）スレーブデバイスを使用している場合に発生します。 ハングは、EdmaCompletionCallback (LPI2C_MasterCreateEDMAHandle(...) に登録) が受信した kStatus_LPI2C_PinLowTimeout イベントによって開始されます。 そうなると、システムを再起動する以外に正常に戻す方法はないようです。 ソフトリセットルーチンとは、以下の手順から構成されるものです。 * MIER、MDERのクリア * LPI2C_MasterTransferAbortEDMA()、EDMA_AbortTransfer()、LPI2C_MasterReset()、LPI2C_MasterClearStatusFlags() を呼び出す * MCRでFIFOをフラッシュする * LPI2C_MasterInit() を使用して再初期化します DMA完了コールバックが期限までに呼び出されなかった場合に呼び出されます。「ソフトリセット」の手順は全く効果がありません。 最初の kStatus_LPI2C_PinLowTimeout イベント以降は、完了イベントは発生しません。LPI2C.MSRでは、BBFビット（バスビジーフラグ）が常にセットされています。 Teensyのリセットボタンではこの状態はリセットされません。スレーブデバイスと再び通信するには、電源を入れ直す必要があります。 どなたかご意見をいただけると幸いです。 * mcux-sdk-ng SDKにバグがあり、誰かが修正パッチを提供している可能性はありますか？ * 同じ非常に安定した同期トランザクションが、eDMA制御下ではなぜ失敗するのか？ * kStatus_LPI2C_PinLowTimeoutが発生しないようにするためのeDMAの設定方法はありますか？（pinLowTimeout_nsを増やしても効果がありません）。クロックストレッチングは、すべてのスレーブで無効化されました。 * SDAラインを9回揺らすなどの方法以外で、すぐに回復できる方法はありますか？ サポートありがとうございます！ --ジョージ i.MXRT 106x Re: i.MXRT1062 - Bus Hang when using LPI2C with eDMA こんにちは、 @zeebrog さん。 弊社製品にご関心をお寄せいただき、また弊社のコミュニティをご利用いただき、誠にありがとうございます。 Q1: mcux-sdk-ng SDKにバグがあり、誰かがパッチを作成した可能性はありますか？ A1：いいえ。入手可能なドキュメントに基づくと、RT1060上のLPI2C + eDMAに関するエラーは報告されていません。 Q2* 同じ非常に安定した同期トランザクションが、eDMA制御下で失敗する理由は何ですか？ A2：ブロッキングモードは、CPUがFIFOを直接処理するため、より堅牢です。eDMAモードでは、FIFOの処理はDMAのタイミングに依存するため、TXアンダーランやRXオーバーランが発生する可能性が高くなり、バスが停止する原因となることがあります。 Q3:* kStatus_LPI2C_PinLowTimeoutが発生しないようにするためのeDMAの設定方法はありますか？（pinLowTimeout_nsを増やしても効果はありません）クロックストレッチングは、すべてのスレーブで無効化されました。 A3：直接的には影響しません。PINLOWタイムアウトはタイムアウトフラグがトリガーされたときにのみ影響し、バスが停止する根本原因ではありません。 Q4* SDAラインを9回揺らすなどの方法以外で、すぐに回復できる方法はありますか？ A4：推奨される方法は、まずLPI2Cマスタを中止または無効にして、内部状態をリセットすることです（たとえば、MCR[MEN]をクリアするか、MCR[RST]をアサートすることによって）。 その後もバスが物理的にローレベルのままの場合、実際には、SDAを解放したままSCLを手動でパルスすることで、スレーブが未完了の転送を完了し、バスを解放するための一般的なI2Cバス復旧の回避策として使用できます。 よろしくお願いいたします。 5月

UDSブートローダーとCAN上のJ1939スタックの統合   説明： チームの皆さん、こんにちは。 私はS32DS 3.6.5とRTD 3.0.0を使用してS32K344で作業しています。 現在の実装： FlexCAN CAN通信 ISO-TP経由のUDSブートローダー J1939アプリケーション通信 GCCコンパイラ AUTOSAR RTDドライバ 以下のものの共存に関して指導が必要です。 UDS診断（ISO14229） ISO-TPトランスポート層 J1939通信スタック S32k344ではCAN終端抵抗の設定をソフトウェアで選択する必要がありますが、その方法を教えてください。 トランシーバとMCUにおけるCAN終端の設計方法について説明します。 質問: 同じCANコントローラ上でUDSとJ1939を同時に実行するための推奨アーキテクチャは何ですか？ UDSとJ1939用に別々のCANメッセージバッファを使用することは推奨されますか？ CAN IDフィルタリングはどのように設定すべきですか？ NXPの参考例はありますか？ UDSブートローダー J1939スタック FlexCANの共有利用 このユースケースに関して、RTD 3.0に既知の制限事項はありますか？ コントローラ: S32K344 RTD 3.0 S32DS 3.5 ありがとう。

在 LX2160ARDB 板中安装和使用 PMD 驱动程序 请建议使用 yocto receipe 安装的方法，我已经使用 bitbake dpdk 命令安装了 dpdk，但默认情况下它只使用 crypto_dpaa2_sec PMD。用户指南提供了使用 yocto 的明确步骤。 当我使用以下命令进行验证时： dpdk-test-crypto-perf-c 0x3--log-level=3-----devtype crypto_dpaa2_sec，则显示的是有意义的结果，而使用其他命令，例如 devtype crypto_armv8/crypto_openssl/crypto_null，则显示 " USER1：无法初始化请求的加密设备类型 "，请参阅附件。 Re: Installing and using PMD drivers in LX2160ARDB boards 请在 DPDK 的配方中添加以下几行   EXTRA_OEMESON:append =" \ -Denable_drivers=crypto/dpaa2_sec,crypto/armv8,crypto/openssl,crypto/null\ ”   bitbake -e dpdk | grep enable_drivers bitbake -c clean dpdk bitbake dpdk   dpdk-test-crypto-perf --list

i.mxrt1062-使用带有 eDMA 的 LPI2C 时总线挂起 在 Teensy（MXRT1062）上，我绕过了 Zephyr I2C 驱动程序，直接使用 Zephyr SDK 0.17.4 版 (mcux-sdk-ng) 提供的恩智浦 SDK。也就是在 modules/hal/nxp/mcux/mcux-sdk-ng/drivers/...: .../edma/fsl_edma.c ../dmamux/fsl_dmamux.c ../lpi2c/fsl_lpi2c.c ../lpi2c/fsl_lpi2c_edma.c ......等等。 Teensy LPI2C 主设备可与几种（类型的）从属设备通信。 在 "阻塞"/"同步 "模式下，我可以连续数天毫无问题地运行此设置--LPI2C 事务的频率高达 100 赫兹。 当我设置相同的 LPI2C 事务（和相同的硬件）以使用 eDMA 引擎时......在挂起前正常运行大约 10 分钟到 1 小时。 即使我将 DMA 帧速率降低到 “同步” 模式速率的一小部分，总线也会在相对较短的时间内挂起。 使用多个（类型）从设备时也会发生这种情况，即使总线减少到只有一个从属设备也是如此。 挂起由 EdmaCompletionCallback（通过 LPI2C_MasterCreateEDMAHandle(...) 注册）收到的 kStatus_LPI2C_PinLowTimeout 事件启动。 一旦发生这种情况，我似乎无法采取任何措施来恢复正常，只能将系统断电。 一个 “软复位” 例程，包括： * 清除 MIER、MDER * 调用 lpi2c_masterTransferAbortedMA ()、edma_abortTransfer ()、lpi2c_masterReset ()、lpi2c_masterClearStatusFlags () * 在 MCR 中刷新 FIFO * 并使用 LPI2C_inMasterIt () 重新初始化，每当 DMA 完成时都会调用回调不会在截止日期之前调用。 “软复位” 例程完全没有效果。 在第一个 kStatus_LPI2C_PinLowTimeout 事件之后，不再发生完成事件。在LPI2C.MSR中，BBF位（总线繁忙标志）是永久设置的。 Teensy 重置按钮无法重置此状态——需要重启电源才能再次与从机通话。 希望有人能提供一些见解： * mcux-sdk-ng SDK 中是否存在错误，是否有人提供了补丁？ * 为什么在 eDMA 控制下，同样稳如磐石的同步事务会失败？ * 是否有一些 eDMA 设置可以防止 kStatus_LPI2C_PinLowTimeout 发生（增加 pinLowTimeout_ns 并无帮助）？所有从机的时钟拉伸均已禁用。 * 有没有快速恢复的方法？ 感谢您的支持！ --乔治 i.MX RT106x Re: i.MXRT1062 - Bus Hang when using LPI2C with eDMA 你好@zeebrog、 非常感谢您关注我们的产品并使用我们的社区。 问题 1:* mcux-sdk-ng SDK 中是否存在错误，可能有人会提供补丁？ 答 1：没有。根据现有文件，没有关于 RT1060 上 LPI2C + eDMA 的勘误报告。 问题 2* 为什么同样稳如磐石的同步事务在 eDMA 控制下会失败？ A2：阻塞模式更稳健，因为 CPU 直接为 FIFO 提供服务。在 eDMA 模式下，FIFO 处理取决于 DMA 时序，这会增加 TX 欠载或 RX 超限的可能性，从而导致总线失速。 问题 3:* 是否有一些 eDMA 设置可以防止 kStatus_LPI2C_PinLowTimeout 发生（增加 pinLowTimeout_ns 并没有帮助）？所有从机的时钟拉伸均已禁用。 A3：不是直接的，PINLOW 超时仅影响触发超时标志的时间，不影响总线卡住的根本原因。 问题 4* 有没有快速恢复的方法？ A4：推荐的方法是先中止或禁用 LPI2C 主机并重置其内部状态（例如清除 MCR [MEN] 或断言 MCR [RST]）。 如果此后总线仍然处于低电平状态，则在实际操作中，在释放 SDA 的同时手动向 SCL 发送脉冲可用作通用 I2C 总线恢复解决方法，让从机完成未完成的传输并释放总线。 顺祝商祺！ 5月

ARA240 的 UM 是否有技术说明或用户手册？ Re: UM for ARA240 你好 希望你一切顺利。您可以在这里找到有关该部件的所有可用文档： Ara240 离散神经处理单元 (DNPU) |恩智浦半导体 我们为这部分提供了一个特定的模块：Ara240 16GB M.2 模块 | 恩智浦半导体 | 恩智浦半导体 我建议查看 ARA2-M2-16G-GT 入门指南 | 恩智浦半导体 此外，我们还提供 Ara SDK | 恩智浦半导体。我建议查看 " Ara2 运行时包 "。此软件包支持的平台是我们的 FRDM i.MX 8M Plus 和 FRDM i.MX 95。 希望对您有所帮助！ 顺祝商祺！ 里卡多

SPI NAND boot on i.MX8ULP Hello, I'm trying to boot from a SPI NAND on i.MX8ULP. The evk has a SPI NOR attached and I was able to boot from it, but when trying with a NAND on our boards I cannot get this to work. I've configured BT*_CFG* pins and I see the boot ROM tries to read the NAND, but neither the M33 nor the A35 cores seem to boot, so I'm thinking the boot image is not correct. I'm building the image with imx-mkimage flash_singleboot_m33_flexspi target, which uses the fspi_header file as header block, but the comments in this file seem to indicate that this is for Serial NOR and not for NAND, so I'm looking into this flexspi configuration block header. How would one go about making an appropriate header file for our target? I found kobs-ng but it doesn't seem to be intended for 8ulp (no GPMI NAND controller, and doesn't work even after patching lightly to run anyway) I couldn't find any documentation about the FCFB block in the 8ulp documentation either. I found some documentation about it in the i.MX 8M Mini Applications Processor reference manual (and the u-boot patch adding options about it in u-boot mkimage), but even if it is indeed the same format then how to use it for i.MX8ULP (in particular what LUT table to use) would be appreciated. Thank you, Dominique Martinet

i.MX95 max96724 2 cameras bringup issue when I plugin 1 camera I can bring up the camera, but I plugin 2 cameras (same module), all the cameras bring up failed. log info: Setting pipeline to PLAYING ... New clock: GstSystemClock [0:00:31.239670305] [973] INFO Camera camera.cpp:1215 configuring streams: (0) 1920x1536-YUYV/Unset [0:00:31.250185346] [972] ERROR V4L2 v4l2_videodevice.cpp:1991 /dev/video0[15:cap]: Failed to start streaming: Broken pipe ERROR: from element /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: Failed to start the camera: Broken pipe Additional debug info: ../src/gstreamer/gstlibcamerasrc.cpp(871): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: Camera.start() failed with error code -32 Execution ended after 0:00:00.012442958 Setting pipeline to NULL ... Freeing pipeline ... Re: i.MX95 max96724 2 cameras bringup issue When two max9295a cameras are connected to same MAX96724, only Frame Sync mode can work, free run will not work in multiple camera use case on MAX96724. In fact, the main loading to debug the MAX96724 is on the setting between camera (MAX9295a) and MAX96724, I think customer maybe need support from Maxim. Before Linux can work, they should make sure MAX96724's LOCK bit is set without error, only after that, MAX96724 can output MIPI video frames to iMX95. Re: i.MX95 max96724 2 cameras bringup issue What's the camera sensor? Are they set to Frame Sync mode in driver? Some camera are working in free run in default, in this case, single camera can work on MAX96724 directly, but for multiple cameras, MAX96724 needs they work in Frame Sync mode, all the cameras should send out video frame after they received the SYNC signal from MAX96724. And what's the media-ctl command the customer used? Re: i.MX95 max96724 2 cameras bringup issue Yes, the GMSL2 Link A&B is Locked for max96724 -> 2 max9295a cameras.    driver log: [ 9.882277] max96724 3-0027: GMSL link mask: configured = 0xf, locked = 0x3 driver code: while (retries--) { locked_links = max96724_check_gmsl_links(priv); if (locked_links == priv->gmsl_link_mask) break; usleep_range(2000, 2500); } if (locked_links == 0) { regmap_write(priv->rmap, MAX96724_TOP_CTRL_PWR1, RESET_ALL); dev_err(dev, "No GMSL link has locked after 3 retries. Abort!\n"); return -ENODEV; } dev_info(dev, "GMSL link mask: configured = 0x%x, locked = 0x%x\n", priv->gmsl_link_mask, locked_links); So, is must need the frame sync between max96724 and max9295a? Re: i.MX95 max96724 2 cameras bringup issue the camera with max9295a，is working in free run, no frame sync need. cam -l , media-ctl  & gst log info： root@imx95evk:~# cam -l [0:01:54.016285137] [1058] WARN IPAManager ipa_manager.cpp:148 No IPA found in '/media/jeffin/dev-work/nxp/codeaurora/libcamera/install/lib/libcamera/ipa' [0:01:54.016504762] [1058] INFO Camera camera_manager.cpp:330 libcamera v0.0.0+6194-lf-6.12.49-2.2.0-dirty (2026-04-24T21:03:02CST) [0:01:54.061756845] [1059] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 8-0062': No sensor delays found in static properties. Assuming unverified defaults. [0:01:54.061982970] [1059] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x00980911 but control is not exposed by device /dev/v4l-subdev12 [0:01:54.062069678] [1059] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x009e0903 but control is not exposed by device /dev/v4l-subdev12 [0:01:54.068941887] [1059] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 9-0062': No sensor delays found in static properties. Assuming unverified defaults. [0:01:54.069094470] [1059] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x00980911 but control is not exposed by device /dev/v4l-subdev13 [0:01:54.069152970] [1059] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x009e0903 but control is not exposed by device /dev/v4l-subdev13 [0:01:54.073940928] [1059] INFO Camera camera_manager.cpp:220 Adding camera '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62' for pipeline handler simple [0:01:54.074970262] [1059] INFO Camera camera_manager.cpp:220 Adding camera '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@1/mx95wecam@62' for pipeline handler simple Available cameras: 1: 'mx95wecam' (/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62) 2: 'mx95wecam' (/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@1/mx95wecam@62) root@imx95evk:~# media-ctl -d /dev/media0 -p Media controller API version 6.12.49 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.49 Device topology - entity 1: crossbar (13 pads, 10 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 2/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 2/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 2/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 2/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video1 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 compose:(0,0)/1920x1536] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 115: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "max96724 3-0027":4 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 120: max96724 3-0027 (6 pads, 3 links, 4 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 4/0 [ACTIVE] 1/0 -> 4/1 [ACTIVE] 2/0 -> 5/2 [ACTIVE] 3/0 -> 5/3 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] <- "mx95wecam 8-0062":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] <- "mx95wecam 9-0062":0 [ENABLED,IMMUTABLE] pad2: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] pad3: SINK [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] pad4: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] [stream:1 fmt:UYVY8_1X16/1920x1536 colorspace:raw] -> "csidev-4ad30000.csi":0 [ENABLED] pad5: SOURCE [stream:2 fmt:UYVY8_1X16/1920x1536 colorspace:raw] [stream:3 fmt:UYVY8_1X16/1920x1536 colorspace:raw] - entity 129: mx95wecam 8-0062 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev12 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "max96724 3-0027":0 [ENABLED,IMMUTABLE] - entity 133: mx95wecam 9-0062 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1536 crop:(0,0)/1920x1536] -> "max96724 3-0027":1 [ENABLED,IMMUTABLE] root@imx95evk:~# gst-launch-1.0 libcamerasrc camera-name=/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62 ! video/x-raw,width=1920,height=1536,format=YUY2 ! autovid eosink Setting pipeline to PAUSED ... [0:03:53.646204235] [1061] WARN IPAManager ipa_manager.cpp:148 No IPA found in '/media/jeffin/dev-work/nxp/codeaurora/libcamera/install/lib/libcamera/ipa' [0:03:53.646456819] [1061] INFO Camera camera_manager.cpp:330 libcamera v0.0.0+6194-lf-6.12.49-2.2.0-dirty (2026-04-24T21:03:02CST) [0:03:53.694436152] [1068] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 8-0062': No sensor delays found in static properties. Assuming unverified defaults. [0:03:53.694678277] [1068] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x00980911 but control is not exposed by device /dev/v4l-subdev12 [0:03:53.694785485] [1068] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x009e0903 but control is not exposed by device /dev/v4l-subdev12 [0:03:53.702510985] [1068] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 9-0062': No sensor delays found in static properties. Assuming unverified defaults. [0:03:53.702685235] [1068] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x00980911 but control is not exposed by device /dev/v4l-subdev13 [0:03:53.702777610] [1068] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x009e0903 but control is not exposed by device /dev/v4l-subdev13 [0:03:53.708162819] [1068] INFO Camera camera_manager.cpp:220 Adding camera '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62' for pipeline handler simple [0:03:53.709431777] [1068] INFO Camera camera_manager.cpp:220 Adding camera '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@1/mx95wecam@62' for pipeline handler simple Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock [0:03:53.713476694] [1069] INFO Camera camera.cpp:1215 configuring streams: (0) 1920x1536-YUYV/Unset [0:03:53.724398360] [1068] ERROR V4L2 v4l2_videodevice.cpp:1991 /dev/video0[15:cap]: Failed to start streaming: Broken pipe ERROR: from element /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: Failed to start the camera: Broken pipe Additional debug info: ../src/gstreamer/gstlibcamerasrc.cpp(871): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: Camera.start() failed with error code -32 Execution ended after 0:00:00.013385834 Setting pipeline to NULL ... Freeing pipeline ... Re: i.MX95 max96724 2 cameras bringup issue GMSL lock is not enough, video lock is needed for MIPI CSI2 output. The video lock will only happen in Frame Sync mode when multiple cameras are used. Re: i.MX95 max96724 2 cameras bringup issue code: ./drivers/media/mc/mc-entity.c ret = entity->ops->link_validate(link); if (ret) { printk( "Link '%s':%u -> '%s':%u failed validation: %d\n", link->source->entity->name, link->source->index, link->sink->entity->name, link->sink->index, ret); goto error; } Re: i.MX95 max96724 2 cameras bringup issue I trace the driver the error log is: <7>[ 26.481786] mx95wecam 8-0062: !!!!!! drivers/media/i2c/mx95wecam.c:L302 mx95wecam_get_fmt() <4>[ 26.481797] !!!!!! drivers/media/mc/mc-entity.c:L875 __media_pipeline_start() <4>[ 26.481802] Link 'mx95wecam 8-0062':0 -> 'max96724 3-0027':0 is valid <4>[ 26.481807] !!!!!! drivers/media/mc/mc-entity.c:L897 __media_pipeline_start() <4>[ 26.481811] Validating pad 'mx95wecam 8-0062':0 <4>[ 26.481815] !!!!!! drivers/media/mc/mc-entity.c:L836 __media_pipeline_start() <4>[ 26.481819] !!!!!! drivers/media/mc/mc-entity.c:L897 __media_pipeline_start() <4>[ 26.481824] Validating pad 'max96724 3-0027':1 <4>[ 26.481827] !!!!!! drivers/media/mc/mc-entity.c:L836 __media_pipeline_start() <4>[ 26.481832] !!!!!! drivers/media/mc/mc-entity.c:L863 __media_pipeline_start() <7>[ 26.481839] mx95wecam 9-0062: !!!!!! drivers/media/i2c/mx95wecam.c:L302 mx95wecam_get_fmt() <4>[ 26.481845] Link 'mx95wecam 9-0062':0 -> 'max96724 3-0027':1 failed validation: -32 <4>[ 26.481851] !!!!!! drivers/media/mc/mc-entity.c:L919 __media_pipeline_start() <4>[ 26.481860] !!!!!! drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c:L1312 mxc_isi_video_streamon() the link A pipe 0 camera mx95wecam 8-0062 is pipe link ok. the link B pipe 1 camera mx95wecam 9-0062 is pipe line failed. That is the pipe set issue?

i.MXRT1170：有关 ENET_QOS（此处为 DMA_CHx_RXDESC_TAIL_POINTER）的问题 你好 我只是想了解 ENET_QOS 的 DMA 功能。我现在的 DMA_CHx_RXDESC_TAIL_POINTER 寄存器有问题。在登记册的描述中，我在参考手册中找到了以下内容： 61.7.1.479.2功能 通道 0 Rx 描述符尾部指针指向基站的偏移量，表示最后一个有效描述符的位置。 因此，应在此处输入最后一个有效描述符的地址。如果环中有 8 个条目，则最后一个条目为 7。从 0 数到 7。 但是，如果我看看 ENET_QOS_ReadFrame 的结尾，这里使用了下面一行代码： /* Always try to start receive, in case it had stopped */ rxDescTail = (uint32_t)(uintptr_t)&rxBdRing->rxBdBase[rxBdRing->rxRingLen]; #if defined(FSL_FEATURE_MEMORY_HAS_ADDRESS_OFFSET) && FSL_FEATURE_MEMORY_HAS_ADDRESS_OFFSET rxDescTail = MEMORY_ConvertMemoryMapAddress(rxDescTail, kMEMORY_Local2DMA); #endif base->DMA_CH[channel].DMA_CHX_RXDESC_TAIL_PTR = rxDescTail; base->DMA_CH[channel].DMA_CHX_RX_CTRL |= ENET_QOS_DMA_CHX_RX_CTRL_SR_MASK; 但此处 rxDescTail 并未设置为有效描述符，而是使用了"境外" 访问。rxBdRing->rxRingLen 是环的大小。 这种情况也发生在其他地方。是这里出错了，还是 DMA_CHx_RXDESC_TAIL_POINTER 究竟应该如何使用？ 致以最诚挚的问候， Michael Re: i.MXRT1170: question about ENET_QOS, here DMA_CHx_RXDESC_TAIL_POINTER 你好@Gavin_Jia、 "MCUXpresso SDK 将其设置为单快结束，以防止 Rx DMA 因电流 == 尾端而停止；" 因此，尾部指针被设置在环外，这样，如果电流 == 尾部，DMA 就不会停止。 然而，ENET_QOS_SendFrame 的情况却令人困惑。在这里，尾部指针比当前指针前移一个条目。这样做是为了在发送完当前帧后停止 DMA 吗？这意味着，如果发送环的大小也是 8，而要发送的新帧位于索引 5 中，则尾指针将被设置为 6。 但如果要发送的新帧在索引 7 中，尾指针将不会设置为索引 0，而是设置为索引 8。 之后，如果在 7 之后使用索引 0，尾部指针将设回 x+1，即 0+1。 我完全不明白为什么要在这里设置尾指针。在这种情况下，将其设置为索引 8 不就可以了吗？因为如果没有为下一个索引设置 OWN 位，DMA 就不会在发送后继续运行。 致以最诚挚的问候， Michael Re: i.MXRT1170: question about ENET_QOS, here DMA_CHx_RXDESC_TAIL_POINTER 嗨，@michael_fischer、 感谢您对 NXP MIMXRT 系列的关注！ SDK 代码是有意为之。&rxBdBase[rxRingLen]用作单次快结束尾边界/门铃值，而不是用作软件或 DMA 访问的描述符。在 ENET_QOS DMA 环模式下，描述符环长度寄存器定义实际有效的描述符范围，而尾部指针用于指示边界，并在 DMA 停止时重新启动。 因此，对于 8 个描述符的环，有效描述符仍然是索引 0~7，而&rxBdBase[8] 的值仅用作尾部边界。 《参考手册》中的 “最后一个有效描述符” 的措辞很容易被误解。更精确的描述是，尾指针标记描述符边界/DMA 恢复点。MCUXpresso SDK 将其设置为单次快结束，以防止 Rx DMA 因当前 == 尾端而停止；DMA 仍根据编程的环长度缠绕，并且不会获取超出绑定的描述符。 致以最诚挚的问候， Gavin Re: i.MXRT1170: question about ENET_QOS, here DMA_CHx_RXDESC_TAIL_POINTER 你好@Gavin_Jia、 是否有关于 ENET_QOS_SendFrameFunktion 的新信息？ 致以最诚挚的问候， Michael

[S32K328およびS32K358] HSE-Bの性能について 親愛なるNXP S32K328GHT1MJBSTとS32K358GHT1MPCSTの間で、HSE-B（サイバーセキュリティエンジン）のセキュリティ機能や性能に違いがあるかどうかを知りたいです。 ありがとう、 ブライアン Re: [S32K328 and S32K358 ] About performance for HSE-B こんにちは、 @bryan_hong さん。 違いはありません。S32K328とS32K358は、同じバージョンのHSEファームウェアを共有しています。また、両デバイスともクロック周波数の制限は同じです。つまり、セキュリティ機能とHSE（環境・安全・衛生）性能は全く同じになります。 よろしくお願いいたします。 ルーカス