Audifort Review: Does It Really Stop Tinnitus Overnight? Audifort Review: Does It Really Stop Tinnitus Overnight? If you are dealing with a non-stop ringing, buzzing, or clicking sound in your ears every single day, you know how desperate the search for relief can get. When looking for solutions online, you may come across aggressive advertisements for liquid dietary drops like Audifort that imply instant results or overnight relief from tinnitus. The short answer is no: Audifort does NOT stop tinnitus overnight. No oral supplement or natural drop can instantly cure chronic tinnitus or rebuild damaged auditory nerves in 24 hours. However, that does not mean the formula is useless. When evaluated realistically as a natural dietary supplement rather than a miracle cure, Audifort provides supportive nutrients that nourish inner ear blood vessels and calm overactive nerve signals over time. In this Audifort review, we look beyond the sales marketing to analyze how the drops actually work, its core ingredients, realistic expectation timelines, potential side effects, and how to avoid fake online listings.

i.MX95 Neutron:同じINT4 LLMで4問中1回答でNPU/CPUの不一致が発生します 概要 i.MX95 上で量子化された ONNX を 1 つ実行します。1 つは CPUExecutionProvider の下、もう 1 つは ニュートロン実行プロバイダー。2つの腕は同じ答えを出しません:2,466対 選択式問題では25.7%が異なる答えを返します(MMLUでは43.6%)。無料で 世代ごとに同じことが起こります - MMLU プロンプトでは、19 世代のうち 13 世代で 異なる回答の手紙。 これは言葉遣いの違いではありません。それはモデルが答える内容の違いです。一方、総合的なベンチマーク精度はわずか-1.8ポイントの変動にとどまった。 私たちは、Neutronランタイムが数値的に何をして生成するかを理解したいのです この大きさが予想されるかどうかも重要です。 設定 あなたの側で再現可能:モデルは表2からUG10166、量子化は 自分だけのレシピ、修正なし。 - ボード:i.MX95 19x19 EVK(IMX95LPD5EVK-19)、LPDDR5 - BSP: LF6.18.2_1.0.0、デバイスツリー imx95-19x19-evk-neutron.dtb - ランタイム:BSP + NeutronExecutionProviderからのONNX Runtime 1.22.0 - Neutron コンバータ:3.1.3 - モデル:meta-llama/Llama-3.2-1B-Instruct - 量子化:NXP/eiq-olive rev aae820e、 例/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 変換:convert_ort_models_to_neutron.py、CPU Armのモデルに適用されます。onnx - 環境: NEUTRON_CMA_512SLOTS=6 両方のArmは1つの量子化されたモデルから来ています。NPUアームはそのモデルを通過させるものです convert_ort_models_to_neutron.py。ソースのSHA-256を記録します - グラフ と 外部重み - 換算時に測定し、測定のたびに再確認します。 2回目の量子化実行や2回目のエクスポートはありません。 私たちが観察すること 1.4つの項目のうち1つは異なる回答が得られる。 MMLU、ARC-Challenge、PIQAからの2,466組のペアアイテム、0ショット、対数尤度でスコアリング 候補者の継続については、候補者ごとに1つのフォワード、生成なし、サンプリングなし。 各ベンチマークについて、ANSWER が変化した項目の割合、次に、 正確性が変更されました: - MMLU（4つの選択肢）：回答変更率43.6%、正誤変更率27.1% - ARCチャレンジ（4つの選択肢）：回答変更率21.3%、正誤変更率13.3% - PIQA（2つの選択肢）：回答変更率9.4％、正誤変更率9.4％ - 合計：回答変更率25.7%、正誤変更率17.3% 2つの数字が異なるのは、変更の3分の1（634件中208件）が1つの間違いから移動しているためです。 別の間違った答えへの答え - 正確さを失わせる真の行動の変化 手つかず。PIQAはバイナリであるため、そのような盲点はなく、2つの数値は一致する。 その通り。 2. 自由生成の場合も同様で、答え自体が変わります。 プロンプト数50、貪欲解読、トークン数64。MMLUプロンプトでは期待される出力が始まります 回答文字を含んで、その答えは世代から直接読み取ることができます (n = 19): - 両Arm間で異なる回答文字:19件中13件 - CPUで正解:19中7 - Neutronで正解:19題中6題 - 両Armが間違っていて、異なる誤答が出る意見の相違:13回中6回 回答の3分の2が変わったが、点数はほぼ同じだった（7対6）。 サンプル数は少ないので、ここでは例として報告します。上記の2,466項目の測定結果 これは定量的なものです。 以下に、一字一句そのままの例を示します。プロンプトには 4 つの選択肢がリストされており、文字を求められ、 期待される答えは 😧 CPU: " A\n説明: 式 9(9m + 3t) は 81m + 27t と同等です。 正解はAです。 NPU：「C\n正解はCです。」 どちらも間違っているが、その間違い方は異なり、それを記録できるベンチマークスコアは存在しない。 3. 乖離は累積ではなく、最初のフォワードで発生します。 このレター形式では、最初に生成されたトークンが答えであり、生成の 60% が 既に違いが生じているのは、デコードを行う前の、プリフィルパスのみで生成されたトークンである。 ステップ。50のプロンプトすべてにおいて、乖離曲線は急激に上昇した後、平坦化する。84%は トークン4、トークン64による98%。これが初期差分の伝播の様子です 貪欲なデコードの場合、KVキャッシュを通じてエラーが蓄積されることはありません。 4. 集計精度はそれらすべてを隠してしまう。 CPUは50.28%、Neutronは48.50%、-1.78ポイント差、そして 3つのベンチマークは個別に重要です。634項目に限定して 意見は異なっています。CPUは37.1%の確率で正しかったのに対し、Neutronは30.1%、235%の確率で正解です。 決定された項目のうち191、すなわち対称ノイズが50/50となる場合、55/45です。 除外したもの - サイレントCPUフォールバック: ORTプロファイリングレポートでは、80/80 MatMulNBitsが NeutronExecutionProvider、CPU使用率0。部分的な配置はできません。 - 2つの異なるモデル:同じソースファイル、グラフのSHA-256および外部重み コンバージョン時に記録され、得点前に再確認されました。 - サンプリング: 全体を通して貪欲なデコード。温度、トップk、トップpは使用しません。 - 異なる入力:両方のアームが同じアイテムファイルを同じ順序で消費します。 同じ固定シードです。 - 成果物のスコアリング:ボードはトークンごとの対数確率のみを捉えます;すべての決定 ロジックはホスト側でオフラインで動作し、両アームで同じように動作します。 - NPUのラン・トゥ・ランノイズ:同じNeutronセッション内で同じ項目を再生すること ビット同一の対数確率が得られます。NPUアームは再現可能であり、その不一致 それはCPUに対してであり、自分自身に対してではありません。 私たちの質問 これはニュートロンSのINT4経路に期待される挙動でしょうか?もしそうなら、どのようにすべきでしょうか NPU上でのLLM展開を検証し、集計ベンチマーク精度を明確に示します 表面に浮かび上がらない? 私たちは欠陥を想定しているわけではありません。浮動小数点CPUカーネルと 整数のNPU経路は通常であり、どのくらいの大きさを考えているのか知りたいです 通常、そしてどの基準でNEUTRONへのLLMポートを受け入れますか?もし 回答の4分の1が変わるのは期待内であり、それは私たちにとって有益なことです 知っていて、それを中心に設計する。 Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 迅速なご回答ありがとうございます！ DS Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM こんにちは、 @DamienSCHNEBELEN さん。 IMX95 NPUはmatmulしか動作できず、NPUでのLLMのパフォーマンスは実際には平均的なレベルです。したがって、あなたが観察した現象は予測可能な範囲内であり、NPU上でLLMモデルを動かすことは推奨しません。 B.R

