Hi, I am using Nvidia Jetson Xavier NX Jetpack version 5.1.5 and I wanted to know the new camera integration process on XavierNX. I have worked on multicamnera integration with IMX477 but this new sensor is new to me kinldy help to integrate with XavierNX.
Is their any driver available for IMX283 in the nvidia source package or do I need to write our own driver file?
I am also aware of dtsi file and soruce build so can you help me a bit more about driver for IMX283 and if this is supported with XavierNX SOM.
I think the location of your dtsi can be in hardware/nvidia/platform/t19x/jakku/kernel-dts as long as you include it in your final device tree. You could also place the dtsi for your camera in the hardware/nvidia/platform/t19x/jakku/kernel-dts/common path so that you can include your dtsi in the hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3509-0000-a00.dtsi file (assuming you are using the standard p3509-0000-a00 devkit).
As for the orientation of your camera, I think this is mostly relevant if you are working with multiple cameras. Either one should work if you are using a single camera.
I’m working on a custom carrier board for Jetson Xavier NX.
Our design has two CSI connectors, each supporting 2 data lanes (CSI0 and CSI1).
We are planning to interface a Sony IMX283 4-lane MIPI CSI camera.
However, due to PCB constraints, we have connected:
2 data lanes to CSI0 (port-index 0x00, serial_a)
2 data lanes to CSI1 (port-index 0x01, serial_b)
So effectively, the 4-lane camera is split as 2+2 across CSI0 and CSI1.
My questions are:
Can the Xavier NX NVCSI hardware aggregate CSI0 and CSI1 into a single 4-lane logical stream for one sensor?
If not natively supported, is there any workaround (such as NVCSI channel pairing or device tree lane remapping) to make it function as a single camera input?
If this configuration is unsupported, can you confirm that all 4 lanes must originate from the same NVCSI brick (e.g., CSI0_A/B) for proper operation?
THe Jetson Xavier NX supports the 4-lane camera split between CSI0 and CSI1. All you have to do is specify the port-index = <0> and then the bus-width = <4>. This automatically uses 2 lanes from CSI0 and then 2 lanes from the next CSI port … CSI1 in this case.
Regards,
Francis Guindon
Embedded SW Engineer at RidgeRun
I am not be able to see CAM0 PWDN pin assign as reset gpio on PP.04 pin on /sys/kernel/gpio ?
As per the pinmuxsheet of xaviernx and our inhouse carrier board hardware layout everything is perfect but still not showing anything on pin PP.04.
Is that because I have used IMX477.c replica IMX283 but I have made some changes like read write reg i2c address and compatible string correctly.
Not even showin in dmesg | grep imx.
Can you help me a bit more to understand how cam detects on dmesg and how sensor probed and some tips to debug my current issue.
Hello. You can dump the dmesg log here just in case - maybe there are some error logs that were logged during probing(if you didn’t remove the error logs). But reading your reply I suppose that there are no errors which means that the driver hasn’t been loaded.
If you built your modified driver and copied it to appropriate path in the fs, did you configure it as a loadable kernel module and if so did you try loading the camera’s driver module manually (insmod) ? Or did you build it alongside the kernel Image from scratch so that the module loads automatically during boot?
Did you make sure that the camera’s device tree node properties correlate with the driver’s configuration so that the kernel knows which driver to bind?
I’ve verified that the IMX283 driver is built directly into the kernel image (not as a loadable module). The kernel config shows: CONFIG_NV_VIDEO_IMX283=y
and I can confirm the compiled object file nv_imx283.o exists inside: kernel/kernel-5.10/build/drivers/media/i2c/
However, during boot there are no logs related to IMX283 — dmesg | grep imx returns nothing, and the PWDN GPIO pin (PP.04) also doesn’t appear in /sys/kernel/debug/gpio
This makes me believe that the driver is compiled correctly but is not being bound to any device node from the device tree.
To debug further, could you please confirm:
What conditions trigger the IMX camera driver probe when it’s built-in (=y)?
Whether the probe is skipped entirely if the device tree node compatible string doesn’t match any of_match_table entry?
Is there a preferred way to verify that the camera device node from the DTB is actually being parsed and registered under I²C during early boot?
Probe is called when the kernel matches the IMX camera device to the specific driver you want to use with it.
A pre-condition for this is that you have set the correct compatible property in the device tree matching the driver’s match table.
Onwards from pt.1 - yes, if your compatible string does not match the driver’s of_match_table entry the probing will be skipped - when the kernel parses the DT, it will try to find a compatible property and use it to find that driver and its probe method → thus, if your compatible property for the IMX’s device tree node is wrong, the kernel won’t find the driver, the device will not be bound to the driver and thus not be initialized
You should see this under dmesg where i2c driver(s) is/are initialized and it creates I2C clients but honestly if you haven’t touched the i2c driver, then I would say it’s the wrong place to look for.
I am sure that your driver must have a function similar to something like e.g. device_example_parse_dt() - you can add logs there and see what happens during parsing, however you would need to rebuild the kernel and the driver as it’s a built-in module. (On the driver side it’s easier to debug drivers if they are loadable modules - you can modify the driver and add logs, recompile it, and re-load it into the kernel and iterate until you pin down the root of failure and fix it).
You haven’t shown your device tree. Would you mind sharing it?
define CAM0_PWDN TEGRA194_MAIN_GPIO(P, 4)
i2c@0 {
reg = <0>; #address-cells = <1>; #size-cells = <0>;
rbpcv3_imx283_a@1a {
status = “okay”;
reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
};
};
I am not be to see PP.04 in sys/class/gpio why ?
I am working with a Sony IMX283 camera sensor on a custom carrier board. I need help in understanding the correct approach to write a new camera driver for this sensor on the Jetson platform.
I have the sensor datasheet, timing information, and register maps, but I am still not fully confident about structuring a complete driver. I would appreciate guidance from the community on:
How to structure a new driver based on the NVIDIA camera framework
Any examples of Sony sensor drivers that I can use as a starting point
Important register settings that must be implemented (stream on/off, PLL, MIPI timing, exposure/gain, etc.)
If someone has already worked on Sony sensors like IMX577/IMX219/IMX477/IMX274, I would love to know which file structures I should follow to create a proper IMX283 driver.
Thank you for any guidance or sample driver references.How to structure a new driver based on the NVIDIA camera framework
Any examples of Sony sensor drivers that I can use as a starting point
Important register settings that must be implemented (stream on/off, PLL, MIPI timing, exposure/gain, etc.)
If someone has already worked on Sony sensors like IMX577/IMX219/IMX477/IMX274, I would love to know which file structures I should follow to create a proper IMX283 driver.
Thank you for any guidance or sample driver references.