Can't load a MIPI kernel driver on STM32MP257F-DK

[rdmikkelsen]

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?

[PatrickF]

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.

[rdmikkelsen]

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. 

[Erwan SZYMANSKI]

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.

[Pwxn]

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,

[rdmikkelsen]

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

 

[Pwxn]

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

[rdmikkelsen]

@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?