PN5190B1 在首次开启射频场时无响应 大家好，希望你们能帮帮我，我们已经黔驴技穷了…… 我们有一块定制板，上面有PN5190B1HN/C121E（主机：CC1352 MCU，通过SPI接口）。新生产的约 100 台设备出现约 75% 的故障率：设备在首次开启射频场时停止对 SPI 做出响应，只有在 VEN RESET 后才能恢复。上一批产品（原型 5 件），设计和物料清单相同，运行正常。我们通过测量排除了天线/匹配问题、发射机短路、静态电源问题、SYS3V 电压骤降、芯片固件和硅批次问题。我们正在寻找已确认的根本原因、可能的芯片缺陷，或者我们可能遗漏的 EEPROM/电源配置。 硬件 NFC 前端：PN5190B1HN/C121E — GetVersion 报告 HW=0x52，ROM=0x02，FW=0x0201。 TX 供电 = 内部 TX_LDO。VUP_TX（引脚 6）= 3.3 V（LDO 输入）。VDDPA（引脚 9）= TX_LDO 输出（仅与 GND 解耦）。VBAT / VBATPWR = 3.3 V。未使用内部 DC-DC（未安装 BOOST_LX 电感器）。 主电源轨 SYS3V = 3.3 V，由 TPS62840 降压器供电（最大 0.7 A）。 27.12 MHz 晶体（Murata XRCGB27M120F3M00R0）。 DPC已禁用。采用超低功耗卡检测（ULPCD）。VDDPA 设置为最小值（TX_LDO_VDDPA_HIGH/LOW，EE 0x06/0x07 = 0x00）。 差分天线 TX1/TX2，EMC 滤波器（L = 160 nH）+ 匹配。测得的谐振≈12.56 MHz（无最终金属环境）（好单元和坏单元相同）。 症状（精确描述） 在字段 ON 之前，完整的 SPI 功能正常：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROM 读/写操作全部返回成功（状态 0x0000）。 第一次触发 FieldOn (RF_ON) 事件时，主机等待场开启事件超时。随后，所有 SPI 寄存器读取操作均超时（读取 CLIF_STATUS、SYSTEM_CONFIG、GetDieId 均返回 HAL IO 超时）。在 VEN RESET 之前，芯片在 SPI 接口上完全没有响应。 VEN 重置后芯片恢复正常（GetVersion OK），然后 FieldOn 又会将其损坏 → 无限重试循环。 不会辐射射频场（NFC 测试 LED 灯不亮）。电路板消耗约 20 mA 电流，且不会回到低功耗状态。 好的单元和坏的单元在固件 (0x0201)、DIEID 批次、EEPROM 配置、天线 (VNA) 和直流电阻方面是相同的。唯一的区别是，在 FieldOn 上，损坏的单位会被损坏。 主机 MCU 在死机期间保持运行（I²C 键盘扩展器持续响应），因此是 PN5190 损坏，而不是整个电路板损坏。 好单元和坏单元的电流消耗在约 2.7 秒内相同；在约 2.7 秒时，好单元完成工作并降至低功率，坏单元则保持在约 20 mA。 已排除（每一项都经过测量，而非凭直觉） 假设：它是如何被排除的 天线/匹配/调谐 使用 4 台正常设备和 4 台故障设备进行 miniVNA 测试 → 结果无法区分：谐振频率正常设备为 12.565 MHz / 故障设备为 12.593 MHz，RL ≈ −9 dB，|Z| ≈ 24.7 Ω，两者的驻波比 (SWR) 均 ≈ 2.08。 TX短路/过流 直流电阻 TX1–TX2 ≈ 1.2 kΩ，TX1–GND ≈ TX2–GND ≈ 1.15 kΩ，相同质量的器件与劣质器件相同。 静态供水泄漏/解耦 电流消耗在约 2.7 秒之前，无论好坏，都相同。 SYS3V 电压骤降 经测试，在 3.3V 电压下稳定；在所有 3.3V 电源轨上添加了 47µF 电容 → 没有变化，仍然失败 芯片固件 将设备更新到最新的 PN5190 固件 → 仍然失败，情况相同。（未经改动的正常设备和故障设备都报告固件版本为 0x0201。） 硅片 DIEID 良好 00000000 0DD0945E 5B38BDDC 892C0810 与 不良 00000000 0DD095A6 6938BDDC 892C0E64 — 前缀/批号结构相同 TX驱动器幅度 场开启前 CLIF_SS_TX1/2_RMCFG CW 幅度降低 → 无变化 TX_LDO 过流保护 通过 TX_LDO_CONFIG 位 11 禁用（0xAE → 0xA6）→ 无变化 TX_LDO 输出电容 移除 VDDPA 输出电容（4.7 µF + 100 pF）→ 无变化 EEPROM配置（正常单元和故障单元相同） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DC 关闭，VUP = VBATPWR，ULPCD 启用) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (默认值) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小值，≈ 1.5 V) DPC 已禁用 问题 这与报告的“首次启动/首次开启射频场时PN5190芯片损坏”的情况相符。您能否确认根本原因和最终解决方案？（注：使用最新的PN5190固件刷新设备并未解决问题——故障依旧。） 该批次/日期代码是否有硅油勘误表？我们可以提供完整的芯片ID和芯片标记照片。 对于我们的拓扑结构（内部 TX_低压差线性稳压器(LDO)，VUP_TX = 3.3 V，VDDPA = 低压差线性稳压器(LDO) 输出，DC-DC 关闭，DPC 关闭，ULPCD，VDDPA 最低为 1.5 V）：此配置是否有效？以最低 VDDPA 运行是否有问题？我们应该与哪种正确的 EEPROM 电源配置进行比较（与 PNEV5190B 相比）？ 是否存在上电时序要求（VEN 与电源斜坡），如果违反该要求会导致这种情况？注意：与之前的（正常工作的）批次相比，我们将 VEN 从 I²C 扩展器输出移到了直接的 MCU GPIO，并且 VEN 上拉电阻为 DNP，因此 VEN 在主机启动期间处于浮空状态。 排除欠压、过流、固件、硅和天线等因素后，RF_ON 路径中还有什么因素会导致芯片停止响应 SPI 信号，直到 VEN RESET？ 提前感谢！   伊格纳西奥 Re: PN5190B1 becomes unresponsive on first RF field ON 令人费解的是：正常工作的单元和出现故障的单元具有相同的固件版本（v2.01）、相同的硅版本（B1）、相同的硬件、相同的天线调谐，并且在克隆后具有相同的 EEPROM 内容。然而，有些有效，大多数无效。 将 PN5190 固件升级到 v2.0D 可以修复故障单元。我们想了解原因，以及 v2.01 中是否存在已知问题。   1. 症状： 对于一台故障设备： 启动和初始化过程正常进行。 在第一个射频场开启时，芯片不会消耗任何有意义的电流，也不会产生射频场（已用 NFC 供电的 LED 测试卡验证——它们不会亮起），并且完全停止对 SPI 做出响应。 主机报告 IO_TIMEOUT 超时。软复位也失败了（它需要 SPI 响应）。 只有硬件重置/断电重启才能恢复芯片。之后它会正常工作，直到下一次射频场开启时，它又会再次卡住。完全可复现。 供电轨（3.3V）始终保持稳定——没有电压骤降。 在电路板的第一次上电时，我们观察到一次性的 ~600 mA 事件（使用 Nordic PPK2 测量为 0.62 A），此后在后续上电时再也没有发生过。 故障设备上的 NFC Cockpit 日志： 信息：RFProtocolTuningService_PN5190：加载协议：RM_A_106 信息：TypeACardViewModel：RM_A_106 协议加载成功。 信息：射频场控制服务：射频开启 警告：ABalDelegate：等待 PIN_IRQ 变为高电平。超时。 错误：RfFieldControlService：字段开启期间发生错误 240，IO_TIMEOUT。 来自一台正常工作的设备（固件版本相同，配置相同）的日志： 信息：RFProtocolTuningService_PN5190：加载协议：RM_A_106 信息：TypeACardViewModel：RM_A_106 协议加载成功。 信息：射频场控制服务：射频开启 信息：射频场控制服务：射频关闭 ATQA 04 00 / SAK 0x08 / UID 04 8D 12 33 2. 测试设置 为了排除我们自己的主机固件，我们按照 NXP 知识库文章“如何将外部 PN5190 连接到 PNEV5190BP 评估板”中的说明，将生产板直接连接到用作 USB↔SPI 桥接器的 PNEV5190BP（R5/R7 已放置，R6 开路；R20 已放置；VBAT/VBAT_PWR/VUP 跳线已移除；SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND 已连接到外部板）。 NFC Cockpit v9.0.0 PNEV5190BP，微控制器固件版本为 NNC_uC_VCOM_04.00.00 外部电路板由 Nordic PPK2 供电，电压为 3.3V（可进行电流测量） 使用 NXP 主机和 NXP 软件也会出现完全相同的故障，因此这不是由我们的主机固件引起的。 3. 我们排除的因素（通过测量）： 假设 它是如何被排除的 供应崩溃/断电 3.3V 电源轨测量结果始终稳定 TX短路 直流电阻 TX1-TX2、TX1-GND、TX2-GND 在正常单元和故障单元上相同（几千欧姆） PA解耦泄漏 在场启动之前，电流消耗在好坏两方面都相同 天线失谐/匹配 VNA测量，4个合格单元+4个不合格单元——见下文 集成电路受到物理损坏 芯片可通过硬件RESET恢复，但随后又会重复出现故障。 我们的主机固件 使用 NFC Cockpit + PNEV5190BP 进行复现 PN5190固件版本 好的和坏的单元都运行在 v2.01 版本，硬件 B1 上。 用户EEPROM内容 将正常单元的完整 EEPROM 克隆到故障单元中 → 仍然失败 差异：~29 kHz (0.2%)，在测量噪声范围内。已在 8 个电路板上确认。天线无法区分。 4. EEPROM 比较 - 单个字节 我们分别从一台运行固件版本为 v2.01 的正常设备和一台故障设备中提取了完整的用户 EEPROM，并比较了它们的差异。 648 个参数中，恰好有一个不同： 区域：DPC_SETTINGS 参数：DPC_CONFIG 偏移量：0x76 良好单元：0x77 错误单元：0x76 其他所有内容都字节完全相同。 这看起来像是答案，特别是考虑到 RN00003 中的预防措施说明： 不要禁用 DPC，并为连接到匹配“对称”天线的 IC 激活 RF 场（例如，客户开发板天线）。长时间过电流可能会导致发射器驱动器损坏。 我们的天线是对称的（差分 TX1/TX2），首次上电时出现的一次 ~600 mA 事件与过电流情况一致。 然而，复制字节并不能修复该单元。 测试 结果 向故障单元（v2.01）写入 DPC_CONFIG = 0x77，验证读取结果，然后断电重启 仍然失败 将正常单元的完整 EEPROM 转储加载到故障单元中（v2.01），然后断电重启 仍然失败 良好单元，未修改，版本 2.01 完美运行 因此，DPC_CONFIG 与通过/失败相关，但并非导致通过/失败的原因。无论真正的区别是什么，都不在用户 EEPROM 区域。 5. 解决方法：将固件安全升级到 V2.0D 版本   使用PN5190Firmware_2.0D.esfwu （LEDL 文件夹，B0/B1 的旧版下载）执行安全固件升级，可使故障设备恢复正常工作： 空闲状态：约 33 mA 射频场开启：持续稳定电流约 240 mA，LED 指示灯亮起 激活Layer3返回ATQA 04 00，SAK 0x08，UID 04 8D 12 33 经验证，使用我们自己的产品固件后可以正常工作。 目前已通过这种方式回收了两台设备，两台设备均功能完好。 副作用：PwrConfig 被覆盖，导致过热。 升级后，EEPROM 偏移量0x0000 ( PwrConfig ) 从0x21变为0xE4 。使用0xE4 ： PwrConfig 0xE4 PwrConfig 0x21（已恢复） 空载电流 约290毫安 约33毫安 芯片温度（ PMU_TEMP_REG@0x5B ） 100℃ 40°C 空闲时电流为 290 mA，无 RF场，内部温度传感器读数为 100 °C（Tj max 为 125 °C）。每次升级后，我们将PwrConfig恢复为0x21 。 0xE4是v2.0D 版本中 PwrConfig 的预期默认值吗？这看起来也可能是其他用户会遇到的问题。 升级更改了 16 个 EEPROM 参数。 参数 偏移量 之前（v2.01） （v2.0D）之后 PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 极性 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 数字TB信号指数 0xCE9 0x00 0x9B 数字TB信号比特 0xCEA 0x00 0x04 模拟TB信号 0xCEB 0x00 0x78 由于将正常单元的完整 EEPROM 克隆到故障单元中并不能解决问题，因此修复方法不可能仅仅依靠这 16 个字节——固件代码本身肯定存在一些问题。 6. 模具 ID 所有设备均为Hw B1，FW v2.01版本： 错误代码 #1：00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 错误代码 #2：00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 错误代码 #3：00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 良好 #1：00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. 问题 FW v2.01 中是否存在已知问题，会导致 RF 场开启时 IC 卡死，既没有产生场也没有 SPI 响应？我们注意到，DPC_CONFIG 寄存器仅在 v02.03 版本中引入（根据 RN00003），并且 v02.07→v02.08 和 v02.08→v02.09 都包含 DPC 法规修复。 为什么固件、芯片版本、硬件和 EEPROM 完全相同的情况下，约 25% 的设备可以正常工作，而约 75% 的设备却无法正常工作？除了用户 EEPROM 区域（出厂设置、内部状态）之外，同一批次的单元之间还有什么可能存在差异吗？ 上述芯片 ID 能否追溯到不同的生产批次或晶圆批次？ 升级到 v2.0D 后，PwrConfig = 0xE4 是否为预期值？我们的设计实现了约 290 mA 的空闲功耗和 100 °C 的芯片温度。 PN5190 设备可以订购预装特定固件版本的吗？尽管工具本身已发出版本 2.01 的警告，但我们仍然使用该版本进行发货，导致我们损失了一整批产品。 对于剩余的约 80 个未使用单元，建议在首次通电前升级到 v2.0D，以完全避免一次性 600 mA 事件的发生。 非常感谢您的指导。 Re: PN5190B1 becomes unresponsive on first RF field ON 您好，先生， 目前尚未发现任何已知的问题会导致 RF Fiel ON 命令使 IC 卡死。 更新固件并克隆 EEPROM 内容后，能否请您确认所有受影响的 PN5190 设备的问题是否都已解决？这些信息将有助于我们更好地了解问题的范围。 如果某些设备上仍然存在该问题，您是否有机会对正常工作的设备和出现故障的设备进行 A/B 对比测试？这样的测试可以帮助确定根本原因是集成电路本身还是系统的其他元件。 关于批次追踪，请您向代理商核实他们是否能提供有关受影响元器件的生产批次和制造历史的更多信息？

