Xavier module is opening but does not detect devices


We designed a carrier card for the module. When we plug the module into the carrier card, we see that the module is opened from the serial console. But USB and HDMI don’t work when we connect USB and HDMI. When we query the devices seen by the module from the serial console with the commands “lsusb”, “lspci”, we realized that it did not see any device. What is the reason of this? When we compare the scheme we do not see any difference for USB. Do we need to make any settings for the module to see the devices?
In addition, when we turn on the module after connecting a mouse with USB to the carrier card, the module is detecting the speed of the USB and giving a low speed warning. Although module detects the speed of USB, when we look through the serial console, it still does not see USB devices. What is the reason of this? Why doesn’t it see USB?

Did you edit the device tree so those items could be found? See the “Jetson AGX Xavier Platform Adaptation and Bring-Up Guide”:

FYI, much of that hardware requires being found by the drivers being told the physical address of the hardware. Without that the drivers won’t be able to find the hardware. The only case of not needing device tree edits would be if your design were an exact match to the dev kit carrier board.

As stated in the “Jetson AGX Xavier Platform Adaptation and Bring-Up Guide” document, I downloaded the “Jetson-AGX-Xavier-Generic-Customer-Pinmux-Template.xlsm” file. I created files with .dtsi extension (pinmux.dtsi, gpio.dtsi, padvoltage.dtsi) by editing. What will I do with these files I created? How do I load it?
Also, we want to create an image and flash it to the module. How do we build the image? And how can we upload this new image we created to the module?
Finally, how can we access the source codes required to create this image? Can you share the source code with us?
Could you give us information about these issues? Also, can you share relevant documents with us, if any?

The “.dtsi” files are “device tree include” files which go in the kernel source. Normally, if you build a kernel, you must first configure it. Once that is done, then building the “dtbs” target combines .dtsi into .dts (for the enabled features) and finally compiles this into the “.dtb” binary device tree files. “dts” is device tree source, “dtb” is device tree binary. The tool which converts formats is “dtc”, device tree compiler, and is part of the kernel build software (but can also be installed separately).

Not all .dtb files will be used, but for those which are, you’d either overwrite the source of those .dtb files in your flash software on the host PC, and then flash, or else place the .dtb file in “/boot” of the Jetson, and make sure it is named in the “extlinux.conf” file. Basically you need to read up about customizing the device tree, and keep in mind that one method of install puts the tree in a partition via flashing, and the other method is to simply copy a file to the right place and name the place in “/boot/extlinux/extlinux.conf”.

When a file (such as a .dtb binary device tree) goes to a partition it has to be signed first (at least for semi-recent releases) and complicates installing by this method. File copy is much easier, but in some commercial releases it might be better to use this in a partition. If the .dtb is found via extlinux.conf pointing to the tree in “/boot”, then this is used; if not, then it boots from the partition version.

The other thing you would want to read up on is compiling a kernel. The device tree is only a subset of kernel compiles and not technically part of the kernel, but since the device tree passes information to drivers in the kernel, the device tree is configured at the same time as the kernel features are configured. If you pick a kernel feature/driver you don’t use, then device tree content will be generated for a driver which never loads. If you fail to specify a kernel feature for some hardware you have, then building the device tree would leave out the tree for that hardware, and very likely the hardware would not function (e.g., because the driver does not know the base address to find the hardware at). Any work with a kernel should always start by matching the exact configuration of the current running kernel.

Your current L4T release can be found via “head -n 1 /etc/nv_tegra_release”. You can then go to the URL for that release, and kernel source (and documents) will be available there with information you need. See:

Follow the docs to configure and build a kernel, but just practice without installing. Check out the make target of dtbs.

Although this sounds complicated it will actually turn out to be fairly simple after you’ve done this once or twice. You can always look at the docs and then ask questions on parts which might be a problem.

I will try to do it by looking at the document as you said.
What changes should I make for USB and HDMI in this image? I use all USBs as USB 2.0 type A.

A custom carrier board requires editing by the creator of the board. There is no way for someone else to know the answer to this, but there is a document related to developing which includes device tree information:

Basically you must change the device tree for any lane configuration which differs from the reference carrier board. The exact device tree file related to this will differ in different situations.

I created the .dtsi files by editing the Jetson-AGX-Xavier-Generic-Customer-Pinmux-Template.xlsm file. But to which .dts file do I need to include these .dtsi files? What directory is this .dts file in?
I have no experience with creating Linux images. Can you explain the steps I need to do after this?

Any time you are talking about a “.dtsi” file you are talking about the kernel source. If the files are in place, then configuring the kernel to match your running system, and then building the “dtbs” build target, you would get some “.dtb” files in the output (probably some “.dts” files in intermediate output too, though I’m not sure about that). The kernel build documents show how to configure and build a kernel.

As to which one to pick I couldn’t tell you. The best way is to flash a Jetson and save a log of the flash where it tells you which “.dtb” files it actually uses. If you were to flash on command line a log could be produced something like this:
sudo ./flash.sh jetson-xavier mmcblk0p1 2>&1 | tee log_build.txt
…then search the log.