Playing with imx662

[6by9]

Wanted for CI build artifacts.

[d4c00]

Thank you so much for working on IMX662 support—this PR is a real lifesaver for me! I recently bought an IMX662 module from 微象电子 (a Chinese manufacturer) specifically for my Raspberry Pi Zero 2 W. I really hope it can get full and seamless support soon.

Right now, using community open-source drivers for IMX662 feels a bit cumbersome to set up, and the results aren't always as optimal or stable as I'd like—especially on smaller boards like the Zero 2 W. Your official driver work here would make a huge difference in making it plug-and-play.

Your efforts mean a lot to me and many others relying on third-party low-light modules for compact projects like this. I'm really looking forward to seeing this merged so I can test it properly on my Zero 2 W. Huge thanks again for your amazing work!

[6by9]

Right now, using community open-source drivers for IMX662 feels a bit cumbersome to set up, and the results aren't always as optimal or stable as I'd like—especially on smaller boards like the Zero 2 W. Your official driver work here would make a huge difference in making it plug-and-play.

Please note that this is NOT an official driver - just my tinkering.
As it happens a driver for imx662 has just been posted to linux-media, however it currently has issues. It claims to have solved a couple of the issues that I still had to address though, so between the two of us we may be able to knock it into shape.
https://lore.kernel.org/linux-media/20260312150437.1091195-1-eagle.alexander923@gmail.com/T/#m5a7b939dcc830749910b0f0fb254d9717cd40d02

The fact it has been posted to linux-media means that the sensor meets the libcamera requirements of having had a driver posted, so the libcamera support for it can be posted now :-)

I'm really looking forward to seeing this merged so I can test it properly on my Zero 2 W. Huge thanks again for your amazing work!

You can already test it. All Pull Requests get built by the CI system, and on Raspberry Pi OS you can then use sudo rpi-update pulls/7239 (where 7239 is the PR number) to download those pre-built kernels. Obviously be aware that things can be totally broken in the build, and it can break systems that rely on initramfs to have provided additional modules, but otherwise you can test out whatever improvements are being offered by the PR.

My module uses a 74.25 MHz crystal oscillator. It would be incredibly helpful if the dtoverlay could support customizing the clock frequency in /boot/firmware/config.txt,

Seeing as you've edited your post I'm guessing you found there already was the clock-frequency override provided by the overlay :-)

[d4c00]

Thank you so much for the reply!

Please note that this is NOT an official driver - just my tinkering.
As it happens a driver for imx662 has just been posted to linux-media, however it currently has issues. It claims to have solved a couple of the issues that I still had to address though, so between the two of us we may be able to knock it into shape.
https://lore.kernel.org/linux-media/20260312150437.1091195-1-eagle.alexander923@gmail.com/T/#m5a7b939dcc830749910b0f0fb254d9717cd40d02

The fact it has been posted to linux-media means that the sensor meets the libcamera requirements of having had a driver posted, so the libcamera support for it can be posted now :-)

I'm sorry that I’m still a complete beginner and not very familiar with how things work on the mailing list or the libcamera development side yet. I'm afraid I don't have enough expertise to follow all the technical details or provide professional feedback.

You can already test it. All Pull Requests get built by the CI system, and on Raspberry Pi OS you can then use sudo rpi-update pulls/7239 (where 7239 is the PR number) to download those pre-built kernels. Obviously be aware that things can be totally broken in the build, and it can break systems that rely on initramfs to have provided additional modules, but otherwise you can test out whatever improvements are being offered by the PR.

I had no idea it was this simple to install a specific PR kernel! I originally thought I would have to compile it myself, which seemed too daunting to try, so thank you so much for pointing that out. I’ve already tried sudo rpi-update pulls/7239 as you suggested, and it works! I can now successfully capture RAW files using v4l2-ctl on my Zero 2 W. This is a huge help for my project.

Seeing as you've edited your post I'm guessing you found there already was the clock-frequency override provided by the overlay :-)

Yes, you’re right. I edited my post as soon as I realized the feature was already there. You caught me! :-)

