The gist of device tree is that there are various pins on the Jetson (and most every computer) which can be optionally set up to different functions, and makes designing the circuit board much easier. However, the software looking to become a driver of hardware needs to know how to find that optional setup, and this is what the device tree does: It is a blueprint of how the lanes are routed, and arguments drivers need to talk on those lanes (e.g., a certain physical address talks to the hardware, or uses a particular speed setting). This is firmware, and although it is not part of the kernel, such firmware often ships with the kernel because the firmware in need of setup depends on which drivers are being compiled. The device tree for the developer board is configured at the same time a kernel build is configured, but it is limited to the developer board. Other boards require modification unless their lane routing is an exact match to the developer board.
The customization of device tree for what functions pins have typically is performed in the PINMUX spreadsheet (if you enable macros it allows altering various pin assignments and will generate a new device tree for that routing). See:
https://developer.nvidia.com/embedded/downloads#?search=PINMUX
When you build a kernel and use the default configuration of “make tegra_defconfig
”, then you get the default configuration a Jetson ships with (well, Orin has a far different shipping versus default config, but it is a developer preview, and we are not talking about Orin). Build target “make dtbs
”, if first configured with “make tegra_defconfig
”, should make the same device tree as what a Jetson ships with, and should also match the default from the PINMUX spreadsheet. You would start there, and then develop changes for your carrier board (or if you purchase the carrier board from a third party, then they would provide the device tree).
Different operating systems might use a device tree differently, but if they use the Linux kernel, then there is a chance that the same drivers would use the same tree. You would have to find out if the alternate operating system handles device trees and firmware in the same way. If not, then you’d probably need to build the tree from scratch with knowledge of how it differs.
A device tree is installed in one of two places. If the security fuses are burned, then this content can only come from a signed partition, and other locations will be rejected. If security fuses are not burned, then you can also name the device tree via the “FDT
” key/value pair in “/boot/extlinux/extlinux.conf
”, and the content will be read instead from the file named there. Quite useful since it doesn’t require signing or flashing tools during development. A simple file copy works there, and one can keep the original boot entry and add a second boot entry (for selection via serial console during boot) to test with (if you destroy your only boot entry, then basically you need to flash again; an SD card model could have that content reverted from a second computer though).
If a device is present on a port which is in device mode (host mode accepts devices like a keyboard, while device mode provides a device such as a keyboard to other computers), then the other computer (running Linux in this case) should see something log related to detecting a device. A Jetson in recovery mode is always a custom device regardless of what is flashed on it, so this should never fail to show up on the other computer. Failure to show up as a device on the other computer means one of:
- There is hardware failure.
- That failure can be the USB cable, e.g., it isn’t a type-B at the Jetson end, or
- That failure is that the Jetson is not in recovery mode, or
- The Jetson itself has a hardware failure. This could technically be from an incorrect carrier board not properly routing the micro-B USB port, but this is unlikely in most cases (this assumes carrier boards known to be of a design with a valid micro-OTG port). This situation would have to be tested on a developer kit carrier board or other known working carrier board to guarantee if it is a carrier board issue version a Jetson module hardware failure.
- The host port itself might be failed.
If the port you are using is not truly a micro-OTG port (which accepts type-A or type-B cables, but has an ID pin so the Jetson knows which type of cable is used), or if you are not using the type-B cable, then I would expect no log would occur. However, since this is so rare, do you have another carrier board you can test on? Recovery mode should work regardless of which carrier board it is, and regardless of what is currently flashed on it. If not, then you likely have hardware failure (but again, it is possibly the carrier board failing and not the Jetson module).