S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hello, I am bringing up a battery-management application on an S32K344 (172-pin MQFP) custom board whose SPI wiring follows the NXP RD33772C14EVM reference design. I am using S32 Design Studio 3.5 with RTD 3.0.0 (the Platform, Port and Spi modules all report SW version 3.0.0) and the FS26 SBC CDD 2.0.0 (Sbc_fs26). My starting point is the Sbc_fs26_example_HLD example for S32K344. In my system LPSPI0 is reserved for a future two-channel daisy-chain and the other SPI instances are already in use, so the FS26 SBC has to run on LPSPI4. Following the RD33772C14EVM schematic, I routed the four LPSPI4 signals to the same pads the reference design uses: lpspi4_pcs0 on PTB8, lpspi4_sout on PTB9, lpspi4_sck on PTB10 and lpspi4_sin on PTB11. On the peripheral side I set the SPI physical-unit mapping to LPSPI_4, left SpiHwUnit at CSIB0, and enabled the LPSPI_4 peripheral-clock gate in the Mcu component. After running "Update Code" and building, the compiler stops with errors in the generated file generate/src/Siul2_Port_Ip_VS_0_PBcfg.c. The generator has produced an assignment with no right-hand side: ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: error: expected expression before ',' token 118 | .slewRateCtrlSel = , The same empty .slewRateCtrlSel = , appears at lines 158, 198 and 238 — one for each of the four LPSPI4 pins. If I manually fill those four lines with PORT_SLEW_RATE_NOT_AVAILABLE, the build gets a little further and then fails the same way on .inputMuxReg = { (empty initializer, "ISO C forbids empty initializer braces"). In other words, the pin-configuration structures for these four pads are generated with empty fields that are not valid C. When I look at the Pins tool "Routing Details" for PTB8–PTB11, the Slew Rate Control column (and the Input Filter column) shows n/a, and selecting the Slew Rate cell shows the tooltip: "The selected pin does not support the configuration of this feature. Selects the slew rate control." So these particular pads simply have no slew-rate-control hardware. My understanding is that in that case the generator should emit PORT_SLEW_RATE_NOT_AVAILABLE (that value does exist in the Siul2_Port_Ip_PortSlewRateControl enum on this device), the same way it uses *_NOT_AVAILABLE values for other unsupported pad features — but instead it emits nothing, which breaks the build. What convinces me this is a tool/driver problem rather than a wrong pin choice is that NXP's own LVBMS_RD_Bring_up_Example uses the exact same four LPSPI4 pads (PTB8/PTB9/PTB10/PTB11) for the FS26 SBC and builds cleanly. The only difference I can find between that example and my project is the RTD version: the LVBMS example is built on RTD 2.0.0 (Platform/Port/Spi SW 2.0.0), while my project uses RTD 3.0.0. Same board pinout, same four pins, and the pin electrical features are identical (only direction is set in both). So it really looks like the Siul2_Port_Ip code generation for slew-rate-unsupported pads regressed between RTD 2.0.0 and RTD 3.0.0. My questions: Is this a known issue in RTD 3.0.0, and is there a fixed / patched RTD release? What is the correct, supported way to configure LPSPI4 on PTB8–PTB11 (the RD33772C14EVM pinout) under RTD 3.0.0 so that the Pins tool generates valid code — i.e. slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE and a valid inputMuxReg, instead of empty fields? If there is no configuration-level fix, is editing the generated Siul2_Port_Ip_VS_0_PBcfg.c by hand the only workaround (it is overwritten on every "Update Code"), or is moving the project to Port/RTD 2.0.0 the recommended path? I can attach the full build log, the Pins "Routing Details" screenshot with the tooltip, and a side-by-side of the two projects' module versions if that helps. Thank you, Hyunsik Song Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi VaneB, Thank you very much — that was exactly the problem. The Pins tool had been updated to LPSPI4 (PTB8–PTB11), but the Port component's PortPin entries were still pointing at the original LPSPI0 pads, so the PortPin Pcr (Mscr) values were stale. I updated the four PortPin Pcr values in the Port configuration to match the new pin assignment: PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10 (Pcr 42) SIN → PTB11 (Pcr 43) After running Update Code and rebuilding, the empty .slewRateCtrlSel / .inputMuxReg errors in Siul2_Port_Ip_VS_0_PBcfg.c are gone and the project builds cleanly. I really appreciate the quick and precise answer — it saved me a lot of time. Marking this as the solution. Best regards, Hyunsik Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi @hyunsiksong  This issue is not related to the RTD itself, nor with the code generated by the S32DS Configuration Tools. Instead, it is related to the configurations. In the Port driver configuration within the Peripheral Tool, the values assigned to the PortPin Mscr parameters still correspond to the original project configuration. For example, the project was previously configured to use PTB1 as LPSPI0_PCS0, corresponds to PortPin Mscr = 33. In the updated configuration, however, LPSPI4 is being used and PCS0 has been reassigned to pin 8. Therefore, the corresponding PortPin Mscr value should be 40 instead of 33. Review the PortPin Mscr for all the pins and ensure they match the current pin assignments Updating these values to reflect the new configuration should resolve the issue. BR, VaneB

S32K311 RTD 5.0 - リンカーエラー: .non_cacheable_bss.int_resultsとのオーバーフローおよび重複 こんにちは、NXP チームの皆様、 私は以下の環境を使用してS32K311プロジェクトに取り組んでいます。 MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 問題 当初、プロジェクトは順調にビルディングされていました。 プロジェクトが進むにつれて、ADC、eMIOS、LCU、ICU、PIT、PORT、LPUART、LPSPI、TRGMUX、MCLなど、いくつかのRTDドライバを有効化・設定し、アプリケーションに必要なその他のペリフェラルを活用しました。 これらのドライバを統合した後、プロジェクトはリンク段階で以下のエラーで失敗します。 .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status メモリレイアウト デフォルトのリンカスクリプトには、以下のSRAM領域が含まれています。 int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 リンカーは、 .non_cacheable_bssがこのセクションは、割り当てられた int_sram_no_cacheable 領域を約440 バイト超過しています。 質問 複数のRTDドライバがS32K311で有効になっている場合、このメモリ使用は予想されますか? .non_cacheable_bssのサイズを減らすための推奨方法はありますか? リンカースクリプトを修正してint_sram_no_cacheable領域を増やすことは推奨されますか？もしそうなら、S32K311の推奨メモリ配置はどうなっていますか? キャッシュできないセクションに割り当てられるメモリを減らすRTDの設定オプションはありますか? 複数のRTDペリフェラルを統合する際に同じような問題に遭遇した方はいらっしゃいますか? 何かご助言や解決策をご提案いただければ大変ありがたいです。 よろしくお願いします。 Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results こんにちは、 @Esakkiさん 以下のディスカッションThreadは、似たような問題を扱い、有用なトラブルシューティングの提案を提供してくれるので役立つかもしれません。 int_sram_no_cacheable の問題 S32K312のSRAMがオーバーフローする さらに、S32K3のアプリケーションノートには、リンカーファイルやスタートアップコードについてより詳しく説明されており、メモリ領域の変更やカスタマイズ方法も含まれています。 AN14893 : S32K3xx リンカーファイルとスタートアップコード この最後のThreadでは、コード最適化技術に関するいくつかの提案が含まれています。 S32K3xxでAPPのコードを最適化してパフォーマンスを向上させる方法 BR、VaneB

Spi transmission using burst registers Hello NXP, Target uC : S32K388 I am using the burst registers TCBR and TDBR0-127 for SPI transmissions using eDMA. Current frame size is 32 bits and everything works as expected Now for an SPI frame size which is less than 32 bits, how can the burst registers be used without changing the dma transfer size, in between. Can TCBR be written in 16 or 8 bit units. Can TDBRn be written in 16 or 8 bit units If not, could you give hints as to how to setup the dma channel for frame sizes 16 and 8 bits. Thanks in advance  Re: Spi transmission using burst registers Yes, both TCBR and TDBRn support 16-bit and 8-bit writes — no DMA transfer size change is needed. TDBRn (16-bit or 8-bit write): Both zero-extend the written data and immediately push it into the transmit FIFO. LPSPI will clock out only the bits defined by TCR[FRAMESZ] . TCBR (16-bit write to [15:0]): Pushes one command entry into the FIFO. Note: an 8-bit write to [7:0] only stages the data — a second 8-bit write to [15:8] is required to trigger the push. RM reference — S32K3xx Reference Manual, Rev. 12, 2025-11-11: Section 70.6.1.17 — Transmit Data (TDR):   "You can write to this register using 32-, 16-, or 8-bit writes. Both 8-bit and 16-bit writes of transmit data zero-extend the data written and push the data into the transmit FIFO. To zero-extend 8-bit and 16-bit writes (to 32 bits) means that the higher order (most significant) empty parts of the 8-bit and 16-bit writes are filled with zeroes." Section 70.3.6.1 — DMA support registers (TCBR / TDBR0–TDBR127): Documents the burst alias region designed for incrementing 8-bit, 16-bit, or 32-bit DMA write accesses to the transmit FIFO.   Re: Spi transmission using burst registers Reg TCBR, if the 16 bit write to [15:00] or the second 8-bit write to [15:8] pushes the data into the FIFO as a command entry, how can the entire TCR be updated. Only the frame size selection is available on the lower half word. The other settings like CPOL,CPHA,PCS etc comes in the upper half word.

HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am currently working on the i.MX95 FRDM EVK board using Zephyr RTOS. On the Linux side, HDMI output is already supported and working correctly. However, I would like to know how to enable and configure HDMI in Zephyr. Could you please guide me on the following? Does Zephyr support HDMI output on the i.MX95 FRDM EVK? If yes, what drivers and Device Tree configurations are required? Is there any reference implementation or sample application available for HDMI on Zephyr? Any guidance or documentation would be greatly appreciated. Thank you. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I confirmed with the AE team. HDMI is not supported in IMX95 Zephyr currently.  Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am looking for the IT6263 Reference Manual or Register Programming Manual. Could you please share the detailed register descriptions (register map with bit-level definitions) for the IT6263 HDMI bridge, or let me know how I can obtain this documentation? Note: I am specifically looking for the chip-level register documentation itself, not the Linux kernel driver source. Thank you, Karthikeyan M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 is not an NXP product, so NXP does not provide a Reference Manual for this device. For configuration and initialization details, you can refer to the IT6263 Linux driver source code. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response and for providing the Arm Support links. I will contact Arm Support regarding the Arm Mali-G310 Technical Reference Manual and the CSF/Firmware Interface documentation. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I have successfully ported HDMI on Zephyr OS, and it is currently running on the CPU. My next goal is to port it to run on the GPU. For this, I need the Arm Mali-G310 Technical Reference Manual, specifically the CSF/Firmware Interface section. Should I request this document from NXP Support, or do I need to contact Arm Support directly? Having access to this reference manual would be very helpful for implementing the GPU port on Zephyr Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please contact Arm Support directly. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response. Could you please share the specific contact email or support portal for Arm Support? If you have a direct contact or the appropriate email address, it would be very helpful. I will contact them regarding this issue. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm Support Hub: https://support.arm.com/support-cases   Support Inquiries Form: https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for the links to the Arm portal and the i.MX Graphics User's Guide. We looked at both, but they don't cover what we need. Those guides explain how to use the GPU under Linux, and we are writing our own low-level GPU driver on i.MX95 (bare-metal, using Zephyr, not Linux). So we need lower-level, register-level information than those documents provide. In the ARM portal, we have searched for the TRM, but it is unavailable. Here is our situation in short:   We have got the Mali-G310 GPU working up to a certain point. The GPU is detected correctly, powered on, reset, and we have loaded the GPU firmware into memory successfully. Everything up to this stage works and is verified.   We are stuck at one step: starting the GPU's firmware microcontroller (the MCU). After we enable it, its status stays "disabled" and it never starts running. There is no error and no interrupt - it simply does not boot.   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please check whether the following information would be helpful. If no, I need to contact the AE team. The Arm Mali-G310 Technical Reference Manual is available from Arm’s documentation portal: search Arm Developer / Arm Documentation for “Mali-G310 Technical Reference Manual” or “Mali-G310 TRM” . It may require an Arm account or acceptance of Arm documentation terms, depending on access level. For NXP i.MX95 work, NXP’s public documentation points to the Mali-G310 GPU through the i.MX Graphics User’s Guide , and the FRDM-i.MX95 getting-started page links that guide for GPU usage details. The FRDM-i.MX95 page states that the board has a Mali-G310 GPU and links the i.MX Graphics User’s Guide for more details: https://www.nxp.com/docs/en/user-guide/UG10159.pdf  Start here: Arm documentation portal:https://developer.arm.com/documentation NXP i.MX Graphics User’s Guide:https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please refer to the following update from the AE team. Regarding the Arm Mali-G310 TRM, this document is Arm confidential IP. NXP is not permitted to forward it to end customers, so it is essentially unavailable through NXP channels. A formal request would have to go through Arm directly, which takes a long time and is unlikely to be granted. In addition, the i.MX95 GPU is still in the pre-production stage, so there is no officially validated bare-metal/Zephyr reference at this time. Regarding the MCU staying "disabled" after enable, this step does not require the TRM. The complete boot flow is available in the following two public sources, both accessible directly on GitHub: Panthor — mainline driver, the main one to look at (it actually boots the MCU and supports i.MX95): https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm's official driver, for cross-checking: https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

S32K344 RTD 3.0.0：空 .slewRateCtrlSel为 LPSPI4 引脚生成 — 版本失败 你好， 我正在 S32K344（172 引脚 MQFP）定制板上开发一个电池管理应用程序，该板的 SPI 布线遵循 NXP RD33772C14EVM 参考设计。我正在使用 S32 Design Studio 3.5 和 RTD 3.0.0。（平台、端口和 Spi 模块均报告软件版本为 3.0.0）以及 FS26 SBC CDD 2.0.0 (Sbc_fs26)。我的出发点是 S32K344 的 Sbc_fs26_example_HLD 示例。 在我的系统中，LPSPI0 已预留给未来的双通道菊花链，而其他 SPI 实例已被使用，因此 FS26 SBC 必须在 LPSPI4 上运行。按照 RD33772C14EVM 原理图，我将四个 LPSPI4 信号连接到参考设计使用的相同焊盘：lpspi4_pcs0 连接到 PTB8，lpspi4_sout 连接到 PTB9，lpspi4_sck 连接到 PTB10，lpspi4_sin 连接到 PTB11。在外围设备方面，我将 SPI 物理单元映射设置为 LPSPI_4，将 SpiHwUnit 设置为 CSIB0，并在 Mcu 元器件中启用了 LPSPI_4 外围时钟门。 运行“更新代码”并构建后，编译器停止运行，生成的文件 generate/src/Siul2_Port_Ip_VS_0_PBcfg.c 出现错误。生成器生成的赋值语句没有右侧等式： ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: 错误：应在逗号 (,) 前插入表达式 118 | .slewRateCtrlSel=， 同样的空 .slewRateCtrlSel等号出现在第 158、198 和 238 行——分别对应四个 LPSPI4 引脚。如果我手动将这四行填充为 PORT_SLEW_RATE_NOT_AVAILABLE，版本会继续进行下去，然后在 .inputMuxReg 处以相同的方式失败。= {（空初始化器，“ISO C 禁止空初始化器大括号”）。换句话说，这四个焊盘的引脚配置结构生成的字段为空，这不是有效的 C。 当我查看 PTB8–PTB11 的“引脚”工具“布线详情”时，“转换速率控制”列（以及“输入滤波器”列）显示为“n/a”，选择“转换速率”单元格时，工具提示显示：“所选引脚不支持此功能的配置。”选择转换速率控制。所以这些特殊的垫子根本没有转换速率控制硬件。我的理解是，在这种情况下，生成器应该发出 PORT_SLEW_RATE_NOT_AVAILABLE（该值确实存在于此设备的 Siul2_Port_Ip_PortSlewRateControl 枚举中），就像它对其他不支持的 pad 功能使用 *_NOT_AVAILABLE 值一样——但它却什么也没发出，这导致版本失败。 让我确信这是工具/驱动程序问题而不是引脚选择错误的原因在于，NXP 自己的 LVBMS_RD_Bring_up_Example 使用了完全相同的四个 LPSPI4 焊盘（PTB8/PTB9/PTB10/PTB11）来构建 FS26 SBC，并且版本构建顺利。我发现该示例与我的项目之间唯一的区别是 RTD 版本：LVBMS 示例基于 RTD 2.0.0（平台/端口/Spi 软件 2.0.0），而我的项目使用 RTD 3.0.0。电路板引脚排列相同，四个引脚相同，引脚的电气特性也相同（两者仅方向设置不同）。所以看起来，RTD 2.0.0 和 RTD 3.0.0 之间，Siul2_Port_Ip 代码生成对于不支持压摆率的 pad 确实出现了倒退。 我的问题： 这是RTD 3.0.0中的已知问题吗？是否有已修复/已打补丁的RTD版本？ 在 RTD 3.0.0 版本下，配置 PTB8–PTB11（RD33772C14EVM 引脚排列）上的 LPSPI4 的正确且受支持的方法是什么？这样，引脚工具就能生成有效的代码——例如，slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE 和一个有效的 inputMuxReg，而不是空字段？ 如果没有配置级别的修复，手动编辑生成的 Siul2_Port_Ip_VS_0_PBcfg.c 是唯一的解决方法吗（每次“更新代码”都会覆盖它），还是将项目迁移到 Port/RTD 2.0.0 是推荐的方案？ 如果需要，我可以附上完整的构建日志、带有工具提示的引脚“布线详情”屏幕截图，以及两个项目模块版本的并排对比图。 谢谢你， 宋炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 嗨 VaneB， 非常感谢——问题果然出在这里。Pins 工具已更新为 LPSPI4 (PTB8–PTB11)，但Port元器件的 PortPin 条目仍然指向原始的 LPSPI0 焊盘，因此 PortPin Pcr (Mscr) 值已过时。 我已将端口配置中的四个 PortPin Pcr 值更新为与新的引脚分配相匹配： PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10（Pcr 42） SIN → PTB11 (Pcr 43) 运行更新代码并重新构建后，.slewRateCtrlSel 文件为空。/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c 中的错误已消失，项目可以顺利构建。 我非常感谢您快速而准确的答复——这为我节省了很多时间。标记为解决方案。 此致， 炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 你好@hyunsiksong 这个问题与 RTD 本身无关，也与 S32DS 配置工具生成的代码无关。相反，它与配置有关。 在外设工具的端口驱动程序配置中，分配给 PortPin Mscr 参数的值仍然与原始项目配置相对应。例如，该项目之前配置为使用 PTB1 作为 LPSPI0_PCS0，对应于 PortPin Mscr = 33。 然而，在更新后的配置中，使用的是 LPSPI4，并且 PCS0 已重新分配给引脚 8。因此，相应的 PortPin Mscr 值应为 40 而不是 33。 检查所有引脚的 PortPin Mscr，确保它们与当前的引脚分配匹配。更新这些值以反映新的配置应该可以解决问题。 BR，VaneB

MCUXpresso Secure Provisioning ToolからFCBデータを構築する方法 こんにちは、 現在、RT1010 EVKボードでOTFADの設定をテストしています。 MCUXpresso Secure Provisioning Tool 26.03を使用してOTFADを設定し、バイナリファイルを生成するプロジェクトをビルドしたいと考えています。 ビルド結果は以下のとおりです。 MIMXRT1011_プロジェクト.bin MIMXRT1011_Project_hab.bin otfad_keyblobs.bin unsigned_MIMXRT1010_flashloader.bin これらが4つのファイルです。 MCUXpresso Secure Provisioning Tool 26.03 を使用して書き込み操作を実行し、フラッシュメモリを読み取ると、プログラムは 0x0400 領域に FCB と思われるデータを含めます。 しかし、ビルドされたファイルの中にFCBに対応するファイルが見当たらないようです。 ビルドプロセス中にFCB情報を含むファイルを生成することは可能ですか？ i.MXRT 101x Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool ご返信よろしくお願いします。 あなたが提供してくれたリンクを参考に、FCBを作成しました。 もう一つ質問があります。 OTFAD設定のリージョン0情報のキーデータに関する説明はどのドキュメントで見られますか? 私が気になっているのは、ユーザーキーデータとカウンターデータセクションです。 説明してもらえますか? よろしくお願いします。 TnseoRnr_0-1785208042935.png Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool こんにちは、 @TnseoRnr さん。 SPTドキュメントの以下のリンクをご覧ください。簡易設定から完全なFCBを作成する手順が明記されています:https://mcuxpresso.nxp.com/secure/26.03/05_user_interface.html#spi-nor また、FCBはペリフェラルツールを使ってMCUXpressoから作成できるとも書かれています。 最後に一つ、SPTの新しいバージョン(v26.06)が存在することを覚えておいてください。最新バージョンの開発を続けることをお勧めします。 BR、 エドウィン。 Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool こんにちは、 @TnseoRnr さん。 これらのフィールドが作成中の OTFAD 構成でどのように使用されるかという意味であれば、おそらく次のリンクが参考になるでしょう: https://mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#booting-otfad-encrypted-image-unsigned-with-user-keys とはいえ、これらの鍵の内部構造やより詳細な説明を求める場合は、RT1010のセキュアファイルへのアクセスを申請し、RT1010のセキュリティ機能を詳細に説明したセキュリティリファレンスマニュアルを参照する必要があります。 このファイルのダウンロードやアクセス申請は、RT1010製品ページのドキュメントセクションの「Secure」チェックボックスをクリックすることで表示されます。 https://www.nxp.com/products/i.MX-RT1010#documentation BR、 エドウィン。

i.MX93ボードを再プロビジョニングすることは可能ですか？ すでにEdgeLock 2GOを使ってFRDM i.MX93ボードのプロビジョニングを完了しており、プロビジョニングは無事完了しています。 今は同じボードに、キーペアやX.509証明書などの新しいまたは更新されたセキュアオブジェクトセットで再プロビジョニングしたいと考えています。 すでにプロビジョニング済みのi.MX93デバイスでの再プロビジョニングはサポートされていますか? もしそうなら、推奨される手順を教えていただけますか?具体的には、以前にプロビジョニングされたセキュアオブジェクトは、再度プロビジョニングする前に削除またはリセットする必要がありますか?それともEdgeLock 2GOを通じて更新できるのでしょうか? また、再プロビジョニングを試みる前に知っておくべき制限や不可逆的な設定はありますか? ログは:-- エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 0xffffffffで故障 Status(oem-prov-app): FAILURE(Status(oem-prov-app): FAILURE(FAILURE) FRDMトレーニング ハンズオン・トレーニング Security Yocto Project Re: Is it possible to reprovision the i.MX93 board? こんにちは、 再プロビジョニングも可能であり、EdgeLock 2GOは初期展開後の証明書や鍵の更新、ローテーション、取り消しを含む完全なライフサイクルマネジメントを目的に設計されています。 安全なプロビジョニングのためにどのような手順を踏みましたか? キーやライフサイクルなど、ヒューズ内の焼き付き構成に関わる手順について理解しておく必要があります。 よろしくお願いいたします。 Re: Is it possible to reprovision the i.MX93 board? サービスレベルでの再プロビジョニングがサポートされていることを確認していただきありがとうございます。明確にしておきますが、これは新規のプロビジョニング試行ではなく、既に一度正常にプロビジョニングされたボード（ライフサイクルOEM_OPEN、ELEファームウェア2.0.5-7a34cee、初回プロビジョニング時に既にキーと証明書オブジェクトが存在する状態）に対する再プロビジョニング試行です。 この 2 回目のパスで、oem-prov-app は iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内の mbedtls_pk_setup_opaque() 呼び出しで失敗し、MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180) を返します。バージョン: el2go-agent 6.4.2-r0、smw 5.3-r0、mbedtls 3.6.5-r0。 2つの質問があります。 1.再プロビジョニングでは、oem-prov-appを再実行する前に、既存のキーオブジェクトを明示的に消去する必要がありますか（psa_destroy_keyまたはSMWキーストレージAPI経由）、それともエージェントが同じキーIDで上書きする必要がありますか？現在、明示的な消去手順は実行していません。 2. el2go-agent 6.4.2-r0 と smw 5.3-r0 の間には、特に再プロビジョニング/更新パスに関して既知の互換性の問題がありますか？というのも、初期起動時にも同じエラーが発生し、そこでもバージョン不一致が疑われたからです。 また、プロビジョニングされた鍵と証明書オブジェクトがELE管理のNVMに存在しているのか確認できますか?つまり、再プロビジョニングに失敗してもその鍵IDが永久に使えなくなるわけではありません。 Re: Is it possible to reprovision the i.MX93 board? こんにちは、 情報ありがとうございます。 1. はい、署名付きメッセージを使用してキーストアの再プロビジョニングを実行してください。キーストアの再プロビジョニングを行うと、HSMによって管理されているすべてのキーストアが消去されます。 2. いいえ、互換性の問題は報告されていません。 3. その通り、アプリケーション鍵や証明書はヒューズではなくELE管理のNVMに保存されます。 よろしくお願いいたします。

IMX95 Aquila ISP usage Hello, I bought an Aquila IMX95 Evaluation Kit 2 with two ov5640 sensors (https://www.toradex.com/cart). I have the drivers for the sensors. The board is flashed correctly, with the isp module active : root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 The cameras are showing in libcamera : root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) Just to check if the mipis are fine, I started a gstreamer pipeline and managed to get a stable 30fps stream on both cameras. I also managed to take snapshots with v4l2-ctl. Now, I'd like to test the Aquila's ISP with my cameras to see what it can do. Following the https://www.nxp.com/docs/en/user-guide/UG10215.pdf I added the environment variable : root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' But, doing so, the camera is not detected anymore by libcamera and I don't know why : root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# Thank you for your reply ! Cordially, Re: IMX95 Aquila ISP usage After looking at your logs, I believe the issue is not related to the MIPI interfaces or the OV5640 driver itself. The fact that: both OV5640 cameras are detected by libcamera GStreamer can stream at 30 fps v4l2-ctl can capture images indicates that the sensor drivers, I2C communication,  CSI-2  links and media topology are all working correctly. The key point is that the NXP Neo ISP pipeline expects a RAW Bayer sensor input. OV5640 is a SoC image sensor with its own internal image processing pipeline, and in the NXP BSP it is typically used in YUV output mode (for example YUV422) rather than as a RAW Bayer sensor. In such a configuration, the camera can be used through the standard V4L2/libcamera pipeline, but it does not match the requirements of the Neo ISP pipeline. This would explain why: `cam -l` shows both OV5640 cameras by default after setting export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' no cameras are detected anymore The cameras are still present in the system, but the NEO pipeline handler cannot find a compatible camera topology and therefore exposes zero cameras to libcamera. To verify the actual sensor output format, could you please provide the outputs of: ```bash media-ctl -p v4l2-ctl --list-formats-ext We are particularly interested in whether the sensor exposes any RAW Bayer formats such as: SBGGR8 SBGGR10 SRGGB10 RG10 BA10 If only YUV formats (for example YUYV/UYVY) are available, then the camera is not operating in RAW mode and cannot be processed by the Neo ISP pipeline. Although the OV5640 hardware is capable of RAW Bayer output, RAW support is not commonly enabled in BSP camera drivers, and the NXP Neo ISP stack also relies on sensor-specific tuning data. Even if RAW output can be enabled, the absence of a dedicated OV5640 tuning profile may prevent proper ISP operation (AE/AWB/image quality tuning). If your goal is to evaluate the Neo ISP framework itself, it may be easier to use a sensor that is known to work with the NXP ISP stack. Common candidates include: OS08A20 OX03C10 OX05B1S AR0521 AR1335 (may require additional tuning work) Could you share the output of the commands above? That will allow us to confirm whether the current OV5640 configuration is exposing RAW Bayer formats to the system. Best regards, Re: IMX95 Aquila ISP usage Thanks for the reply. I did some additional checks: You were right and the OV5640 was initially running in UYVY mode, but I manually switched one sensor to RAW Bayer (SRGGB8). media-ctl -p now shows:   root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] (The second OV5640 remains in UYVY mode for comparison) So : OV5640 -> SRGGB8 CSI -> SRGGB8 Formatter -> SRGGB8 Crossbar -> SRGGB8 => RAW Bayer is successfully propagated through the sensor, CSI and formatter. The neoisp kernel module is loaded: root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 An ISP node is present in the running device tree:   /sys/firmware/devicetree/base/soc/isp@4ae00000   => However, I only see a single media device (/dev/media0) exposing the CSI/Formatter/ISI pipeline. No neoisp entity appears in the media graph. I do not see any neoisp entity in the media graph, and I do not know whether this is expected. => cam -l (libcamera) still returns no available cameras. At this point the RAW Bayer path appears functional, but I cannot identify where the Neo ISP becomes part of the active pipeline.   How can I verify that the stream is actually processed by the Neo ISP rather than simply following the CSI -> Formatter -> ISI path?   Also, is https://www.nxp.com/docs/en/user-guide/UG10215.pdf still the recommended guide for this setup, or is there a more specific reference for OV5640 + Neo ISP on i.MX95?       Cordially, Re: IMX95 Aquila ISP usage My current suspicion is that one of the following is happening: OV5640 is running in YUV mode rather than RAW Bayer mode (most likely). The camera DT overlay is not the ISP-enabled variant. The Neo IPA/calibration components are missing from the root filesystem. The media topology seen by the Neo pipeline does not match the expected i.MX95 ISP graph. The media-ctl -p output will usually pinpoint which of these is the actual issue. Re: IMX95 Aquila ISP usage Hello ! Here is the output : root@imx95-1:~# v4l2-ctl --list-formats-ext -d /dev/video2 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'YUYV' (YUYV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [1]: 'YUVA' (32-bit YUVA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [2]: 'NV12' (Y/UV 4:2:0, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [3]: 'NM12' (Y/UV 4:2:0 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [4]: 'NV16' (Y/UV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [5]: 'NM16' (Y/UV 4:2:2 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [6]: 'YM24' (Planar YUV 4:4:4 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [7]: 'RGBP' (16-bit RGB 5-6-5, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [8]: 'RGB3' (24-bit RGB 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [9]: 'BGR3' (24-bit BGR 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [10]: 'XR24' (32-bit BGRX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [11]: 'AR24' (32-bit BGRA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [12]: 'RA24' (32-bit ABGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [13]: 'AB24' (32-bit RGBA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [14]: 'RX24' (32-bit XBGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [15]: 'XB24' (32-bit RGBX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [16]: 'AR30' (32-bit ARGB 2-10-10-10, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [17]: 'GREY' (8-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [18]: 'Y10 ' (10-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [19]: 'Y12 ' (12-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [20]: 'Y14 ' (14-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [21]: 'BA81' (8-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [22]: 'GBRG' (8-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [23]: 'GRBG' (8-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [24]: 'RGGB' (8-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [25]: 'BG10' (10-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [26]: 'GB10' (10-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [27]: 'BA10' (10-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [28]: 'RG10' (10-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [29]: 'BG12' (12-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [30]: 'GB12' (12-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [31]: 'BA12' (12-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [32]: 'RG12' (12-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [33]: 'BG14' (14-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [34]: 'GB14' (14-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [35]: 'GR14' (14-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [36]: 'RG14' (14-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [37]: 'BYR2' (16-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [38]: 'GB16' (16-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [39]: 'GR16' (16-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [40]: 'RG16' (16-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [41]: 'MJPG' (Motion-JPEG, compressed, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 If I read it correctly, camera does take raw bayer, and I configured it to aswell (hopefully I did it correctly). I'll try to flash again with another image to see if the issue is somewhere around there. Cordially, Re: IMX95 Aquila ISP usage Thank you for the update. The  v4l2-ctl  output confirms that the ISI capture node supports RAW Bayer formats, and the  media-ctl -p  output from your previous message already shows that the RAW Bayer path is correctly propagated through the pipeline: OV5640 (SRGGB8) -> CSI (SRGGB8) -> Formatter (SRGGB8) -> Crossbar (SRGGB8) So the sensor-side configuration looks correct. The core issue now is that the  neoisp  module is loaded but does not appear in the media graph, and no  /dev/media1  is created. This typically indicates that the  neoisp  driver loaded successfully as a kernel module but failed during device probe, which would prevent it from registering a media device. Could you please provide the following diagnostic information: # Check neoisp probe status dmesg | grep -i neoisp dmesg | grep -i "isp@4ae" dmesg | grep -i "probe failed" dmesg | grep -i "4ae00000" # Confirm all available media devices ls -la /dev/media* # Check neoisp status in sysfs ls /sys/bus/platform/drivers/nxp-neoisp/ cat /sys/firmware/devicetree/base/soc/isp@4ae00000/status In parallel, we would also like to ask: do you have access to any of the following sensors that are officially supported by the NXP Neo ISP stack with complete tuning profiles? OS08A20 OX03C10 OX05B1S Testing with one of these sensors would allow us to quickly verify whether the Neo ISP driver itself is functioning correctly in your environment, and help isolate whether the issue is driver/environment-related or specific to the OV5640 configuration. Note that while OV5640 is capable of RAW Bayer output, it does not have an official NXP Neo ISP tuning profile, which means even if the pipeline is connected correctly, AE/AWB and image quality tuning will not be available. Re: IMX95 Aquila ISP usage Some update: We checked this internally and would like to share the following observations regarding OV5640 and the i.MX95 Neo ISP pipeline. Although the OV5640 is capable of outputting RAW Bayer data, we generally do not recommend the OV5640 + Neo ISP combination for new designs for the following reasons: OV5640 is already an end-of-life (EOL) sensor. Although RAW output is supported, the sensor itself provides only limited tunable controls compared to more recent RAW sensors. NXP's i.MX95 reference camera solution is based on RAW sensors such as OS08A20, which are already supported and validated within the Neo ISP software framework. Therefore, our recommendation would be one of the following: Use OV5640 together with its existing image processing path (without relying on Neo ISP AE/AWB tuning functionality). Use an NXP-supported RAW sensor such as OS08A20 if full Neo ISP functionality is required. If OV5640 must be used with the Neo ISP pipeline, additional software enablement work will be required. For the OV5640 + Neo ISP approach, a libcamera CameraHelper needs to be implemented. The following file can be used as a starting reference: camera_helper_ov5640.cpp https://github.com/nxp-imx/libcamera/blob/lf-6.6.52_2.2.0/src/ipa/nxp/cam_helper/camera_helper_ov5640.cpp Please note that this CameraHelper implementation is only the first step. Its primary purpose is to allow libcamera to recognize and identify the OV5640 sensor. Additional sensor-specific adaptation is still required. For example, if Neo ISP Auto Exposure (AE) is expected to work, APIs such as the sensor gain conversion functions need to be implemented. A simple example can be found in the IMX219 CameraHelper implementation: https://github.com/nxp-imx/libcamera/blob/lf-6.18.20_2.0.0/src/ipa/nxp/cam_helper/camera_helper_imx219.cpp In particular, the customer would need to determine and implement the mapping between: Sensor gain code Real analog gain multiplier (gain value) so that the Neo ISP AE algorithm can correctly control the sensor exposure and gain. For CameraHelper development details, please refer to the Camera Porting Guide: Section 5.3 – "Implementing a libcamera CameraHelper for a new sensor" One special consideration for OV5640 is that it already contains its own AE functionality. Therefore, if the intention is to continue using the sensor's internal AE instead of the Neo ISP AE algorithm, implementations such as gainCodeToGain() and gainToGainCode() may not be strictly required. In this case, a basic CameraHelper used only for sensor detection may be sufficient to bring up the pipeline. However, image quality tuning would still need to be evaluated and adjusted. Since OV5640 was not originally characterized and tuned as a Neo ISP reference sensor, additional ISP tuning work may be required to achieve optimal image quality. Overall, while OV5640 RAW output can be connected to the i.MX95 Neo ISP pipeline, some sensor-specific libcamera and ISP integration work is expected. For new developments, we would recommend using a Neo ISP validated RAW sensor such as OS08A20 whenever possible. Re: IMX95 Aquila ISP usage Following up on our previous discussion, we have investigated the root cause of the Neo ISP pipeline not recognizing the OV5640 sensor. The issue is that the NXP Neo IPA (Image Processing Algorithm) framework uses a  CameraHelper  factory to look up sensor-specific gain/exposure algorithms by matching the kernel V4L2 subdev model string. Since no  CameraHelper  was registered for  "ov5640" , the factory returned  nullptr  and the ISP pipeline could not be configured for this sensor. To address this, we have implemented a  CameraHelper  for the OV5640 sensor based on the in-tree NXP kernel driver ( drivers/media/i2c/ov5640.c 😞 Gain register mapping: Register:  OV5640_REG_AEC_PK_REAL_GAIN  ( 0x350a ), 10-bit value Format: Q6.4 fixed point, unity gain = 16 gainCode(g) = round(g * 16) gain(code) = code / 16.0 Two files have been modified: camera_helper_ov5640.cpp  – new CameraHelper implementation for OV5640, registered as  "ov5640"  to match the kernel subdev model string meson.build  – added  camera_helper_ov5640.cpp  to the build source list Please rebuild libcamera with these two files and retry with  LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' . The Neo ISP pipeline should now be able to find and configure the OV5640 sensor. Note that while this enables the gain/exposure control path, a full ISP tuning profile (AE/AWB parameters) for OV5640 is not yet available. Image quality tuning may still require further work. Please let us know the results after rebuilding.

SE050漏洞报告   我有一个关于SE050的技术支持问题。我们将推出一款使用 SE050 的产品，该产品在现场不会获得软件更新。根据欧盟网络弹性法案 (CRA)，我们有义务监测我们使用的组件中的漏洞，并在规定的时间内报告已被积极利用的漏洞和严重事件。   请问您能告诉我们以下信息吗： - NXP 是否针对 SE050 运行漏洞披露或网络安全通知流程（例如邮件列表、网络安全公告页面或 PSIRT 信息流），我们可以订阅或监测？ - 鉴于该特定产品线不支持现场更新，如何将已知的漏洞及其状态（已修复、已缓解、不适用）传达给使用 SE050 的客户？ - 是否有办法接收主动通知，而不是手动查看？ SE050 Re: SE050 vulnerability reporting 嗨@djdirkj ， [产品网络安全漏洞 | 恩智浦半导体 | https://www.nxp.com/support/support/product-security-vulnerability:PSIRT ]PSIRT 团队可以接到漏洞报告，他们会进行评估，找到合适的解决方案，并与受影响的产品购买者（直接客户和分销商）沟通，然后分销商再通知他们的购买者。 错误及补救措施记录在勘误表和用户指南中。任何人都可以通过点击产品页面上的“接收提醒”选项来接收这些文档的更新信息，从而了解文档的更新情况。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

KW45B41Z EVKが搭載デバッガーMCUリンクでプログラムされていないこと。 こんにちは、 kw45b41zevk_hello_world SDKのサンプルコードを使ってKW45B41Z-EVKをプログラムしようとしています。デバッグを開始すると、オンボードデバッガーは検出されますが、その後、次のエラーが発生します。 検出された利用可能なSWDデバイスは0個です。 デバイスを接続して、もう一度お試しください。 USBケーブルは J14 に接続し、 JP22はオン ボードデバッガでプログラムするために開いたままにしています。また、 KW45UMで述べられているように、 JP28のピン1と2は短絡されています。しかし、その後もサンプルプログラムをプログラミングしたりデバッグしたりすることができません。 kw45b41zevk_led_blinky SDKの例も試しましたが、同じように動作します。 KW45UMで説明されているように、外部デバッガを使用してJP22をショートさせてボードのデバッグも試みましたが、同じ問題が発生します。 発生している問題のスクリーンショットを添付しました。 セキュアプロビジョニングツールを使用して、フラッシュメモリを消去してイメージを書き込むことも試しました。まず、 JP25をショートさせてSW4を有効にし、次にSW4とリセット（SW3）を長押ししてISPモードに入りました。接続テストが成功した後、フラッシュメモリ（位置0x00000000 、サイズ0x100000 ）の消去に成功しました。次に、以下の画像を使用しました。 ${SPT_INSTALL_BIN} \data\sample_data\targets\KW45B41Z8\source_images\kw45b41zevk_led_blinky.s19 画像の構築とプログラムは無事にでき、意図した RGB LED1 も点滅しており、KW45B41Z マイクロコントローラが正常に動作していることを示しています。しかし、それでもなお、基板のプログラミングやデバッグができません。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 どのIDEを使っていますか? MCUXpresso IDEまたはMCUXpresso for VS Code? 私の方で試してみて、デフォルトのジャンパー設定をお知らせします。 よろしくお願いいたします。 Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 ジャンパーの設定を参照してください。ローカル側で確認済みで、hello_world例をボードに正常にフラッシュできます。 そして、MCUXpresso IDEとSDK 25.12.00を使っています。 私のジャンパー設定を試してみて、うまくいくかどうか教えてください。 よろしくお願いいたします。 Christine。

「セキュアボックス版」とは何ですか？ AN12413仕様のGetVersion-APDUでは、「VersionInfo」に2バイトの「セキュアボックスバージョン」が定義されています。それが一体何なのか、明確な定義はない。 なぜこの情報が必要なのですか？ 私は現在、通知機関との製品の認証手続きの最中です。この製品は特定のセキュリティ機能のためにSE050を使用しており、SE050にはファームウェアも含まれているため、これは認証の一部です。 SE050 Re: What is "Secure Box version"? こんにちは@Kan_Liさん 迅速なご返信ありがとうございます。感謝いたします。 すべての SE050A2 が同じかどうか確認できますか? OEF ID、プラットフォームビルドID、OSパッチレベル、アプレットのバージョン、機能設定。 そして、新たなロットを注文した場合でも、この点は変わりません。 この話題について知っておくべきことはこれだけです。 敬具 ダーク・ヤン Re: What is "Secure Box version"? こんにちは、 @djdirkj さん。 SE050A2すべてのチップが文字通り同一であることを証明しようとしないでください。OEF ID、プラットフォームビルドID、OSパッチレベル、アプレットバージョン、機能構成が同じであることを証明しつつ、トレーサビリティのために独自のシリアル/バッチデータを記録してください。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: What is "Secure Box version"? こんにちは@Kan_Liさん ご回答ありがとうございます！ 質問を言い換えてみましょう。 弊社のEMS（電子機器受託製造業者）には、SE050A2部品が約500個入ったリールがあります。これらのSE050で500個の製品を生産した場合、すべてのSE050がまったく同じかどうかどうやって確信できますか? SE050に違いがある場合、証明書に適合しておらず、証明書の修正が必要です。これが望ましい状況ではないことをご理解いただければ幸いです。 Re: What is "Secure Box version"? こんにちは、 @djdirkj さん。 Secure Box版はSE050ソフトウェア/構成証拠の一部として記録してください。ただし、NXPが管理された定義を提供しない限り、独立して解釈しようとしないでください。認証の場合は完全なものが必要です  GetVersion  /  se05x_GetInfo  出力はより強力なトレーサビリティのアーティファクトです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: What is "Secure Box version"? こんにちは、 @djdirkj さん。 はい、SE050Aではこれらのパラメータはすべて静的です。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

如何将 S32 Design Studio 许可证转移/重新注册到我自己的 NXP 帐户 你好， 尊敬的技术支持团队： 这是第二条信息 （第一页： https ://community.nxp.com/t5/MPC5xxx/Request-for-Software-License-Extension-Due-to-Expiration/mp/2396968#M28490） 我的办公电脑是我从前任经理那里继承来的，S32 Design Studio 仍然是在他的 NXP 账户下激活的，而不是我的。因此，我电脑上安装的许可证似乎已经过期了。 我已经确认我的许可证有效期至 2028 年，因此我想将这台电脑上的 S32DS 切换到我的 NXP 帐户和许可证，而不是前任所有者的帐户和许可证。 请问正确的操作步骤是什么？具体来说： 1. 是否有办法停用或解除与先前帐户关联的现有激活状态？ 2. 我能否使用我自己的帐户凭据重新激活 S32DS，还是需要完全卸载并重新安装？ 感谢您的帮助。 顺祝商祺！ Re: How to transfer/re-register an S32 Design Studio license to my own NXP account 你好， 您可以使用之前用户的旧激活码。激活码与特定账户无关。 您可以使用旧代码重新激活现有安装。

How to transfer/re-register an S32 Design Studio license to my own NXP account Hello, Dear Support Team, That is Second Message  ( First : https://community.nxp.com/t5/MPC5xxx/Request-for-Software-License-Extension-Due-to-Expiration/m-p/2396968#M28490 ) I inherited my work PC from my former manager, and S32 Design Studio is still activated under his NXP account, not mine. Because of this, the installed license appears to have expired on my machine. I have confirmed that my own license is valid until 2028, so I would like to switch S32DS on this PC over to my NXP account and license instead of the previous owner's. Could you let me know the correct procedure for this? Specifically: 1. Is there a way to deactivate or release the existing activation tied to the previous account? 2. Can I simply re-activate S32DS with my own account credentials, or is a full uninstall and clean reinstall required? Thank you for your help. Best regards, Re: How to transfer/re-register an S32 Design Studio license to my own NXP account Hi,  you can use the old activation code from previous user. The activation code is not connected to specific account.  You can re-activate existing installation with the old code. 

S32K OTA Rollback 各位好，我想咨询一下，关于S32K3系列的HSE ABSwap OTA回滚机制。我了解到的是如果A区为稳定区，将A区切换到B区，B区如果出现Hardfault或看门狗超时等错误问题，OTA的错误计数器会累减，当错误计数器为0时，程序会认定B区为不稳定区从而切换片区回到A区。请问这个机制是正确的吗？如果不是，那么OTA的回滚机制是怎样的呢？ Re: S32K OTA Rollback 嗨@RootOf3 对于 S32K3 HSE AB Swap，回滚机制不基于 HSE 监控运行时故障，例如 HardFaults 或看门狗 RESET。 HSE 本身并不会根据应用程序运行时行为来判断新激活的应用程序是否稳定。AB 交换执行完毕后，新映像将变为活动状态，通常由用户引导加载程序/应用程序决定更新是否成功或是否应请求回滚。 安全启动也可以用作恢复策略的一部分。如果活动映像的身份验证失败，则可以根据配置的启动流程和客户的软件设计，将启动流程设计为执行备用映像或专用的恢复映像。一旦有效的恢复映像或备用映像正在运行，软件可以在需要时请求另一个 AB 交换。 综上所述，HSE 提供了安全启动、映像认证和 AB 交换的机制，但实际的回滚策略（包括如何检测运行时故障以及系统何时切换回之前的映像）是由用户引导加载程序/应用程序实现的。 此致， Lukas

S32K OTA Rollback Hello everyone, I'd like to inquire about the HSE ABSwap OTA rollback mechanism for the S32K3 series. My understanding is that if partition A is a stable partition, switching from partition A to partition B will cause errors such as Hardfault or watchdog timeout to occur in partition B. The OTA error counter will decrease, and when the error counter reaches 0, the program will consider partition B an unstable partition and switch back to partition A. Is this mechanism correct? If not, what is the OTA rollback mechanism? Re: S32K OTA Rollback Hi @RootOf3  For S32K3 HSE AB Swap, the rollback mechanism is not based on HSE monitoring runtime failures such as HardFaults or watchdog resets. HSE itself does not determine whether the newly activated application is stable based on the application runtime behavior. After the AB Swap is performed, the new image becomes active, and it is typically the responsibility of the user bootloader/application to decide whether the update was successful or whether a rollback should be requested. Secure Boot can also be used as part of the recovery strategy. If authentication of the active image fails, the boot flow can be designed to execute an alternate image or a dedicated recovery image, depending on the configured boot flow and the customer’s software design. Once a valid recovery or alternate image is running, the software can request another AB Swap if needed. So, in summary, HSE provides the mechanisms for Secure Boot, image authentication, and AB Swap, but the actual rollback policy, including how runtime failures are detected and when the system switches back to the previous image, is implemented by the user bootloader/application. Regards, Lukas

NXPのデモイメージを使ってもfrdm-imx93が起動しない SDカードからfrdm-imx93を起動しようとしています。eMMCからでも問題なく動作します。 NXPのサイトリンクから ZIP Rev 4.0 Jun 25, 2025 2.45 MB LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93をダウンロードしました。その後、以下の手順を実行しました。 zstd -d imx-image-full-imx93frdm.rootfs.wic.zst sudo dd if=imx-image-full-imx93frdm.rootfs.wic of=/dev/sdc bs=1M status=progress && sync sudo dd if=imx-boot-imx93frdm-sd.bin-flash_singleboot of=/dev/sdc bs=1k seek=32 status=progress それからSDカードをスロットに入れて、SW1[3:0]=0011に設定してから起動を試みました。 しかし、ブートはここから先へ進みません。 U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33 準備完了 誰か至急助けてください… よろしくお願いいたします！ Re: frdm-imx93 not booting even with demo images from NXP シリアルポートでも同じ現象が見られます。複数のケーブルで試してみました。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、 この手順に従っている際に、ボードのシリアルポートにどのようなエラーが表示されますか？ 高速起動モードに移行できない場合は、別のUSBケーブルをお試しください。 よろしくお願いいたします。 Re: frdm-imx93 not booting even with demo images from NXP 少し先まで進んだが、まだOSには到達していない。問題はブートドライブの内容と、シングルブートバイナリ自体にあると思います。 これについても、ボードに詳しい人に手伝ってもらいたい。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、私も同じ問題を抱えています。WindowsとLinuxの両方で、また異なるLinuxディストリビューションで、様々なイメージを試してみました。EMMCとSDカードの両方が動作していません 結局、原因は分かりましたか？ Re: frdm-imx93 not booting even with demo images from NXP Hello 私がやったことはこうです。 root@debian:/mnt/host/LF_v6.6.36-2.1.0_images_FRDM_3.0_i.MX93# uuu -V -b sd_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst NXP IMXチップ用uuu（Universal Update Utility） -- libuuu_1.5.243-5-g124d086   設定ファイルに含める: PctlチップビデオPID Bcdバージョンシリアル番号 ================================================== SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS: MX8DXL 0x1fc9 0x0147 SDPS: MX28 0x15a2 0x004f SDPS: MX815 0x1fc9 0x013e SDPS: MX865 0x1fc9 0x0146 SDPS: MX8ULP 0x1fc9 0x014a SDPS: MX8ULP 0x1fc9 0x014b SDPS: MX93 0x1fc9 0x014e SDPS: MX91 0x1fc9 0x0159 SDPS: MX95 0x1fc9 0x015d SDPS: MX95 0x1fc9 0x015c SDPS: MX943 0x1fc9 0x0027 SDPS: MX952 0x1fc9 0x0028 SDP: MX7D 0x15a2 0x0076 SDP: MX6Q 0x15a2 0x0054 SDP: MX6D 0x15a2 0x0061 SDP: MX6SL 0x15a2 0x0063 SDP: MX6SX 0x15a2 0x0071 SDP: MX6UL 0x15a2 0x007d SDP: MX6ULL 0x15a2 0x0080 SDP: MX6SLL 0x1fc9 0x0128 SDP: MX7ULP 0x1fc9 0x0126 SDP: MXRT106X 0x1fc9 0x0135 SDP: MX8MM 0x1fc9 0x0134 SDP: MX8MQ 0x1fc9 0x012b SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998] FBK: 0x066f 0x9afe FBK: 0x066f 0x9bff FBK: 0x1fc9 0x0153 FB: 0x0525 0xa4a5 FB: 0x18d1 0x0d02 FB: 0x3016 0x0001 FB: 0x1fc9 0x0152 FB: 0x0483 0x0afb FB: 0x1d6b 0x0104   組み込みスクリプトを実行します:   uuu_version 1.4.149   # @_flash.bin| wicイメージから抽出できるブートローダー # @_image [_flash.bin]| wicイメージをemmcに書き込む。     # このコマンドはi.MX6/7 i.MX8MM、i.MX8MQで実行されます SDP: boot -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000   # このコマンドはROMがストリームモードに対応しているときに実行されます # i.MX8QXP、i.MX8QM SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000   # これらのコマンドはSPLを使用するときに実行され、SPLがない場合はスキップされます # SDPUは非推奨になります。SDPUの代わりにSDPVを使用してください # ヤミン・アメックス SDPU: 遅延 1000 SDPU: write -f imx-boot-imx93frdm-sd.bin-flash_singleboot-オフセット 0x57c00 -スキャン制限 0x800000 SDPU: ジャンプ -scanlimited 0x800000 # }   # これらのコマンドはSPLを使用するときに実行され、SPLがない場合はスキップされます # if (SPL が SDPV をサポートしている場合) # ヤミン・アメックス SDPV: 遅延 1000 SDPV: write -f imx-boot-imx93frdm-sd.bin-flash_singleboot-skipspl -scanterm -scanlimited 0x800000 SDPV: ジャンプ -scanlimited 0x800000 # }   FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${sd_dev} FB: ucmd mmc dev ${sd_dev} FB: flash -raw2sparse all imx-image-full-imx93frdm.rootfs.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93frdm-sd.bin-flash_singleboot FB: 完了     既知のUSBデバイスが表示されるまでお待ちください... 新しいUSBデバイスが1:2で接続されました。 1:2->開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 1:2->HID(W)エラー: LIBUSB_ERROR_TIMEOUT (-7)(20.02秒)     よろしくお願いいたします。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、 どのコマンドを使用しましたか？ 再現できません。 よろしくお願いいたします。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは！はい、そうしました。WindowsとLinuxの両方で必ずタイムアウトが発生し、Linuxではセグメンテーション違反が発生します。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、 UUUを使ってフラッシュしようとしましたか？ よろしくお願いいたします。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、 シリアルポートには何が見えますか？高速起動モードでインターセプトできますか？ 別のBSPやバージョンで試してみましたか？私の環境では、まだその問題を再現できていません。 よろしくお願いいたします。 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、 シリアルポートからはSPL出力しか確認できません。U-Bootが完全に起動しないため、U-Bootプロンプトやfastbootモードに入ることができません。 公式Rev 4.0イメージを使用したシリアル出力： U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK それ以降の出力はありません。 また、再構築したFlexbuild/U-Boot 2025.04ブートイメージをSDカードの32 KiBオフセットに書き込んでテストしました。ボードは新しいSPLを実行しますが、同じ箇所で停止します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK そのため、U-Bootが完全に起動しないので、fastbootモードに入ることができません。 私は以下のBSP/イメージをテストしました。 1. 公式FRDM-i.MX93 Rev 4.0イメージ： LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 2. MACHINE=imx93frdm 用の私自身の Yocto ビルド 3. Flexbuild/U-Boot 2025.04 SPL/コンテナを再構築 公式のRev 4.0と私のYoctoビルドでは、このブートイメージハッシュを使用しています。 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot UUUもフラッシュ前に失敗する。ボードが検出されました： MX93 SDPS 0x1FC9:0x014E しかしSDPS：起動がタイムアウトします： 開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 HID(W)エラー:LIBUSB_ERROR_TIMEOUT これはLinuxとWindowsの両方で発生し、別のノートPCを試しても同じ結果になります。 SDカード起動モードの選択についても確認しました。SDカード起動モードを選択し、SDカードを挿入しない場合、シリアル出力は発生しません。SDカードを挿入すると、SPLは起動し、M33準備完了後に停止します。 そのため、現状ではボードはU-Boot/fastbootに到達しません。 Re: frdm-imx93 not booting even with demo images from NXP 私も同じ問題に直面しています。i.mx93 frdm ポータルで入手可能な 4 つの改訂版すべてを試しましたが、 UUUはいつも投げる HID(W)エラー: LIBUSB_ERROR_TIMEOUT (-7)(20.02秒) eMMCへの書き込みだけでなく、SDカードへの書き込みにも対応しています。 Re: frdm-imx93 not booting even with demo images from NXP ようやく何とか動くようになった。 仕様通り32GBのSDカードを使用しました。 NXP Yoctoリンクからコードをクローンし、ドキュメントに記載されているとおりにコードをビルドしてフラッシュしました。 カードに書き込んで、上記の手順に従って起動してください。これは私には効果がありました。以前の試みで使用したubootバイナリがEVM向けであってFRDM向けではなかったことが問題だったと思います。 Re: frdm-imx93 not booting even with demo images from NXP 解決しましたか？私も同じ問題に遭遇しました Re: frdm-imx93 not booting even with demo images from NXP こんにちは@jventura 、 @qingyu 、 @ssb1 、 @skrimby123 ぜひ試してみてください。 Re: frdm-imx93 not booting even with demo images from NXP お使いのU-Bootは古いようです。ハードウェアの変更があったようで、FRDM-IMX93をサポートするのは2025年以降のバージョンのみとなります。 イメージファイルと一緒にブートローダーをフラッシュする方法については、上記の私の投稿を参照してください。 うまくいくといいですね 🙂 Re: frdm-imx93 not booting even with demo images from NXP 私も全く同じ問題を抱えています。 もしかしたら、新しいボードに欠陥があるのかもしれませんね？ 😞 Re: frdm-imx93 not booting even with demo images from NXP こんにちは、みんな、 ボードは正常に動作するようになりました。どうやらFRDM-i.MX93ボードにハードウェアの変更があったようで、古いU-bootブートローダー（2025年以前のもの）を使用している場合は、この問題が発生するようです。 シリアルダウンローダーモードで起動またはフラッシュを試みると、シリアルモニターでU-Bootのバージョンを確認できます。 古いU-Bootバージョンの例：U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) 以下のコマンドでこのブートローダーを試してみてください。うまくいくはずです。 🙂 imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot UUUコマンド： uuu -b sd_all imx-boot-imx93-11x11-lpddr4x-frdm-sd.bin-flash_singleboot .wic.zst 上記のブートローダーがうまく動作した場合は、変更を加えた最新のYocto i.MX BSPリポジトリはこちらです： GitHub - nxp-imx/meta-imx: i.MX Yocto Project i.MX BSP Layer · GitHub Re: frdm-imx93 not booting even with demo images from NXP NXPのサポートからこの問題を解決しました。 デモ画像ダウンロードページで、バージョン4.0ではなくバージョン1.0を選択し、最新のuuuを使用して画像をボードにダウンロードします。 Re: frdm-imx93 not booting even with demo images from NXP 遅れてすみません。 はい、おそらくそうでしょう。私のU-Bootバージョン： U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) しかし、投稿にある正しいブートロードへのリンクが壊れていて、ダウンロードできません。 😞 Re: frdm-imx93 not booting even with demo images from NXP 私も同じエラーが発生しており、UART DEBUGの出力は以下のとおりです。 U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK Re: frdm-imx93 not booting even with demo images from NXP ブートローダーへのリンクが機能していません Re: frdm-imx93 not booting even with demo images from NXP ブートローダーのダウンロードリンクを更新してください。これは依然として多くの人にとって解決されていない問題であり、まだ解決策は見つかっていません。

是否可以对 i.MX93 板进行重新配置？ 我已使用 EdgeLock 2GO 成功配置了我的 FRDM i.MX93 板。现在我想使用一组新的或更新的安全对象（例如密钥对和 X.509 证书）重新配置同一块板。已配置的 i.MX93 设备是否支持重新配置？如果支持，请问推荐的步骤是什么？具体来说，之前配置的安全对象是否需要在重新配置之前删除或 RESET，还是可以通过 EdgeLock 2GO 进行更新？此外，在尝试重新配置之前，我是否需要注意任何限制或不可逆的设置？ 日志：-- 错误：iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败：0xffffc180 错误：iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败：0xffffffff 错误：iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败：0xffffc180 错误：iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败：0xffffffff 错误：iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败：0xffffc180 错误：iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败：0xffffffff 错误：iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 失败，错误代码为 0xffffffff 状态（oem-prov-app）：失败 FRDM 培训 动手实践培训 安全 Yocto Project Re: Is it possible to reprovision the i.MX93 board? 你好， EdgeLock 2GO 可进行重新配置，其设计旨在实现完整的生命周期管理，包括在初始部署后更新、轮换或撤销证书和密钥。 请问您能否分享一下您在安全配置过程中遵循了哪些步骤？ 您需要了解与熔丝中烧毁的配置相关的程序，例如键、生命周期等。 顺祝商祺！ Re: Is it possible to reprovision the i.MX93 board? 感谢您确认服务级别支持重新配置。澄清一下：这不是一次全新的配置尝试，而是对已经成功配置过一次的板子进行的重新配置尝试（生命周期 OEM_OPEN，ELE 固件 2.0.5-7a34cee，第一次配置时已经存在密钥和证书对象）。 在第二次尝试中，oem-prov-app 在 iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内部的 mbedtls_pk_setup_opaque() 调用处失败，返回 MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180)。版本：el2go-agent 6.4.2-r0，smw 5.3-r0，mbedtls 3.6.5-r0。 两个问题： 1.重新配置是否需要在重新运行 oem-prov-app 之前显式擦除现有密钥对象（通过 psa_destroy_key 或 SMW 密钥存储 API），还是代理应该在相同的密钥 ID 处就地覆盖它？我们目前没有执行任何显式擦除步骤。 2. el2go-agent 6.4.2-r0 和 smw 5.3-r0 之间是否存在已知的兼容性问题，尤其是在重新配置/更新路径上？因为我们在初始启动时也看到了同样的错误，并怀疑是版本不匹配导致的。 另外，能否确认已配置的密钥和证书对象位于 ELE 管理的 NVM 中，而不是熔丝中，这样即使重新配置失败，也不会导致该密钥 ID 永久无法使用？ Re: Is it possible to reprovision the i.MX93 board? 你好， 谢谢你提供的信息。 1. 是的，使用签名消息执行密钥库重新配置。密钥存储重新配置会导致 HSM 处理的所有密钥存储被擦除。 2. 没有，没有报告任何兼容性问题。 3. 没错，应用程序密钥和证书存储在 ELE 管理的 NVM 中，而不是存储在熔丝中。 顺祝商祺！

IMX95 Aquila ISP 使用情况 你好， 我购买了一套 Aquila IMX95 评估套件 2，包含两个 ov5640 传感器（ https://www.toradex.com/cart ）。 我有传感器的驱动程序。主板固件已正确刷写，ISP模块已激活： root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 摄像头显示在 libcamera 中： root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) 为了检查 mipis 是否正常，我启动了一个 gstreamer 流水线，并成功地在两个摄像头上都获得了稳定的 30fps 流。我还成功地使用 v4l2-ctl 拍摄了快照。 现在，我想用我的摄像头测试一下 Aquila 的 ISP，看看它的表现如何。 请参阅https://www.nxp.com/docs/en/user-guide/UG10215.pdf我添加了环境变量： root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 但是这样做之后，libcamera 就检测不到摄像头了，我不知道为什么： root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# 感谢你的回复 ！ 此致敬礼， Re: IMX95 Aquila ISP usage 查看您的日志后，我认为该问题与 MIPI 接口或 OV5640 驱动程序本身无关。 事实是： libcamera 检测到了两台 OV5640 摄像头。 GStreamer 可以以 30 fps 的帧率进行流媒体传输。 v4l2-ctl 可以捕获图像 这表明传感器驱动程序、I2C 通信、  CSI-2  链接和媒体拓扑结构均运行正常。 关键在于 NXP Neo ISP 流水线需要原始的拜耳传感器输入。 OV5640 是一款 SoC 图像传感器，具有自己的内部图像处理流程，在 NXP 电路板支持包 中，它通常以 YUV 输出模式（例如 YUV422）使用，而不是作为 RAW Bayer 传感器使用。在这种配置下，可以通过标准的 V4L2/libcamera 流水线使用摄像头，但它不符合 Neo ISP 流水线的要求。 这就能解释为什么了： `cam -l` 默认会显示两台 OV5640 摄像头。 设置后 export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 已检测不到任何摄像头 摄像头仍然存在于系统中，但 NEO 流水线处理程序找不到兼容的摄像头拓扑结构，因此没有向 libcamera 公开任何摄像头。 为了验证传感器的实际输出格式，请提供以下输出： ```bash media-ctl -p v4l2-ctl --list-formats-ext 我们特别感兴趣的是，该传感器是否支持任何 RAW Bayer 格式，例如： SBGGR8 SBGGR10 SRGGB10 RG10 BA10 如果只有 YUV 格式（例如 YUYV/UYVY）可用，则表示相机未在 RAW 模式下运行，无法通过 Neo ISP 处理流程进行处理。 虽然 OV5640 硬件能够输出 RAW Bayer 格式图像，但 BSP 相机驱动程序通常不会启用 RAW 支持，NXP Neo ISP 堆栈也依赖于传感器特定的调整数据。即使启用了 RAW 输出，由于缺少专用的 OV5640 调谐配置文件，可能会阻止 ISP 的正常操作（AE/AWB/图像质量调谐）。 如果您的目标是评估 Neo ISP 框架本身，那么使用已知可与 NXP ISP 协议栈配合使用的传感器可能会更容易。常见候选人包括： OS08A20 OX03C10 OX05B1S AR0521 AR1335（可能需要额外调校） 能否分享一下上述命令的输出结果？这将使我们能够确认当前的 OV5640 配置是否向系统暴露了 RAW Bayer 格式。 此致， Re: IMX95 Aquila ISP usage 谢谢回复。 我做了一些额外的检查： 您是对的，OV5640 最初运行在UYVY 模式下，但我手动将一个传感器切换到了RAW Bayer (SRGGB8) 。 media-ctl -p 现在显示：   root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] （第二个OV5640仍保持UYVY模式，用于对比） 所以 ： OV5640 -> SRGGB8 CSI -> SRGGB8 格式化程序 -> SRGGB8 横杆 -> SRGGB8 => RAW Bayer 成功通过传感器、CSI 和格式化器进行传输。 neoisp内核模块已加载： root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 运行中的设备树中存在 ISP 节点：   /sys/firmware/devicetree/base/soc/isp@4ae00000   => 但是，我只看到一个媒体设备（/dev/media0）暴露了 CSI/Formatter/ISI 管道。媒体图中没有出现新独立党派实体。我在媒体图中没有看到任何 neoisp 实体，我不知道这是否正常。 => cam -l (libcamera) 仍然返回没有可用的摄像头。 目前看来，RAW Bayer 路径似乎可以正常工作，但我无法确定 Neo ISP 在哪个环节成为活动流程的一部分。   如何验证该流是否确实由 Neo ISP 处理，而不是仅仅遵循 CSI -> 格式化程序 -> ISI 路径？   另外，请参阅https://www.nxp.com/docs/en/user-guide/UG10215.pdf对于这种配置，目前还是推荐的指南吗？或者有没有针对 i.MX95 上 OV5640 + Neo ISP 的更具体的参考资料？       此致敬礼， Re: IMX95 Aquila ISP usage 我目前怀疑以下情况之一正在发生： OV5640 很可能运行在 YUV 模式而不是 RAW Bayer 模式。 摄像头 DT 叠加层不是 ISP 启用版本。 根文件系统中缺少 Neo IPA/校准组件。 Neo 管道看到的媒体拓扑结构与预期的 i.MX95 ISP 图不匹配。 media-ctl -p 的输出通常会指出哪个才是真正的问题所在。 Re: IMX95 Aquila ISP usage 您好！ 以下是输出结果： root@imx95-1:~# v4l2-ctl --list-formats-ext -d /dev/video2 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'YUYV' (YUYV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [1]: 'YUVA' (32-bit YUVA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [2]: 'NV12' (Y/UV 4:2:0, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [3]: 'NM12' (Y/UV 4:2:0 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [4]: 'NV16' (Y/UV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [5]: 'NM16' (Y/UV 4:2:2 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [6]: 'YM24' (Planar YUV 4:4:4 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [7]: 'RGBP' (16-bit RGB 5-6-5, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [8]: 'RGB3' (24-bit RGB 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [9]: 'BGR3' (24-bit BGR 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [10]: 'XR24' (32-bit BGRX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [11]: 'AR24' (32-bit BGRA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [12]: 'RA24' (32-bit ABGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [13]: 'AB24' (32-bit RGBA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [14]: 'RX24' (32-bit XBGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [15]: 'XB24' (32-bit RGBX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [16]: 'AR30' (32-bit ARGB 2-10-10-10, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [17]: 'GREY' (8-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [18]: 'Y10 ' (10-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [19]: 'Y12 ' (12-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [20]: 'Y14 ' (14-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [21]: 'BA81' (8-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [22]: 'GBRG' (8-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [23]: 'GRBG' (8-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [24]: 'RGGB' (8-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [25]: 'BG10' (10-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [26]: 'GB10' (10-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [27]: 'BA10' (10-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [28]: 'RG10' (10-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [29]: 'BG12' (12-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [30]: 'GB12' (12-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [31]: 'BA12' (12-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [32]: 'RG12' (12-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [33]: 'BG14' (14-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [34]: 'GB14' (14-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [35]: 'GR14' (14-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [36]: 'RG14' (14-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [37]: 'BYR2' (16-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [38]: 'GB16' (16-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [39]: 'GR16' (16-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [40]: 'RG16' (16-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [41]: 'MJPG' (Motion-JPEG, compressed, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 如果我理解正确的话，相机可以拍摄原始拜耳格式照片，我也将其配置为拍摄原始拜耳格式照片（希望我配置正确）。 我再尝试用另一个镜像文件刷机，看看问题是不是出在这里。 此致敬礼， Re: IMX95 Aquila ISP usage 谢谢你的更新。这  v4l2-ctl  输出结果证实 ISI 捕获节点支持 RAW Bayer 格式，并且  media-ctl -p  您上一条消息的输出已经表明，RAW Bayer 路径已正确传递到整个流程中： OV5640 (SRGGB8) -> CSI (SRGGB8) -> 格式化器 (SRGGB8) -> 十字开关 (SRGGB8) 所以传感器侧的配置看起来是正确的。 现在的核心问题是：  新互联网服务  模块已加载，但未出现在媒体图中，也没有其他信息。  /dev/media1  已创建。这通常表明  新互联网服务  驱动程序已成功作为内核模块加载，但在设备探测期间失败，这将阻止其注册媒体设备。 请您提供以下诊断信息： # 检查 NeoISP 探测状态 dmesg | grep -i neoisp dmesg | grep -i "isp@4ae" dmesg | grep -i “探测失败” dmesg | grep -i "4ae00000" # 确认所有可用的媒体设备ls -la /dev/media* # 检查 sysfs中的neoisp 状态ls /sys/总线/platform/drivers/nxp-neoisp/ cat /sys/firmware/devicetree/base/soc/isp@4ae00000/status 同时，我们也想问一下：您是否可以访问以下任何一款由 NXP Neo ISP 协议栈官方支持且具有完整调优我的的传感器？ OS08A20 OX03C10 OX05B1S 使用这些传感器之一进行测试，可以让我们快速验证 Neo ISP 驱动程序本身在您的环境中是否正常工作，并有助于确定问题是与驱动程序/环境相关还是 OV5640 配置特有的问题。 请注意，虽然 OV5640 能够输出 RAW Bayer 图像，但它没有官方的 NXP Neo ISP 调谐我的，这意味着即使管道连接正确，AE/AWB 和图像质量调谐功能也无法使用。 Re: IMX95 Aquila ISP usage 一些更新： 我们内部对此进行了检查，并想分享以下关于 OV5640 和 i.MX95 Neo ISP 流水线的观察结果。 虽然 OV5640 能够输出 RAW Bayer 数据，但出于以下原因，我们通常不建议在新设计中使用 OV5640 + Neo ISP 组合： OV5640 已经是一款停产（EOL）传感器。 虽然支持 RAW 输出，但与较新的 RAW 传感器相比，该传感器本身提供的可调控制功能有限。 NXP 的 i.MX95 参考，引用相机解决方案基于 OS08A20 等 RAW 传感器，这些传感器已在 Neo ISP 软件框架中得到支持和验证。 因此，我们的建议如下： 将 OV5640 与其现有的图像处理路径一起使用（不依赖 Neo ISP AE/AWB 调整功能）。 如果需要完整的 Neo ISP 功能，请使用 NXP 支持的 RAW 传感器，例如 OS08A20。 如果 OV5640 必须与 Neo ISP 管道一起使用，则需要额外的软件启用工作。 对于 OV5640 + Neo ISP 方案，需要实现 libcamera CameraHelper。以下文件可作为参考，引用： camera_helper_ov5640.cpp https://github.com/nxp-imx/libcamera/blob/lf-6.6.52_2.2.0/src/ipa/nxp/cam_helper/camera_helper_ov5640.cpp 请注意，此 CameraHelper 实现只是第一步。它的主要目的是让 libcamera 能够识别 OV5640 传感器。还需要针对特定传感器进行额外的适配。 例如，如果希望 Neo ISP 自动曝光 (AE) 功能正常工作，则需要实现传感器增益转换函数等 API。IMX219 CameraHelper 实现中提供了一个简单的示例： https://github.com/nxp-imx/libcamera/blob/lf-6.18.20_2.0.0/src/ipa/nxp/cam_helper/camera_helper_imx219.cpp 具体而言，客户需要确定并实施以下之间的映射关系： 传感器增益代码 实际模拟增益倍增器（增益值） 这样 Neo ISP AE 算法就能正确控制传感器曝光和增益。 有关 CameraHelper 开发的详细信息，请参阅相机移植指南： 第 5.3 节 – “为新传感器实现 libcamera CameraHelper” OV5640 的一个特殊之处在于它本身就包含 AE 功能。因此，如果打算继续使用传感器的内部 AE 而不是 Neo ISP AE 算法，则诸如 gainCodeToGain() 和 gainToGainCode() 之类的实现可能并非严格必需。在这种情况下，一个仅用于传感器检测的基本 CameraHelper 可能就足以启动管道。 然而，图像质量调优仍然需要进行评估和调整。由于 OV5640 最初并非作为 Neo ISP 参考，引用传感器进行特性分析和调校，因此可能需要额外的 ISP 调校工作才能达到最佳图像质量。 总的来说，虽然 OV5640 RAW 输出可以连接到 i.MX95 Neo ISP 流水线，但预计还需要一些针对特定传感器的 libcamera 和 ISP 集成工作。对于新开发项目，我们建议尽可能使用经过 Neo ISP 验证的 RAW 传感器，例如 OS08A20。 Re: IMX95 Aquila ISP usage 在前文讨论的基础上，我们调查了 Neo ISP 管道无法识别 OV5640 传感器的根本原因。 问题在于 NXP Neo IPA（图像处理算法）框架使用了一种  相机助手  工厂通过匹配内核 V4L2 子设备模型字符串来查找传感器特定的增益/曝光算法。由于没有  相机助手  已登记  “ov5640” ，工厂退回  nullptr  无法为该传感器配置 ISP 管道。 为了解决这个问题，我们实施了一项  相机助手  适用于基于 NXP 内核内部驱动程序（ drivers/media/i2c/ov5640.c） 的 OV5640 传感器😞 增益寄存器映射： 登记：  OV5640_REG_AEC_PK_REAL_GAIN  ( 0x350a )，10 位值 格式：Q6.4 定点，单位增益 = 16 gainCode(g) = round(g * 16) gain(code) = code / 16.0 两个文件已被修改： camera_helper_ov5640.cpp  – 为 OV5640 开发的新 CameraHelper 实现，已注册为  "ov5640"  与内核子设备模型字符串匹配 meson.build  ——已添加  camera_helper_ov5640.cpp  添加到版本源列表 请使用这两个文件重新构建 libcamera，然后重试。  LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 。Neo ISP 管道现在应该能够找到并配置 OV5640 传感器。 请注意，虽然这可以实现增益/曝光控制路径，但 OV5640 的完整 ISP 调谐我的（AE/AWB 参数）尚未可用。图像质量调优可能仍需进一步完善。 重建完成后与我们联系结果。

SE050 vulnerability reporting   I have a technical support question regarding the SE050. We are bringing a product to market that uses the SE050, and this product will not receive software updates in the field. Under the EU Cyber Resilience Act (CRA), we have an obligation to monitor for vulnerabilities in the components we use and to report actively exploited vulnerabilities and severe incidents within the required timelines.   Could you tell us: - Does NXP operate a vulnerability disclosure or security notification process for the SE050 (e.g. a mailing list, security advisories page, or PSIRT feed) that we could subscribe to or monitor? - How are known vulnerabilities and their status (fixed, mitigated, not applicable) communicated to customers using the SE050, given that this specific product line does not support field updates? - Is there a way to get proactive notifications rather than having to check manually? SE050 Re: SE050 vulnerability reporting Hi @djdirkj , [Product Security Vulnerability | NXP Semiconductors|https://www.nxp.com/support/support/product-security-vulnerability:PSIRT] PSIRT team can be reported of vulnerabilities, they evaluate, find apt solution and communicate to affected buyers of the product - direct customers and distis which then inform their buyers. Errors and mitigiations are documented in errata sheet and user guidance. Anyone can receive updates of these documents by clicking the "receiving alerts" option on the website of the product page to get informed on document updates. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

What is "Secure Box version"? The GetVersion-APDU in AN12413 specification defines "VersionInfo" with a 2-byte "Secure Box version". There is no definition as to what is exactly is. Why do I need this information? I'm in the middle of a certification of a product with a notified body. This product uses a SE050 for certain security features and this is part of the certification since the SE050 also contains a form of firmware.  SE050 Re: What is "Secure Box version"? Hi @Kan_Li , thank you for your timely reply, I appreciate it. Can you confirm that every SE050A2 has the same: OEF ID, platform build ID, OS patch level, applet version, and feature configuration. And if we order a new batch, this does not change. This is all I need to know regarding this topic. Kind regards, Dirk Jan Re: What is "Secure Box version"? Hi @djdirkj , Please do not try to prove that all SE050A2 chips are literally identical; prove that they have the same OEF ID, platform build ID, OS patch level, applet version, and feature configuration, while recording unique serial/batch data for traceability. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: What is "Secure Box version"? Hi @Kan_Li , thank you for your response! Let me rephrase the question: I have a reel of about 500 SE050A2 components at our EMS. If I produce 500 products with these SE050, how can I be sure that every SE050 is exactly the same? If there is a difference in the SE050 it does not adhere to the certificate and it needs amendments to the certificate. I hope you understand that this is not desirable. Re: What is "Secure Box version"? Hi @djdirkj , Please record the Secure Box version as part of the SE050 software/configuration evidence, but do not try to interpret it independently unless NXP provides a controlled definition; for certification, the full  GetVersion  /  se05x_GetInfo  output is the stronger traceability artifact. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: What is "Secure Box version"? Hi @djdirkj , Yes, all these parameters are static on SE050A. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------