Since I haven't learned how to handle the ISP pipeline or post-process RAW data yet, I’ll probably just add a long-pass IR filter and treat it as a monochrome sensor for now as a workaround.

It’s really exciting to see the progress being made on this sensor. I’ll be keeping an eye on the updates, and it would be amazing if one day I could get color images through Picamera2 thanks to efforts like yours.

Thank you again for making this technology so accessible to us!

[6by9]

I'm sorry that I’m still a complete beginner and not very familiar with how things work on the mailing list or the libcamera development side yet. I'm afraid I don't have enough expertise to follow all the technical details or provide professional feedback.

No problem. Having folks just willing to test stuff is very valuable.

This repo is what would be termed a Vendor kernel or Board Support Package (BSP). It's taken the mainline Linux kernel and added a number of patches to better support the Raspberry Pi hardware. A number of those patches will be upstreamed to the mainline Linux kernel, but also we benefit from non-platform specific drivers that are submitted to mainline, such as the one for IMX662.

libcamera have a hard requirement that a driver must have been submitted to the mainline kernel mailing lists before support for any camera can be merged to libcamera.
Seeing as that has happened (not by us), we can submit the supporting libcamera patches and get them merged. That then ripples down and means that the standard libcamera in Raspberry Pi OS will get support for imx662.

[pelwell]

Score one for the automated overlay checker:

* imx662: misused fragment label clk_frag

[6by9]

I'd just been looking at why I couldn't set the clock frequency to 37.125MHz and scratching my head a bit.
Point the override at the right bit and it works.

[d4c00]

Issue with register update latency on IMX662 driver

Hi 6by9,

I'm currently trying to use the driver from this PR for an automatic long-exposure time-lapse script.
My AE logic is not yet well tuned, but I found a strange issue:
when I set new exposure + hblank + vblank, the new parameters seem to take effect only after 5~6 frames delay.
This causes my AE to misjudge the actual exposure used for the captured frame.
Here is how I actually use it (simplified shell-like flow):

# Keep the stream running and output raw data to a FIFO or pipe
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=0 --stream-to=/tmp/sensor_pipe &

while true; do
    # A. Update parameters via subdev
    v4l2-ctl -d /dev/v4l-subdev0 -c horizontal_blanking=XXX,vertical_blanking=YYY,exposure=ZZZ,analogue_gain=34

    # B. Read the very next frame (The "freshest" one available after the flush)
    dd if=/tmp/sensor_pipe bs=EXACT_RAW_SIZE count=1 of=lights_01_....raw

    # C. Perform AE calculation and repeat
done

(T = exposure in ms, G = gain, Y = measured brightness, target Y ≈ 0.33):

lights_01_20260411_120505_T82.8_G34.0_E-1.6_Y1.000_CPU55.raw        ← The light reading is too bright here, and T is falling fast
lights_01_20260411_120510_T58.5_G34.0_E-1.6_Y1.000_CPU56.raw        ← shutter 58.5ms, Y1.000
lights_01_20260411_120515_T41.4_G34.0_E-1.6_Y0.983_CPU56.raw
lights_01_20260411_120520_T29.3_G34.0_E-1.1_Y0.711_CPU56.raw
lights_01_20260411_120525_T21.6_G34.0_E-0.6_Y0.517_CPU55.raw
lights_01_20260411_120530_T18.8_G34.0_E-0.2_Y0.379_CPU56.raw        ← shutter 18.8ms, Y0.379
lights_01_20260411_120535_T18.6_G34.0_E0.2_Y0.283_CPU56.raw
lights_01_20260411_120540_T18.6_G34.0_E0.6_Y0.215_CPU57.raw
lights_01_20260411_120545_T18.6_G34.0_E0.9_Y0.171_CPU56.raw
lights_01_20260411_120550_T18.8_G34.0_E1.1_Y0.156_CPU56.raw         ← shutter 18.8ms, but Y0.156
lights_01_20260411_120555_T19.4_G34.0_E1.1_Y0.155_CPU57.raw
lights_01_20260411_120600_T20.9_G34.0_E1.1_Y0.155_CPU56.raw
lights_01_20260411_120605_T24.1_G34.0_E1.1_Y0.155_CPU56.raw
lights_01_20260411_120610_T29.1_G34.0_E1.1_Y0.155_CPU57.raw
lights_01_20260411_120615_T35.9_G34.0_E1.1_Y0.157_CPU56.raw
lights_01_20260411_120620_T44.7_G34.0_E1.0_Y0.161_CPU57.raw
lights_01_20260411_120625_T55.2_G34.0_E1.0_Y0.168_CPU56.raw     ← overshoot to 55.2ms while Y still very low (Y0.168)
lights_01_20260411_120630_T66.8_G34.0_E0.8_Y0.185_CPU56.raw
lights_01_20260411_120635_T77.1_G34.0_E0.6_Y0.215_CPU56.raw
lights_01_20260411_120640_T83.3_G34.0_E0.4_Y0.253_CPU56.raw
lights_01_20260411_120645_T85.6_G34.0_E0.2_Y0.293_CPU56.raw
lights_01_20260411_120650_T86.0_G34.0_E-0.1_Y0.363_CPU57.raw
lights_01_20260411_120655_T86.0_G34.0_E-0.4_Y0.428_CPU57.raw

