IMX283 Integration on XavierNX

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.

  1. Is their any driver available for IMX283 in the nvidia source package or do I need to write our own driver file?

  2. 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.

Thanks in Advance..

You need to implement the driver and device tree by yourself.

Have check below document for the detail.

How to add entry in dtsi file for IMX283 for single camera ?
What will be the position for single camera ?

Here I found postion for two camera: two-camera system: rear and front.

Do I need to create the dtsi file for IMX283 like IMX477 Cam in this path ?

source/public/kernel_src/hardware/nvidia/platform/t19x/jakku/kernel-dts

Thanks.

Hi @Sunim_1,

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.

Let me know if this helps,
Regards,

Francis Guindon
Embedded SW Engineer at RidgeRun

Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: http://www.ridgerun.com/

@francis.guindon Thanks for your help.

Hello,

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:

  1. Can the Xavier NX NVCSI hardware aggregate CSI0 and CSI1 into a single 4-lane logical stream for one sensor?

  2. 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?

  3. 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?

Here are relevant connection details:

  • SoC: Jetson Xavier NX (JetPack 5.1.5 / Kernel 5.10)

  • Sensor: Sony IMX283 (4-lane MIPI)

  • CSI0 → port index 0x00, serial_a

  • CSI1 → port index 0x01, serial_b

Appreciate your clarification on whether this 2+2 split can operate as one 4-lane camera or not.

Thank you.

Hi @Sunim_1,

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

Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: http://www.ridgerun.com/

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.

Thanks..

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?

Thanks for the response.

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 IMX283dmesg | 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:

  1. What conditions trigger the IMX camera driver probe when it’s built-in (=y)?

  2. Whether the probe is skipped entirely if the device tree node compatible string doesn’t match any of_match_table entry?

  3. 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?

Hi

  1. 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.
  2. 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
  3. 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?

Thanks for your response.
Here is my device tree:

devicetree_sample.txt (6.8 KB)
Have a look once and tell me is it look good.

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 ?

Hi, please extract & share the currently active device tree during runtime.

You can extract the active dt to see the changes:
sudo dtc -I fs -O dts -o active_extracted_dt.dts /proc/device-tree

  1. One thing I recommend is to to consolidate the DT structure - merge all the camera device’s subnode properties under a single / { } block
/ {
    // Combine all subnodes here, previously vi-capture, nvcsi etc
    cam_i2cmux {
        // ... all properties from both instances
    };
};

DT merging usually handles double-definitions but it’s easier to keep track of things if everything is in one place.

Here is the dts file below,

active_extracted_dt.txt (369.4 KB)

When I try to manually toggle the pin PP.O4 using this cmd,
gpioset gpiochip1 114=1
gpioget gpiochip1 114

I am able to see this,

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – – – – – – –
10: – – – – – – – – – – 1a – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – – – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –

I am not getting anything in dmesg and PP.04 pin is not used anywhere in the sys/class/gpio.
I need to manually high the pin.

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:

  1. How to structure a new driver based on the NVIDIA camera framework

  2. Required files (device-tree, driver .c file, mode table, kernel config changes, etc.)

  3. Reference drivers similar to IMX283

  4. Any examples of Sony sensor drivers that I can use as a starting point

  5. 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

  1. Required files (device-tree, driver .c file, mode table, kernel config changes, etc.)

  2. Reference drivers similar to IMX283

  3. Any examples of Sony sensor drivers that I can use as a starting point

  4. 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.

@Sunim_1

You can check the programing guide and reference to IMX219/IMX477 for knowing necessary things.

Thanks

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.