Ara240 16GB M.2 模块 Ara240 16GB M.2 模块官方支持哪些量化精度？（INT4、8、16） Re: Ara240 16GB M.2 Module 根据Ara240 离散神经处理单元数据表 精确测量 官方文件支持 INT4 未找到相关文档支持 INT8 支持 INT16 支持 INT32 虽然不在您的 INT4/8/16 列表中，但已支持。

SDAファームウェアに関する質問 FRDM-A-S32K358の開発ボードを購入し、Open SDAを担当するMK26チップのファームウェアを変更するためにJTAGポートを確認しました。もし誤ってJ13にファームウェアをインストールしてしまった場合、Open SDAのファームウェアを入手する必要があります。この場合、サポートチケットを通じてファームウェアを入手できますか? Re: Open SDA Firmware Question こんにちは、 @wj_kwak MK26 OpenSDAデバイスがJ13経由で上書きされた場合、正常に動作するOpenSDAブートローダーを前提としているため、標準のOpenSDAアップデート手順は適用できなくなる可能性があります。OpenSDAのリカバリファームウェアは、通常、単体のプログラミングイメージとしては配布されていません。 OpenSDAのファームウェアとブートローダーは、NXPが開発したソフトウェアではなくPEmicro技術です。PEmicroはOpenSDAのファームウェアアップデート、ブートローダー更新アプリケーション、関連サポートを提供しています。 したがって、MK26がJTAG/SWDで消去または再プログラムされ、OpenSDAブートローダーが機能しなくなった場合、回復案内やファームウェアの入手は主にPEmicroが担当となります。 https://www.pemicro.com/support/index.cfm よろしくお願いいたします。 ルーカス

