Xavier NX R32.7.1 changes to DTSI Overlay for cameras has no effect

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
10

Thanks for sharing the link Shane, though I can’t say it helped very much.

This task can be marked resolved, as I figured out answers to my questions. I’ll try to capture my findings here, with the obvious disclaimer that I can only report what I’ve seen and gotten working, and my answers might be misguided or incomplete.

How was the imx219 set as the default?

The stock device tree source is included in the kernel sources. For finding where the sources can be downloaded and how to build them, I found the script made available in this post unbelievably helpful in getting off the ground with building and flashing the kernel source. Shout out to @sgroesz and @james.rhodes for fighting the good fight. For posterity, note that the script didn’t work as is–I updated to use newer sources, used the build step and then flashed the resulting dtb using flash.sh instead of the payload update script.

Anyway, the answer to my original question here was obvious in hindsight. The first thing I want to highlight for noob posterity is that the Jakku device tree defines all four sensor instances in question (2x imx477 and 2x imx219) simultaneously, and then just selectively defines which are enabled and disabled. You can see this by looking at the includes in hardware/nvidia/platform/t19x/jakku/common/tegra194-p3509-0000-a00.dtsi:

 19 #include "tegra194-camera-jakku-rbpcv3-imx477.dtsi"
 20 #include "tegra194-camera-jakku-rbpcv2-imx219.dtsi"

This means under the cam_i2cmux element has all four sensors defined. Then you can see the default dts files describing the driver configuration leave the imx477 status as disabled, and leave the status attribute unset for the imx219, which appears to then default to okay/enabled. So the actual dts for the imager configuration is set up for dual imx219 until the overlays say otherwise.

Excerpt from the stock hardware/nvidia/platform/t19x/jakku/common/tegra194-camera-jakku-rbpcv3-imx477.dtsi, showing the default state of disabled:

    cam_i2cmux {
        compatible = "i2c-mux-gpio";
        #address-cells = <1>;
        #size-cells = <0>;
        mux-gpios = <&tegra_aon_gpio CAM_I2C_MUX GPIO_ACTIVE_HIGH>;
        i2c-parent = <&i2c7>; // @shoelick: I'm pretty sure this is a bug, had to change to match imx219
        i2c@0 {
            reg = <0>;
            #address-cells = <1>;
            #size-cells = <0>;
            rbpcv3_imx477_a@1a {
                status = "disabled"; // emphasis 
                reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
            };
        };
        i2c@1 {
            reg = <1>;
            #address-cells = <1>;
            #size-cells = <0>;
            rbpcv3_imx477_c@1a {
                status = "disabled"; // emphasis
                reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
            };
        };

Excerpt from the stock hardware/nvidia/platform/t19x/jakku/common/tegra194-camera-jakku-rbpcv2-imx219.dtsi, showing no state attribute:

   cam_i2cmux{
        compatible = "i2c-mux-gpio";
        #address-cells = <1>;
        #size-cells = <0>;
        i2c-parent = <&cam_i2c>;
        mux-gpios = <&tegra_aon_gpio CAM_I2C_MUX GPIO_ACTIVE_HIGH>;
        i2c@0 {
            reg = <0>;
            #address-cells = <1>;
            #size-cells = <0>;
            rbpcv2_imx219_a@10 {
                reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
            };
        };
        i2c@1 {
            reg = <1>;
            #address-cells = <1>;
            #size-cells = <0>;
            rbpcv2_imx219_c@10 {
                reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
            };
        };

At this point gaining an understanding of the video pipeline defined in the device tree is also helpful. Reading this post got me another “aha” moment and explains why the overlays apply statuses the other elements defined in common/tegra194-p3668-all-p3509-0000-camera-imx219-dual.dts and common/tegra194-p3668-all-p3509-0000-camera-imx477-imx219.dts. You have to get these elements right to have an actual working video node when your system boots.

Bonus knowledge: these files are also where the imx drivers and associated pipeline are tied to specific CSI lanes.

jetson-io.py and config-by-hardware.py

The second place I’ve seen overlays applied is the infamous /opt/nvidia/jetson-io/jetson-io.py script. This script appears to find any compatible .dto files in /boot (based on the headers), makes nice ncurses menus out of it, and when you choose a setting in the ncurses interface, it grabs the base device tree (maybe from /boot/dts or something, not actually sure which), applies the overlay you’ve chosen, compiles this combo into one new dtb, writes it to /boot, and then makes sets a new default extlinux.conf boot entry that loads the new dtb with the overlay applied.

That said, with our custom carrier board this method with a dtb specified with a boot entry in the extlinux.conf doesn’t seem to work. The settings from jetson-io don’t take effect. In fact, I can put gibberish in the /boot/extlinux/extlinux.conf and the system boots with the last flashed dtb, ignoring whatever is in extlinux.conf.

Unanswered questions

Within the kernel sources, down in hardware/nvidia/platform/t19x/jakku/, you can see in the makefile that all three overlays are included in the build.

dtbo-$(CONFIG_ARCH_TEGRA_19x_SOC) += tegra194-p3668-all-p3509-0000-camera-imx477-imx219.dtbo
dtbo-$(CONFIG_ARCH_TEGRA_19x_SOC) += tegra194-p3668-all-p3509-0000-camera-imx477-dual.dtbo
dtbo-$(CONFIG_ARCH_TEGRA_19x_SOC) += tegra194-p3668-all-p3509-0000-camera-imx219-dual.dtbo

One small question that remains is whether these overlays are actually applied to the resulting base device tree build, or just included on the filesystem for future usage. I may test this when I have time.

The jetson documentation still remains incomplete based on some things I’ve seen. Some other questions remain for me, but they’re outside the scope of this post.

  • Why did extlinux stop taking effect on our custom board? How’s this thing even booting…?!
  • This post mentions a separate dtb partition, which I can only presume is where the dtb is being loaded from when my extlinux.conf is being ignored as described above.
  • I have only found so far that flash.sh as a reliable way of updating the dtb/applying new overlays. For past l4t versions there used to be a separate script to apply update payloads, but it doesn’t seem to be supported since Jetson Nano.

Other helpful references

4 Likes