Processor / Platform: NXP i.MX95 FRDM Board
Camera Module: RPI-CAM-MIPI (AR0144 Sensor + AP1302 Onboard ISP)
Firmware Used: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin (renamed to ap1302_ar0144_single_fw.bin and placed in /lib/firmware/)
I am experiencing a persistent pink / magenta color cast in the decoded images/video streams coming from the AR0144 camera module via the AP1302 ISP.
Despite using this tuned firmware file, the decoded frames still exhibit a noticeable pink cast (sample image attached).
Is this a known issue with the AR0144 + AP1302 setup?
Is there an updated AP1302 firmware binary available to fix this color balance issue?
The NXP documentation for the RPI-CAM-MIPI camera module states:
"The bypassable onboard ISP chip allows it to be used with a wide range of SoCs."
Since the i.MX95 features an integrated hardware NEO ISP, we would like to bypass the AP1302 onboard processing and route the RAW Bayer stream from the AR0144 directly into the i.MX95 internal NEO ISP using libcamera and the neo-ipa-uguzzi pipeline handler.
Questions for NXP:
Is RAW passthrough (bypassing AP1302 hardware processing to feed RAW Bayer directly to the i.MX95 NEO ISP) officially supported on the i.MX95 FRDM board?
If yes, could NXP provide the step-by-step configuration required to enable RAW passthrough?
How can we acquire or generate the required DTP / YAML tuning files for the AR0144 sensor under the NEO ISP? Does NXP have a pre-calibrated YAML/DTP file available for AR0144 that can be shared?
I reproduce this on my imx95 frdm board, doesn't have any color issue, you should set the correctly since you can bring up the camera, just check if your display has any issue or not
1) set the dtb file as imx95-15x15-frdm-ap1302.dtb
2) your firmware is correct
3) use the command gst-launch-1.0 libcamerasrc ! autovideosink
Hi,
Thank you for testing and providing the feedback on Question 1.
Could you please also address my second question regarding bypassing the onboard AP1302 ISP to utilize the i.MX95's internal NEO ISP?
Since the RPI-CAM-MIPI board documentation states that the onboard ISP is bypassable, we want to route the RAW Bayer stream from the AR0144 sensor directly into the i.MX95's internal NEO ISP.
Could you please clarify:
Is RAW passthrough (bypassing AP1302 hardware ISP processing) supported for the AR0144 on the i.MX95 FRDM board in the Linux 6.12.49_2.2.0 BSP release?
Device Tree Changes: What exact Device Tree configuration or overlay is needed to bypass the AP1302 ISP block and capture RAW Bayer frames directly on the MIPI-CSI interface?
Tuning & YAML Configuration: Does NXP provide the tuning/DTP configuration files for the AR0144 under the NEO ISP pipeline handler? If available, could you share these files or guide us on how to properly set up libcamera and LIBCAMERA_IPA_MODULE_PATH for this workflow?
Thank you for your assistance!
Is RAW passthrough (bypassing AP1302 hardware ISP processing) supported for the AR0144 on the i.MX95 FRDM board in the Linux 6.12.49_2.2.0 BSP release?>couldn't support it as default bsp, you can find the dtb file named ap1302 only
Device Tree Changes: What exact Device Tree configuration or overlay is needed to bypass the AP1302 ISP block and capture RAW Bayer frames directly on the MIPI-CSI interface?> refer to the ap1302 dtso file
isp_en-gpios = <&adp5585_isp 2 GPIO_ACTIVE_HIGH>; this pin is enable ap1302, you can bypass ap1302 by control this pin, hi is for enable, low is for bypass
3.Tuning & YAML Configuration: Does NXP provide the tuning/DTP configuration files for the AR0144 under the NEO ISP pipeline handler? If available, could you share these files or guide us on how to properly set up libcamera and LIBCAMERA_IPA_MODULE_PATH for this workflow?
>you can find all of the SW pacakge here
Hi,
Thank you for the detailed clarification regarding bypass mechanism.
Regarding the color issue, I want to clarify that this is not a display or monitor artifact. To be certain, we did not take a photo of the screen; rather, we dumped the raw image/video file directly from the GStreamer pipeline and inspected the saved file on a separate host machine, where the light reddish/magenta pink tint is clearly present in the pixel data.
Since we are using the correct DTB (imx95-15x15-frdm-ap1302.dtb) and the official AWB-tuned firmware (ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin), could you please help us isolate the root cause?
Question: Is there a specific test we can run from user space to verify whether this pink tint is caused by a hardware defect in the specific AR0144 camera module unit we have, or if it is a configuration/software issue?
Thank you for your continued support!
Hi @joanxie ,
1) As I mentioned earlier we have confirmed this is NOT a display issue. Because the images are dumped to a file and pulled to a host PC (Not a capture from the Display)
2) We have checked the same camera on IMX 95 EVK and IMX 95 FRDM baord, just to confirm that the problem is with the camera module or not. Both the places we are able to see the red tint.
3) We are using this firmware for ap1302:
https://github.com/ONSemiconductor/ap1302_binaries/blob/main/NXP_i.MX93/ap1302_60fps_ar0144_27M_2Lan...
And placing this in /lib/firmware with a name "ap1302_ar0144_single_fw.bin" (as we saw this is file name from dmesg logs).
Can you confirm whether you are using the same firmware. If not could you please let us know from where we can get the proper firmware
4) Is there any way to identify whether it's a tuning, firmware problem . Or some hardware issue with the specific module we are having? If it is hardware issue we want to consider buying another fresh unit