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 分钟后未发现任何问题，已记录错误： Re: Random occurences of timeouts while reading variables 你好， 我目前还没有遇到过这个问题，但我有一些建议，或许能帮到你： 尝试使用 12V 电源适配器为 S32K144EVB 供电，而不是使用 USB 接口。S32K144EVB 入门指南 尝试不同的方法将 FreeMASTER 项目连接到 EVB： 使用板载 USB 连接器 外置串口转USB转换器 使用调试探针直接连接到 S32K144 MCU 尽量减少非关键变量的刷新时间。 阻止笔记本电脑进入睡眠模式（因为睡眠模式可能会切断 USB 电源以节省电池电量）。 尝试从头开始创建一个新的 FreeMASTER 项目。 顺祝商祺！ 索林·班奇拉

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分間の実行後、問題なくログに記録されたエラー： Re: Random occurences of timeouts while reading variables こんにちは、 私はまだその問題に直面していないと思いますが、いくつか提案があります。役に立つかもしれません。 S32K144EVBをUSBではなく12V電源から起動してみてください。S32K144EVB の入門 FreeMASTERプロジェクトをEVBに接続するために、さまざまな方法を試してみてください: オンボードのUSBコネクタを使用する 外部シリアル-USB変換アダプター デバッグプローブを使って直接S32K144 MCUに接続してください 重要度の低い変数については、更新時間を短縮してみてください。 ノートPCがスリープモードに入らないようにしてください(バッテリー節約のためにUSB電源が切れる可能性があります)。 FreeMASTERプロジェクトをゼロから新規作成してみてください。 よろしくお願いいたします。 ソリン・バンシラ

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 开关。 谢谢！ 此致， 丹尼尔

S32DS arm V1.3 activation code failed Hello, the software activation code of my S32DS Arm V1.3 has expired. Could you help me extend the time.   My original activation code was:FF3F-27C7-FFAB-837F Re: S32DS arm V1.3 activation code failed Hello, It is extended now. Best regards, Peter 回复： S32DS arm V1.3 activation code failed My activation ID (0D3F-EFEF-B771-DA51) is new, and both online and offline activation failed when I tried to activate the same version of the software. The failure screen is in the attachment below. I hope you can help me solve this. Thank you.

NXPS32K358: ブートローダーがアプリケーションにジャンプした後にFreeRTOSタスクが実行されない サンプルアプリケーションプロジェクトを作成し、それをブートローダーとして使用しています。実際のアプリケーションプロジェクトは同一で、唯一の違いはフラッシュスタートのアドレスだけです。 ブートローダーは無事にアプリケーションにジャンプし、アプリケーションは実行を開始します。しかし、アプリケーション内ではxTaskCreate()関数は実行されません。 ブートローダーからFreeRTOSベースのアプリケーションにジャンプする際に、追加の設定が必要ですか?例えば、FreeRTOSタスクを作成・実行する前に、起動、割り込み、ベクターテーブル、スタックポインタ、スケジューラ関連の設定などを行う必要がありますか? 私はそのことを紹介しました コミュニティからの統一ブートローダーデモ チケット。解決策は得られませんでした。問題はFreeRTOSを含めたときだけで、RTOSなしでアプリケーションは問題なく動作することです。  S32K344では動作しますが、NXPS32K358では動作しません。 追加情報が必要な場合はお知らせください。 Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application 私たちのプロジェクトで使用されているブートローダーからアプリケーションへのジャンプコード: void Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t 関数; 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トグルを配置することです。 ありがとうございました。 よろしくお願いいたします。 ダニエル