i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, I am using an i.MX RT1064 controller and debugging/flashing through the PEmicro Multilink interface in MCUXpresso IDE. Occasionally, I encounter the attached "PEmicro Connection Assistant" error while attempting to connect to the target. The issue appears to occur randomly; I have not identified any specific software activity, code change, or hardware event that consistently triggers it. What I have observed is that when this error occurs, the controller's boot configuration appears to have changed unexpectedly. In this state, I am unable to flash or debug the device. The only way I have been able to recover is by restoring the boot configuration to its original settings - Internal Flash Mode, after which flashing and debugging work normally again. A few additional details: MCU: i.MX RT1064 Debug Probe: PEmicro Multilink Universal Rev E IDE: MCUXpresso IDE Has anyone encountered a similar issue? I would appreciate any guidance on: What could cause the boot configuration to change unexpectedly. Whether there are known scenarios in which the debugger or application code could affect the boot configuration. Recommended methods to prevent this from happening. Can the boot configuration be changed through software without manual change I've attached a screenshot of the error message for reference. Thank you. i.MXRT 106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, Could you help me with the following questions? Are you using a custom board or the EVK? What version of the SDK and IDE are you using? Have you burned any fuses? You mentioned that you need to restore the boot configuration to internal flash mode—what boot configuration are you currently using? Best Regards, Pablo Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly I am using a custom board, but this issue was also observed on the EVK. SDK Version : 26.03.00 IDE Version : 25.6.136 We haven't burned any fuse. We usually use Internal Boot mode to flash our code and normal operation, but it causes some unexpected issues randomly, so we change it to Serial Download Mode, erase the flash and then change it back to Internal Boot mode before flashing code again. Please find attached image for boot configuration info. Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi @Subhasri_S, The BOOT_MODE register is initialized by sampling the BOOT_MODE0 and BOOT_MODE1 inputs on the rising edge of POR_B. After these inputs are sampled, their subsequent state does not affect the contents of the internal BOOT_MODE register. If BT_FUSE_SEL = 0, the specific boot configuration parameters can be set using the GPIO pins instead of eFuses. Could you help me measure the BOOT_MODE and BT_CFG pins during reset when the issue occurs? Another possible conclusion for this issue is described in the following knowledge base article: Knowledge Base : RT board recovery for debugger connect issues "When the flash contains an app that is abnormal(access memory does not exist, memory is corrupted, misconfiguration of the clocks, etc.), it will cause the board to end up in an unknown state, then the debugger can’t take control over the core. But, when put the core in serial downloader mode, then it will put the core in a known state, this way, the debugger will be able to take control of the core. So, when meeting the debugger issues in the RT board, try to mass erase the external flash in serial download mode, then it will recover the board debugger to a normal situation." Best Regards, Pablo Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, please find the recorded BOOT_MODE and BOOT_CFG Pin values when the issue occurs.

minimal configuration to negotiate higher current limit on USB I have a device that can be powered over USB with an MCXN947 processor on it.  I don't currently have the USB configured, just pulling 5V.  However, I would like to raise the current limit which seems to default to 100mA. What's the minimal configuration I can do to raise the current limit?  In MCUXpresso config tools, I tried setting up USBFS.  It requires at least one interface, so I tried to set up DFU.  I managed to get things to build mostly, but the config tools generate a file timer_queue.c that defines a SysTick_Handler that conflicts with the FreeRTOS port.c SysTick_Handler. 1) Is there something better I can do to try to raise the current limit? 2) If setting up this DFU interface is as good as anything else, how should I resolve conflicts between autogenerated code and the FreeRTOS port? Re: minimal configuration to negotiate higher current limit on USB Hello @robert_hines  Yes, a USB device must declare its required power in the bMaxPower field during USB enumeration. To draw more than 100 mA, I recommend configuring your device as a USB HID or USB CDC device, as these are generally easier to implement than DFU.   Thank you.   BR Alice

针对 Android Automotive 16.0.0_1.3.0 的安全更新预编译版本，不会破坏内核/U-Boot 构建 您好， 我们使用的是NXP Android Automotive 16.0.0_1.3.0，内核版本为 6.12 ，并采用 NXP 官方文档中记录的预编译版本： platform/prebuilts/clang/host/linux-x86 66acdd82ee62e4aaa4248f03191c59dfed9db193 kernel/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 platform/prebuilts/rust 5156e7f81ae254c79ee736e44c960e75ad685c67 platform/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 以下是 NXP Android Automotive 用户指南中针对此版本列出的修订内容。 使用这些修订版本可以构建，但我们的容器漏洞扫描报告称，提供的 Android 预构建版本中存在几个高危和严重漏洞。 例如，Clang 预编译版本包含嵌入式 Go 标准库。对于 clang-r536225/bin/clang，扫描结果显示： 总计：22 高危：21 严重：1 Go 标准库版本：v1.23.2 示例：CVE-2025-68121 crypto/tls - 证书验证错误 同样的发现模式也出现在 clang++ 和 clang-tidy 中，以及嵌入的 Go 版本为 v1.23.4 的较新的 clang-r547379 二进制文件中。 NXP 锁定的内核/预编译/构建工具也包含受影响的 soong_zip 二进制文件，其 Go-stdlib 查找模式相同。 Rust 预编译版本中还包含对已发布的 Cargo 锁定文件的发现，例如： thin-vec 0.2.13 版本已修复 常见漏洞与后门-2026-6654 漏洞（已在 0.2.16 版本中修复）；hashbrown 0.15.0 版本已修复 GHSA-wwq9-3cpr-mm53 漏洞（已在 0.15.1 版本中修复）。 我们不希望用任意更新的 AOSP 提交替换已记录的修订版本，因为这些预构建版本是 NXP 内核/U-Boot 构建环境的一部分，我们希望保持与Android Automotive 16.0.0_1.3.0 / 内核 6.12 的兼容性。 对于这些预构建版本，是否有 NXP 推荐的更新版本或已知兼容的提交 ID？ 我们尤其需要以下方面的更新修订： platform/prebuilts/clang/host/linux-x86 kernel/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   NXP 或社区中的其他人是否已经更新了这些版本并验证了以下内容仍然有效？ 理想情况下，我们也希望确认完整的 Android Automotive 版本仍然能够与更新后的预构建版本兼容。 我们更倾向于更新受影响的预构建版本，而不是永久压制网络安全漏洞。 我已附上失败的漏洞扫描日志供您参考。它包含了受影响的 Clang、内核构建工具和 Rust 预编译版本的完整调查结果，包括检测到的嵌入式版本和可用的修复版本。 谢谢。 Android Re: Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot bu 你好， 我正在查看您的问题，稍后会向您汇报进展。 此致问候

最小配置即可协商更高的 USB 限流 我有一个可以通过USB供电的设备，它搭载了MCXN947处理器。我目前还没有配置USB，只是直接取5V电源。但是，我想提高限流，它的默认值似乎是 100mA。 我只需做哪些最少的配置就能提高限流？我在MCUXpresso配置工具中尝试设置USBFS。它至少需要一个接口，所以我尝试设置DFU模式。大部分东西都编译成功了，但是配置工具生成了一个名为 timer_queue.c 的文件。它定义了一个与 FreeRTOS port.c 冲突的 SysTick_Handler。SysTick_Handler。 1）我还能做些什么来提高限流？ 2) 如果设置此 DFU 接口与其他方法一样好，我应该如何解决自动生成的代码和 FreeRTOS 端口之间的冲突？ Re: minimal configuration to negotiate higher current limit on USB 你好@robert_hines 是的，USB 设备必须在 USB 枚举期间在 bMaxPower 字段中声明其所需的功率。 如果要消耗超过 100 mA 的电流，我建议将设备配置为 USB HID 或 USB CDC 设备，因为这些通常比 DFU 更容易实现。   谢谢！   BR 爱丽丝

