DTB Overlay created by jetson-io doesn't seem to be applied

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
,
1

Brand new Jetson Orin Nano Super Devkit, flashed with JP 36.4.4.

nvidia,p3768-0000+p3767-0005-super\0nvidia,p3767-0005nvidia,tegra234

Ran jetson-io to enable spi1 which created /boot/jetson-io-hdr40-user-custom.dtbo and updated /boot/extlinux/extlinux.conf with a new entry…

LABEL JetsonIO
	MENU LABEL Custom Header Config: <HDR40 User Custom [2025-09-02-171254]>
	LINUX /boot/Image
	FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv-super.dtb
	INITRD /boot/initrd
	APPEND ${cbootargs} root=PARTUUID=152b0b6d-d542-43ea-a9af-52511d7b627b rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 video=efifb:off console=tty0 systemd.zram=0
	OVERLAYS /boot/jetson-io-hdr40-user-custom.dtbo

Rebooted but can’t find any evidence that the overlay was actually applied. I know the JetsonIO section in extlinux.conf was used because I added the systemd.zram=0 kernel commandline parameter and that DID take effect. I would have expected that /sys/firmware/devicetree/base/bus@0/pinmux@c300000/exp-header-pinmux would have entries in it since that’s what the overly actually does…

/dts-v1/;
// magic:		0xd00dfeed
// totalsize:		0xaa9 (2729)
// off_dt_struct:	0x38
// off_dt_strings:	0x9a0
// off_mem_rsvmap:	0x28
// version:		17
// last_comp_version:	16
// boot_cpuid_phys:	0x0
// size_dt_strings:	0x109
// size_dt_struct:	0x968
/ {
    jetson-header-name = "Jetson 40pin Header";
    overlay-name = "User Custom [2025-09-02-171254]";
    compatible = "nvidia,p3768-0000+p3767-0000", "nvidia,p3768-0000+p3767-0001", "nvidia,p3768-0000+p3767-0003", "nvidia,p3768-0000+p3767-0004", "nvidia,p3768-0000+p3767-0005", "nvidia,p3768-0000+p3767-0000-super", "nvidia,p3768-0000+p3767-0001-super", "nvidia,p3768-0000+p3767-0003-super", "nvidia,p3768-0000+p3767-0004-super", "nvidia,p3768-0000+p3767-0005-super", "nvidia,p3509-0000+p3767-0000", "nvidia,p3509-0000+p3767-0001", "nvidia,p3509-0000+p3767-0003", "nvidia,p3509-0000+p3767-0004", "nvidia,p3509-0000+p3767-0005";
    fragment@0 {
        target = <0xffffffff>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <0x00000001>;
            exp-header-pinmux {
                phandle = <0x00000001>;
                hdr40-pin19 {
                    nvidia,pins = "spi1_mosi_pz5";
                    nvidia,function = "spi1";
                    nvidia,tristate = <0x00000000>;
                    nvidia,enable-input = <0x00000001>;
                };
                hdr40-pin21 {
                    nvidia,pins = "spi1_miso_pz4";
                    nvidia,function = "spi1";
                    nvidia,tristate = <0x00000000>;
                    nvidia,enable-input = <0x00000001>;
                };
                hdr40-pin23 {
                    nvidia,pins = "spi1_sck_pz3";
                    nvidia,function = "spi1";
                    nvidia,tristate = <0x00000000>;
                    nvidia,enable-input = <0x00000001>;
                };
                hdr40-pin24 {
                    nvidia,pins = "spi1_cs0_pz6";
                    nvidia,function = "spi1";
                    nvidia,tristate = <0x00000000>;
                    nvidia,enable-input = <0x00000001>;
                };
                hdr40-pin26 {
                    nvidia,pins = "spi1_cs1_pz7";
                    nvidia,function = "spi1";
                    nvidia,tristate = <0x00000000>;
                    nvidia,enable-input = <0x00000001>;
                };
            };
        };
    };
    fragment@1 {
        target = <0xffffffff>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <0x00000002>;
            exp-header-pinmux {
                phandle = <0x00000002>;
            };
        };
    };
    __symbols__ {
        jetson_io_pinmux = "/fragment@0/__overlay__/exp-header-pinmux";
        jetson_io_pinmux_aon = "/fragment@1/__overlay__/exp-header-pinmux";
    };
    __fixups__ {
        pinmux = "/fragment@0:target:0";
        pinmux_aon = "/fragment@1:target:0";
    };
    __local_fixups__ {
        fragment@0 {
            __overlay__ {
                pinctrl-0 = <0x00000000>;
            };
        };
        fragment@1 {
            __overlay__ {
                pinctrl-0 = <0x00000000>;
            };
        };
    };
};