IMX95 Aquila ISP の使用状況 こんにちは、 私はAquila IMX95評価キット2を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) MIPが正常に動作しているかどうかを確認するために、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ドライバ自体には関係ないと思います。 事実： 両方のOV5640カメラはlibcameraによって検出されます GStreamer は30fpsでストリーミング可能です V4L2-CTLは画像を撮影できます センサードライバー、I2C通信、  CSI-2  links、メディアトポロジーがすべて正常に動作していることを示します。 重要な点は、NXP Neo ISPパイプラインがRAWのBayerセンサー入力を想定していることです。 OV5640は独自の内部画像処理パイプラインを持つSoCイメージセンサーであり、NXP BSPでは通常、RAWバイヤーセンサーとしてではなくYUV出力モード(例:YUV422)で使用されます。このような構成では、カメラは標準のV4L2/libcameraパイプラインを通じて使用できますが、Neo ISPパイプラインの要件には合致しません。 これは以下の理由を説明するだろう。 `cam -l` はデフォルトで両方の OV5640 カメラを表示します 設定後 export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' カメラは検出されなくなりました カメラはシステム内に存在しますが、NEOパイプラインハンドラーは互換性のあるカメラトポロジーを見つけられず、そのためlibcameraにはカメラが0台も露出します。 実際のセンサー出力フォーマットを確認するために、以下の出力を教えていただけますか: 「バッシュ」 media-ctl -p V4L2-ctl --list-formats-ext 特に、センサーが以下のようなRAWバイヤーフォーマットを露出しているかどうかに関心があります: SBGGR8 SBGGR10 SRGGB10 RG10 BA10 YUVフォーマット(例:YUYV/UYVY)のみが利用可能な場合、カメラはRAWモードで動作せず、Neo ISPパイプラインで処理できません。 OV5640ハードウェアはRAWバイヤー出力に対応していますが、BSPカメラドライバーではRAWサポートは一般的に有効ではなく、NXP Neo ISPスタックもセンサー固有のチューニングデータに依存しています。RAW出力が有効であっても、専用のOV5640チューニングプロファイルがないため、ISPの適切な動作(AE/AWB/画像品質チューニング)が妨げられる可能性があります。 もしNeo ISPフレームワーク自体を評価するのが目的なら、NXP ISPスタックで動作することが知られているセンサを使う方が簡単かもしれません。一般的な候補としては、以下のようなものがあります。 OS08A20 OX03C10 OX05B1S AR0521 AR1335（追加の調整作業が必要になる場合があります） 上記のコマンドの出力を教えてもらえますか?これにより、現在のOV5640の設定がRAWベイヤーフォーマットをシステムに公開しているかどうかを確認できます。 よろしくお願いします、 Re: IMX95 Aquila ISP usage ご返信ありがとうございます。 追加の確認を行いました。 おっしゃる通り、OV5640は最初は UYVYモードで動作していましたが、手動で1つのセンサーを 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] （比較のため、2台目のOV5640はUYVYモードのままです） SO : OV5640 -> SRGGB8 CSI -> SRGGB8 フォーマッター -> SRGGB8 クロスバー -> SRGGB8 => RAWバイエルはセンサ、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   => しかし、CSI/Formatter/ISIパイプラインを公開しているメディアデバイス(/dev/media0)は1台だけです。メディアグラフにはneoispのエンティティは現れません。メディアのグラフにneoispの存在は見当たりませんし、これが予想されるものなのかも分かりません。 => cam -l (libcamera) を実行しても、利用可能なカメラは返されません。 現時点ではRAWのBayerパスは機能しているようですが、Neo ISPがどこでアクティブなパイプラインの一部になるのかは特定できません。   ストリームが実際にNeo ISPによって処理されているか、単にCSI -> Formatter -> ISI経路をたどるのではなく、どうやって確認できますか?   また、 https://www.nxp.com/docs/en/user-guide/UG10215.pdf も参照してください。この構成に関する推奨ガイドはまだありますか？それとも、i.MX95 上で OV5640 + Neo ISP を使用するためのより具体的な参考資料はありますか？       敬具 Re: IMX95 Aquila ISP usage 現時点で私が疑っているのは、以下のいずれかが起こっているということです。 OV5640はRAWベイヤーモードではなく、YUVモードで動作している可能性が高い。 カメラの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 私の理解が正しければ、このカメラはRAWベイヤー形式で撮影できるはずなので、私もそのように設定しました（正しく設定できていればいいのですが）。 別のイメージを使って再度フラッシュしてみて、問題がそのあたりにあるかどうか確認してみます。 敬具 Re: IMX95 Aquila ISP usage 最新情報のご提供ありがとうございます。The  v4l2-ctl  outputはISIキャプチャノードがRAWバイエルフォーマットをサポートしていることを確認しており、前のメッセージの  media-ctl -p  outputはすでにRAWバイエルパスがパイプライン内で正しく伝播していることを示しています: OV5640 (SRGGB8) -> CSI (SRGGB8) -> フォーマッタ (SRGGB8) -> クロスバー (SRGGB8) つまり、センサー側の構成は正しいように見えます。 現在の核心的な問題は、  neoisp  モジュールが読み込まれているものの、プレスリリース、製品ニュースグラフに表示されず、  /dev/media1  が作成されていないことです。これは通常、  neoisp  ドライバがカーネルモジュールとしては正常にロードされたが、デバイスプローブ中に失敗し、プレスリリース、製品ニュースデバイスの登録ができなくなることを意味します。 以下の診断情報を教えていただけますか? # Neoispプローブの状態を 確認 dmesg |grep -i neoisp dmesg |grep -i "isp@4ae" DMESG |grep -i 「プローブ失敗」 DMESG |grep -i "4ae00000" # 利用可能なプレスリリース、製品ニュース機器を ls -la /dev/プレスリリース、製品ニュース* # sysfs の neoisp ステータスを確認してください ls /sys/bus/プラットフォーム/ドライバ/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のバイエルデータの出力が可能ですが、以下の理由から一般的にOV5640+Neo ISPの組み合わせは新しいデザインに推奨しません。 OV5640はすでに寿命切れ(EOL)センサです。 RAW出力はサポートされていますが、センサ自体は最新のRAWセンサに比べて調整可能なコントロールが限られています。 NXPのi.MX95リファレンスカメラソリューションは、すでにNeo ISPソフトウェアフレームワーク内でサポート・検証されているOS08A20などのRAWセンサに基づいています。 したがって、弊社の推奨案は以下のいずれかとなります。 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 車載 Exposure(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機能を備えています。したがって、Neo ISP AEアルゴリズムの代わりにセンサ内部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(Image プロセッシング Algorithm)フレームワークがa  CameraHelper  factoryを使って、カーネルのV4L2サブ開発モデル文字列を照合してセンサ固有のゲイン/露出アルゴリズムを調べていることです。 CameraHelper "ov5640" に登録されていなかったため、工場出荷時は nullptr が戻り、ISPパイプラインはこのセンサに設定できませんでした。 これに対処するため、  CameraHelper  をOV5640センサ用にNXPカーネルドライバ( drivers/media/i2c/ov5640.c )に基づく実装しました😞 ゲインレジスタのマッピング: 登録する：  OV5640_REG_AEC_PK_REAL_GAIN  ( 0x350a )、10ビット値 形式: Q6.4 固定小数点、ユニティゲイン = 16 gainCode(g) = round(g * 16) ゲイン(コード) = コード / 16.0 2つのファイルが変更されました。 camera_helper_ov5640.cpp – OV5640用の新しいCameraHelper実装で、カーネルのサブ開発モデル文字列に合わせて "ov5640 " として登録 メソンビルド  - 追加した  camera_helper_ov5640.cpp  ビルドソースリストへ これらの2つのファイルを使用してlibcameraを再構築し、再度試してください。  LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 。Neo ISPパイプラインは今後OV5640センサーを見つけて設定できるようになるはずです。 なお、これによりゲイン／露出制御パスは有効になりますが、OV5640用の完全なISPチューニングプロファイル（AE／AWBパラメータ）はまだ利用できません。画像品質調整にはさらなる作業が必要かもしれません。 再建後の結果をお知らせください。