i.MX RT1064 - PEmicro Connection Assistant エラーおよび起動設定の予期しない変更 こんにちは、 i.MX RT1064コントローラーを使い、MCUXpresso IDEのPEmicro Multilinkインターフェースを通じてデバッグやフラッシュを行っています。 ターゲットへの接続を試みる際に、添付の「PEmicro Connection Assistant」エラーが発生することがあります。この問題はランダムに発生するようです。特定のソフトウェア活動、コード変更、ハードウェアイベント情報で継続的にトリガーされるものは特定していません。 私が観察したのは、このエラーが起こると、コントローラーの 起動設定が予期せず変更されているように見えることです。この状態では、デバイスのフラッシュやデバッグを行うことができません。唯一回復できた方法は、起動設定を元の設定(内部フラッシュモード)に戻すことで、その後はフラッシュやデバッグが正常に動作します。 追加情報： MCU:i.MX RT1064 デバッグプローブ: PEmicro Multilink Universal Rev E IDE:MCUXpresso IDE 同様の問題に遭遇した方はいらっしゃいますか？ 以下の点についてご助言いただければ幸いです。 なぜ起動設定が予期せず変わるのでしょうか。 デバッガやアプリケーションコードがブート設定に影響を与える既知のシナリオがあるかどうか。 これを防ぐための推奨方法。 CAN 手動変更なしでソフトウェアで起動設定を変更することはできますか 参考までに、エラーメッセージのスクリーンショットを添付しました。 よろしくお願いします。 i.MXRT 106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly こんにちは、 以下の質問に答えてもらえますか? カスタムボードを使用していますか、それともEVKを使用していますか？ SDKとIDEのバージョンは何を使っていますか? ヒューズを焼いてしまったことはありますか？ 起動設定を内部フラッシュモードに復元する必要があるとおっしゃっていましたが、現在どのブート設定を使っていますか? よろしくお願いします、 パブロ Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 私はカスタムボードを使用していますが、この問題はEVKでも確認されています。 SDK バージョン : 26.03.00 IDEバージョン:25.6.136 ヒューズは一つも切っていない。 通常は内部ブートモードでコードをフラッシュし、通常の動作をしますが、予期せぬ問題がランダムに起こるため、シリアルダウンロードモードに変え、フラッシュを消去してから再び内部ブートモードに戻してから再度コードをフラッシュします。 ブート設定情報については、添付画像をご覧ください。 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly こんにちは、 @Subhasri_S さん。 BOOT_MODEレジスタは、POR_Bの立ち上がりエッジでBOOT_MODE0とBOOT_MODE1の入力をサンプリングすることによって初期化されます。これらの入力がサンプリングされた後、その後の状態は内部のBOOT_MODEレジスタの内容に影響を与えません。 BT_FUSE_SEL = 0の場合、特定のブート設定パラメータはeFuseの代わりにGPIOピンで設定できます。 問題が起きたときにリセット時にBOOT_MODEとBT_CFGピンの測定を手伝ってもらえますか? この問題に関する別の可能性のある結論については、以下のナレッジベース記事に記載されています。 ナレッジベース：デバッガー接続の問題に対するRTボードの復旧 「フラッシュに異常なアプリ(アクセスメモリが存在しない、メモリが破損している、クロックの誤設定など)が含まれていると、ボードが未知の状態に陥り、デバッガがコアを制御できなくなります。しかし、コアをシリアルダウンローダーモードにすると、コアは既知の状態になり、デバッガーがコアを制御できるようになります。 SO、RTボードでデバッガの問題が発生した場合は、シリアルダウンロードモードで外部フラッシュを一括消去してみてください。そうすればボードデバッガは通常の状態に復元されます。」 よろしくお願いします、 パブロ Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly こんにちは。問題が発生した際に記録されたBOOT_MODEとBOOT_CFGのピン値を確認してください。

关于 HSE FW 2.40.0 和 2.55.0 中 GCM IV 长度支撑的问题 你好， 我有一个关于 S32K358 上 HSE 的 GCM 操作的问题。 在 HSE 服务 API 参考手册的 AEAD 服务描述中，HSE FW 2.40.0 和 2.55.0 都对 GCM 进行了如下规定： GCM: 1 <= ivLength <= 2^32-1。建议大小为 12 字节或更大。 但是，HSE FW 2.40.0 手册包含以下附加说明，而 HSE FW 2.55.0 手册中没有此说明： 在 GCM 操作中，建议使用正好 12 字节的 IV 值。对于任何非 12 字节的 IV 大小，GCM 加密操作生成的认证标签可能不正确。在 GCM 解密操作中，身份验证检查可能会失败。 在此，我想澄清以下几点： 1. 当 IV 长度不是 12 字节时，HSE FW 2.40.0 中 GCM 操作能否正常使用？ 2. 当使用 12 字节以外的 IV 长度时，HSE FW 2.40.0 和 2.55.0 在 GCM 操作方面是否存在行为差异？ 3. 当使用 12 字节以外的 IV 长度时，HSE FW 2.40.0 和 2.55.0 的 GCM 操作可靠性是否存在差异？ 在我们的测试中，即使 IV 长度不是 12 字节，GCM 加密和解密也能成功执行，并且认证结果也正确。 因此，我想确认 HSE FW 2.40.0 是否完全支持使用 12 字节以外的 IV 长度，以及在这种情况下与使用 HSE FW 2.55.0 相比是否存在任何功能差异。 谢谢你的解释。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 嗨@wodudwo 从技术上讲，ivLength 可以配置为不同的长度；但是，不建议这样做，因为不能保证其行为可靠。正如您正确指出的那样，文档中说明，对于 GCM 解密操作，当使用 12 字节以外的 IV 长度时，身份验证检查可能会失败。 虽然使用不同长度的静脉输液管进行的测试可能通过了，但这并不能保证手术一定会成功。换句话说，某个测试用例的成功结果不应被解释为表明该配置完全受支持或在所有情况下都能稳定运行。 此外，如果您查看这两个固件版本的发行说明，您会发现限制列表包含相同的建议：使用正好为 12 字节的 IV 值。 虽然从 HSE 固件 2.55.0 版本开始，HSE 服务 API 参考手册中已删除该注释，但限制本身仍然存在。 BR，VaneB

GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Board/BSP: i.MX8M Plus, aarch64 Galcore version 6.4.11.p2.745085 ONNX Runtime with VSINPUExecutionProvider (statically linked against libtim-vx.so) Vivante OpenCL ICD present and functional (Vivante.icd → libVivanteOpenCL.so) Goal: Run ResNet50 inference benchmarks (MLPerf loadgen harness) on the GC7000UL 3D GPU core specifically, as a comparison point against existing NPU (VIP8000Nano) and CPU benchmark results already collected. What's confirmed working: clGetPlatformIDs/clGetDeviceIDs via the Vivante OpenCL ICD cleanly enumerates two independent devices under one platform: Device 0: GC7000UL.6204.0000 Device 1: VIP8000Nano-S+I.8002.0000 Both report CL_DEVICE_TYPE_ACCELERATOR, no errors, confirmed via a minimal C test program linked against libOpenCL.so → libGAL.so. What's blocking GPU dispatch via ORT: ort.get_available_providers() returns only ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — no OpenCL-based EP. VSINPUExecutionProvider is statically linked to libtim-vx.so (OVXLIB/vsi_nn_* API). Symbol/string dump of both libtim-vx.so and libGAL.so shows no DEVICE_INDEX/DEVICE_ID-style env var or config surface — only behavior toggles (VIV_VX_ENABLE_SHADER, VSI_NN_ENABLE_*, etc). libGAL.so does export gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex at the raw HAL layer, but there's no visible plumbing from OVXLIB/TIM-VX down to that call which is  suggesting the graph compiler used by VSINPU may be hardcoded to target the NPU core only, regardless of device index. Specific question: Does TIM-VX / OVXLIB on this BSP (galcore 6.4.11.p2) support compiling and dispatching a graph to the GC7000UL as a general-compute target, or is the graph compiler NPU-only by design in this build, and how can I verify if it is possible to run it that way ?  If GPU-target graph compilation is supported upstream in TIM-VX but not enabled in this NXP-shipped build, is there a build flag / SDK component that exposes it? If there is no supported path through TIM-VX/ORT, is there an NXP-recommended way to run generic  inference on the GC7000UL directly (e.g. via the OpenCL/OpenVX layer, since that portion of the stack is confirmed functional) ,  a sample app, SDK component, or reference implementation we should be building against instead? as a currently a student, and trying to work on this implementation and running an ORT on TOP of the GPU, is there any way, or any other way to be able use the GPU for inference ?  Thank you very much  IMX8MPLUS  #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only HI @WaleedO, Thank you for contacting NXP Support. To run inference on the GPU, you should use the GPU delegate, which enables supported operations to be accelerated by the GPU instead of running entirely on the CPU. I recommend reviewing our Machine Learning User Guide to better understand the available execution backends, delegate configuration, supported frameworks, and example applications. The guide also includes step-by-step examples that can help you validate that the GPU delegate is being loaded correctly and that your model is executing as expected. If you encounter any issues during setup or execution, please share the model, BSP version, and the commands you are using, and I will be happy to assist further. Best regards, Alejandro Garcia Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Hello @Chavira  Nice to meet you. After checking the documentation, the GPU delegate and the OpenCL path is used within  i.MX 95/952 GPU (Arm Mali G310). I am curently working on The IMX8MPLUS .  the imx8m Plus have this stack:  VX delegate ==> TIM-VX ==>  GPU/NPU (unified driver)  ==> I.MX 8 series NPU and GPU (GC7000,GC7000L, GC7000UL).  as per the documentation.  Currently, I am working with ONNX and ORT. When I run the execution, It is per default running on the NPU. Is there any way to use the OpenCL to work ont the IMX8MPLUS  GPU ? or if there is any manual override, or technique that I can implement, so that I can manually set the compilation toward either NPU or/And  GPU ?  Thank Your very much for your reply.  Kind regards,  IMX8MPLUS  #TIM-VX #VX-delegate Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Hello, Yes there is still a possible path, but I would not try to force VSINPU Execution Provider to use the GC7000UL. Your results strongly suggest that the current NXP TIM-VX/OVXLIB build is wired primarily for the VIP8000 NPU. gcoHAL_SetDeviceIndex() in libGAL.so alone doesn't mean TIM-VX can redirect NN graphs to the GPU. First test TIM-VX/OpenVX directly, outside ONNX Runtime, with a small model. Check whether your specific OVXLIB exposes a GC7000UL/GPU NN target. Compare your NXP TIM-VX build with upstream TIM-VX, especially its multi-device/platform support. If TIM-VX cannot compile for GC7000UL, use the Vivante OpenCL/OpenVX stack directly for the GPU benchmark. For your MLPerf project, you don't necessarily need ORT for the GPU path. You can make a separate GC7000UL backend and connect it to the same LoadGen harness used for CPU/NPU. So I would structure it as: MLPerf LoadGen → ResNet50 GPU backend → OpenCL/OpenVX → GC7000UL rather than: MLPerf → ORT → VSINPU → somehow force GPU Best Regrad, fesaji

USBの電流制限を引き上げるための最小限の設定 USB経由で電源が供給できるデバイスがあり、MCXN947プロセッサを搭載しています。現在USBは設定しておらず、5V電源のみを供給しています。しかし、デフォルトで100mAに設定されている電流制限値を引き上げたいと考えています。 電流制限を上げるために最低限の設定は何でしょうか?MCUXpressoの設定ツールで、USBFSの設定を試みました。少なくとも1つのインターフェースが必要なので、DFUを設定してみました。なんとかほとんどのものはビルドできたのですが、設定ツールがtimer_queue.cというファイルを生成します。FreeRTOS port.c と競合する SysTick_Handler を定義するSysTick_Handler。 1) 電流制限を上げるためにもっと良い方法はありますか? 2) このDFUインターフェースの設定が他のどんな方法と同じくらい良い場合、自動生成コードとFreeRTOSポート間の競合はどう解決すればよいでしょうか? Re: minimal configuration to negotiate higher current limit on USB こんにちは、 @robert_hines さん。 はい、USBデバイスはUSB列挙時にbMaxPowerフィールドで必要な電力を宣言する必要があります。 100mAを超える電流を消費する場合は、デバイスをUSB HIDまたはUSB CDCデバイスとして構成することをお勧めします。これらは一般的にDFUよりも実装が容易です。   よろしくお願いします。   BR アリス

Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hello, I have a question regarding the GCM operation of the HSE on the S32K358. In the AEAD service description of the HSE Service API Reference Manual, both HSE FW 2.40.0 and 2.55.0 specify the following for GCM: GCM: 1 <= ivLength <= 2^32-1. Recommended 12 bytes or greater. However, the HSE FW 2.40.0 manual contains the following additional note, which is not present in the HSE FW 2.55.0 manual: In GCM operations, it is recommended to use IV values of exactly 12 bytes. For any IV size different from 12 bytes, the authentication tag generated by the GCM encryption operation might not be correct. In GCM decryption operations, the authentication check might fail. In this regard, I would like to clarify the following: 1. Can GCM operations be used normally in HSE FW 2.40.0 when the IV length is not 12 bytes? 2. Is there any behavioral difference in GCM operations between HSE FW 2.40.0 and 2.55.0 when using an IV length other than 12 bytes? 3. Is there any difference in the reliability of GCM operations between HSE FW 2.40.0 and 2.55.0 when using an IV length other than 12 bytes? In our tests, GCM encryption and decryption were performed successfully even when the IV length was not 12 bytes, and the authentication results were also correct. Therefore, I would like to confirm whether using an IV length other than 12 bytes is fully supported in HSE FW 2.40.0, and whether there is any functional difference compared to using HSE FW 2.55.0 in this case. Thank you for your clarification. Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hi @wodudwo  Technically, ivLength can be configured with a different length; however, doing so is not recommended because the behavior is not guaranteed to be reliable. As you correctly pointed out, the documentation states that for GCM decryption operations, the authentication check may fail when IV lengths other than 12 bytes are used. While your test may have passed using a different IV length, this does not guarantee that the operation will always succeed. In other words, a successful result in a particular test case should not be interpreted as an indication that the configuration is fully supported or will work consistently in all scenarios.  Additionally, if you review the release notes for both firmware versions, you will find that the List of Limitations includes the same recommendation: use IV values of exactly 12 bytes. Although the note was removed from the HSE Service API Reference Manual starting with HSE FW 2.55.0, the limitation itself remains unchanged.  BR, VaneB