…but it just has its name and phandle…

$ ls -al /sys/firmware/devicetree/base/bus@0/pinmux@c300000/exp-header-pinmux
total 0
drwxr-xr-x 2 root root  0 Sep  2 17:19 .
drwxr-xr-x 3 root root  0 Sep  2 17:19 ..
-r--r--r-- 1 root root 18 Sep  2 17:19 name
-r--r--r-- 1 root root  4 Sep  2 17:19 phandle

What am I missing?

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, it appears that you are trying to apply a custom device tree overlay (DTBO) to your Jetson Orin Nano Super Devkit. You have created a DTBO file (bootjetsoniohdr40usercustom.dtbo) using the dtc compiler and updated the extlinux.conf file to include a new entry that references this DTBO file.

However, after rebooting, you are unable to find any evidence that the overlay was actually applied. You have checked the sys/firmware/devicetree/base/bus@0/pinmux@c3000000/exp_header_pinmux node, which is supposed to be modified by the overlay, but it only contains its name and phandle.

To troubleshoot this issue, let’s compare your setup with the expected behavior:

  1. DTBO file creation: You have created a DTBO file using the dtc compiler, which is correct.
  2. extlinux.conf update: You have updated the extlinux.conf file to include a new entry that references the DTBO file, which is correct.
  3. Reboot: You have rebooted the system, which should cause the DTBO file to be applied.

However, there are a few potential issues that might be causing the overlay to not be applied:

  • DTBO file location: Make sure that the DTBO file is located in the correct directory, which is typically /boot/.
  • DTBO file name: Verify that the DTBO file name matches the one referenced in the extlinux.conf file.
  • Overlay compatibility: Ensure that the overlay is compatible with your Jetson Orin Nano Super Devkit. Check the compatible property in the DTBO file to ensure it matches the device tree compatible string.
  • Device tree structure: The device tree structure has changed in Rel-36, so ensure that your overlay is compatible with the new structure.

To further debug this issue, you can try the following:

  • Check the kernel logs for any errors related to the DTBO file or device tree overlay application.
  • Use the dtc compiler to decompile the DTBO file and verify that it contains the expected modifications.
  • Use the jetson-io tool to verify that the overlay is being applied correctly.

If none of these troubleshooting steps resolve the issue, please provide more information about your setup, including the contents of your DTBO file and extlinux.conf file, and I’ll be happy to help you further.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Hi,
We now use jetson-io.py to generate custom dtb and it is supposed to work well. We have validated it and listed the steps in

Making sure you're not a bot!

Could you please try this? It is possible overlay does not work well. Custom dtb should work.

6

@DaneLLL Well, I hadn’t actually tested it because neither gpioinfo nor /sys/firmware/devicetree/base/bus@0/pinmux@c300000/exp-header-pinmux showed any evidence but I just tested and it does seem to work. After comparing to some of my older devkits, I think I know why the entries don’t show in /sys/firmware/devicetree/base anymore… It’s because entries created from overlays aren’t in the base. :)

I recall that on older Jetpacks the extlinux the OVERLAYS parameter didn’t work and jetson-io actually created a custom dtb and set the FDT parameter to it. On my Xavier NXs for instance, /sys/firmware/devicetree/base/pinmux@2430000/exp-header-pinmux does show the entries. The overlays however aren’t merged into the base but doing a fdtdump /sys/firmware/fdt does show them.

So it looks like everything is working as expected. I just need to remember to check the live fdt to confirm that changes were properly applied.

Thanks.

1 Like
8

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