IMX415 camera bringup

Other OS Support Other OS-related topics
1

Good day

I have been trying to integrate the IMX 415 sensor with the Rubik Pi, to no success, here is the rubikpi3.dts file that I have compiled with:


yoctosmasher@yoctosmasherPC:~/yoctoproject/src/vendor/qcom/opensource/kernel-6.6/arch/arm64/boot/dts/qcom$ cat rubikpi3.dts 
// SPDX-License-Identifier: BSD-3-Clause
/*
 * Turbox RUBIK Pi 3 device tree source
 */

#include "turbox-c6490p-devkit.dtsi"

/ {
	model = "Thundercomm, Inc. RUBIK Pi 3";
	compatible = "qcom,qcm6490-addons-idp","qcom,sc7280";

	qcom,msm-id = <497 0x10000>, <498 0x10000>, <475 0x10000>, <515 0x10000>;
	qcom,board-id = <32 0xb>, <32 0x60b>;

	/* Camera 2 VIO power supply (GPIO 19) */
	camera2_vio_ldo: gpio-regulator@1 {
		compatible = "regulator-fixed";
		reg = <0x01 0x00>;
		regulator-name = "camera2_vio_ldo";
		regulator-min-microvolt = <1800000>;
		regulator-max-microvolt = <1800000>;
		regulator-enable-ramp-delay = <233>;
		enable-active-high;
		gpio = <&tlmm 19 0>;
		status = "ok";
	};

	qcom,cam-res-mgr {
		status = "ok";
		compatible = "qcom,cam-res-mgr";
	};
};

&uart2 {
	status = "okay";
};

&i2c1 {
	status = "okay";

	rpi-sense@46 {
		compatible = "rpi,rpi-sense";
		reg = <0x46>;
		keys-int-gpios = <&tlmm 26 1>;
		status = "okay";
	};

	lsm9ds1-magn@1c {
		compatible = "st,lsm9ds1-magn";
		reg = <0x1c>;
		status = "okay";
	};

	lps25h-press@5c {
		compatible = "st,lps25h-press";
		reg = <0x5c>;
		status = "okay";
	};

	hts221-humid@5f {
		compatible = "st,hts221-humid", "st,hts221";
		reg = <0x5f>;
		status = "okay";
	};

	lsm9ds1-accel@6a {
		compatible = "st,lsm9ds1-accel";
		reg = <0x6a>;
		status = "okay";
	};
};

&spi12 {
	status = "okay";
	spidev@0 {
		compatible = "qcom,spidev";
		spi-max-frequency = <50000000>;
		reg = <0>;
	};
};

&tlmm {
	cam_sensor_mclk1_active: cam_sensor_mclk1_active {
		mux {
			pins = "gpio65";
			function = "cam_mclk";
		};
		config {
			pins = "gpio65";
			bias-disable;
			drive-strength = <2>;
		};
	};

	cam_sensor_mclk1_suspend: cam_sensor_mclk1_suspend {
		mux {
			pins = "gpio65";
			function = "cam_mclk";
		};
		config {
			pins = "gpio65";
			bias-pull-down;
			drive-strength = <2>;
		};
	};

	cam_sensor_active_rst3: cam_sensor_active_rst3 {
		mux {
			pins = "gpio46";
			function = "gpio";
		};
		config {
			pins = "gpio46";
			bias-disable;
			drive-strength = <2>;
		};
	};

	cam_sensor_suspend_rst3: cam_sensor_suspend_rst3 {
		mux {
			pins = "gpio46";
			function = "gpio";
		};
		config {
			pins = "gpio46";
			bias-pull-down;
			drive-strength = <2>;
			output-low;
		};
	};
};

&cci0 {
	qcom,cam-sensor8 {
		cell-index = <8>;
		compatible = "qcom,cam-sensor";  /* THIS IS THE KEY CHANGE */
		csiphy-sd-index = <2>;
		sensor-position-roll = <0>;
		sensor-position-pitch = <0>;
		sensor-position-yaw = <0>;
		cam_vio-supply = <&camera2_vio_ldo>;
		regulator-names = "cam_vio";
		power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
		rgltr-cntrl-support;
		rgltr-min-voltage = <1800000>;
		rgltr-max-voltage = <1800000>;
		rgltr-load-current = <120000>;
		gpio-no-mux = <0>;
		pinctrl-names = "cam_default", "cam_suspend";
		pinctrl-0 = <&cam_sensor_mclk1_active
					&cam_sensor_active_rst3>;
		pinctrl-1 = <&cam_sensor_mclk1_suspend
					&cam_sensor_suspend_rst3>;
		gpios = <&tlmm 65 0>,
				<&tlmm 46 0>;
		gpio-reset = <1>;
		gpio-req-tbl-num = <0 1>;
		gpio-req-tbl-flags = <1 0>;
		gpio-req-tbl-label = "CAMIF_MCLK1",
							"CAM_RESET3";
		cci-master = <0>;
		status = "okay";
		clocks = <&camcc CAM_CC_MCLK1_CLK>;
		clock-names = "cam_clk";
		clock-cntl-level = "nominal";
		clock-rates = <24000000>;
	};
};

