DT Overlays on Xavier NX Devkit

Product support
1

Out application uses this “Respeaker 2-Mic HAT Board” mounted on “40-Pin header” of the “Xavier NX Devkit”.

For HAT Board to work, we need to update the pinmux configuration on NX Devkit. So far we have tested our software with “Xavier NX Devkit” running Jetpack L4T Release. On this platform we used a “Device Tree overlay” to update the Pinmux configuration as desired.

Now we are moving to BalenaOS and we want to know if “Device Tree Overlay file” can be used on “Xavier NX” running balena OS.

As per this article posted on balena blog, this can be easily done on a Pi Board by running following steps

  • Mount the SDCard on a PC and copy CUSTOM_DT_OVERLAY_FILE.dtbo to /resin-boot/overlays folder.
  • In Balena cloud find your device and set a device configuration variable RESIN_HOST_CONFIG_dtoverlay to the “CUSTOM_DT_OVERLAY_FILE” (i.e. DT overlay filename without extension).

The Xavier SDCard however has no folder with name “overlays”. Is there any other location on Xavier SDcard where we could copy our custom DT overlay file and get it working?

4

Hi @PaintedSnipe, the Xavier platform - both AGX and NX - doesn’t have u-boot support, therefore loading custom device trees or device tree overlays is not possible on it.

6

Is it possible to only re-flash the device tree partition with Balena Xavier NX devices, so a Yocto rebuild isn’t necessary anytime?

  • Using jetson-flash?
  • By mounting and replacing files on some partition in the image?

I know how to do it on native L4T installations. I can provide more information if you think it’s possible.

Kind regards,
Clint

8

Hi Clint,

You can try write the signed dtb to kenrel-dtb and kernel-dtb_b partitions, see these lines. But before generating the *sigheader.dtb.encrypt file for writing, you need to check which is the current active rootfs partition (ls -l /dev/disk/by-state) and set the root=LABEL=… appropriately in the dtb, like in this example. For signing the dtb without doing any yocto build it should be possible to use the BSP script ./flash.sh with the argument --no-flash (perform all steps except physically flashing the board.)