リファレンス ドキュメントの請求:S32DSにおけるCody ChatとのAIツール統合 親愛なるNXPコミュニティチームの皆様、 現在はS32 Design Studioを使っていて、IDEにあるCody Chat機能を使っています。 OpenAI、ChatGPT、Anthropic Claude のような外部AIモデルを S32 Design StudioのCody Chatセクションに 統合することが可能かどうか知りたい です。 私の要件は、S32DS内でAIアシスタントを直接使用して、次のような作業を行うことです。 C/C++コードの生成と解説 組み込みC言語開発 コンパイラとリンカーのエラーのデバッグ CAN、SPI、I2C、UART、ADCの開発 S32K3/S32K344の開発 現在のS32DSプロジェクトの状況を理解し、それに基づいて作業を行う 公式のSourcegraph Codyドキュメントでは、OpenAIとAnthropicの両方のモデルをサポートし、モデル設定やBring Your Own Key(BYOK)オプションが含まれていることがわかりました。 もう少し詳しく教えていただけますか: S32 Design Studioで使われているCody統合は、ChatGPT/OpenAIやClaudeなどの外部AIプロバイダーと接続可能でしょうか? Cody Chatのセクションで、これらのAIプロバイダ向けに独自のAPIキーを設定CANできますか? 公式のNXPドキュメント、S32DSのドキュメント、Codyのドキュメント、またはS32DSで外部AIモデルをCodyで構成・統合する方法を説明する例プロジェクトはありますか? もしこの機能が現在のS32DSバージョンで直接サポートされていない場合、Cody/Eclipseプラグインを外部のAIプロバイダーに拡張する公式な方法はありますか? S32DS版Codyの実装には、標準のSourcegraph版Codyの実装と比較して、何か制限事項はありますか？ 参考までに、サポートされているLLMとモデル構成に関する以下のSourcegraphドキュメントを見つけました: 支援対象のLLM（法学修士）課程 コーディモデル構成 コーディモデルの構成例 これをS32DSで実装するための適切なNXP参照ドキュメントや推奨手順を教えていただけますか? 再開まで今しばらくお待ちください。 よろしくお願いします、 アラヴィンド・トガラリ Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS こんにちは、 外部利用用のドキュメント付きAIツールのリリースは9月26日に予定されています。

在 i.MX8M Plus 和 TIM-VX/VSINPU 上，GC7000UL 通用计算推理路径似乎仅支持 NPU。 板/电路板支持包。： i.MX8M Plus，aarch64 Galcore 版本 6.4.11.p2.745085 ONNX 运行时，带有 VSINPUExecutionProvider（静态链接到 libtim-vx.so） Vivante OpenCL ICD 已存在且功能正常（Vivante.icd → libVivanteOpenCL.so） 目标： 专门在 GC7000UL 3D GPU 核心上运行 ResNet50 推理基准测试（MLPerf loadgen 测试框架），以便与已收集的现有 NPU（VIP8000Nano）和 CPU 基准测试结果进行比较。 已确认有效的功能： 通过 Vivante OpenCL ICD 使用 clGetPlatformIDs/clGetDeviceIDs 可以清晰地枚举同一平台下的两个独立设备： 设备 0：GC7000UL.6204.0000 设备 1：VIP8000Nano-S+I.8002.0000 两者都报告 CL_DEVICE_TYPE_ACCELERATOR，没有错误，通过链接到 libOpenCL.so → libGAL.so 的最小 C 测试程序确认。 是什么阻碍了通过 ORT 进行 GPU 调度： ort.get_available_providers() 仅返回 ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — 没有基于 OpenCL 的 EP。 VSINPUExecutionProvider 静态链接到 libtim-vx.so（OVXLIB/vsi_nn_* API）。libtim-vx.so 和 libGAL.so 的符号/字符串转储显示没有 DEVICE_INDEX/DEVICE_ID 风格的环境变量或配置表面——只有行为切换（VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_* 等）。 libGAL.so 确实在原始 HAL 层导出了 gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex，但是从 OVXLIB/TIM-VX 到该调用没有明显的管道，这表明 VSINPU 使用的图形编译器可能被硬编码为仅针对 NPU 核心，而不管设备索引如何。 具体问题： 此电路板支持包 (galcore 6.4.11.p2) 上的 TIM-VX / OVXLIB 是否支持将图编译并分发到 GC7000UL 作为通用计算目标？或者，此版本中的图编译器是否设计为仅限 NPU？我如何验证是否可以以这种方式运行它？ 如果 TIM-VX 上游支持 GPU 目标图编译，但 NXP 提供的版本中未启用，是否有构建标志/SDK 元器件可以启用它？ 如果无法通过 TIM-VX/ORT 获得支持，NXP 是否有推荐的方法可以直接在 GC7000UL 上运行通用推理（例如通过 OpenCL/OpenVX 层，因为该部分协议栈已被确认功能正常），或者是否有示例应用程序、SDK 组件或参考实现可供我们参考？ 我目前是一名学生，正在尝试进行这项实现，并在 GPU 上运行 ORT，请问是否有任何方法或途径可以使用 GPU 进行推理？ 非常感谢 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 嗨@WaleedO ， 感谢您联系恩智浦技术支持。 要在 GPU 上运行推理，您应该使用 GPU 委托，它允许由 GPU 加速支持的操作，而不是完全在 CPU 上运行。 我建议您查看我们的机器学习用户指南，以便更好地了解可用的执行后端、委托配置、支持的框架和示例应用程序。该指南还包含逐步示例，可以帮助您验证 GPU 委托是否已正确加载以及您的模型是否按预期执行。 如果在安装或执行过程中遇到任何问题，请分享您的模型、BSP 版本以及您正在使用的命令，我将很乐意为您提供进一步的帮助。 此致， 亚历杭德罗·加西亚 Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好@Chavira 很高兴见到你。 查阅文档后发现，GPU 委托和 OpenCL 路径是在 i.MX 95/952 GPU（Arm Mali G310）中使用。我目前正在研究IMX8MPLUS。IMX8M Plus 的架构如下：VX 代理 ==> TIM-VX ==> GPU/NPU（统一驱动程序） ==> I.MX 8 系列 NPU 和 GPU（GC7000、GC7000L、GC7000UL）。根据文件记载。 目前我正在使用 ONNX 和 ORT。当我运行该程序时，它默认在 NPU 上运行。是否有办法使用 OpenCL 在IMX8MPLUS GPU 上工作？或者是否有任何手动覆盖或我可以实现的技术，以便我可以手动将编译目标设置为 NPU 或/和 GPU？ 非常感谢您的回复。 亲切的问候， IMX8MPLUS #TIM-VX #VX-delegate Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好， 是的，还有一条可能的途径，但我不会尝试强制 VSINPU 执行提供程序使用 GC7000UL。 您的结果强烈表明，当前的 NXP TIM-VX/OVXLIB 版本主要针对 VIP8000 NPU 进行了布线。libGAL.so 中的 gcoHAL_SetDeviceIndex() 函数本身并不能将 NN 图重定向到 GPU。 首先在 ONNX 运行时环境之外，使用小型模型直接测试 TIM-VX/OpenVX。 检查您的特定 OVXLIB 是否公开了 GC7000UL/GPU NN 目标。 将您的 NXP TIM-VX 版本与上游 TIM-VX 版本进行比较，特别是其多设备/平台支持。 如果 TIM-VX 无法为 GC7000UL 编译，则直接使用 Vivante OpenCL/OpenVX 堆栈进行 GPU 基准测试。 对于你的 MLPerf 项目，GPU 路径不一定需要 ORT。您可以创建一个单独的 GC7000UL 后端，并将其连接到用于 CPU/NPU 的同一 LoadGen 线束。 所以我会这样组织它： MLPerf 负载生成器 → ResNet50 GPU 后端 → OpenCL/OpenVX → GC7000UL 而不是： MLPerf → ORT → VSINPU → 以某种方式强制 GPU 致以最诚挚的问候， 费萨吉