S9KEAZN16AM WDOGタイミングに関する補足説明：128バスクロックと観測された80µsおよび2.5msの遅延について こんにちは、 私はS9KEAZN16AMを扱っており、WDOGの初期化タイミングについていくつか確認したい点があります。 設定 MCU:S9KEAZN16AM バスクロック: 16.777216 MHz WDOGクロックソース：1kHz LPOCLK リセットタイプ:ソフトウェアリセット(SYSRESETREQ) KEA64リファレンスマニュアルによると、ウォッチドッグの解除シーケンスの後: 「アンロックシーケンスを完了した後、ユーザーは128のバスクロック内でウォッチドッグを再構成しなければなりません;そうでなければ、監視役はMCUのリセットを強制します。」 バスクロック周波数は16.777216MHzです。 128バスクロック ≈ 7.63マイクロ秒 補足事項 現在の実装では、安定した動作のために以下の遅延が必要となります。 ソフトウェアリセット();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); 我々は2つの問題点を指摘する。 Software_Reset() の後の 2.5 ms の遅延を削除または短縮すると、ウォッチドッグ カウンタが正しく起動/実行されない場合があります。 WDOG_Init() の後の 80 µs の遅延を削除すると、ウォッチドッグの設定が常に正しく適用されるとは限りません。 質問 128バスクロックの要件は、ロック解除後の設定ウィンドウのみに適用されるのでしょうか、それともその後も追加の内部同期が行われるのでしょうか？ 1 kHzのLPOクロックの使用によって追加の同期遅延が生じることはありますか? ソフトウェアリセット後の起動タイミングの要件で、約2.5msの遅延が必要になる理由は何かありますか? 固定遅延の代わりに、推奨されるステータスビットやポーリングメカニズムはありますか？ 混乱の主な原因は、観測された遅延（ 80 µs と 2.5 ms ）が、文書化された128 バス クロックの要件（約 7.6 µs）から示唆されるタイミングよりもかなり大きいことである。 何かご助言いただければ大変ありがたいです。 よろしくお願いします。

