2026-04-15 5:06 PM
Hello,
I am trying to load a kernel driver (.ko file) for a MIPI camera I would like to use with the STM32MP257F-DK. It's for the imx664, and no driver is present already.
I have the source for the driver, and was able to compile it into a .ko file, cross-compiled with the exact same OS as is present on the board and with the SDK set up as required. The vermagic line matches exactly: vermagic: 6.6.78 SMP preempt mod_unload aarch64
However, every time I try and load the driver with insmod, with or without -f, I get the error: insmod: ERROR: could not insert module imx664.ko: Invalid module format
I am struggling to find where the incompatibility could be, since I have re-tried it a few times and been careful to set it up as ST's documentation says and also to match what is expected by the board. Is there something I am missing with this?
Solved! Go to Solution.
2026-04-21 7:27 PM - edited 2026-04-21 9:18 PM
Hi @rdmikkelsen,
Have you modified the kernel DTS according to your new configuration?
It's seems the imx335 (camera sensor that ST provide with the B-CAMS-IMX) is trying to probe.
Please have a look at i2c2 node, specially the of stm32mp257f-dk.dts. Base configuration is:
imx335: camera@1a {
compatible = "sony,imx335";
reg = <0x1a>;
clocks = <&clk_ext_camera>;
avdd-supply = <&scmi_v3v3>;
ovdd-supply = <&scmi_v3v3>;
dvdd-supply = <&scmi_v3v3>;
reset-gpios = <&gpiob 1 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
powerdown-gpios = <&gpiob 11 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
status = "okay";
port {
imx335_ep: endpoint {
remote-endpoint = <&csi_sink>;
clock-lanes = <0>;
data-lanes = <1 2>;
link-frequencies = /bits/ 64 <594000000>;
};
};
};Regards,
2026-04-16 5:30 AM
Hi @rdmikkelsen
I'm not SW expert, but did you follow what is inside this page : https://wiki.st.com/stm32mpu/wiki/How_to_cross-compile_with_the_Developer_Package#Modifying-2Fadding_an_external_Linux_kernel_module
Regards.
2026-04-16 12:16 PM
Thanks for the quick response. I had seen those steps and also these for cross-compilation: https://wiki.st.com/stm32mpu/wiki/Cross-compile_with_OpenSTLinux_SDK and I had tried following each without much success.
2026-04-17 1:58 AM
Hello @rdmikkelsen ,
I would advice you to add your imx664 driver directly in your kernel sources, next to imx335.c for example (drivers/media/i2c).
Update also the Makefile to compile it automatically as module (or add your own CONFIG in the Kconfig file), you can get inspired by what is already done in the kernel.
Then recompile your Linux kernel image and your modules, and install them following the process explained in the wiki.
------------
If you want to cross compile your module out of tree (without putting it in Linux sources), you have to indirectly link it to the Linux running on your machine. Corresponding steps are explained here: https://wiki.st.com/stm32mpu/wiki/How_to_cross-compile_with_the_Developer_Package#Adding_an_external_out-of-tree_Linux_kernel_module
Kind regards,
Erwan.
2026-04-21 12:48 PM
Thank you very much for the procedure to add in my driver and recompile the kernel. I have noticed that when I do this, the driver is indeed loaded successfully:
root@stm32mp2-e3-cb-7b:~# modinfo imx664.ko
filename: /home/root/imx664.ko
license: GPL v2
description: A low-level driver for SONY imx664 sensors
author: Fengyu Sheng <fengyus@leopardimaging.com>
alias: i2c:imx664
alias: of:N*T*Csony,imx664C*
alias: of:N*T*Csony,imx664
depends: v4l2-async,videodev,v4l2-fwnode,mc
name: imx664
vermagic: 6.6.78 SMP preempt mod_unload aarch64
However, when I have the camera plugged in and bring up the board, I am still not seeing an attached camera. I have noticed in dmesg that the imx664 is never mentioned, but a camera that's not present fails to load:
root@stm32mp2-e3-cb-7b:~# dmesg | grep "imx"
[ 10.041295] imx335 0-001a: Error reading reg 0x3912: -6
[ 10.041346] imx335 0-001a: failed to find sensor: -6
Is there something else beyond this that I need to do in order for this board to recognize the camera?
2026-04-21 7:27 PM - edited 2026-04-21 9:18 PM
Hi @rdmikkelsen,
Have you modified the kernel DTS according to your new configuration?
It's seems the imx335 (camera sensor that ST provide with the B-CAMS-IMX) is trying to probe.
Please have a look at i2c2 node, specially the of stm32mp257f-dk.dts. Base configuration is:
imx335: camera@1a {
compatible = "sony,imx335";
reg = <0x1a>;
clocks = <&clk_ext_camera>;
avdd-supply = <&scmi_v3v3>;
ovdd-supply = <&scmi_v3v3>;
dvdd-supply = <&scmi_v3v3>;
reset-gpios = <&gpiob 1 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
powerdown-gpios = <&gpiob 11 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
status = "okay";
port {
imx335_ep: endpoint {
remote-endpoint = <&csi_sink>;
clock-lanes = <0>;
data-lanes = <1 2>;
link-frequencies = /bits/ 64 <594000000>;
};
};
};Regards,
2026-04-22 1:54 PM - edited 2026-04-22 4:38 PM
Thank you for the response, I have updated both the stm32mp257f-dk.dts and stm32mp257f-ev.dts files by adding nodes right after the imx335 node you mentioned, but changed all references to imx664. This resulted in me being able to see something at address 0x10 with i2cget. Then I updated the address in the imx664 node from 0x1a to 0x10, but that resulted in me not being able to see any device again, so I changed it back. I had also changed the &csi section to refer to the imx664 endpoint:
&csi {
vdd-supply = <&scmi_vddcore>;
vdda18-supply = <&scmi_v1v8>;
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi_sink: endpoint {
remote-endpoint = <&imx664_ep>;
data-lanes = <1 2>;
bus-type = <4>;
};
};
port@1 {
reg = <1>;
csi_source: endpoint {
remote-endpoint = <&dcmipp_0>;
};
};
};
};Is there anything else I would need to change to be able to see the camera? It feels like it's very close, after everyone's help here.
Editing to add that I see this with dmesg regarding probing CSI using address 0x1a in the device tree, but I don't see anything with "imx" in the dmesg output:
[ 10.159841] stm32-csi 48020000.csi: Probed CSI with 2 lanes
[ 10.166436] stm32-dwmac 482c0000.eth1: IRQ eth_lpi not found
[ 10.176906] stm32-dwmac 482c0000.eth1: User ID: 0x1a, Synopsys ID: 0x53
[ 10.177962] stm32-dwmac 482c0000.eth1: DWMAC4/5
[ 10.184329] stm32-dwmac 482c0000.eth1: DMA HW capability register supported
[ 10.191508] stm32-dwmac 482c0000.eth1: RX Checksum Offload Engine supported
[ 10.243782] stm32-dwmac 482c0000.eth1: TX Checksum insertion supported
[ 10.244729] stm32-dwmac 482c0000.eth1: Wake-Up On Lan supported
[ 10.252424] stm32-dwmac 482c0000.eth1: TSO supported
[ 10.256774] stm32-dwmac 482c0000.eth1: Enable RX Mitigation via HW Watchdog Timer
[ 10.264446] stm32-dwmac 482c0000.eth1: Enabled L3L4 Flow TC (entries=2)
[ 10.274235] stm32-dwmac 482c0000.eth1: Enabled RFS Flow TC (entries=10)
[ 10.282807] stm32-dwmac 482c0000.eth1: TSO feature enabled
[ 10.282856] stm32-dwmac 482c0000.eth1: Using 32/32 bits DMA host/device width
[ 10.304087] dcmipp 48030000.dcmipp: Probe done
2026-04-23 3:28 AM
Hi @rdmikkelsen
The logs you share are not really related to the camera sensor itself..
You might need to have a look to the driver probe function, add some debugging line.. You should be able to see a probe or an error when you modprobe imx664.
You should also have a look at the wave of NRST _CAM / EN_MODULE and the I2C_SCL / I2C_SDA you could have a timing error here and need to adjust
reset-gpios = <&gpiob 1 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
powerdown-gpios = <&gpiob 11 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;Some module require GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW.
Regards
2026-04-27 4:00 PM
@Pwxn Thanks for the pointers for this. After some looking for a timing problem like you mentioned, I found that the clock frequency needed to be a little different from the default value, so I updated the clk_ext_camera clock frequency in the device tree.
I noticed that, after changing the clock frequency, it looks like it recognizes the IMX664 camera specifically now, at 0x10 as expected:
root@stm32mp2-e3-cb-7b:~# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- 37 UU -- -- -- UU UU -- UU
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@stm32mp2-e3-cb-7b:~# dmesg | grep imx
[ 10.257475] imx664 0-0010: enter SONY IMX664 camera driver probe
[ 10.275761] imx664 0-0010: supply dovdd not found, using dummy regulator
[ 10.589309] imx664 0-0010: read register 0x3071 : 0x00
[ 10.589684] imx664 0-0010: read register 0x3070 : 0x00
[ 10.713704] imx664 0-0010: IMX664 power off
[ 11.064707] imx664 0-0010: SONY IMX664 camera driver probed
The registers 0x3071 and 0x3070 are defined in the driver as IMX664_REG_GAIN_HI and IMX664_REG_GAIN_LO, respectively, and I am seeing a new device with v4l2-ctl --list-devices, /dev/media2. I would have expected it to be a /dev/videoX device, but other than this, does the behavior seem correct?
2026-04-28 1:55 AM
Hello @rdmikkelsen
Good work on bring up the probe. The behavior you observe is mostly correct now.
I have limited experience on image sensor driver, it is hard for us to guide you more on this, specially on the register or mode you want to implement.
However, now that you probed your sensor you should see it as a /dev/v4l-subdevX. What you need to do now is to tune the V4L framework to create your pipeline.
https://wiki.st.com/stm32mpu/wiki/STM32MP2_V4L2_camera_overview
You camera sensor should not be a /dev/videoX as it the output of our DCMIPP pipeline: see the chapter on topology
Try to configure the DCMIPP pipeline with V4L, if you encounter some issue we will try to help you.
Also, I recommend comparing the other camera sensor driver in linux/driver/media/i2c. The imx335.c will give you some hint on using v4l on driver side.
Regards