[SPSDK][i.MX95] nxpele read-common-fuse が失敗する こんにちは、 私はIMX95 19x19 EVKボードでセキュアブートを有効にする作業に取り組んでいます。SPSDKを使用して画像に署名することに成功しました。さて、ヒューズを書き込む前に、`nxpele` を使用してそれらを読み取ろうとしたのですが、以下のエラーが発生します。 ``` $ NXPELE -f MIMx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-fuse --index 136 SPSDKParsingError: SPSDK: レスポンスのメッセージSIZEが無効: 0x4 詳細はデバッグログファイル /home/user/.local/state/spsdk/3.11.0/log/debug.log を参照してください ``` ログには次のように記載されています。 ``` $ tail -60 /home/ユーザー/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"レスポンスのメッセージサイズが無効です: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: レスポンスのメッセージサイズが無効です: 0x4 DEBUG:spsdk:*************************************************** (開始から206ms、spsdk_logger.py:212) DEBUG:spsdk:* SPSDK デバッグログ記録開始 2026-09-03 15:58:44 * (開始から 207ms、spsdk_logger.py:213) DEBUG:spsdk:* SPSDK バージョン: 3.11.0* (開始から207ms、spsdk_logger.py:215) デバッグ:spsdk:* Python バージョン: 3.14.4* (開始から207ms、spsdk_logger.py:216) DEBUG:spsdk:* OS バージョン: Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (開始から208ms、spsdk_logger.py:217) DEBUG:spsdk:* 最後のコマンド: ['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-fuse', '--index', '136'] * (開始から 208ms、spsdk_logger.py:218) DEBUG:spsdk:*************************************************** (開始から208ms、spsdk_logger.py:219) TRACE:spsdk.uboot.uboot:Uboot書き込み -> 無効 (開始から 210ms、 __init__ .py:50) デバッグ:spsdk.uboot.uboot:UbootREAD UNTIL <- => (開始から210ms、uboot.py:271) DEBUG:spsdk.uboot.uboot:チェック中無効なコマンドを送信してシリアルコンソールを開いた場合: "invalid\r\n不明なコマンド 'invalid' - 'help' を試してください\r\nu-boot=> " (開始から 224ms、uboot.py:209) デバッグ:spsdk.utils.database:現在データベースフィンガープリントハッシュ: f0f0598d4e6ae6c755d693693f232e30537cfb3b (開始から226ms、database.py:1967) デバッグ:spsdk.utils.database:ロード済みキャッシュからのデータベース: /tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache (開始から226ms、database.py:1976) デバッグ:spsdk.utils.misc:読み込み中/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml からのテキストファイル (開始から 226ms、misc.py:312) INFO:spsdk.ele.ele_comm:ELEコミュニケーターは、mimx9596のアドレス92800000で196608 Bサイズのバッファを使用しています。リビジョン：最新ターゲット。 デバッグ:spsdk.ele.ele_comm:ELEmsg 0x92800000 0x30000 0602971788000000 (開始から245ms、ele_comm.py:502) TRACE:spsdk.uboot.uboot:Uboot書き込み -> ele_message 0x92800000 0x30000 0602971788000000 (開始から246ms、 __init__ .py:50) デバッグ:spsdk.uboot.uboot:UbootREAD UNTIL <- => (開始から246ms、uboot.py:271) デバッグ:spsdk.ele.ele_comm:RawELEメッセージ出力: ele_message 0x92800000 0x30000 0602971788000000 060497e1d600000000000000000000200u-boot=> (開始から256ms、ele_comm.py:422) DEBUG:spsdk.ele.ele_comm:Stripped出力: 060497e1d600000000000000 (開始から256ms、ele_comm.py:460) デバッグ:spsdk.apps.utils.utils:SPSDK:応答メッセージのサイズが無効です: 0x4 (開始から257ms、utils.py:182) トレースバック（最新の呼び出し）： ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py",172行目、ラッパー内 retval = function(*args, **kwargs) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py",safe_main の 2189 行目 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",1631行目、 __call__ return self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",1552行目、メイン rv = self.invoke(ctx) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py"、2032行目、invoke内 return _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",1415行目、invoke内 return ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py",910行目、invoke内 return callback(*args, **kwargs) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py",46行目、new_func内 return f(get_current_context().obj, *args, **kwargs) ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py",575行目、cmd_read_common_fuse内 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py",588行目、ele_read_common_fuse内 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py",send_message 関数の 519 行目 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py",decode_response の 1235 行目 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ ファイル "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py",decode_response の 346 行目 raise SPSDKParsingError(f"レスポンスのメッセージサイズが無効です: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: レスポンスのメッセージサイズが無効です: 0x4 「`」 注：私は`SPDK 3.11.0`を使用しています。 SPSDKのGitHubページにも問題を報告しました。https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 どんなご支援でも大変ありがたく思います。 ありがとうございました。 BR、 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails こんにちは、ジョアンクシー 私はLinux BSPバージョンLF6.18.20_2.0.0(yocto wrynose)を使っています そして、これが nxpele get-info の出力です。 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails このコマンドでどのELEのFWバージョンを使っているか教えてもらえますか?もう一度確認させてください Re: [SPSDK][i.MX95] nxpele read-common-fuse fails この問題を再現し、内部データベースを確認したところ、これは既知の問題であり、spsdk 3.12.0で修正される予定です。

88W8887 RF準拠試験 親愛なる、 私たちは88W8887チップセットをベースにしたWi-Fi/Bluetoothモジュールを使用しています。製品準拠のために、連続パケットの送信や受信モードなどのRFテストを行う必要があります。別のモジュール88W8997については、以下のアプリケーションノードAN14114をたどっています。しかし、アプリケーションノートには88W8887がサポートされているとは記載されていません。 アプリケーションノートにはmwifiexドライバを使用しています。コードを見る限り、88W8887はドライバーがサポートしているはずです。残念ながら、ドライバにはファームウェアファイルsd8887_wlan_a2.binが必要ですが、私たちは見つけることができませんでした。 88W8887でRFテストを行う推奨方法(ANに記載されているものと似ています)は何ですか?NXPはまだこのユースケースをサポートしていますか? 敬具 ヨシ Re: 88W8887 RF compliance testing こんにちは@shaun_wu 提供されたリンクにアクセスできません。アクセスを得るために自分の側で何かやるべきことはありますか? 敬具 ヨシ Re: 88W8887 RF compliance testing こんにちは、 @YoshiDev さん。 8887はrf_test_modeをサポートしていません。mfg_modeを使えばいい。以下のリンクを参照できる https://www.nxp.com/webapp/Download?colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license よろしくお願いいたします。 ショーン Re: 88W8887 RF compliance testing こんにちは、 @YoshiDev さん。 この文書は機密情報です。NDAチームにチケットを提出してアクセス権を得ることもできます。 よろしくお願いいたします。 ショーン

