Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
FRDM-RW612 (Zephyr) — CTIMER0 MAT0/GPIO0 PWM 不切换,MAT1/MAT2 工作正常 开发板/SDK: FRDM-RW612,NXP-Zephyr v4.3.0 将板载 RGB LED(GPIO0=蓝色,GPIO1=红色,GPIO12=绿色)配置为 CTIMER0 上的 pwm-leds,通道分别为 0/1/2,使用共享 pinctrl-0 组中的 IO_MUX_CT0_MAT0_OUT_IO0、IO_MUX_CT0_MAT1_OUT_IO1、IO_MUX_CT0_MAT2_OUT_IO12。运行测试应用程序,对所有三个通道进行占空比循环测试。 红色和绿色 LED 的 PWM 工作正常(已使用 Saleae 逻辑分析仪确认——GPIO1 和 GPIO12 上的波形干净)。蓝色 LED (GPIO0/MAT0) 完全熄灭——逻辑分析仪显示一条直线,在任何占空比 (0–100%) 下都不会切换。数字GPIO(非PWM)切换GPIO0工作正常, 只有 CTIMER0 MAT0 通道无法输出 PWM;同一定时器实例上的 MAT1/MAT2 可以正常工作。 我们需要: 确认在 Zephyr 下,FRDM-RW612 上的 GPIO0/CT0_MAT0 是否为已知可用的 PWM 组合。 关于 RW612 上 CTIMER0 通道 0 的任何勘误/限制的指导。 任何可用的 .overlay例如,通过 CTIMER 对 GPIO0 进行 PWM 控制,以便我们进行比较。 frdm_rw612.overlay ``` #include / { pwm_outputs { 兼容 = "pwm-leds"; pwm_gpio0:pwm_gpio0 { pwms = <&ctimer0_pwm 0 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; pwm_gpio1:pwm_gpio1 { pwms = <&ctimer0_pwm 1 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; pwm_gpio12:pwm_gpio12 { pwms = <&ctimer0_pwm 2 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; }; 别名 { pwm-gpio0 = &pwm_gpio0; pwm-gpio1 = &pwm_gpio1; pwm-gpio12 = &pwm_gpio12; }; }; ctimer0_pwm: &ctimer0 { 兼容 = "nxp,ctimer-pwm"; 状态 = "好的" clk-source = <5>; clocks = <&clkctl1 MCUX_CTIMER0_CLK>; #pwm-cells = <3>; 模式 = <0>; 预缩放 = <0>; pinctrl-0 = <&pinmux_ctimer0_pwm>; pinctrl-names = "default"; }; &pinctrl { pinmux_ctimer0_pwm:pinmux_ctimer0_pwm { group0 { pinmux = < IO_MUX_CT0_MAT0_OUT_IO0 IO_MUX_CT0_MAT1_OUT_IO1 IO_MUX_CT0_MAT2_OUT_IO12 >; 转换速率 = "正常"; }; }; }; ``` 评估板
記事全体を表示
FRDM-RW612 (Zephyr) — CTIMER0 MAT0/GPIO0 PWM not toggling, MAT1/MAT2 work fine Board/SDK: FRDM-RW612, NXP-Zephyr v4.3.0 Configured on-board RGB LED (GPIO0=Blue, GPIO1=Red, GPIO12=Green) as pwm-leds on CTIMER0, channels 0/1/2 respectively, using IO_MUX_CT0_MAT0_OUT_IO0, IO_MUX_CT0_MAT1_OUT_IO1, IO_MUX_CT0_MAT2_OUT_IO12 in a shared pinctrl-0 group. Ran a test app cycling duty cycle on all three channels. Red and Green LEDs PWM correctly (confirmed with Saleae logic analyzer — clean waveforms on GPIO1 and GPIO12). Blue LED (GPIO0/MAT0) stays completely off — logic analyzer shows a flat line, no toggling at any duty cycle (0–100%). Digital GPIO (non-PWM) toggle on GPIO0 works fine, Only CTIMER0 MAT0 channel fails to output PWM; MAT1/MAT2 on the same timer instance work. What we need: Confirmation whether GPIO0/CT0_MAT0 is a known-working PWM combination on FRDM-RW612 under Zephyr. Guidance on any erratum/limitation for CTIMER0 channel 0 on RW612. Any working .overlay example that PWMs GPIO0 via CTIMER, for us to diff against. frdm_rw612.overlay ``` #include / { pwm_outputs { compatible = "pwm-leds"; pwm_gpio0: pwm_gpio0 { pwms = <&ctimer0_pwm 0 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; pwm_gpio1: pwm_gpio1 { pwms = <&ctimer0_pwm 1 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; pwm_gpio12: pwm_gpio12 { pwms = <&ctimer0_pwm 2 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; }; aliases { pwm-gpio0 = &pwm_gpio0; pwm-gpio1 = &pwm_gpio1; pwm-gpio12 = &pwm_gpio12; }; }; ctimer0_pwm: &ctimer0 { compatible = "nxp,ctimer-pwm"; status = "okay"; clk-source = <5>; clocks = <&clkctl1 MCUX_CTIMER0_CLK>; #pwm-cells = <3>; mode = <0>; prescale = <0>; pinctrl-0 = <&pinmux_ctimer0_pwm>; pinctrl-names = "default"; }; &pinctrl { pinmux_ctimer0_pwm: pinmux_ctimer0_pwm { group0 { pinmux = < IO_MUX_CT0_MAT0_OUT_IO0 IO_MUX_CT0_MAT1_OUT_IO1 IO_MUX_CT0_MAT2_OUT_IO12 >; slew-rate = "normal"; }; }; }; ``` Evaluation Board
記事全体を表示
FRDM-RW612(Zephyr) — CTIMER0 MAT0/GPIO0 PWMが切り替えられず、MAT1/MAT2は問題なく動作します ボード/SDK: FRDM-RW612、NXP-Zephyr v4.3.0 搭載のRGB LED(GPIO0=青、GPIO1=赤、GPIO12=緑)をpwm-ledとしてCTIMER0、それぞれチャネル0/1/2として、IO_MUX_CT0_MAT0_OUT_IO0、IO_MUX_CT0_MAT1_OUT_IO1、IO_MUX_CT0_MAT2_OUT_IO12を共用pinctrl-0グループで構成しました。3チャネルすべてでテストアプリをサイクルサイクルで実行しました。 赤色および緑色のLEDは正しくPWM制御されています(Saleaeロジックアナライザで確認済み - GPIO1およびGPIO12の波形は正常です)。青色LED(GPIO0/MAT0)は完全に消灯したままで、ロジックアナライザは平坦な線を示し、デューティサイクル(0~100%)のいずれにおいてもトグルは発生しません。GPIO0のデジタルGPIO(非PWM)トグルは問題なく動作します。 CTIMER0 MAT0チャネルのみがPWM出力に失敗します。同じタイマーインスタンス上のMAT1/MAT2は動作します。 必要なもの: GPIO0/CT0_MAT0がZephyrのFRDM-RW612上で既知の動作PWM組み合わせであるかどうかの確認。 RW612のチャネル0 CTIMER0に関するエラタムや制限に関するガイダンスがあります。 動作する.overlay例として、CTIMER を介して GPIO0 を PWM する例を挙げ、それと比較します。 frdm_rw612.オーバーレイ 「`」 #include < zephyr/dt-bindings/pwm/pwm.h> / { pwm_outputs { compatible = "pwm-leds"; pwm_gpio0: pwm_gpio0 { pwms = <&ctimer0_pwm 0 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; pwm_gpio1: pwm_gpio1 { pwms = <&ctimer0_pwm 1 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; pwm_gpio12: pwm_gpio12 { pwms = <&ctimer0_pwm 2 PWM_KHZ(1) PWM_POLARITY_NORMAL>; }; }; エイリアス { pwm-gpio0 = &pwm_gpio0; pwm-gpio1 = &pwm_gpio1; pwm-gpio12 = &pwm_gpio12; }; }; ctimer0_pwm: &ctimer0 { compatible = "nxp,ctimer-pwm"; ステータス = "okay" clk-source = <5>; クロック = <&clkctl1 MCUX_CTIMER0_CLK>; #pwm-cells = <3>; モード = <0>; プリスケール = <0>; pinctrl-0 = <&pinmux_ctimer0_pwm>; pinctrl-names = "default"; }; &pinctrl { pinmux_ctimer0_pwm: pinmux_ctimer0_pwm { グループ0 { pinmux = < IO_MUX_CT0_MAT0_OUT_IO0 IO_MUX_CT0_MAT1_OUT_IO1 IO_MUX_CT0_MAT2_OUT_IO12 >; スルーレート = "通常"; }; }; }; 「`」 評価ボード
記事全体を表示
关于 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 引脚值。
記事全体を表示
Wrynose SDK 对 PowerPC 的支持 您好, 我们正在考虑将基于 T4240rdb 的开发板从 Dunfell 迁移到 Wrynose Yocto SDK。Wrynose SDK 是否支持 PowerPC 板? 如果以上方法都不行,我们还有哪些途径可以获得对PowerPC主板的支持? 谢谢! 苏巴拉奥·纳拉贾拉 泰雷兹集团高级工程师 Re: PowerPC support for Wrynose SDK 你好, NXP Wrynose Yocto SDK 不支持 PowerPC/T4240RDB 板。这是所有较新的 NXP Yocto 版本(Dunfell 之后)都存在的既定限制。 为什么 Wrynose 不支持 PowerPC? NXP 的 Wrynose SDK(Yocto 6.0)专门针对基于 ARM 的 i.MX 和 Layerscape 处理器。QorIQ T 系列(包括 T4240)采用Power 架构(e6500 内核) ,但该架构并未延续到较新的 Yocto SDK 版本中。这与恩智浦的整体战略是一致的: “QorIQ SDK 是一款功能齐全、成熟的基于 Yocto 的软件工具包,适用于 QorIQ 基于 PowerPC 的 P 系列和 T 系列处理器……Layerscape SDK 是一款基于 Ubuntu 的混合型软件工具包,适用于 Layerscape 系列处理器,未来将成为 Layerscape 平台上最新软件的主要交付机制。” NXP 官方支持的最后一个适用于 T4240RDB 的 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. 您的选择 方案一:留在邓费尔(推荐给 T4240RDB 用户) QorIQ Yocto SDK 的 Dunfell 分支仍然是 T4240RDB 最新官方支持的 Yocto 版本。您可以通过以下方式访问: https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell 这是 NXP 推荐给需要稳定、受支持的 Yocto 环境的 PowerPC T 系列客户的路径。 方案二:使用社区/上游资源 NXP 针对 Power Architecture P 系列和 T 系列客户的官方建议是,利用上游社区资源获取更新的内核和 U-Boot 版本: “今后,我们鼓励使用基于 Power Architecture 的 P 系列和 T 系列平台的客户直接从 kernel.org 和 denx.de (uboot) 等社区资源获取启用软件。” 这意味着您可以使用主线源代码为 T4240RDB 构建更新的内核(例如 5.x 或 6.x),但这需要手动集成工作,并且不是 NXP 支持的交钥匙 SDK。 方案三:迁移到基于 ARM 的 Layerscape 平台 如果必须使用较新的 Yocto SDK(包括 Wrynose),则唯一的途径是将硬件平台迁移到基于 ARM 的 Layerscape 处理器(例如 LX2160A、LS1046A、LS1088A),这些处理器在 Wrynose 和未来的 NXP Yocto 版本中都得到完全支持。这是一项意义重大的硬件重新设计工作,但符合恩智浦的长期发展路线图。 选项 4:NXP 专业/高级支持 如果您需要定制 BSP 工作或将 T4240RDB 移植到更新的 Yocto 基线,NXP 可提供处理器和微控制器的专业支持,包括 Linux/Yocto 配方协助和直接联系 NXP 工程师。   此致问候
記事全体を表示
i.MX95 Neutron:四分之一的相同 INT4 LLM 测试结果存在 NPU/CPU 差异 摘要 我们在 i.MX95 上运行一个量化的 ONNX,一次在 CPUExecutionProvider 下,一次在 CPUExecutionProvider 下。 NeutronExecutionProvider。两条臂给出的答案并不一致:在 2,466 对配对样本中 多项选择题中,25.7% 的答案与实际答案不同(MMLU 中为 43.6%)。免费 同样的情况也会发生——在 MMLU 提示符下,19 代中有 13 代产生了 不同的答复信。 这不是措辞上的区别。这是模型给出的答案不同的问题。与此同时,综合基准准确率仅下降了 1.8 个百分点。 我们想了解 Neutron 运行时在数值上做了哪些工作,从而产生这些结果。 这一点,以及这种程度的规模是否在预期之内。 设置 请确认您那边可以复现:模型来自 UG10166 表 2,量化方式为: 你自己的配方,未经修改。 - 主板:i.MX95 19x19 EVK (IMX95LPD5EVK-19),LPDDR5 - BSP:LF6.18.2_1.0.0,设备树 imx95-19x19-evk-neutron.dtb - 运行时:来自 BSP 的 ONNX Runtime 1.22.0 + NeutronExecutionProvider - 中子变流器:3.1.3 - 型号:meta-llama/Llama-3.2-1B-Instruct - 量化:NXP/eiq-olive rev aae820e, examples/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 转换:convert_ort_models_to_neutron.py,应用于 CPU arm 的 model.onnx - 环境:NEUTRON_CMA_512SLOTS=6 两条臂均源自同一个量化模型。The NPU Arm is that model passed through convert_ort_models_to_neutron.py。我们记录源图的 安全散列算法 (SHA)-256 值, 外部砝码——在转换时使用,并在每次测量前重新验证,因此 没有第二次量化运行,也没有第二次导出。 我们观察到的 1.每四件物品中就有一件会得到不同的答案。 来自 MMLU、ARC-Challenge 和 PIQA 的 2,466 个配对项目,零次测试,采用对数似然法评分 候选延续 - 每个候选者向前推进一次,不进行生成,不进行抽样。 对于每个基准,首先计算答案发生变化的项目的比例,然后计算答案发生变化的项目的比例。 正确性已改变: - MMLU(4 个选项):43.6% 的答案发生了改变,27.1% 的正确性发生了改变。 - ARC挑战(4个选项):21.3%的答案被修改,13.3%的正确性被修改。 - PIQA(2个选项):9.4%的答案被更改,9.4%的正确性被更改。 总计:答案更改率为 25.7%,正确率更改率为 17.3%。 这两个数字之所以不同,是因为三分之一的变化(634 处变化中的 208 处)是从一个错误值转移到另一个错误值。 对另一个错误答案的回应——一种真正能带来准确性的行为改变 未受影响。由于PIQA是二进制的,因此不存在这种盲点,它的两个数值完全一致。 确切地。 2. 自由生成中也会发生同样的情况——答案本身会发生变化。 50 个提示,贪婪解码,64 个令牌。对于 MMLU 提示符,预期输出开始 连同答题信一起,就可以直接从生成过程中读取答案。 (n = 19): - 两臂答案字母不同:19 封信中有 13 封不同 - CPU 正确率:7/19 - 正确答案:19题中的6题 - 双方都犯错且错误答案不同的分歧:13 例中有 6 例 三分之二的答案发生了变化,但得分基本相同(7 分对 6 分)。 样本量很小——我们仅将其作为示例进行报告;以上2466项测量结果。 是定量分析。 举个例子,原话如此。提示列出了四个选项,并要求写一封信。 预期答案是 😧 CPU:“A\n解释:表达式 9(9m + 3t) 等价于 81m + 27t。 最佳答案是A。 NPU:“C\n最佳答案是C。” 两者都错了,错的点不同,而且没有基准分数会记录这一点。 3. 这种分歧在第一个正向传播中就存在,而不是逐渐积累的。 在这种信件格式中,第一个生成的令牌就是答案,并且有 60% 的生成结果都是如此。 两者之间已经存在差异——这是仅由预填充过程生成的令牌,尚未经过任何解码。 步。在所有 50 个提示中,分歧曲线先急剧上升,然后趋于平缓:84% 令牌 4,98% 到令牌 64。这就是初始差异传播的样子 在贪婪解码模式下,不会通过 KV 缓存累积错误。 4. 总体准确率掩盖了所有这些问题。 CPU 使用率为 50.28%,而 Neutron 使用率为 48.50%,相差 1.78 个百分点,且没有其他问题。 三个基准指标各自都具有重要意义。仅限于以下 634 项: 双方意见不一致,CPU 的正确率是 37.1%,而 Neutron 的正确率是 30.1%——235 对 在已决定的项目中,有 191 个,即 55/45,而对称噪声会给出 50/50。 我们排除了哪些选项 - 静默 CPU 回退:ORT 分析报告显示 80/80 个 MatMulNBits 处于开启状态 NeutronExecutionProvider,CPU 占用率为 0。不进行局部植入。 - 两种不同的模型:相同的源文件,图的 安全散列算法 (SHA)-256 值和外部权重 转换时记录,并在得分前重新核实。 - 采样:全程贪婪解码;无温度、无 top-k、无 top-p。 - 不同的输入:两个 Arm 都从同一个物品文件中按相同的顺序读取数据。 相同的固定种子。 - 评分指标:板 仅 捕获 每个标记的对数概率;所有决策 逻辑在主机上离线运行,两个 Arm 的逻辑完全相同。 - NPU 上的运行间噪声:在同一 Neutron 会话中重复播放相同的项目 产生比特相同的对数概率。NPU Arm是可重复的;差异 这是针对CPU的,而不是针对CPU本身的。 我们的问题是 这是 Neutron-S 上 INT4 路径的预期行为吗?如果是,我们应该怎么做? 验证在 NPU 上部署 LLM 的可行性,前提是总体基准测试准确率明显高于预期。 没有显示出来吗? 我们并未假定存在缺陷。浮点CPU内核和 整数 NPU 路径是正常的,我们想知道您认为的量级是多少。 正常情况下,你们接受 LLM 端口到 Neutron 的标准是什么?如果 四分之一的答案发生变化在预期之内,这对我们来说是件好事。 了解并围绕其进行设计。 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 只能运行矩阵乘法运算,其 LLM 性能在 NPU 上实际上只是中等水平。因此,您观察到的现象在可预测的范围内,我们不建议在 NPU 上运行 LLM 模型。 B.R
記事全体を表示
Audifortレビュー:本当に一晩で耳鳴りを止めることができるのか? Audifortレビュー:本当に一晩で耳鳴りを止めることができるのか? 毎日耳鳴り、ブンブン、カチカチという音に悩まされているなら、救いを求める過程がどれほど必死になるかをご存知でしょう。オンラインで解決策を探していると、次のような液体栄養剤の積極的な広告を目にするかもしれません。 オーディフォート それは、即効性がある、あるいは一晩で耳鳴りが解消されるといったことを示唆するものです。 簡潔に言うと、答えはノーです。Audifortは耳鳴りを一夜にして止めるものではありません。 経口サプリメントや天然の点滴薬では、慢性的な耳鳴りを即座に治したり、損傷した聴神経を24時間以内に再生したりすることはできません。 しかし、だからといってその公式が無意味だというわけではない。奇跡の治療薬ではなく、天然の栄養補助食品として現実的に評価すると、オーディフォートは内耳の血管を栄養し、過剰に活動している神経信号を時間をかけて鎮めるのに役立つ栄養素を提供します。 この Audifortのレビューでは、販売促進のためのマーケティングにとらわれず、このドロップが実際にどのように作用するのか、その主要成分、現実的な効果発現までの期間、潜在的な副作用、そして偽のオンライン広告を回避する方法などを分析します。
記事全体を表示
88W8887 射频合规性测试 亲爱的, 我们使用的是基于 88W8887 芯片组的 wifi/蓝牙模块。为了确保产品符合规范,我们需要进行多项射频测试(tx 连续数据包、rx 模式等)。对于另一个模块 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团队提交工单以获取访问权限。 顺祝商祺! 肖恩
記事全体を表示