Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
在 KW45B41Z-EVK 上实现 AI/ML NXP社区的各位好, 我正在开发一款适用于KW45B41Z-EVK (Cortex-M33) 的边缘 AI 应用,希望就如何在该板上部署机器学习模型获得一些建议。 由于 KW45 SDK 默认不包含 eIQ/TFLM 中间件,我的计划是: 模型训练:使用eIQ Time Series Studio (eIQ TSS)训练一个用于时间序列数据的 n 类分类模型。由于 eIQ TSS 中未列出 KW45 作为目标平台,因此我选择FRDM-MCXN947 (Cortex-M33) 作为导出模型的目标平台。 运行时部署:将FRDM-MCXN947 SDK中的 中间件/eiq/tensorflow-lite 文件夹移植到我的 KW45 SDK 项目中,并将其与 CMSIS-NN 链接。 我的问题: 将 eIQ TFLM 中间件从 MCXN947 SDK 移植到 KW45 SDK 是否是一种有效且受支持的方法? 在 eIQ TSS 中选择 FRDM-MCXN947 是否适合生成在 KW45 上运行的模型? 在 KW45B41Z-EVK 上实现 AI/ML 是否有其他推荐的或原生工作流程? 感谢您的帮助! KW45B41Z-EVK KW45 EIQ-TFLITE-MICRO EIQ-工具包#AIML Re: Implementing AI/ML on KW45B41Z-EVK 你好,希望你一切都好。 如果您使用的是 eIQ Time Series Studio (TSS),我建议您将项目从 FRDM-MCXW71 移植过来。它是 eIQ TSS 官方支持的目标,并且在软件上与 KW45 兼容。这两个设备都采用相同的 Cortex-M33 内核架构和类似的内存配置,因此生成的库应该与您的硬件更加匹配。 当使用硬件配置差异很大的设备(例如 FRDM-MCXN947)作为移植目标时,可能会生成不兼容的模型,例如,由于两个设备之间的可用 RAM 存在差异,或者生成了专门针对 MCXN947 的 NPU 加速模型。 希望这能帮到你! 此致, 索菲亚。
查看全文
i.MX8MP - Qt OpenGL / 大規模EGLレンダーターゲットを使用すると、Vivante 6.4.11.p4.xでWestonがクラッシュする こんにちは、NXPサポートの皆さん、 私たちはi.MX8MPプラットフォーム上の再現可能なグラフィックス問題を調査しています。 動作構成 ヨクト・スカースギャップ カーネル: 6.6.52 Vivanteスタック: 6.4.11.p2.x Weston 14.0.2.imx Qt 6.8.3 結果: Qt Quickは QOpenGLWindowは動作します クラッシュなし 設定エラー ヨクト・ライノーズ カーネル: 6.18.20 Vivanteスタック:6.4.11.p4.4および6.4.11.p4.6 Weston 14.0.2.imx Qt 6.8.3 および 6.8.4 結果: QQuickWindowがクラッシュする QOpenGLWindowがクラッシュする ウェストンがSIGSEGVと衝突 また、メモリ破損の症状も確認されました。 malloc(): unaligned tcache chunk detected グラフィック障害発生後には、無関係なプロセスが時折クラッシュする。 Qtはおそらく根本原因ではない 当初、この問題はQt Quickの問題のように見えた。 しかし、テストケースは最小限に絞りました: QOpenGLWindow   QML、シーングラフ、QRhi、テクスチャ、カスタムレンダリングは使用しません。 故障は依然として発生する。 ネイティブEGLテスト シンプルなネイティブのWayland/EGL/GLES3アプリケーションは安定しています: wl_egl_window eglCreateContext glClear eglSwapBuffers   最大サイズまでリサイズした場合でも:   1920x1080   何時間も。 追加のネイティブEGLテスト 私たちは以下の方法でネイティブのWayland/EGL/GLES3テストを作成しました。 テクスチャ割り当て FBOの作成 テクスチャへのレンダリング glFramebufferTexture2D() glBlitFramebuffer() eglSwapBuffers() 以下のサイズは正常に通過します。 500x500 640x480 800x480 900x540 1024x600   この問題は、以下のようなより大きなレンダリングターゲットで発生し始めます。   1280x720 1280x800   ウェストンの行動 OpenGLアプリケーションを起動した後、Westonはクラッシュします: weston.service: Main process exited status=11/SEGV   Qtアプリケーションは次のように報告します:   The Wayland connection broke. Did the Wayland compositor die?   これは、ウェストンが最初に衝突したことを示唆している。 Vivanteのユーザースペースの違い 正常に動作するシステムと故障しているシステムで異なるライブラリは以下のとおりです。 libGAL.so libEGL.so libGLESv2.so   この問題はどちらの環境でも再現可能です。   6.4.11.p4.4 6.4.11.p4.6   一方、年配の方は: 6.4.11.p2.x   6.6カーネルで動作します。 質問 Vivante 6.4.11.p4.x には、以下の点に関する既知の問題はありますか? Weston ウェイランド-EGL FBO(固定基地運営事業者) glBlitFramebuffer() 大きなレンダリングターゲット p2.xとp4.xの間には既知の回帰関係はありますか? 以下の項目について、推奨されるデバッグオプションはありますか? ガルコア libGAL libgbm_viv Westonバッファのインポートパス 何かご助言いただければ大変ありがたいです。 Vivanteスタックを使ったカーネル6.18.20でクラッシュを再現できる簡単なテストアプリ(6.4.11.p4.4と6.4.11.p4.6)を添付しました Re: i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets 私はさらに調査を進めた。 カーネル6.6.52とVivante p6.4.11.p4.4の組み合わせは動作します。 カーネル6.18.20とVivante p6.4.11.p4.4の組み合わせでクラッシュする 調査結果は明らかに悪化している。 500x500から1024x600への直接的なサイズ変更だけでも、クラッシュを引き起こすのに十分だ。 クラッシュはOpenGLの処理パス内で、スワップチェーンのサイズ変更直後に発生します。 同時に、systemd-journalのSEGVが再び発生します。 これは単なるアプリのエラーではなく、GL/Wayland/Vivanteスタックにおけるメモリ破損の強い兆候です。 仮説の現状 重要なのは1280x720という解像度だけではない。 むしろ、決定的な要因は「再構成」に直接ジャンプし、その後に「提示」を実行することである。 連続的に小さなサイズ変更を行う方が、直接的なサイズ変更よりもはるかに堅牢です。 ソフトウェアバックエンドは安定しており、問題はハードウェア-GL経路にあることが確認されています。 Re: i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets こんにちは、 Qtの問題よりもVivante/galcoreやバッファ管理の問題です。特にネイティブEGLテストもトリガーし、Westonが最初にクラッシュするプロセスなので。レンダリングターゲットが大きい場合に発生し、p4.xスタックでのみ発生するという事実は、特に興味深い。p2とp4のGAL/GBMの変更点を比較し、バッファの割り当てとインポートに関するgalcore/Westonのデバッグを有効にします。
查看全文
HSE安装问题 帮助!我参考官方演示项目编写了一个 HSE 固件安装程序。但是,在执行两次 RESET 后,HSE 安装地址 0x007E0000 处没有任何数据。这是否意味着 HSE 安装失败了? 1131_0-1788746050565.png1131_0-1788746050565.png 这是 ld 文件 1131_1-1788746137817.png1131_1-1788746137817.png 这是重写的 IVT 向量 1131_2-1788746175542.png1131_2-1788746175542.png 1131_3-1788746225953.png1131_3-1788746225953.png 1131_4-1788746253844.png1131_4-1788746253844.png 最后,我附上我的 HSE 安装演示项目。 Re: HSE installation issues S32 版本为 3.6.8,芯片型号为S32K314,RTD版本为7.0.1。 Re: HSE installation issues 首先,您应该查看 HSE_CONFIG_GPR3 寄存器 (0x4039C028),以确定您的 HSE 固件是否已安装。
查看全文
关于8M+实时精度 您好,我们想更多地了解 8M Plus 在实时应用方面的功能。是否有关于TSN、实时性能或抖动方面的测试报告或相关资料? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy 面积 可用材料 它包含什么 实时 CPU/RTOS 延迟 鱼叉用户指南 测量实时延迟 i.MX 8M Plus / Zephyr 包括 IRQ 延迟和任务延迟(单位:纳秒)。示例结果:空载 IRQ 延迟最小值/平均值/最大值/标准差 = 625 / 796 / 11,125 / 1,798 ns 任务延迟 = 2,583 / 2,671 / 13,041 / 6,045 ns 。在 Linux 系统下,CPU + 内存负载,IRQ 延迟 = 625 / 798 / 4,250 / 4,674 ns ,任务延迟 = 2,583 / 2,670 / 14,333 / 10,407 ns 。 实时基准测试方法 Harpoon 用户指南 — 实时延迟应用程序 将基准定义为硬件 IRQ 事件与软件操作之间的时间差,使用硬件计时器以亚微秒精度进行测量。 TSN 能力 i.MX 8M Plus 产品/参考资料 i.MX 8M Plus 包含双千兆以太网接口,其中一个以太网接口支持 TSN,并使用集成式 800 MHz Arm Cortex-M7 用于工业实时控制。 TSN硬件标准 i.MX 8M Plus 参考手册 TSN支持包括 IEEE 802.1Qbv 时间感知整形器 , 802.1Qav 基于信用的整形者 , IEEE 1588v2 PTP 以太网模块实现了 802.1Qbv-2015 , 802.3br , 和 802.1Qbu 与帧抢占相关的TSN功能。 TSN 测试/验证环境 实时边缘计算用户指南 描述了用于评估 i.MX 8M Plus TSN 功能的 TSN 测试环境,包括流量生成/分析以及对延迟、抖动和同步精度的监控。 TSN抖动/延迟示例 实时边缘用户指南 — TSN 端点示例应用程序 提供 TSN 端点统计信息,包括流量延迟最小值/平均值/最大值和备注 延迟约为 503 微秒 和 延迟抖动约为 300 纳秒 在所示示例中。 TSN 应用演示 AN13588 演示 GenAVB/TSN 实时控制应用。它描述了一个 2毫秒周期 ,一个 400 微秒预留/保证的控制流量窗口 以及一个用于调度、处理时间、流量正确性和延迟的统计线程。 TSN 802.1Qbv 演示 AN13995 演示了使用 i.MX 8M Plus 的 TSN 802.1Qbv,并解释了时间感知整形技术如何利用固定的重复周期来提供确定性的延迟;它还包含 Linux 版本。  tc  /  taprio  配置示例。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 感谢您提供信息。请问您能否也向我们提供有关 iMX8M Plus EVK 的信息? 谢谢。 Re: Regarding 8M Plus Real time Accuracy 我们了解到,i.MX95 EVK 尚未正式发布任何公开的“实时性能报告”。但是,NXP 内部确实对 i.MX95 平台进行了实时基准测试。内部基准测试文档表明,已在运行实时边缘软件和 PREEMPT_RT Linux 的 i.MX95 LPDDR5 EVK 上执行了 cyclictest 和 EtherCAT 性能评估。报告的例子包括:在 6 小时的压力测试期间,循环测试的最大延迟约为 38 µs;在记录的测试条件下,EtherCAT 滤波后的最大抖动约为 12 µs。由于实时性能很大程度上取决于 BSP 版本、内核配置、CPU 隔离、工作负载和网络流量,因此这些值应被视为参考测量值,而不是保证的应用级限制。   请参阅https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf 作为支持的基准测试平台,并提供详细的循环测试、压力测试和 rt_latency 测试程序。 Re: Regarding 8M Plus Real time Accuracy 我们的代理商告知我们,目前还没有关于 NXP i.MX95 EVK 实时性能或抖动的官方性能报告。 但是,他们还提供了描述评估实时延迟的测试方法(例如,循环测试)的文档。 这导致我们这边有些困惑。由于存在标准化的测试方法,我们假设此类测试一定已在内部执行过——至少在参考 EVK 平台上执行过。 因此,我们想澄清如下: NXP 是否对 i.MX95 EVK 进行过任何实时性能(例如延迟、抖动)的内部测量? 如果可以,是否有任何参考结果或基准结果可以分享? 我们了解到,实时性能可能会因系统配置和工作负载而异。然而,即使是受控条件下的基准结果(例如,默认 BSP,最小负载)对于初步评估也非常有帮助。 感谢您的支持。 hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (实时边缘软件用户指南)( https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf ) 实时边缘软件(最相关) 恩智浦半导体的实时边缘软件正式支持 i.MX8M Plus EVK,并包含以下内容: PREEMPT_RT Linux TSN 协议栈 IEEE 802.1AS (gPTP) 同步 TSN流量整形和调度 EtherCAT、OPC-UA、CAN 相关工业协议 使用 Cortex-A53 + Cortex-M7 的异构实时操作 内部文件REALTIMEEDGEUG指出,实时边缘软件提供: 实时网络(TSN) 实时 Linux (PREEMPT_RT) 纯RTOS/裸机选项 监狱隔断 工业协议支持 支持 i.MX 8M Plus LPDDR4 EVK NXP 应用笔记AN13995 – 使用 i.MX 8M Plus 进行 TSN 802.1Qbv 演示 实时优势产品概览材料中描述了 PREEMPT_RT + TSN 支持 Re: Regarding 8M Plus Real time Accuracy @yipingwang非常感谢您提供的信息。 Re: Regarding 8M Plus Real time Accuracy 下载方式: 1 Real-Time Edge 产品概览 materials 2 实时边缘用户指南 — TSN 端点示例应用程序 3 实时边缘用户指南 4. Harpoon 用户指南 — 实时延迟应用程序 5. 鱼叉用户指南 6 AN13588 谢谢!
查看全文
S32DSのアクティベーションコードの有効期限が切れました こんにちは: 私の S32 Design Studio for S32 プラットフォーム v.3.4のライセンスが もうすぐ切れます。 確認して延長してもらえますか? アクティベーションコード:533B-878B-88A9-C68F ありがとうございます。 Re: S32DS activation code expired こんにちは、 お客様のS32DSライセンスが延長されました。
查看全文
Could you please provide me the pin delay of LS1021AXE7KQB? Hi, Currently, I'm designing PCB for my board. For critical timing requirement of DDR4 interface, I need to compensate the pin delay difference in the  LS1021AXE7KQB package on the PCB. So, could you please provide me the pin delay information of LS1021AXE7KQB? Thanks in advance! Best regards! Jason QorIQ LS1 Devices Re: Could you please provide me the pin delay of LS1021AXE7KQB? All internal die to pad wires of the DDR4 interface are length matched within the package, so the layout trace length task is to be done between processor's and SDRAM's pins. No specific package delay values were provided as they are not needed for the design approach. Re: Could you please provide me the pin delay of LS1021AXE7KQB? Hi,yiping For DDR4 interface of LS1021A, is it necessary to compensate pin delay difference in the package on the PCB?  Thanks in advance! Best regards! Jason Re: Could you please provide me the pin delay of LS1021AXE7KQB? The requested documents are NXP Confidential Proprietary and can only be provided under non-disclosure agreement (NDA).   Did you sign NDA with NXP? If yes, would you please provide your NDA copy or your NDA number?   You could sing a new NDA from https://www.nxp.com/webapp-signup/ndaReqForm Re: Could you please provide me the pin delay of LS1021AXE7KQB? Asked for the required information from the AE team. Re: Could you please provide me the pin delay of LS1021AXE7KQB? Hi, Any response is welcome! Thanks in advance! Best regards! Jason Re: Could you please provide me the pin delay of LS1021AXE7KQB? Hi, yiping: Get it, many thanks to you!!! BTW, I have another question.  eTSEC1 and eTSEC3 of LS1021A will be configured as RGMII mode to driver PHY. But the size of my board is very big,  I'm afraid that the too long trace on PCB will cause insufficient drive capability for RGMII interface(250Mbps per data signal) . Could you please provide the route constraint for RGMII interface, especially trace length on PCB based on common FR-4 PCB(Dk 4.2~4.4, Df 0.022)? Cause, I can't find any PCB design consideration on NXP website.  Also AN4878_Design Checklist only show the design requirement of schematic. Thanks in advance! Best regards! Jason Re: Could you please provide me the pin delay of LS1021AXE7KQB? Would you please create a new thread for your new question? Thanks. Re: Could you please provide me the pin delay of LS1021AXE7KQB? copy that! Thank you very much! Best regards! Jason
查看全文
#S32K388 Enhanced RX FIFO + eDMA: Continuous Circular Buffer Reception Without CPU Interrupts Hi NXP Support, I am using an S32K388 with the FlexCAN Enhanced RX FIFO and RTD. I would like to implement a continuous DMA-based CAN reception without any CPU interrupt. My requirements are: MCU: S32K388 CAN: Classical CAN, CAN FD disabled CAN payload: 8 bytes FlexCAN Enhanced RX FIFO enabled DMA reception enabled I need to receive CAN messages with any CAN ID, without filtering. I want DMA to automatically transfer every received CAN frame into a RAM software ring buffer. I do not want a FlexCAN RX interrupt. I also do not want a DMA major-loop-complete interrupt. DMA should continue running automatically without the CPU having to call FlexCAN_Ip_RxFifo() again. Ideally, each received FIFO element should trigger a DMA transfer immediately, so I do not want to wait for a large FIFO watermark. I checked the RTD source code. In FlexCAN_StartRxMessageEnhancedFifoData(), I found that the driver configures DMA approximately as follows: Source address = Enhanced RX FIFO output Source transfer size = 4 bytes Source offset = 4 bytes Destination transfer size = 4 bytes Destination offset = 4 bytes Minor loop size = 80 bytes Major loop count = num_enhanced_watermark EnMajorInt = TRUE DisAutoHwRequest = TRUE I understand that the current RTD implementation performs a finite DMA transfer and then stops, requiring FlexCAN_Ip_RxFifo() to be called again. My question is: Is it possible on S32K388 to configure the eDMA TCD so that the FlexCAN Enhanced RX FIFO DMA request continuously transfers received FIFO elements into a circular RAM buffer, without any CPU interrupt or software re-arming? In particular, can Destination Modulo and/or another eDMA TCD feature be used to implement this continuous ring buffer? If this is possible, could you please provide an example configuration or point me to an NXP example/reference implementation? I am willing to modify the RTD FlexCAN driver or configure the eDMA TCD directly if necessary. Thanks! Re: #S32K388 Enhanced RX FIFO + eDMA: Continuous Circular Buffer Reception Without CPU Interrupts Hello @zhangyu5454, The driver is written in a way that requires FlexCAN_Ip_RxFifo() to be called in order to re-arm reception inside the FLEXCAN_EVENT_DMA_COMPLETE event. It should be possible to have a continuous transfer from DMA to buffer; however, you will need to modify the RTDs or create your own driver. Unfortunately, this is out of our support scope, and if done, verification and functionality should be tested by you. You would have to set TCDn_CSR[D_REQ] = 0 (DisAutoHwRequest = FALSE) & TCDn_CSR[INTMAJOR] in order to keep the channel armed and disable interrupts, as well as configure your circular data queue. You can refer to S32K3's DMA Training Presentation, under S32K3 Product Page and 'Secure Files'. Best regards, Julián
查看全文
KW45B41Z-EVKへのAI/MLの実装 こんにちは、NXPコミュニティの皆さん、 私はKW45B41Z-EVK(Cortex-M33)向けのエッジAIアプリケーションを開発しており、このボード上で機械学習モデルを展開する際にアドバイスをいただきたいです。 KW45 SDKにはデフォルトでeIQ/TFLMミドルウェアが含まれていないため、私の計画は以下の通りです: モデルトレーニング:eIQ Time Series Studio(eIQ TSS)を用いて時系列データのnクラス分類モデルを訓練します。KW45はeIQ TSSのターゲットとしてリストされていないため、モデルをエクスポートするターゲットプラットフォームとしてFRDM-MCXN947(Cortex-M33)を選択しました。 ランタイムデプロイ:FRDM-MCXN947 SDKのmiddleware/eiq/tensorflow-liteフォルダを私のKW45 SDKプロジェクトにポートし、CMSIS-NNと連携させます。 私の質問: MCXN947 SDKからKW45 SDKへのeIQ TFLMミドルウェアの移植は有効でサポートされている方法でしょうか? eIQ TSSでFRDM-MCXN947を選択することは、KW45上で動作するモデルを生成するのに適していますか? KW45B41Z-EVKにAI/MLを実装するための、他に推奨されるワークフローやネイティブなワークフローはありますか? ご協力いただきありがとうございます! KW45B41Z-EVK KW45 EIQ-TFLITE-MICRO EIQ-ツールキット#AIML Re: Implementing AI/ML on KW45B41Z-EVK こんにちは、お元気でお過ごしでしょうか。 eIQ Time Series Studio (TSS) を使用している場合は、FRDM-MCXW71 からプロジェクトを移植することをお勧めします。eIQ TSSで公式にサポートされているターゲットであり、KW45ともソフトウェア互換性があります。両デバイスは同じCortex-M33コアアーキテクチャと似たメモリプロファイルを共有しているので、生成されるライブラリはあなたのハードウェアにかなり近いはずです。 FRDM-MCXN947のようにハードウェアプロファイルが大きく異なるデバイスをポーティング対象として使用する場合、両デバイス間の利用可能なRAMの違いや、MCXN947特有のNPU加速モデルの生成などにより互換性のないモデルを生成するリスクがあります。 お役に立てば幸いです! よろしくお願いします、 ソフィア。
查看全文
MCU SDKにI2Cドライバを追加 NXPチームの皆様、こんにちは。 MCU SDKに24cxxシリーズのeeprom i2cドライバを追加したいと考えています。どうやって追加できるのでしょうか? ありがとうございます。 Re: Add I2C driver to MCU SDK こんにちは、 @taw さん。 あなたが共有してくれた情報からすると、カスタムSDKを探しているのだと思います。 このプロセスは使っているIDEによって異なります。 MCUXpresso for VS Codeについては、以下のドキュメントを参照してください。 MCUXpresso SDK:カスタムマニフェストの作成 MCUXpresso IDEについては、以下のドキュメントを参照してください。 カスタム基板サポートパッケージの作成 |NXP半導体 もしこれがあなたの言及でなければ、申請の詳細を教えていただけますか? よろしくお願いします、 パブロ
查看全文
向MCU SDK添加I2C驱动程序 您好,NXP团队, 我们希望在MCU SDK中添加我们的24cxx系列eeprom i2c驱动程序。我们该如何添加它? 谢谢 & 此致敬礼, Re: Add I2C driver to MCU SDK 嗨@taw , 根据您提供的信息,我推测您正在寻找定制的 SDK。 具体过程取决于您使用的集成开发环境 (IDE)。 对于 VS Code 版 MCUXpresso,您可以参考以下文档: MCUXpresso SDK:创建自定义清单 对于 MCUXpresso IDE,您可以参考以下文档: 创建定制板支持包 | 恩智浦半导体 如果您指的不是这个,请您提供更多关于您的请求的详细信息好吗? 此致, 巴勃罗
查看全文
Plumber Fairfield CA Fast & Reliable Local Plumbers Plumber Fairfield CA provides professional plumbing services for homeowners and businesses dealing with everyday plumbing needs and unexpected emergencies. From leaking faucets and clogged drains to water heater problems and damaged pipes, having access to a dependable local plumber can help prevent small plumbing issues from becoming more serious and costly. The main idea behind choosing a Plumber Fairfield CA is simple: get reliable local help when you need plumbing repairs, maintenance, or emergency assistance. Professional plumbers can diagnose plumbing problems, recommend the appropriate solution, and complete repairs using the right tools and techniques. Whether you are dealing with a slow drain, a hidden leak, low water pressure, sewer problems, or a water heater issue, a qualified plumber in Fairfield, CA can help keep your residential or commercial plumbing system working properly.
查看全文
S32DS activation code expired Hi: My license of S32 Design Studio for S32 Platform v.3.4 is about to expire. Could you help check and extend it for me?  Activation code: 533B-878B-88A9-C68F Thanks. Re: S32DS activation code expired Hi,  your S32DS license has been extended. 
查看全文
S32DS激活码已过期 您好: 我的S32 Design Studio for S32 Platform v.3.4许可证即将到期。 您能帮我检查并延长一下吗? 激活码:533B-878B-88A9-C68F 谢谢。 Re: S32DS activation code expired 你好, 您的S32DS许可证已延期。
查看全文
科罗拉多州洛夫兰市水管工常见管道问题及何时寻求帮助 最后更新日期:2026年9月9日(官方网站链接见评论框) Loveland Co 管道公司指的是科罗拉多州 Loveland 市提供的专业管道服务,旨在帮助房主和企业处理常见的管道需求。从水龙头漏水、排水管堵塞到热水器问题以及更复杂的管道维修,经验丰富的管道工可以提供切实可行的解决方案,使管道系统正常运转。这就是为什么在科罗拉多州洛夫兰市选择一位可靠的水管工,以便在需要及时可靠的服务时非常重要的原因之一。 Plumber Loveland Co 的主要理念很简单:为客户提供专业的管道服务,包括日常维修、维护、安装和突发的管道问题。合格的当地水管工可以帮助找出问题的原因,推荐合适的解决方案,并安全高效地完成必要的工作。无论您需要小修小补还是大型管道工程方面的帮助,拥有值得信赖的管道专业人员都能帮助保护您的财产,并保持您家中管道系统的顺畅运行。
查看全文
HSE: Error code 0x67030001 after first two resets following MU install I have followed the install procedure for installing through MU interface in FULL_MEM mode, as described in section 3.2.3.1 in Firmware Reference Manual version 2.7. Installing works exactly as described, but when I perform a functional reset (step 7) I get HSE error code 0x67030001. This persists after a second reset but reliably goes away after a third. I have a few questions: Is the particular value of uppermost bits (0x6703) significant? What could cause the HSE driver to enter an error state on startup but recover following exactly two resets? What is the most likely cause for the error in the first place? Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  As indicated in the HSE_B Firmware Reference Manual, the GSR register logs fatal and warning events in its 16 least significant bits: Bits 0-7 indicate fatal errors. Bits 8-15 indicate warnings (non-fatal failures). The 16 most significant bits are reserved for NXP internal errors. Since bit 0 is set on your device, this indicates that a fatal error occurred, causing the HSE to shut down. In this state, a device reset is required to recover and exit the shutdown mode. Could you please share the values of the FSR register and HSE_CONFIG_GPR3 (0x4039C028)? Also, after performing the reset, did you wait until the HSE_STATUS_INIT_OK flag in GPR3 was set? Additionally, in the thread S32K3 recovery issue when install HSE fw via MU, a demo for HSE firmware installation via MU was shared. It may serve as a useful reference. BR, VaneB Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  Resets 1 & 2: FSR = 0x00400000. Bit 24 (HSE_STATUS_INIT_OK) is not set, which indicates that HSE had not yet completed its initialization. The GSR value 0x67030001 shows that bit 0 (HSE_ERR_GENERAL) is set, which triggered an HSE sub-system shutdown. Reset 3: FSR = 0x09600000. Bit 24 (HSE_STATUS_INIT_OK) is now set, indicating that HSE completed its initialization successfully. The GSR value0x00000000 shows that no HSE errors/warnings were reported. A possible cause of this behavior could be that the application is performing clock initialization, XRDC configuration, or Flash operations before HSE initialization is fully completed. Re: HSE: Error code 0x67030001 after first two resets following MU install After the first two resets the values were as follows: HSE_CONFIG_GPR3: 0x10000081 DCMRWP1: 0xA5000400 GSR: 0x67030001 FSR: 0x00400000 Then after the third reset values were: HSE_CONFIG_GPR3: 0x000000C1 DCMRWP1: 0xA5000400 GSR: 0x00000000 FSR: 0x09600000   Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  Regarding XRDC, refer to the note in Section 14.6.3 of the HSE_B Firmware Reference Manual, Rev. 2.7. For clock initialization, the relevant information can be found in Section 2.4.2.3.3 of the same document. Re: HSE: Error code 0x67030001 after first two resets following MU install Thank you, I'm looking into flash synchronization now. I was not aware that clock or XRDC init could affect HSE startup, where is this described?
查看全文
POWER consumption at runtime on NXP i.MX93 & i.MX8MPLUS EVK I am using NXP i.MX93 & i.MX8MPLUS EVK and want to monitor the POWER consumption at runtime how can I get this data ? The agenda is to monitor the power during the inference of AI-models. How can I monitor the power metrics ?  How can I monitor power metrics using only software, without any external hardware? Re: POWER consumption at runtime on NXP i.MX93 & i.MX8MPLUS EVK Thank you for this detailed information and reference to ANI3054. This is very helpful. Does the i.MX93 EVK also have a similar power measurement setup , or is there a different approach recommended for i.MX93? Re: POWER consumption at runtime on NXP i.MX93 & i.MX8MPLUS EVK Please refer to the document AN13054 i.MX 8M Plus Power Consumption Measurement To measure the power consumption, the PWR CPU board is designed with current sense resistors of suitable value inserted between the PMIC and CPU for each key power rail. The power data is obtained by sampling the average voltage drop across the sense resistors using power monitor chip PAC1934. The voltage drop for each power supply is divided by its sense resistor value within the BCU PC software tool to calculate the current.
查看全文
LSDK 21.08 OP-TEE breaks boot Custom board using LS1043AE have it secure booting just fine with no OP-TEE. Trying to introduce OP-TEE to the system and console outputs and hangs at: NOTICE: 2 GB DDR4, 32-bit, CL=11, ECC off NOTICE: BL2: v2.4(release):LSDK-21.08-1-ga08bfddba-dirty NOTICE: BL2: Built : 22:39:20, Aug 31 2026 NOTICE: Initializing & configuring SEC block. NOTICE: Sec is already initialized and configured. NOTICE: Verifying RSA NOTICE: Verifying hash NOTICE: Verifying RSA NOTICE: Verifying hash NOTICE: Verifying RSA NOTICE: Verifying hash NOTICE: BL2: Booting BL31 NOTICE: BL31: v2.4(release):LSDK-21.08-1-ga08bfddba-dirty NOTICE: BL31: Built : 22:39:48, Aug 31 2026 NOTICE: Welcome to ls1043aerb BL31 Phase According to Google/Gemini it thinks there is a problem with GIC. ATF and OP-TEE appear to be using 64k page aligned, but in a uboot dts it has it at a 4k page aligned. I don't think it's this issue, or at least not yet. Because it doesn't appear to Initialize OP-TEE at all. Thoughts? QorIQ LS1 Devices Re: LSDK 21.08 OP-TEE breaks boot It seems that there is problem with your u-boot. Would you please try whether it can work to boot normal u-boot(not secured) with OPTEE enabled? Re: LSDK 21.08 OP-TEE breaks boot I don't mind trying that, but what is that testing for? What are you currently thinking is possibly wrong with uboot? Since it works without optee I'm curious as to what could be wrong or what I should look for? Re: LSDK 21.08 OP-TEE breaks boot What I would check first: Rebuild TF-A in debug mode and confirm the exact stop point. Use DEBUG=1 LOG_LEVEL=50 if practical, or add NOTICE() breadcrumbs in early BL31 platform code around: platform setup entry GIC init TZC/TZASC/TZPC setup secure payload dispatcher / OP-TEE setup BL32 entry-point preparation NXP support guidance for similar LS1043A hangs is to add ATF/U-Boot debug prints or use CodeWarrior/JTAG to inspect where execution is stuck. Verify the FIP actually contains BL32 and that BL31 was built with OP-TEE support. For OP-TEE in TF-A, the build must include SPD=opteed and BL32=  ; for secure boot/NXP CoT, the secure TF-A build flow also includes TRUSTED_BOARD_BOOT=1 , CST_DIR=... , BL32=$TEE_BIN , SPD=opteed , and BL33=$UBOOT_SECURE_BIN . Run something like:  fiptool info fip.bin and confirm BL31, BL32/OP-TEE, and BL33 are all present. If BL32 is missing or BL31 was not built with SPD=opteed , OP-TEE will never be entered. Check LS1043A secure-boot reserved-memory handling. There is a reported LS1043A secure-boot issue fixed by changing plat/nxp/soc-ls1043a/soc.def NXP_ROM_RSVD from 0x5900 to 0x8000 . Since you are already secure-booting and now adding another signed FIP component, this is worth checking early. It is more plausible than a later U-Boot DTS GIC alignment issue. Do not assume “RSA/hash verified” means the image layout is good. Your BL2 log proves authentication reached success for the components it validated, but it does not prove the runtime addresses, reserved-memory overlap, BL32 load address, or BL31 secure-payload configuration are correct. BL2 is documented as loading BL31/BL32/BL33 to DDR after validation before handing control to BL31. If the hang moves to BL31: Initializing BL32 , then shift focus to OP-TEE proper. At that later stage I would look at OP-TEE load address, secure DDR carveout, pager/non-pager layout, CAAM/SEC configuration, and OP-TEE console. There is NXP guidance in a related OP-TEE/crypto context to try disabling crypto/CAAM in OP-TEE with CFG_NXP_CAAM=n and CFG_CRYPTO_DRIVER=n when early OP-TEE crypto initialization is suspected. But your current log does not yet prove OP-TEE is being entered. My strongest hypothesis: BL31 is built/configured differently when OP-TEE is enabled and is hanging in early BL31 platform/SPD setup before the OP-TEE banner or BL32 entry. I would first instrument BL31 around GIC/platform setup and verify FIP/ SPD=opteed / BL32=tee.bin /secure-boot CSF layout, then check the LS1043A NXP_ROM_RSVD=0x8000 issue. Re: LSDK 21.08 OP-TEE breaks boot So I built atf with debugging and the final message I get before silent hang is: INFO: BL31: Initializing BL32 So if I understood your recommandation correctly, I should focus on OP-TEE specifically now, correct? Re: LSDK 21.08 OP-TEE breaks boot Yes, please verify OP-TEE with normal boot(not secured) first to make sure there is no problem with your building and deployment procedure with OP-TEE. Re: LSDK 21.08 OP-TEE breaks boot I believe I was using the wrong tee.bin. I was using the tee.bin that was generated during a manual build of OP-TEE and not the objcopy version I needed to generate. That appears to allow the system to initialize and boot into linux. I do have more kernel logging messages about optee that I need to look into, but I will close this thread because this specific issue is resolved.
查看全文
ハードウェアシミュレーションには、システムVerilogやVAMS、またはPCA9698DGG,512(GPIOエキスパンダー)のspiseモデルが必要です。 システム用Verilog、VAMS、またはIOエクスパンダーの部品番号のSPICEモデルが必要です - PCA9698DGG,512。重要な業務に必要なため、至急ご提供ください。 データシートリンク - PCA9698 40ビットFm+ I2Cバス:RESET、OE、INT対応の高度なI/Oポート
查看全文
关于 QNX 7.1 上 S32G274A PFE 的 PTP/IEEE 1588 支持和配置指南的请求 专家您好! 我们计划在我们定制的 S32G274A 板的 PFE 以太网接口上实现 IEEE 1588/PTP 时间同步。 我们目前的软件配置如下: - SoC:NXP S32G274A - 电路板:基于 S32G274A 的客户电路板 操作系统:QNX 7.1 - PFE驱动程序:PFE-DRV_S32G_A53_QNX 1.9.0,io-pkt版本 - PFE固件:PFE-FW_S32G 1.12.0 - 正在测试的 PFE 接口:PFE EMAC0 和 PFE EMAC2 - 由于 PFE EMAC1 的外部 AQR113C PHY 的固件尚未编程,因此当前测试中未包含 PFE EMAC1。 我们检查了 PFE 驱动程序源代码,发现它包含 IEEE 1588 支持,并实现了以下 QNX 驱动程序特定的 PTP 命令: - PTP_GET_TIME - PTP_SET_TIME - PTP_GET_TX_TIMESTAMP - PTP_GET_RX_TIMESTAMP - PTP_SET_COMPENSATION - PTP_GET_COMPENSATION 当前默认版本配置禁用了此功能: PFE_CFG_IEEE1588_SUPPORT=0 PFE_CFG_IEEE1588_I_CLK_HZ=0 PFE_CFG_IEEE1588_EMAC0_O_CLK_HZ=0 PFE_CFG_IEEE1588_EMAC1_O_CLK_HZ=0 PFE_CFG_IEEE1588_EMAC2_O_CLK_HZ=0 我们的启动代码已经通过 SCMI 启用了 PFE_TS 时钟,但我们还没有在 PFE 驱动程序中配置 IEEE 1588 输入和输出时钟频率。 请问您能否就以下问题提供指导? 1.在 QNX 7.1 上使用 PFE-DRV 1.9.0 和 PFE-FW 1.12.0 时,S32G274A 上的 PFE EMAC0/EMAC1/EMAC2 是否正式支持 IEEE 1588 硬件 TX 和 RX 时间戳? 2. S32G274A 的预期 SCMI PFE_TS 时钟频率是多少? 3. 以下构建参数建议取哪些值? PFE_CFG_IEEE1588_I_CLK_HZ PFE_CFG_IEEE1588_EMAC0_O_CLK_HZ PFE_CFG_IEEE1588_EMAC1_O_CLK_HZ PFE_CFG_IEEE1588_EMAC2_O_CLK_HZ 4. 这三个 PFE EMAC 是否共享同一个 PTP 硬件时钟,还是每个 EMAC 都有一个独立的 PTP 系统时间计数器? 5. 此驱动程序支持哪些 PTP 传输模式? - 二层点对点传输协议 (PTP),以太网类型 0x88F7 - UDP/IPv4 - UDP/IPv6 一步式时间戳 - 两步时间戳 端到端延迟机制 - 点对点延迟机制 6.启用 PTP 是否需要任何额外的 PFE 固件配置、固件功能、FCI 配置或启动初始化? 7. NXP 或 QNX 是否有推荐的用户空间 PTP 守护程序或适用于此 PFE 驱动程序的示例应用程序?当前驱动程序通过 netdrvr/ptp.h 公开 PTP 功能。并且是 SIOCGDRVSPEC/SIOCSDRVSPEC,而不是 Linux 风格的 /dev/ptpX PHC 设备。 8. 是否存在与以下方面相关的已知勘误、限制或所需的初始化顺序: - PFE 时间戳时钟初始化; - 通过 HIF 进行 TX/RX 时间戳交付; - 时间戳补偿; - 在多个 PFE EMAC 上同时进行 PTP 操作? 如果可以的话,能否提供 QNX 系统下 S32G274A PFE 芯片上符合 IEEE 1588 标准的参考配置、示例应用或验证程序? 感谢您的支持。 BR, 怀特旺 Re: Request for PTP/IEEE 1588 Support and Configuration Guidance for S32G274A PFE on QNX 7.1 您好,专家 感谢您提供如此详细的信息。我们已经验证了 PFE0 和 PFE2 上的 PTP 时间和补偿接口在 PFE-DRV 1.9.0 和 PFE-FW 1.12.0 下能够正常工作。 在关闭此 NXP PFE 支持案例之前,能否请您澄清以下三个与 S32G274A 相关的具体问题? 1. 我们目前对启用的 EMAC 使用 PFE_CFG_IEEE1588_I_CLK_HZ = 200 MHz 和 50 MHz 输出时钟。这种配置是否得到官方支持和推荐? 2. 每个 PFE EMAC 是否有独立的 IEEE 1588 定时器,还是可以将一个 EMAC 配置为与另一个 EMAC 共享时间基准? 3.所需的 400 MHz XBAR 时钟配置在哪里?可以使用哪个寄存器或运行时指示来验证它? Re: Request for PTP/IEEE 1588 Support and Configuration Guidance for S32G274A PFE on QNX 7.1 嗨,韦特旺 感谢您与我们联系。希望以下信息对您有所帮助! 1.IEEE 1588 时间戳功能(AAVB-2500)首次在 BETA_0.9.0 中引入。请注意,原始记录为 [PFE_QNX_DRIVER] 添加 IEEE1588 时间戳支持。(请参阅 PFE-FW_S32G_1.12.0_ReleaseNotes.pdf。)您的软件版本符合兼容性要求。 Joey_z_1-1788772191193.pngJoey_z_1-1788772191193.png Joey_z_0-1788772167682.pngJoey_z_0-1788772167682.png 2. PFE_TS 的时钟由 GMAC_TS_CLK 提供,范围为 5-200 MHz。最小值需要根据设定的模式来确定。 Joey_z_2-1788772339124.pngJoey_z_2-1788772339124.png Joey_z_3-1788772351660.pngJoey_z_3-1788772351660.png 3. 需要根据 GMAC0_TS_CLK 的值进行设置。请参考以下内容。 Joey_z_4-1788772395380.pngJoey_z_4-1788772395380.png 4. 是的,您可以参考下图。 Joey_z_5-1788772417926.pngJoey_z_5-1788772417926.png 5. 从代码和文档信息来看,PTP 在技术上统一标识传输层,支持(UDP/IPv4、UDP/IPv6、第 2 层 PTP),支持两步和 E2E/P2P。 6. 请注意以下事项:为确保时间戳功能可靠运行,XBAR 时钟频率需设置为 400 MHz,具体请参阅 S32G 参考手册。PFE_CFG_IEEE1588_EMACn_O_CLK_HZ 的值必须小于 PFE_CFG_IEEE1588_I_CLK_HZ。在执行加载过程之前,必须确认以下事项:所有相关的时钟、电源/复位以及 PFE 引脚均已按照 S32G 参考手册进行配置,并且固件二进制文件 s32g_pfe_class.fw 已部署到目标板。 7. 我们很抱歉,恩智浦半导体没有为QNX PFE驱动程序提供现成的PTP守护程序或示例应用程序。 8. 请参阅附件中的以下内容: PFE-DRV_S32G_QNX_1.9.0_发行说明.pdf/4已知问题 PFE-DRV_S32G_QNX_1.9.0_UserManual.pdf/5.2局限性 PFE-DRV_S32G_QNX_1.9.0_UserManual.pdf/5用法 我们目前不提供专用的应用示例。建议参考以下文档中的相关信息。(PFE-DRV_S32G_A53_QNX_1.9.0\doc) BR 乔伊 Re: Request for PTP/IEEE 1588 Support and Configuration Guidance for S32G274A PFE on QNX 7.1 嗨,维特旺 感谢您的回复。 1.根据 S32G RM,建议输入时钟为 100MHz。PFE_CFG_IEEE1588_EMACn_O_CLK_HZ 值必须小于 PFE_CFG_IEEE1588_I_CLK_HZ。 Joey_z_0-1788848856306.png 2.PFE EMAC 支持两种时间戳模式,内部时间戳模式和外部时间戳模式。详细信息请参阅 PFE-DRV_S32G_QNX_1.9.0_UserManual.pdf 的第 6.4.1 章“配置和启用 IEEE1588 定时器”。 3. XBAR时钟将在 ATF 中进行配置;您可以使用 uboot 中的“clk dump”命令来检查它。 希望这些信息对您有所帮助。 BR 乔伊
查看全文
i.MX8M Plus:同时运行 VIP8000 时出现间歇性帧向下偏移和绿色顶带闪烁 1. 系统和环境 参数配置 SoC NXP i.MX 8M Plus 四核处理器 芯片版本 A1 / B0 核心 6.12.20-lts-next-g604d4ef7a1e4 BSP NXP linux-imx / LTS-Next Vivante / Galcore 司机 6.4.11.p3.1049711 Galcore 位置 drivers/mxc/gpu-viv/galcore(内置) 2D引擎 Vivante GC520L (imxvideoconvert_g2d / libg2d.so) 纳米物理大学 VeriSilicon/Vivante VIP8000 NPU性能 2.3 顶级 视频编码器 Hantro VC8000E (v4l2h264enc) 内存 约 5.7 GB LPDDR4 CMA 总计 约960 MB 2. 问题描述 我们观察到,当VIP8000 NPU 推理与使用 GC520L G2D 引擎的硬件缩放/颜色转换同时运行时,会出现间歇性视频损坏问题。 受影响的 H.264 流不会完全变成绿色。相反,个别帧偶尔会出现以下情况: 当前图像似乎向下移动了少量像素/扫描线。 画面顶部出现一条水平的绿色条带。 下一帧立即恢复到正确位置。 结果是画面间歇性向下跳帧/绿色顶部边缘闪烁。 该问题在并发加速器工作负载期间可以重现,但当单独测试 NPU 或 G2D 工作负载时则无法可靠地重现。 3. 主要观察结果 3.1 仅 G2D 工作负载稳定 我们可以同时运行最多三个 G2D 视频分支: 主屏幕:1080p 字幕:360p MJPEG:480p 已禁用NPU。 视频长时间保持稳定,未观察到绿帧或帧偏移。 3.2 仅使用 NPU 的工作负载稳定 当 G2D 处理不活跃时,VIP8000 NPU 的重型推理以大约15–30 FPS 的速度持续运行,没有观察到推理错误或视频损坏。 3.3 用 CPU 处理代替 G2D 处理可以消除该问题。 当硬件 G2D 处理被以下方式取代时: videoscale ! videoconvert 即使 NPU 持续满负荷运行,系统仍保持稳定。 不再出现绿带/帧偏移问题。 3.4 并发 NPU + G2D 会触发该问题 当 NPU 处于活动状态且 G2D 同时用于视频/AI 处理时,就会出现数据损坏。 引入额外的 G2D 工作负载时,频率会增加。 这表明该问题与并发加速器活动有关,而不是与单个 NPU 或 G2D 工作负载本身有关。 4. 测试矩阵 我们进行了以下测试以找出故障原因。 测试 NPU AI 处理视频 G2D 结果 1 关 无 主 + 子 + MJPEG(3 个 G2D 分支) 通过——无闪烁 2 关 SHM附件 主字幕 + MJPEG 通过——无闪烁 3 ON 状态 G2D 功能 主要 G2D 故障——观察到间歇性绿带/帧偏移 4 ON 状态 CPU(视频缩放!视频转换) 主要 G2D 通过——主流清洁 5 ON 状态 CPU 主+子 G2D 失败——当引入额外的 G2D 工作负载时出现此问题。 6 ON 状态 CPU 所有视频分支均已转换为 CPU 缩放 通过——所有溪流均保持清洁 注意:我们目前正在准备一个较小的独立组网 \\(SA\\) 复现程序,以确定触发该问题所需的最小并发 G2D 客户端数量。 5. 当前调查 根据以上结果,我们想了解这种行为是否可能与以下某个领域有关。 A. Galcore / 加速器并发 在我们的设备树中,GPU/NPU 组件是同一个 GPU/ML 子系统的一部分: mix_gpu_ml@40000000 { compatible = "fsl,imx8mp-gpu", "fsl,imx8-gpu-ss"; cores = <&gpu_3d &ml_vipsi &gpu_2d>; reg-names = "phys_baseaddr", "contiguous_mem"; memory-region = <&gpu_reserved>; }; 中断也由 galcore 处理: 34: 520 0 0 0 GICv3 35 Level galcore:0 35: 13583 0 0 0 GICv3 45 Level galcore:3d-1 36: 1737916 0 0 0 GICv3 57 Level galcore:2d 我们想了解: galcore 是否在 GC520L、GC7000 和 VIP8000 之间共享同步原语或锁? G2D 和 NPU 命令队列是否完全独立? 当 VIP8000 推理处于活动状态时,多个 G2D 客户端/进程提交工作是否存在任何已知限制? 在并发工作负载下,命令提交、上下文管理、中断处理或资源锁定是否会引入延迟? B. 片上网络/DDR带宽或服务质量 GC520L G2D 和 VIP8000 NPU 都是主动总线主控器,可访问外部 LPDDR4 内存。 我们想确定高负载NPU推理是否可能: 大幅增加NoC/DDR流量。 增加 G2D 的内存访问延迟。 导致 G2D 交易延迟。 找出 G2D 与下游消费者之间的时序/同步问题。 受NoC/DDR QoS优先级的影响。 NXP能否就i.MX8MP上可用于调查此类工作负载的推荐NoC/AXI/DDR性能监控和QoS功能提供指导? C. G2D 缓冲区同步/栅栏/步长问题 这种视觉瑕疵特别有趣,因为整个画面并没有损坏。 受影响的帧大致如下所示: +----------------------------------+ | GREEN HORIZONTAL BAND | +----------------------------------+ | | | | | IMAGE SHIFTED DOWN | | | | | +----------------------------------+ 这让我们不禁怀疑,这个问题是否可能涉及以下方面: G2D目标缓冲区同步。 DMA-BUF 所有权/重复使用。 围栏信号/完工。 临时 G2D 目标偏移/步长状态。 G2D内存写入延迟。 在 G2D 操作完全完成之前,下游 VPU 访问就已经发生。 具体来说,延迟的 G2D 完成或同步事件是否会导致 v4l2h264enc / VC8000E 在所有 G2D 写入完成之前消耗目标 DMA-BUF? NXP G2D/V4L2 流水线中是否存在已记录的同步机制,以保证在 VPU 消耗目标 DMA-BUF 之前 G2D 完成? D. 内存 / CMA 我们在重现问题时监控了内存使用情况: Total RAM : ~5.7 GB CmaTotal : ~960 MB CmaFree : ~677 MB 因此,在故障期间,CMA 并未接近耗尽。 但是,我们想了解是否还有其他与内存相关的因素会影响并发的 NPU/G2D/VPU 工作负载,例如: DMA-BUF 同步。 缓存一致性。 内存功能域映射。 物理缓冲区对齐。 缓冲区重复使用。 IOMMU/MMU映射。 保留内存交互。 6.其他诊断实验 我们目前正在准备一个最小的独立组网 (SA) 复现程序,以消除应用程序层面的复杂性。 计划中的复制器将包含: Thread 1 → VIP8000 NPU inference Thread 2 → GC520L G2D processing Thread 3 → Additional GC520L G2D processing 我们还计划测试以下配置: NPU OFF + G2D NPU ON + G2D NPU ON + 2 × G2D NPU ON + G2D → buffer inspection NPU ON + G2D → VPU encoder 这应该有助于确定损坏是发生在 G2D 输出缓冲区本身,还是仅在缓冲区被 VPU 消耗之后才发生。 7. 向恩智浦提出的问题 我们希望恩智浦能就以下方面提供指导。 1. 已知的硬件/软件限制 是否同时进行以下操作: VIP8000 NPU + GC520L G2D + VC8000E VPU i.MX8M Plus 完全支持,包括多个同时运行的 G2D 客户端? 对于这种组合,是否存在已知的硬件限制、勘误或软件限制? 2. Galcore VIP8000 和 GC520L 同时运行时是否存在已知的 galcore 问题? 具体而言,是否存在以下方面的已知问题: 共享锁 命令队列, 上下文切换, 中断处理 同步, 或者资源管理? 3. DMA缓冲区/同步 在下游 V4L2/VPU 组件消耗目标 DMA-BUF 之前,使用什么机制来保证 G2D 完成? 在并发加速器工作负载下,imxvideoconvert_g2d / libg2d 是否存在已知的围栏或缓冲区所有权问题? 4. 片上网络/服务质量 NXP 推荐使用哪些调试寄存器、调试文件系统节点、性能计数器或工具进行测量? GC520L AXI 流量, VIP8000 AXI 流量, VPU流量, DDR带宽, NoC 争议, 以及服务质量/仲裁行为? 5. 驱动程序版本 我们目前使用的是: Kernel: 6.12.20-lts-next-g604d4ef7a1e4 Galcore: 6.4.11.p3.1049711 这种组合是否是 i.MX8MP 的验证/推荐配置? 是否有更新的 galcore / G2D 驱动程序或补丁集可以解决并发 NPU/G2D 工作负载的问题? 6. 硅勘误表 请问我们A1/B0版本的i.MX8M Plus芯片勘误表中是否存在以下问题? G2D, VIP8000 VPU, AXI/NoC仲裁, DDR, 缓存一致性 或者同时进行加速器操作? 7. 推荐配置 对于需要以下条件的应用程序: VIP8000 NPU inference + multiple G2D scaling/color-conversion pipelines + VC8000E H.264 encoding NXP推荐哪种配置? 是否有具体规定: 驱动程序参数 QoS设置, 内存/缓冲池配置, 同步机制 或 GStreamer 流水线实践 应该遵循什么? 8. 我们可以提供的信息 如有需要,我们可以提供以下服务: 完整的 GStreamer 流水线。 设备树配置。 内核配置。 重现过程中的 dmesg 输出。 /proc/中断。 G2D/NPU 工作负载详情。 v4l2-ctl 信息。 最小 NPU + G2D 复现器。 包含损坏帧的视频样本。 驱动程序版本和内部版本信息。 我们非常感谢您提供任何关于推荐的调试程序或附加跟踪/寄存器的指导,以帮助确定根本原因是否与G2D/NPU 同步、DMA-BUF/fence 处理、NoC/DDR 竞争、galcore 或芯片限制有关。 谢谢! 毗湿奴 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano
查看全文