Android オートモーティブ 16.0.0_1.3.0向けのセキュリティアップデート済みプリビルドで、カーネルやU-Bootビルドを壊さずに提供されました こんにちは、 NXPの Android オートモーティブ 16.0.0_1.3.0をカーネル6.12 と、NXPが文書化したプリビルドのリビジョンを使用しています。 プラットフォーム/Prebuilts/Clang/Host/Linux-x86 66acdd82ee62e4AAAA4248F03191C59DFED9DB193 カーネル/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 プラットフォーム/prebuilts/rust 5156e7f81ae254c79ee736e44C960e75AD685C67 プラットフォーム/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 これらは本リリースのNXP Android Automotiveユーザーガイドに記載された改訂版です。 ビルドはこれらのリビジョンで動作しますが、当社のコンテナ脆弱性スキャンでは、 提供されたAndroidプリビルト内でいくつかのHIGHかつCRITICALな発見が報告されています。 例えば、Clangのプリビルド版にはGoの標準ライブラリが組み込まれています。clang-r536225/bin/clang のスキャン結果は以下のとおりです。 合計: 22 高: 21 重大: 1 Go stdlib バージョン: v1.23.2 例: CVE-2025-68121 crypto/tls - 証明書の検証が正しく行われていない 同様の検出パターンは、clang++ および clang-tidy、そして組み込みの Go バージョンが v1.23.4 である新しい clang-r547379 バイナリでも見られます。 NXPが固定しているkernel/prebuilts/build-toolsにも、同じGo-stdlib検出パターンを持つ、影響を受けるsoong_zipバイナリが含まれています。 Rustのプリビルド版には、出荷されるCargoロックファイルに含まれる発見事項も含まれています。例えば、以下のとおりです。 thin-vec 0.2.13 CVE-2026-6654 は 0.2.16 で修正されました。 hashbrown 0.15.0 GHSA-wwq9-3cpr-mm53 は 0.15.1 で修正されました。 これらのプリビルドはNXPカーネル/U-Bootビルド環境の一部であり、 Android Automotive 16.0.0_1.3.0 / カーネル6.12との互換性を維持したいため、ドキュメント化されたリビジョンを任意の新しいAOSPコミットで置き換えるつもりはありません。 これらのプリビルド製品に対応する、NXPが推奨する、または互換性が確認されている新しいコミットIDはありますか？ 特に、以下の項目に関する最新の改訂版を求めています。 platform/prebuilts/clang/host/linux-x86 カーネル/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   NXP社、あるいはコミュニティの誰かが、これらの改訂版を既に更新し、以下の内容が引き続き正常に動作することを確認しましたか？ 理想的には、更新されたプリビルト車と完全なAndroid Automotiveビルドがまだ動作するかどうかの確認も望んでいます。 セキュリティ調査結果を恒久的に抑制するよりも、影響を受けたプリビルトを更新したいと考えています。 参考までに、失敗した脆弱性スキャンログを添付しました。これには、影響を受けるClang、カーネルビルドツール、およびRustのプリビルド版に関する完全な調査結果が含まれており、検出された組み込みバージョンと利用可能な修正バージョンも含まれています。 ありがとうございます。 Android Re: Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot bu こんにちは、 ご指摘いただいた件について調査中です。進捗状況は随時ご連絡いたします。 よろしくお願いします。

Wrynose SDKのPowerPCサポート こんにちは、 私たちはDunfellからWrynose Yocto SDKへのT4240rdbベースのボードを移行しようと考えています。Wrynose SDKでPowerPCのボードはサポートされていますか? もし無理なら、PowerPCボードのサポートを得るための選択肢は何でしょうか。 ありがとうございます スッバラオ・ナラジャラ タレスグループのシニアエンジニア Re: PowerPC support for Wrynose SDK こんにちは、 PowerPC/T4240RDBボードはNXP Wrynose Yocto SDKではサポートされていません。これはダンフェル以外のすべての新しいNXP Yoctoリリースに適用されるよく知られた制限です。 WrynoseでPowerPCがサポートされていない理由 NXPのWrynose SDK(Yocto 6.0)は ARMベースの i.MX およびLayerscapeプロセッサ専用です。QorIQ Tシリーズ(T4240を含む)は Power Architecture(e6500コア)を使用しており、これは新しいYocto SDKリリースには引き継がれていません。これはNXPのより広範な戦略と一致している。 「QorIQ SDKは、QorIQ PowerPCベースのPシリーズおよびTシリーズプロセッサファミリー向けの、完全機能かつ成熟したYoctoベースのソフトウェアキットです...Layerscape SDKはLayerscapeファミリープロセッサのハイブリッドUbuntuベースのソフトウェアキットであり、今後はLayerscapeプラットフォーム上で最新のソフトウェアを提供する主要な配信手段となるでしょう。」 T4240RDBにおける最後の公式NXP対応YoctoリリースはDunfell(Yocto 3.1)です。新しいYoctoのリリース(Scarthgap、Wrynoseなど)にはT4240RDBや他のPowerPC Tシリーズボードは含まれていません。 既知のビルドエラーもglibcレベルでこれを裏付けています — ポストDunfell Yoctoでe6500 PowerPC64アーキテクチャ向けにビルドしようとすると、以下のような結果が出ます。 configure: error: The e6500 subspecies of powerpc64 is not supported. 選択肢 オプション1：ダンフェルに滞在する（T4240RDBに推奨） QorIQ Yocto SDKのダンフェル支部は、今もT4240RDBの最新の公式サポートYoctoリリースです。以下でアクセスできます: https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell これは、安定しサポートされたYocto環境を必要とするPowerPC T-Seriesの顧客にNXPが推奨する道です。 オプション2：コミュニティ/アップストリームソースを使用する NXPのPower Architecture PシリーズおよびTシリーズお客様向けの公式ガイダンスは、新しいカーネルおよびU-Bootバージョンについては 、上流のコミュニティソース を活用することです。 「今後は、Power ArchitectureベースのPシリーズおよびTシリーズプラットフォームを利用するお客様には、kernel.org や denx.de(uBoot)などのコミュニティソースから直接イネーブルメントソフトウェアを入手することを推奨します。」 つまり、メインラインソースを使ってT4240RDB向けの新しいカーネル(例:5.xや6.x)を構築できますが、これは手動の統合作業が必要であり、NXPがサポートするSDKではありません。 オプション3:ARMベースのレイヤースケーププラットフォームへの移行 もし新しいYocto SDK(Wrynoseを含む)が必須条件であれば、唯一の方法は ハードウェアプラットフォームを ArmベースのLayerscape® プロセッサ(例:LX2160A、LS1046A、LS1088A)に移行することです。これらはWrynoseおよびFUTUREのNXP Yoctoリリースで完全にサポートされています。これは大規模なハードウェア再設計の取り組みではあるが、NXPの長期的なロードマップに沿ったものである。 オプション4:NXPプロフェッショナル/プレミアムサポート カスタムBSP作業や新しいYoctoベースラインへのT4240RDB移植が必要な場合、NXPは プロセッサーおよびマイクロコントローラのプロフェッショナルサポートを提供しており、Linux/Yoctoのレシピ支援やNXPエンジニアへの直接アクセスも可能です。   よろしくお願いします。

Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot builds Hi, we are using NXP Android Automotive 16.0.0_1.3.0 with kernel 6.12 and the prebuilt revisions documented by NXP: platform/prebuilts/clang/host/linux-x86 66acdd82ee62e4aaa4248f03191c59dfed9db193 kernel/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 platform/prebuilts/rust 5156e7f81ae254c79ee736e44c960e75ad685c67 platform/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 These are the revisions listed in the NXP Android Automotive User's Guide for this release. The build works with these revisions, but our container vulnerability scan reports several HIGH and CRITICAL findings inside the supplied Android prebuilts. For example, the Clang prebuilts contain embedded Go standard libraries. For clang-r536225/bin/clang, the scan reports: Total: 22 HIGH: 21 CRITICAL: 1 Go stdlib version: v1.23.2 Example: CVE-2025-68121 crypto/tls - incorrect certificate validation The same finding pattern also appears in clang++ and clang-tidy, and in the newer clang-r547379 binaries where the embedded Go version is v1.23.4. The NXP-pinned kernel/prebuilts/build-tools also contains affected soong_zip binaries with the same Go-stdlib finding pattern. The Rust prebuilts also contain findings in shipped Cargo lock files, for example: thin-vec 0.2.13 CVE-2026-6654 fixed in 0.2.16 hashbrown 0.15.0 GHSA-wwq9-3cpr-mm53 fixed in 0.15.1 We do not want to replace the documented revisions with arbitrary newer AOSP commits, because these prebuilts are part of the NXP kernel/U-Boot build environment and we want to preserve compatibility with Android Automotive 16.0.0_1.3.0 / kernel 6.12. Are there newer NXP-recommended or known-compatible commit IDs for these prebuilts? In particular, we are looking for updated revisions for: platform/prebuilts/clang/host/linux-x86 kernel/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   Has NXP, or anyone in the community, already updated these revisions and verified that the following still work? Ideally, we would also like confirmation that a complete Android Automotive build still works with the updated prebuilts. We would prefer to update the affected prebuilts instead of permanently suppressing the security findings. I have attached the failed vulnerability scan log for reference. It contains the complete findings for the affected Clang, kernel build-tools and Rust prebuilts, including detected embedded versions and available fixed versions. Thanks. Android Re: Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot bu Hello, I'm reviewing your issue, I'll keep you updated.  Regards.