Random occurences of timeouts while reading variables Hello, I have been working on a battery test rig set up by my predecessors on the project. The test rig uses an nxp S32K144EVB board connected via usb to a computer. The code is built from a simulink file and monitoring of the test is made via FreeMASTER 3.2. The project has been working on a laptop for a few months and it has been necessary to configure a new laptop as a replacement. However, even while installing the same FreeMASTER version, the same drivers and using the same project files, all variable reads as "?" due to timeout errors after a seemingly random duration. Any help would be greatly appreciated. Logged errors after 12 minutes of runtime with no issues :

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.

打开 SDA 固件问题 我购买了 FRDM-A-S32K358 开发板，并检查了 JTAG 端口，以便更改负责 Open SDA 的 MK26 芯片上的固件。如果我误将固件安装到了 J13 上，我将需要获取 Open SDA 固件。在这种情况下，我可以通过提交支持工单来申请获取固件吗？ Re: Open SDA Firmware Question 嗨@wj_kwak 如果 MK26 OpenSDA 设备已通过 J13 覆盖，则标准的 OpenSDA 更新程序可能不再适用，因为它依赖于一个正常工作的 OpenSDA 引导加载程序。OpenSDA 恢复固件通常不以独立编程镜像的形式分发。 OpenSDA 固件和引导加载程序采用的是 PEmicro 技术，而不是 NXP 开发的软件。PEmicro 为 OpenSDA 提供固件更新、引导加载程序更新应用程序及相关支持。 因此，如果 MK26 已通过 JTAG/SWD 擦除或重新编程，并且 OpenSDA 引导加载程序不再有效，则 PEmicro 将是恢复指导和固件可用性的主要联系人。 https://www.pemicro.com/support/index.cfm 此致， Lukas