S32K118 FlexIO Hello. I would like to consult about implementing both-edge detection for motor Hall sensor signals using the FlexIO module on S32K118. Currently, I need to capture both rising and falling edges of three Hall feedback signals from the BLDC motor. I am trying to configure FlexIO pins as input capture channels. However, I am confused about how to set FlexIO to detect both rising and falling edges simultaneously. Could you share the proper FlexIO timer and shifter configuration workflow for dual-edge capture。Besides.I also want to know if interrupts can be triggered on every edge, and whether there are known limitations or precautions when using FlexIO for Hall signal sampling on the S32K118 platform. Thank you very much. Re: S32K118 FlexIO Hello @Niuyanlin, If application is Hall sensor in BLDC motor feedback, I suggest looking into the FTM module instead. The following application note mentions how to configure the module for single and dual edge capture, and how to generate a capture interrupt: AN5303: Features and Operation Modes of FlexTimer Module on S32K – Application Note. "The Hall sensors are connected to the channels of the independent FTM (FTM_CHx). The FTM can then detect both the falling and rising edges of the Hall sensor signals and generate a capture interrupt." FlexIO, by contrast, requires constructing input capture behavior indirectly through timer-decrement modes, and it can work, but in my opinion, FTM module is better suited. Best regards, Julián Re: S32K118 FlexIO Hello, Julian, Thank you very much for your prompt reply and valuable suggestions. I recognize that FTM is a superior choice for feedback from BLDC motor Hall sensors. However, due to insufficient peripheral resources in the project, we had to implement input capture functionality using FlexIO. We would greatly appreciate it if you could provide a detailed software implementation plan related to FlexIO for our reference. Best regards, Niu Yanlin Re: S32K118 FlexIO Hello @Niuyanlin, Since FlexIO does not have the dedicated input capture capability, most of the documentation is based on communication emulation. The main suggestion I can give is to refer to S32K1's reference manual chapter 54. You can refer to the following application notes, which detail how to configure shifters and timers, along with the respective interrupts: AN14284: Timing Parameter Tuning for FlexIO Emulated Interface | NXP Semiconductors AN12174: Using FlexIO to emulate communications and timing peripherals – Application Note Understanding FlexIO The FlexIO module can generate an interrupt from 3 sources: Shifter error, Shifter status flag and Timer status flag. To enable the interrupts, you need to set the bits in the SHIFTSIEN, SHIFTEIEN and TIMIEN. However, there are no routines for input capture or BLDC motor control. I apologize for the inconveniences. Best regards, Julián

GUIGuider 1.10.1 から 2.0.0 への移行 私たちはGUIGuiderプロジェクトをバージョン1.10.1で構築してきましたが、新しいバージョン2.0.0に移行して新機能を試してみたいと思っています。古いGUIGuiderプロジェクトファイルが新しいバージョンでは読み込めないことが分かりました。おそらくそれはプロジェクトが使う新しいJSON構造の2.0.0のせいだと思います。 GUIGuiderの新しいバージョンにプロジェクトを簡単に移行する方法はありますか？それとも手動で変換する必要がありますか？

iMXEBOOKDC5 触摸控制器 IC 零件编号 亲爱的团队， 我正在使用iMXEBOOKDC5和i.MX8ULP EVK 。 目前为止，一切进展顺利。电子墨水显示屏工作正常，按钮和操纵杆也都能正常工作。 我现在想启用显示屏上的触摸面板。但是，我无法确定 EPD 模块上使用的触摸控制器 IC 的零件编号，因为 IC 上的标记似乎已被激光打标擦除。 我曾尝试自己查找相关信息，但没有成功。 请问您能否分享一下： iMXEBOOKDC5 显示屏上使用的触摸控制器 IC 部件号。 任何可用于支持触摸功能的 Linux 驱动程序、库或软件包。 感谢您的帮助。 顺祝商祺！ 评估板 Re: Touch Controller IC Part Number for iMXEBOOKDC5 你好， 所使用的触摸控制器IC是汇顶科技（Goodix Technology）生产的GT911。 您可以通过以下链接查看驱动程序： https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/input/touchscreen/goodix.c 顺祝商祺！ Re: Touch Controller IC Part Number for iMXEBOOKDC5 亲爱的， 感谢您的支持 顺便问一下，您能否提供电子墨水面板的 wayform bin 文件？ BRs， 莱德

S32K5の2つの異なるコルテックスM7からメインプラットフォームドメインのSEMA42ユニットにアクセスする S32K5の2つの異なるCortex M7コア(M7_0とM7_1)からメインプラットフォームのSEMA42_1ユニットにアクセスしようとしています。システムがフリーズします。ここで社内作業スペースを共有することはできません。 訂正ERR053433には次のように記載されています:SEMA42:複数のアプリケーションコアによるSEMA42_0およびPBRIDGE_2への同時アクセスによりシステムがハングします。 残念ながら、SEMA42_1を使用するという回避策では、システムハングアップの問題は解決しません。 S32K56xで2つのCortex M-7コアを設定・検証し、Design StudioのSEMA42_1ユニットのgate0にアクセスして最適化-OSを有効にしてもらえますか? システムのフリーズ問題は、以下のいずれか１つを使用することで解消されます。 最適化を無効にする -O0 命令キャッシュを無効にする SoC上の別のドメインのSRAMを使用する例CPE デバッガー経由でステップインする Re: Accessing SEMA42 unit on main platform domain from two different cortex M7 in S32K5 こんにちは、 @seasonedbit さん。 ご存知かもしれませんが、S32K5は現在プリプロダクション段階にあります。イネーブルメント(ドキュメント、ソフトウェア、ボード)は承認されたお客様のみが利用可能であり、そのため当社のグローバルオンラインサポートチームからはまだサポートされていません。 最初にこの装置を提供したFAEやNXPの担当者に連絡していただけますか?彼らはさらなる支援を提供できるでしょう。 ご理解いただきありがとうございます。 よろしくお願いします、 ジュリアン