USB C Ports Jetson AGX Xavier stopped working

if you mount the image to the Host PC you will be able to access files from it;
img in my example is a placeholder and it means that any raw image file might be placed in its place;
Probably reflashing the device might resolve the original issue.

Hi @linuxdev,

thank for all this explanations. Especially the calculation for the images functionality and the theory behind .raw files were very helpful.
The size of my .raw file can be divided by two times 1024 to an int, so I assume the image should work.

I replaced the custom.dtb file in the directory Linux_For_Tegra/kernel/dtb and also in Linux_For_Tegra/bootloader, because I found the original file on both places.
Before flashing, I got one question to this line:

Do I have to replace system.img with my custom.raw.img or do I have to replace system.img.raw? In both cases, do I have to remove the other “old” file (system.img or system.img.raw)?

Btw. on the Xavier the /mnt directory was empty…

Again I really appreciate your explanations. Thanks for that.

@Andrey1984, also thank you too for your last post.

Normally “bootloader/system.img” is a temporary file. A huge temporary file. Flash without the “-r” option will regenerate this. Actually, normal flash regenerates “bootloader/system.img.raw” every flash, and then creates a sparse version as “bootloader/system.img”. “system.img.raw” could be renamed as “system.img”, and the result would be exactly the same flash, but take longer to flash.

You need to place your clone raw image in place of “bootloader/system.img”, and keep your clone as name “system.img” without regenerating the file during the flash (without “-r” you won’t be flashing your clone image…a new image would overwrite what you put there…do not forget “-r”).

You can always delete “bootloader/system.img.raw” to save space if you want, but it is there for you to examine after a flash if you want to explore it. Other than being used to create a default sample rootfs system.img this file has no purpose other than your curiosity. I would delete “bootloader/system.img.raw” and save space.

Incidentally, the “mksparse” application can be used to create a sparse version of your raw image. In your case where the filesystem is nearly full this won’t save much flash time and will cost about 28GB of disk space on the host PC. A sparse file in a production environment saving only a few seconds could help, but is not worth much other than costing effort when running a single flash and not repeated hundreds of times per day. The default sample sparse image is so much smaller than the full filesystem that it makes sense to convert to sparse before flash even if it is just for one flash.

The “/mnt” directory is just an example of where to mount. “/mnt” is more tradition than anything else. If a disk or loopback image is mounted there, then you should see any content there. Just make sure mount actually succeeded. You can also run command “df -H -T /mnt” to see what is mounted there (before and after mount) and verify the loopback image is mounted versus the actual eMMC or hard disk. If the loopback image is empty, then it probably was not a valid clone (after a successful “mount -o loop imagename /mnt” there should be new content in “/mnt” until the “umount”, and “df -H -T /mnt” should change depending on mount or not mount).

On the Xavier and even on a host PC expect “/mnt” to be empty unless you’ve modified something or mounted something there. If something is already there, and you mount there, then the modified content will temporarily become inaccessible and be replaced with the mount content. Once mount is removed the old content will once again become accessible. I take advantage of this on my host PC by copying my “/home” content into the actual home directory, and then mounting my home content over the top of it with a RAID partition. If my RAID partition fails, or if I umount it, then I still have home directory content (but out of date). Useful for maintenance.

Individual users have an equivalent to “/mnt”: “/var/run/user/<numeric_user_id>”. Think of “/mnt” as the manual mount location for user root to customize, and “/var/run/user/” as the auto mount location for any user.

Hi linuxdev,

thanks as always for the detailed information.
I flashed my Jetson Xavier on my host computer with running the command

sudo ./flash.sh -S 28GiB -r jetson-xavier mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee log.txt

I uploaded the logs that were created (as .log file, even if they were .txt files) logFlash.log (1.9 MB) logFlash3.log (1.9 MB) logFlash2.log (1.9 MB). It seems, that it flashed successfully.

After this command was executed, I pressed Jetson Xaviers reset button to start it. Everything went normal, files were there as always. Unfortunately I still receive the same output for cat /proc/cmdline:

root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt tegra_fbmem=0x800000@0xa0697000 lut_mem=0x2008@0xa0693000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr=0x8000000@0xf0000000 sdhci_tegra.en_boot_part_access=1

Also /sys/module/usbcore/parameters/autosuspend still gives the output 2.

I did two things for flashing:

  1. cp my_Backup.img.raw /SDKManager/SDKNvidia/JetPack_4.2.3_Linux_GA_P2888/Linux_for_Tegra/bootloader/system.img 
    