Open SDA Firmware Question I purchased the FRDM-A-S32K358 development board and checked the JTAG port for changing the firmware on the MK26 chip responsible for Open SDA. If I accidentally install the firmware on J13, I will need to obtain the Open SDA firmware. In this case, can I obtain the firmware by requesting it via a support ticket? Re: Open SDA Firmware Question Hi @wj_kwak  If the MK26 OpenSDA device has been overwritten via J13, the standard OpenSDA update procedure may no longer be applicable, since it relies on a functioning OpenSDA bootloader. The OpenSDA recovery firmware is not generally distributed as a standalone programming image. The OpenSDA firmware and bootloader are PEmicro technology rather than NXP-developed software. PEmicro provides the firmware updates, bootloader update applications, and related support for OpenSDA. Therefore, if the MK26 has been erased or reprogrammed via JTAG/SWD and the OpenSDA bootloader is no longer functional, PEmicro would be the primary contact for recovery guidance and firmware availability. https://www.pemicro.com/support/index.cfm Regards, Lukas

读取变量时随机出现超时 您好，我一直在使用前人在这个项目中搭建的电池测试装置。 测试装置使用 nxp S32K144EVB 板，通过 USB 连接到计算机。 该代码由 simulink 文件构建，测试监控通过 FreeMASTER 3.2 进行。 该项目已在一台笔记本电脑上运行了几个月，现在需要配置一台新的笔记本电脑作为替代品。然而，即使安装相同版本的 FreeMASTER、相同的驱动程序并使用相同的项目文件，所有变量仍然显示为“?”由于在看似随机的时间段后出现超时错误。 若能得到任何帮助，我将不胜感激。 运行 12 分钟后未发现任何问题，已记录错误：

S32DS arm V1.3 激活码失败 您好，我的S32DS Arm V1.3软件激活码已过期。您能帮我延长一下时间吗？ 我最初的激活码是：FF3F-27C7-FFAB-837F Re: S32DS arm V1.3 activation code failed 你好， 现在已经延长了。 顺祝商祺！ Peter 回复： S32DS arm V1.3 activation code failed 0D3F-EFEF-B771-DA51我的激活ID是新的，对同版本的软件进行激活，在线激活和离线激活都失败了，失败界面在下面的附件中，希望帮我一起解决一下谢谢

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 参数）尚未可用。图像质量调优可能仍需进一步完善。 重建完成后与我们联系结果。