I let AI read your driver code. It seems REGHOLD is defined at 0x3001 but never actually used.It looks like the sensor is still using the old timing for several frames after the control is set.

Full code:
https://github.com/d4c00/rpi-starlapse

I’m not very familiar with V4L2 sensor drivers (most of the code was helped by AI), so my question might be naive.
Do you think this is related to the missing REGHOLD implementation? Or is there another reason for the multi-frame latency?

Thanks!

[6by9]

@d4c00 REGHOLD is only an issue if you are updating multiple parameters close to the end of frame (when the new settings will be latched) and want to ensure that they are all written atomically rather than risking getting some and not others.
If you're running long exposures, then you're very unlikely to hit issues with making updates atomic. Not using it certainly won't increase the time taken to apply settings to 5-6 frames.

Reading the datasheet, it implies that changes to register SHR0 (exposure) are adopted at the next CSI2 frame start.
Gain (and LCG/HCG switching) will be delayed by one additional frame.

This should be reflected in the camera_sensor_properties for the sensor in libcamera. IMX662 is the follow on from IMX327/290/462, so I would have expected it to match those in https://github.com/raspberrypi/libcamera/blob/main/src/libcamera/sensor/camera_sensor_properties.cpp#L234-L243 which has a 2 frame delay for all controls.

[6by9]

Closing as branch https://github.com/6by9/linux/tree/rpi-6.18.y-imx662-mainline has the more recent work with those looking to submit an IMX662 driver to mainline. I'll create a PR in due course.

[d4c00]

@d4c00 REGHOLD is only an issue if you are updating multiple parameters close to the end of frame (when the new settings will be latched) and want to ensure that they are all written atomically rather than risking getting some and not others. If you're running long exposures, then you're very unlikely to hit issues with making updates atomic. Not using it certainly won't increase the time taken to apply settings to 5-6 frames.

Reading the datasheet, it implies that changes to register SHR0 (exposure) are adopted at the next CSI2 frame start. Gain (and LCG/HCG switching) will be delayed by one additional frame.

@6by9 Thanks for the pointers! Now I feel a bit embarrassed—I should have suspected my own script's buffering logic first. It seems I’ve been chasing a "ghost" that I created myself.

Knowing that the hardware limit is strictly 2 frames is a huge help. It gives me a solid starting point to go back and clean up my messy code and figure out where those extra frames are piling up.

Thanks again for your patience and for clearing this up for me!

This should be reflected in the camera_sensor_properties for the sensor in libcamera. IMX662 is the follow on from IMX327/290/462, so I would have expected it to match those in https://github.com/raspberrypi/libcamera/blob/main/src/libcamera/sensor/camera_sensor_properties.cpp#L234-L243 which has a 2 frame delay for all controls.

That makes a lot of sense! It’s really helpful to see how libcamera handles this. I’ll try to mimic this behavior in my own script by adding a delay to my AE feedback loop. I think this might be the 'missing link' for my project. Thank you!