I assume I am not near a solution yet, but I want to believe this is not an impossible task, I know that the Qualcomm ISP is being used instead of v4l2 and @kinkin has indicated in another thread that thundercomm is working on bringing v4l2 online, but since the imx415.c file is included in the src of the yocto image for the Pi, what other modifications are necessary for spinning up the imx 415?

2

I’m not entirely sure if it’s appropriate for me to respond, but I’ll try to clarify based on my experience. The key point is that you don’t need to create either the device tree or the device driver yourself in this case.

There are two main ways to receive image data from a camera sensor via MIPI on the Rubik Pi:

1. The Linux Standard Method

(also referred to as upstream, V4L2, or CAMSS):

This is typically used when you want to receive RGB or YUV images through the ISP in compliance with the standard Linux media pipeline. It is commonly used when the Qualcomm ISP is not accessible. While you could use the ISP via media pipeline, that requires Qualcomm’s official support.

In this approach, two components are essential:

  • A device tree file (like the one you mentioned)
  • A device driver for the sensor

Once those are in place, you can use media-ctl and v4l2-ctl to build the media pipeline, and then stream the image using GStreamer.

From what you described, you are currently attempting this method — but this approach is not applicable in your case. I also attempted it before, but at the time, Rubik Pi did not support V4L2 at all.

When I tried it, I received advice from @kinkin to use the device tree based on RB3 and to check I2C activity with a resistor probe. However, I saw completely unrelated MIPI data waveforms instead of valid I2C traffic. It turned out that they hadn’t even tested it properly on Rubik Pi back then. It may be worth checking again whether V4L2 is supported now, but it’s uncertain.

2. The Qualcomm Proprietary Camera Framework

(also referred to as downstream or qcom-camera):

This method does not follow the Linux standard. Many platforms like Qualcomm, Raspberry Pi, and Rockchip use their own proprietary camera stacks.

If you want to connect a new sensor using this method — whether the ISP is involved or not — Qualcomm’s official support is essential.

In this approach:

  • You do not use the device tree or driver files found in the standard Linux kernel source directory.
  • Everything is managed via Qualcomm’s own HAL and camera stack.

Since the IMX415 module is officially supported by Rubik Pi, if you’re using their IMX415 module, it should work without much issue. But if you’re using a third-party IMX415 module, it may not work, as Rubik Pi has likely completed downstream ISP tuning specifically for their own module.

In short, since both the driver and the device tree are already precompiled and integrated into Rubik Pi’s system, there is nothing you need to modify on the kernel side.

I may have said too much, but to summarize:
:backhand_index_pointing_right: You don’t need to write or compile the device tree or driver manually.
Just follow the instructions in the official documentation.

Please refer to the following site and search using the keyword below:

key word: The camera can be operated by using

You should be able to get the camera stream working by following those steps.

1 Like
3

Dear customer,
If you want to bring up a new camera, the open-source code currently available on GitHub is not sufficient,you need more complete code.
If you need it, please leave your email, and we will contact you and discuss follow-up issues.

4

gideon@creox.co.za

I would appreciate a follow-up

5

thank you so much for the response, this is what I was hoping wasnt true and that I would be able use this camera without proprietary drivers, since my imx415 is not the one sold by thundercomm, but is the one here:

will post here if it gets resolved

6

I also believe that the camera module you’re using is not the official IMX415 module from Rubik Pi.
You might have assumed it would work because the camera pinout is the same between Rubik Pi and Raspberry Pi.

But let me start by saying this:
There is a very high chance that you won’t get any video output at all, and even if you do, the image will likely look very different from what you saw on the Raspberry Pi.

There are two major differences between the IMX415 module sold by Waveshare and the one provided by Rubik Pi:

  • The Rubik Pi module includes a VCM (Voice Coil Motor) for lens focusing, but does not have a day-and-night IR-cut filter.
  • The Waveshare module is designed for low-light performance, and the model number ending in “98” suggests it has slightly different sensor register values and has been tuned for low-light ISP settings.

At first glance, it might seem like you only need to get the IR-cut filter to work — but it’s more complicated than that. If the Rubik Pi downstream driver for IMX415 doesn’t detect a compatible lens actuator, it may be intentionally designed to fail or stop the image stream entirely.

Even if you somehow manage to get the video stream working, without proper ISP tuning for your module, the image quality and color rendering may be completely off. Also, if the VCM isn’t functioning properly, you’ll likely experience blurry images at close distances due to incorrect focus.

Without Thundercomm’s support, there’s a 99.999999% chance that the module you’ve purchased will not work on Rubik Pi.

If Thundercomm is offering help, I strongly recommend that you take advantage of their support as soon as possible.

7

Dear customer,
We have sent the email.