S9KEAZN16AM WDOG 时序说明：128 个总线时钟与观察到的 80 微秒和 2.5 毫秒延迟对比 你好， 我正在与S9KEAZN16AM合作，想了解一下 WDOG 初始化时间的相关问题。 配置 MCU：S9KEAZN16AM 总线时钟：16.777216 MHz WDOG 时钟源：1 kHz LPOCLK 重置类型：软件重置（SYSRESETREQ） 根据KEA64参考手册，在看门狗解锁序列之后： “解锁序列完成后，用户必须在 128 个总线时钟周期内重新配置看门狗；否则，看门狗将强制 RESET MCU。” 总线时钟频率为 16.777216 MHz： 128 个总线时钟周期 ≈ 7.63 微秒 说明 为了确保可靠运行，我们目前的实施方案需要以下延迟： 软件重置();   SysTick_DelayUs(2500);   禁用中断();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   启用中断(); 我们发现两个问题： 如果移除或减少Software_Reset() 之后的 2.5 毫秒延迟，看门狗计数器并不总是能正确启动/运行。 如果移除WDOG_Init() 之后的 80 µs 延迟，看门狗配置将无法始终正确应用。 问题 128 总线时钟要求是否仅限于解锁后的配置窗口，还是之后还会进行额外的内部同步？ 使用1 kHz LPO 时钟是否会引入额外的同步延迟？ RESET后是否存在已知的启动时间要求，可以解释为何需要约 2.5 毫秒？ 是否有推荐的状态位或轮询机制可以替代固定延迟？ 主要令人困惑的是，观察到的延迟（ 80 µs 和 2.5 ms ）明显大于记录在案的128 总线时钟（~7.6 µs）要求所隐含的时序。 任何指导都将不胜感激。 谢谢！

S32DS Arm V1.3 起動コードが失敗しました こんにちは、私のS32DS Arm V1.3のソフトウェアアクティベーションコードが期限切れになりました。時間を延長する手助けをしてもらえますか? 私の元の認証コードはFF3F-27C7-FFAB-837Fでした。 Re: S32DS arm V1.3 activation code failed こんにちは、 現在は延長されています。 よろしくお願いいたします。 ピーター 回复： S32DS arm V1.3 activation code failed 私の認証ID（0D3F-EFEF-B771-DA51）は新しいもので、同じバージョンのソフトウェアをオンラインでもオフラインでも認証しようとしましたが、どちらも失敗しました。失敗画面は添付ファイルをご覧ください。解決にご協力いただければ幸いです。よろしくお願いいたします。

S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays Hello, I am working with S9KEAZN16AM and would like some clarification regarding WDOG initialization timing. Configuration MCU: S9KEAZN16AM Bus Clock: 16.777216 MHz WDOG Clock Source: 1 kHz LPOCLK Reset Type: Software Reset (SYSRESETREQ) According to the KEA64 Reference Manual, after the watchdog unlock sequence: "On completing the unlock sequence, the user must reconfigure the watchdog within 128 bus clocks; otherwise, the watchdog forces a reset to the MCU." With a bus clock of 16.777216 MHz: 128 bus clocks ≈ 7.63 µs Observations Our current implementation requires the following delays for reliable operation: Software_Reset();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); We observe two issues: If the 2.5 ms delay after Software_Reset() is removed or reduced, the watchdog counter does not always start/run correctly. If the 80 µs delay after WDOG_Init() is removed, the watchdog configuration is not always applied correctly. Questions Is the 128 bus clock requirement only the configuration window after unlock, or does additional internal synchronization occur afterwards? Can the use of the 1 kHz LPO clock introduce additional synchronization delays? Is there any known startup timing requirement after a software reset that could explain the need for ~2.5 ms? Is there a recommended status bit or polling mechanism that should be used instead of fixed delays? The main point of confusion is that the observed delays (80 µs and 2.5 ms) are significantly larger than the timing implied by the documented 128 bus clock (~7.6 µs) requirement. Any guidance would be greatly appreciated. Thank you.

変数の読み取り中にタイムアウトがランダムに発生する こんにちは。私はこのプロジェクトの前任者たちが設置したバッテリー試験装置を使って作業しています。 テストリグはnxp S32K144EVBボードをUSBでコンピューターに接続しています。 コードはSimulinkファイルから構築され、テストの監視はFreeMASTER 3.2を介して行われます。 このプロジェクトは数ヶ月間ノートPCで作業しており、新しいノートPCを交換する必要がありました。しかし、同じFreeMASTERバージョン、同じドライバ、同じプロジェクトファイルを使っていても、すべての変数が「?」と読み取られます。一見ランダムな時間経過後にタイムアウトエラーが発生するため。 どんなご支援でも大変感謝いたします。 12分間の実行後、問題なくログに記録されたエラー：

NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application We have created a sample application project and are using it as the bootloader. The actual application project is identical, with the only difference being the flash start address. The bootloader successfully jumps to the application, and the application starts executing. However, within the application, the xTaskCreate() function does not executed. Is there any additional configuration required when jumping from a bootloader to a FreeRTOS-based application? For example, are there any startup, interrupt, vector table, stack pointer, or scheduler-related configurations that must be performed before the application can create and execute FreeRTOS tasks? I referred the Unified bootloader Demo ticket from community. I didn't get the solution. Issue is only when we include FreeRTOS, without RTOS the application is working fine.  Its working for S32K344 not for NXPS32K358. Please let me know if any additional information is required. Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Hi @Indhumathi, This "xTaskCreate() does not execute" is ambiguous and could mean different things. Can you check the following? 1. Execution never reaches xTaskCreate() The application starts, but something hangs or faults before the call. 2. xTaskCreate() is called but returns an error The function is called and returns an error, for example errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY. 3. Tasks are created, but the scheduler never runs them xTaskCreate() succeeds (returns pdPASS) and the tasks are created, but vTaskStartScheduler() is never called, fails, or SysTick/PendSV are not operating correctly after the bootloader jump. As a result, the tasks remain in the Ready state and never get CPU time. Also, is vApplicationMallocFailedHook() called? Which heap implementation are you using? What is the state of CM7_2? Is it running, held in reset, or started by the bootloader? Thank you, BR, Daniel Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Bootloader-to-Application Jump Code Used in Our Project: void Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t func; uint8 i;   DisableAllInterrupts();   S32_SysTick->CSRr = 0; S32_SysTick->RVR = 0; S32_SysTick->CVR = 0;       for(i = 0; i < 10; i++)     {     S32_NVIC->ICER[i] = 0xFFFFFFFFU;     S32_NVIC->ICPR[i] = 0xFFFFFFFFU;     }     appStack = *(volatile uint32_t *)0x00442000; __set_MSP(appStack); S32_SCB->VTOR = 0x00442000; func = *(uint32_t volatile *)(((uint32_t)0x00442004)); (* (void (*) (void)) func)(); } Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Hello @Indhumathi, To narrow down the root cause, could you please verify whether the following interrupt handlers are actually being executed? SVC handler (vPortSVCHandler) — responsible for starting the first FreeRTOS task PendSV handler (vPortPendSVHandler) — responsible for context switching between tasks SysTick handler (vPortSysTickHandler / xPortSysTickHandler) — responsible for the FreeRTOS tick The simplest way to check is to place a breakpoint or a GPIO toggle at the entry of each handler in the application. Thank you, Regards, Daniel

Ara240 16GB M.2 Module Which quantization precisions are officially supported in Ara240 16GB M.2 Module ?(INT4,8,16) Re: Ara240 16GB M.2 Module According to Ara240 Discrete Neural Processing Unit Data Sheet Precision Officially documented support INT4 No documented support found INT8 Supported INT16 Supported INT32 Supported, though not in your INT4/8/16 list

Ara240 16GB M.2モジュール Ara240 16GB M.2モジュールで公式にサポートされている量子化精度はどれですか？(INT4、8、16) Re: Ara240 16GB M.2 Module Ara240離散神経プロセッシングユニットのデータシートによると 高精度 公式に文書化されたサポート INT4 ドキュメントのサポートは見つかりませんでした INT8 サポートされる INT16 サポートされる INT32 サポートされていますが、INT4/8/16 のリストには含まれていません。

NXPS32K358：引导加载程序跳转到应用程序后，FreeRTOS 任务未运行 我们创建了一个示例应用程序项目，并将其用作引导加载程序。实际的应用程序项目与之完全相同，唯一的区别在于闪存起始地址。 引导加载程序成功跳转到应用程序，应用程序开始执行。但是，应用程序中的 xTaskCreate() 函数并未执行。 从引导加载程序跳转到基于 FreeRTOS 的应用程序时，是否需要任何额外的配置？例如，在应用程序能够创建和执行 FreeRTOS 任务之前，是否必须执行任何与启动、中断、向量表、堆栈指针或调度程序相关的配置？ 我提到了 统一引导加载程序演示 社区提交的工单。我没有找到解决方案。问题只出现在引入 FreeRTOS 时，不引入 RTOS 时应用程序运行正常。  它适用于 S32K344，但不适用于 NXPS32K358。 如有需要，请告知是否需要提供其他信息。 Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application 我们项目中使用的引导加载程序到应用程序的跳转代码： 无效 Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t func; uint8 i;   DisableAllInterrupts();   S32_SysTick->CSRr = 0; S32_SysTick->RVR = 0; S32_SysTick->CVR = 0;   for(i = 0; i < 10; i++)     { S32_NVIC->ICER[i] = 0xFFFFFFFFU; S32_NVIC->ICPR[i] = 0xFFFFFFFFU;    } appStack = *(volatile uint32_t *)0x00442000; __set_MSP(appStack); S32_SCB->VTOR = 0x00442000; func = *(uint32_t volatile *)(((uint32_t)0x00442004)); (* (void (*) (void)) func)(); } Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application 你好@Indhumathi ， 为了缩小问题根源范围，请您验证一下以下中断处理程序是否正在执行？ SVC 处理程序 (vPortSVCHandler) — 负责启动第一个 FreeRTOS 任务 PendSV 处理程序 (vPortPendSVHandler) — 负责任务之间的上下文切换 SysTick 处理程序（vPortSysTickHandler / xPortSysTickHandler）——负责 FreeRTOS 滴答 最简单的检查方法是在应用程序中每个处理程序的入口处设置断点或 GPIO 开关。 谢谢！ 此致， 丹尼尔