PowerPC support for Wrynose SDK Hi, We are looking to migrate our T4240rdb based board from Dunfell to Wrynose Yocto SDK. Are PowerPC boards supported in Wrynose SDK ? If not what are our options to get support for PowerPC boards. Thanks, Subbarao Nalajala Senior Engineer at Thales Group Re: PowerPC support for Wrynose SDK Hello, PowerPC/T4240RDB boards are NOT supported in the NXP Wrynose Yocto SDK. This is a well-established limitation that applies to all newer NXP Yocto releases beyond Dunfell. Why PowerPC is Not Supported in Wrynose NXP's Wrynose SDK (Yocto 6.0) is exclusively targeted at ARM-based i.MX and Layerscape processors. The QorIQ T-Series (including T4240) uses the Power Architecture (e6500 core), which has not been carried forward into the newer Yocto SDK releases. This is consistent with NXP's broader strategy: "QorIQ SDK is a fully featured and mature Yocto-based software kit for QorIQ PowerPC-based P-series and T-series family of processors... Layerscape SDK is the hybrid Ubuntu-based software kit for the Layerscape family of processors, and going forward will be the primary delivery mechanism for the most up-to-date software on Layerscape platforms." The last officially NXP-supported Yocto release for T4240RDB is Dunfell (Yocto 3.1). Newer Yocto releases (Scarthgap, Wrynose, etc.) do not include T4240RDB or other PowerPC T-Series boards. A known build error also confirms this at the glibc level — attempting to build for the e6500 PowerPC64 architecture in post-Dunfell Yocto results in: configure: error: The e6500 subspecies of powerpc64 is not supported. Your Options Option 1: Stay on Dunfell (Recommended for T4240RDB) The Dunfell branch of the QorIQ Yocto SDK remains the latest officially supported Yocto release for the T4240RDB. You can access it at:  https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell This is the path NXP recommends for PowerPC T-Series customers who need a stable, supported Yocto environment. Option 2: Use Community/Upstream Sources NXP's official guidance for Power Architecture P-Series and T-Series customers is to leverage upstream community sources for newer kernel and U-Boot versions: "Going forward, we encourage customers using Power Architecture-based P-series and T-series platforms to get the enablement software directly from the community sources like kernel.org and denx.de (uboot)." This means you can build a newer kernel (e.g., 5.x or 6.x) for T4240RDB using mainline sources, but this requires manual integration work and is not a turnkey NXP-supported SDK. Option 3: Migrate to an ARM-Based Layerscape Platform If a newer Yocto SDK (including Wrynose) is a hard requirement, the only path is to migrate the hardware platform to an ARM-based Layerscape processor (e.g., LX2160A, LS1046A, LS1088A), which are fully supported in Wrynose and future NXP Yocto releases. This is a significant hardware redesign effort but aligns with NXP's long-term roadmap. Option 4: NXP Professional/Premium Support If you need custom BSP work or a porting effort for T4240RDB on a newer Yocto baseline, NXP offers Professional Support for Processors and Microcontrollers, which includes Linux/Yocto recipe assistance and direct access to NXP engineers.   regards

i.MX RT1064 - PEmicro 连接助手错误和启动配置意外更改 您好， 我正在使用i.MX RT1064控制器，并通过 MCUXpresso IDE 中的PEmicro Multilink接口进行调试/烧录。 有时，我在尝试连接目标设备时会遇到附件中的“PEmicro 连接助手”错误。这个问题似乎是随机发生的；我还没有发现任何特定的软件活动、代码更改或硬件事件会持续触发信号它。 我观察到，当出现此错误时，控制器的启动配置似乎发生了意外变化。在这种状态下，我无法对设备进行刷机或调试。我目前唯一能恢复的方法是将启动配置恢复到其原始设置——内部闪存模式，之后刷写和调试功能就能再次正常工作了。 一些补充细节： MCU：i.MX RT1064 调试探针：PEmicro 多链路通用 Rev E IDE：MCUXpresso IDE 有人遇到过类似的问题吗？ 我希望您能就以下方面提供指导： 什么原因会导致启动配置意外更改？ 是否存在调试器或应用程序代码可能影响启动配置的已知场景。 防止这种情况发生的建议方法。 能否在不手动更改的情况下通过软件更改启动配置 我附上了错误信息的截图供您参考。 谢谢！ i.MX RT106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好， 您能帮我解答以下问题吗？ 你用的是定制主板还是EVK主板？ 您使用的是哪个版本的SDK和IDE？ 你烧断过熔丝吗？ 您提到需要将启动配置恢复到内部闪存模式——您目前使用的是哪种启动配置？ 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 我使用的是定制电路板，但这个问题在 EVK 上也出现过。 SDK 版本：26.03.00 IDE 版本：25.6.136 我们没有烧断熔丝。 我们通常使用内部启动模式来烧录代码并进行正常操作，但它会随机导致一些意想不到的问题，所以我们将其更改为串行下载模式，擦除闪存，然后再将其改回内部启动模式，之后再次烧录代码。 请查看附件图片以获取启动配置信息。 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好@Subhasri_S ， 通过在 POR_B 的上升沿对 BOOT_MODE0 和 BOOT_MODE1 输入进行采样来初始化 BOOT_MODE 寄存器。对这些输入进行采样后，它们的后续状态不会影响内部 BOOT_MODE 寄存器的内容。 如果 BT_FUSE_SEL = 0，则可以使用 GPIO 引脚而不是 eFuse 来设置特定的启动配置参数。 能否请您在问题出现时，在 RESET 过程中测量一下 BOOT_MODE 和 BT_CFG 引脚的值？ 关于此问题的另一种可能结论，请参阅以下知识库文章： 知识库： RT板恢复调试器连接问题 “当闪存中包含异常应用程序（访问内存不存在、内存损坏、时钟配置错误等）时，会导致板处于未知状态，此时调试器无法控制内核。但是，当将核心置于串行下载器模式时，它将使核心处于已知状态，这样，调试器就可以控制核心。 因此，当RT板出现调试器问题时，尝试在串行下载模式下批量擦除外部闪存，这样就能使板载调试器恢复正常状态。 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 您好，请提供问题发生时记录的 BOOT_MODE 和 BOOT_CFG 引脚值。