I deleted the old system.img file and the system.img.raw file.

  1. I added usbcore.autosuspend=-1 in the chosen node in the files Linux_for_Tegra/kernel/dtb/tegra194-p2888-0001-p2822-0000.dts and Linux_for_Tegra/kernel/dtb/tegra194-p2888-0001-p2822-0000.dtb.
    They had different entries inside the chosen-node.

The chosen node in the .dtb-file in /kernel/dtb looks like this:

chosen {
	bootargs = "console=ttyTCU0,115200, usbcore.autosuspend=-1";
	board-has-eeprom;
};

The chosen node in the .dtb-file in /bootloader looks like this:

chosen {
	bootargs = "root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 usbcore.autosuspend=-1    ";
	board-has-eeprom;
};

When the flashing is done, and I look beck into the converted .dts file, the part usbcore.autosuspend=-1 is removed. (I double checked multiple times). In total I repeated the flash three times, to which the log-files belong.
I also tried to the usbcore parameter in extlinux.conf and also in usbcore.conf.
Am I missing something, or why does the flashing not result in what we expected?

Looks like my gawk filter is leaving in the progress bar (sadly, this makes the log size huge just from the progress bar).

The flashes were correct and successful. Which exact file name and location did you place this in on your host’s “Linux_for_Tegra/” content? If the wrong dtb file were copied in, then it might miss the updates to “chosen->bootargs”. The log file should be able to verify if your file was actually copied in during the flash.

Hi linuxdev,

the file, in which I added the option usbcore.autosuspend = 1 is
tegra194-p2888-0001-p2822-0000.dts.
Its reconverted .dtb file is located in /SDKManager/SDKNvidia/JetPack_4.2.3_Linux_GA_P2888/Linux_for_Tegra/kernel/dtb/.
In the log, lin 137, the file is mentioned the first time.

Just for the check, after flashing the Jetson Xavier I reconverted tegra194-p2888-0001-p2822-0000.dtb to .dts. The option usbcore.autosuspend=-1 still was written there.

Also I added the usbcore-option to another file named alsotegra194-p2888-0001-p2822-0000, located in /SDKManager/SDKNvidia/JetPack_4.2.3_Linux_GA_P2888/Linux_for_Tegra/bootloader. This did not seem to have an impact, because there the option was removed after flashing.

I also would like to add two other things, that I tried and found and that might be helpful for finding a solution.

There is a difference in the dmesg | grep -i usb output depending on which USB C port is connected. I tested it by connecting one of the USB C ports to my host PC while being logged in in Jetson Xavier.
If I connect J512 it gives:

[ 46.911465] l4tbr0: port 2(usb0) entered blocking state
[ 46.911473] l4tbr0: port 2(usb0) entered forwarding state
whole dmesg | grep -i usb here: dmesgGrep-iUSB_Output_J512_front.log (6.4 KB)

If I use J513 the output usb usb2: usb_suspend_both: status -16 (as shown in my first post) is generated.
Also sometimes there is a log different from the first one, giving these errors/warnings:
[ 13.416769] usb 1-4-port1: Cannot enable. Maybe the USB cable is bad?
[ 3918.126020] usb usb2: usb_suspend_both: status -16
[ 3918.126457] usb usb2-port1: config error
[ 3926.269932] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2: usb_suspend_both: status 0

I did not find a logic behind, if one of the different outputs in Port J513 is generated.

The second thing I found is, that it was temporarily possible to enable usbcore.autosuspend=-1 (Found here)
In the file sys/module/usbcore/parameters/autosuspend I could set the number from 2 to -1. The output $ cat /sys/module/usbcore/parameters/autosuspend was -1, but with no effect on the functionality of the USB C ports.
I also tried the command
sudo sh -c "echo -1 > /sys/bus/usb/devices/2-0:1.0/power/autosuspend_delay_ms"
but even as being logged in as root I had no permissions to execute this command.

Hi,
If you suspect the hardware may be broken, please try to re-flash the whole system through SDKManager and check if the two ports work. If it is still does not work, you may consider RMA.

Please check

The “/sys” files are not real files, but are drivers printing data about themselves, and only sometimes it will be possible to actually write (it depends on the source code of the driver). You may find places where these files are a reflection of current settings, but not usable as an actual method to impose changes.

As mentioned by @DaneLLL it is probably time to consider reflashing from scratch to see if this has been some other issue in software, versus some sort of failure in need of RMA.