USB C Ports Jetson AGX Xavier stopped working

Hey everybody,

I am confused because both of my USB C ports on my Jetson Xavier stopped working.
Both of them were working. Then I connected both of them to a USB 3.1 (no Power Delivery Port).
I think it could be a problem with the kernel (not sure)…

If I try dmesg | grep -i usb I get this output (please see below)

Any help is appreciated.

Preformatted text[ 0.000000] Kernel command line: 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
[ 1.113299] usbcore: registered new interface driver usbfs
[ 1.113438] usbcore: registered new interface driver hub
[ 1.113619] usbcore: registered new device driver usb
[ 1.182404] vdd-usb-3v3: at 3300 mV
[ 4.587028] usbcore: registered new interface driver r8152
[ 4.587082] usbcore: registered new interface driver asix
[ 4.587145] usbcore: registered new interface driver ax88179_178a
[ 4.587183] usbcore: registered new interface driver cdc_ether
[ 4.587245] usbcore: registered new interface driver net1080
[ 4.587290] usbcore: registered new interface driver cdc_subset
[ 4.587332] usbcore: registered new interface driver zaurus
[ 4.587397] usbcore: registered new interface driver cdc_ncm
[ 4.589269] ehci_hcd: USB 2.0 ‘Enhanced’ Host Controller (EHCI) Driver
[ 4.589332] ohci_hcd: USB 1.1 ‘Open’ Host Controller (OHCI) Driver
[ 4.596516] tegra-xusb 3610000.xhci: USB2 port 0 has OTG_CAP
[ 4.596524] tegra-xusb 3610000.xhci: USB3 port 2 has OTG_CAP
[ 4.603150] usbcore: registered new interface driver uas
[ 4.603253] usbcore: registered new interface driver usb-storage
[ 4.603348] usbcore: registered new interface driver usbserial
[ 4.628182] usbcore: registered new interface driver xpad
[ 7.837529] usbcore: registered new interface driver usbhid
[ 7.837532] usbhid: USB HID core driver
[ 7.858433] usbcore: registered new interface driver snd-usb-audio
[ 11.898285] tegra-xusb 3610000.xhci: USB2 port 0 has OTG_CAP
[ 11.899587] tegra-xusb 3610000.xhci: USB3 port 2 has OTG_CAP
[ 11.904317] tegra-xusb 3610000.xhci: extcon 0: ffffffc3d9dbb800 id
[ 11.912891] tegra-xusb 3610000.xhci: Firmware timestamp: 2019-07-24 05:47:34 UTC, Version: 60.06 release
[ 11.912941] tegra-xusb 3610000.xhci: xHCI Host Controller
[ 11.912959] tegra-xusb 3610000.xhci: new USB bus registered, assigned bus number 1
[ 11.913642] tegra-xusb 3610000.xhci: hcc params 0x0184ff25 hci version 0x110 quirks 0x00050810
[ 11.913681] tegra-xusb 3610000.xhci: irq 472, io mem 0x03610000
[ 11.913868] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 11.913871] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 11.913874] usb usb1: Product: xHCI Host Controller
[ 11.913876] usb usb1: Manufacturer: Linux 4.9.140-tegra xhci-hcd
[ 11.913879] usb usb1: SerialNumber: 3610000.xhci
[ 11.919914] hub 1-0:1.0: USB hub found
[ 11.920290] tegra-xusb 3610000.xhci: xHCI Host Controller
[ 11.920297] tegra-xusb 3610000.xhci: new USB bus registered, assigned bus number 2
[ 11.920315] tegra-xusb 3610000.xhci: Host supports USB 3.1 Enhanced SuperSpeed
[ 11.920498] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 11.920501] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 11.920504] usb usb2: Product: xHCI Host Controller
[ 11.920506] usb usb2: Manufacturer: Linux 4.9.140-tegra xhci-hcd
[ 11.920508] usb usb2: SerialNumber: 3610000.xhci
[ 11.925052] hub 2-0:1.0: USB hub found
[ 12.281046] usb 1-4: new high-speed USB device number 2 using tegra-xusb
[ 12.304466] usb 1-4: New USB device found, idVendor=05e3, idProduct=0610
[ 12.305749] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 12.306990] usb 1-4: Product: USB2.0 Hub
[ 12.308142] usb 1-4: Manufacturer: GenesysLogic
[ 12.310451] hub 1-4:1.0: USB hub found
[ 13.377747] usb 1-4-port1: Cannot enable. Maybe the USB cable is bad?
[ 14.125995] usb0: HOST MAC ce:04:f4:1a:92:92
[ 14.126033] usb0: MAC ce:04:f4:1a:92:93
[ 14.155069] l4tbr0: port 2(usb0) entered blocking state
[ 14.155076] l4tbr0: port 2(usb0) entered disabled state
[ 14.155311] device usb0 entered promiscuous mode
[ 14.160464] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[ 15.105122] usb 1-4.3: new full-speed USB device number 5 using tegra-xusb
[ 15.128707] usb 1-4.3: New USB device found, idVendor=e0ff, idProduct=0002
[ 15.128712] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 15.128715] usb 1-4.3: Product: G3
[ 15.128717] usb 1-4.3: Manufacturer: A…
[ 15.131495] input: A… G3 as /devices/3610000.xhci/usb1/1-4/1-4.3/1-4.3:1.0/0003:E0FF:0002.0001/input/input6
[ 15.131795] hid-generic 0003:E0FF:0002.0001: input,hidraw0: USB HID v1.00 Mouse [A… G3] on usb-3610000.xhci-4.3/input0
[ 15.136554] input: A… G3 as /devices/3610000.xhci/usb1/1-4/1-4.3/1-4.3:1.1/0003:E0FF:0002.0002/input/input7
[ 15.197435] hid-generic 0003:E0FF:0002.0002: input,hidraw1: USB HID v1.00 Keyboard [A… G3] on usb-3610000.xhci-4.3/input1
[ 15.421077] usb 1-4.4: new low-speed USB device number 6 using tegra-xusb
[ 15.461530] usb 1-4.4: New USB device found, idVendor=04d9, idProduct=1603
[ 15.461535] usb 1-4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 15.461538] usb 1-4.4: Product: USB Keyboard
[ 15.461556] usb 1-4.4: Manufacturer:
[ 15.472600] input: USB Keyboard as /devices/3610000.xhci/usb1/1-4/1-4.4/1-4.4:1.0/0003:04D9:1603.0003/input/input8
[ 15.529862] hid-generic 0003:04D9:1603.0003: input,hidraw2: USB HID v1.10 Keyboard [ USB Keyboard] on usb-3610000.xhci-4.4/input0
[ 15.546776] input: USB Keyboard as /devices/3610000.xhci/usb1/1-4/1-4.4/1-4.4:1.1/0003:04D9:1603.0004/input/input9
[ 15.605504] hid-generic 0003:04D9:1603.0004: input,hidraw3: USB HID v1.10 Device [ USB Keyboard] on usb-3610000.xhci-4.4/input1
[ 16.101656] tegra-xusb 3610000.xhci: Upgrade port 0 to USB3.0
[ 16.101660] tegra-xusb 3610000.xhci: Upgrade port 1 to USB3.0
[ 16.205284] usb usb2: usb_suspend_both: status 0
[ 44.172405] usb 1-4: USB disconnect, device number 2
[ 44.172430] usb 1-4.3: USB disconnect, device number 5
[ 44.283436] usb 1-4.4: USB disconnect, device number 6
[ 44.681113] usb 1-4: new high-speed USB device number 7 using tegra-xusb
[ 44.704622] usb 1-4: New USB device found, idVendor=05e3, idProduct=0610
[ 44.704641] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 44.704689] usb 1-4: Product: USB2.0 Hub
[ 44.704697] usb 1-4: Manufacturer: GenesysLogic
[ 44.706930] hub 1-4:1.0: USB hub found
[ 44.997281] usb 1-4.3: new full-speed USB device number 8 using tegra-xusb
[ 45.019280] usb 1-4.3: New USB device found, idVendor=e0ff, idProduct=0002
[ 45.019301] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 45.019310] usb 1-4.3: Product: G3
[ 45.019317] usb 1-4.3: Manufacturer: A…
[ 45.023603] input: A… G3 as /devices/3610000.xhci/usb1/1-4/1-4.3/1-4.3:1.0/0003:E0FF:0002.0005/input/input10
[ 45.024803] hid-generic 0003:E0FF:0002.0005: input,hidraw0: USB HID v1.00 Mouse [A… G3] on usb-3610000.xhci-4.3/input0
[ 45.029690] input: A… G3 as /devices/3610000.xhci/usb1/1-4/1-4.3/1-4.3:1.1/0003:E0FF:0002.0006/input/input11
[ 45.090274] hid-generic 0003:E0FF:0002.0006: input,hidraw1: USB HID v1.00 Keyboard [A… G3] on usb-3610000.xhci-4.3/input1
[ 45.169146] usb 1-4.4: new low-speed USB device number 9 using tegra-xusb
[ 45.209434] usb 1-4.4: New USB device found, idVendor=04d9, idProduct=1603
[ 45.209457] usb 1-4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 45.209465] usb 1-4.4: Product: USB Keyboard
[ 45.209472] usb 1-4.4: Manufacturer:
[ 45.222406] input: USB Keyboard as /devices/3610000.xhci/usb1/1-4/1-4.4/1-4.4:1.0/0003:04D9:1603.0007/input/input12
[ 45.284332] hid-generic 0003:04D9:1603.0007: input,hidraw2: USB HID v1.10 Keyboard [ USB Keyboard] on usb-3610000.xhci-4.4/input0
[ 45.302648] input: USB Keyboard as /devices/3610000.xhci/usb1/1-4/1-4.4/1-4.4:1.1/0003:04D9:1603.0008/input/input13
[ 45.362148] hid-generic 0003:04D9:1603.0008: input,hidraw3: USB HID v1.10 Device [ USB Keyboard] on usb-3610000.xhci-4.4/input1
[ 287.685293] usb usb2: usb_suspend_both: status -16
[ 287.701286] usb usb2: usb_suspend_both: status -16
[ 287.717241] usb usb2: usb_suspend_both: status -16
[ 287.733283] usb usb2: usb_suspend_both: status -16
[ 287.749234] usb usb2: usb_suspend_both: status -16
[ 287.769265] usb usb2: usb_suspend_both: status -16
[ 287.785247] usb usb2: usb_suspend_both: status -16
[ 287.801234] usb usb2: usb_suspend_both: status -16
[ 287.817248] usb usb2: usb_suspend_both: status -16
[ 287.833247] usb usb2: usb_suspend_both: status -16
[ 287.849346] usb usb2: usb_suspend_both: status -16
[ 287.865502] usb usb2: usb_suspend_both: status -16
[ 287.881305] usb usb2: usb_suspend_both: status -16
[ 287.897227] usb usb2: usb_suspend_both: status -16
[ 287.913265] usb usb2: usb_suspend_both: status -16
[ 287.929266] usb usb2: usb_suspend_both: status -16
[ 287.945274] usb usb2: usb_suspend_both: status -16
[ 287.961370] usb usb2: usb_suspend_both: status -16
[ 287.977226] usb usb2: usb_suspend_both: status -16
[ 287.993238] usb usb2: usb_suspend_both: status -16
[ 288.009270] usb usb2: usb_suspend_both: status -16
[ 288.025255] usb usb2: usb_suspend_both: status -16
[ 288.041231] usb usb2: usb_suspend_both: status -16
[ 288.057167] usb usb2: usb_suspend_both: status -16
[ 288.073376] usb usb2: usb_suspend_both: status -16
[ 288.089223] usb usb2: usb_suspend_both: status -16
[ 288.105170] usb usb2: usb_suspend_both: status -16
[ 288.121194] usb usb2: usb_suspend_both: status -16
[ 288.137244] usb usb2: usb_suspend_both: status -16
[ 288.153235] usb usb2: usb_suspend_both: status -16
[ 288.169190] usb usb2: usb_suspend_both: status -16
[ 288.185219] usb usb2: usb_suspend_both: status -16
[ 288.201212] usb usb2: usb_suspend_both: status -16
[ 288.217345] usb usb2: usb_suspend_both: status -16
[ 288.233242] usb usb2: usb_suspend_both: status -16
[ 288.249178] usb usb2: usb_suspend_both: status -16
[ 288.265252] usb usb2: usb_suspend_both: status -16
[ 288.281368] usb usb2: usb_suspend_both: status -16
[ 288.301245] usb usb2: usb_suspend_both: status -16
[ 288.317288] usb usb2: usb_suspend_both: status -16
[ 288.337213] usb usb2: usb_suspend_both: status -16
[ 288.353232] usb usb2: usb_suspend_both: status -16
[ 288.369355] usb usb2: usb_suspend_both: status -16
[ 288.385255] usb usb2: usb_suspend_both: status -16
[ 288.401259] usb usb2: usb_suspend_both: status -16
[ 288.417247] usb usb2: usb_suspend_both: status -16
[ 288.437688] usb usb2: usb_suspend_both: status -16
[ 288.453373] usb usb2: usb_suspend_both: status -16
[ 288.469295] usb usb2: usb_suspend_both: status -16
[ 288.485245] usb usb2: usb_suspend_both: status -16
[ 288.501215] usb usb2: usb_suspend_both: status -16
[ 288.517199] usb usb2: usb_suspend_both: status -16
[ 288.533282] usb usb2: usb_suspend_both: status -16
[ 288.549229] usb usb2: usb_suspend_both: status -16
[ 288.565406] usb usb2: usb_suspend_both: status -16
[ 288.581206] usb usb2: usb_suspend_both: status -16
[ 288.597258] usb usb2: usb_suspend_both: status -16
[ 288.613177] usb usb2: usb_suspend_both: status -16
[ 288.629258] usb usb2: usb_suspend_both: status -16
[ 288.645265] usb usb2: usb_suspend_both: status -16
[ 288.661235] usb usb2: usb_suspend_both: status -16
[ 288.677287] usb usb2: usb_suspend_both: status -16
[ 288.693181] usb usb2: usb_suspend_both: status -16
[ 288.709238] usb usb2: usb_suspend_both: status -16
[ 288.725217] usb usb2: usb_suspend_both: status -16
[ 288.741221] usb usb2: usb_suspend_both: status -16
[ 288.757197] usb usb2: usb_suspend_both: status -16
[ 288.773213] usb usb2: usb_suspend_both: status -16
[ 288.789364] usb usb2: usb_suspend_both: status -16
[ 288.805486] usb usb2: usb_suspend_both: status -16
[ 288.821272] usb usb2: usb_suspend_both: status -16
[ 288.837268] usb usb2: usb_suspend_both: status -16
[ 288.853284] usb usb2: usb_suspend_both: status -16
[ 288.869295] usb usb2: usb_suspend_both: status -16
[ 288.885334] usb usb2: usb_suspend_both: status -16
[ 288.901302] usb usb2: usb_suspend_both: status -16
[ 288.921308] usb usb2: usb_suspend_both: status -16
[ 288.937390] usb usb2: usb_suspend_both: status -16
[ 288.953256] usb usb2: usb_suspend_both: status -16
[ 288.969244] usb usb2: usb_suspend_both: status -16
[ 288.985256] usb usb2: usb_suspend_both: status -16
[ 289.001226] usb usb2: usb_suspend_both: status -16
[ 289.017245] usb usb2: usb_suspend_both: status -16
[ 289.033364] usb usb2: usb_suspend_both: status -16
[ 289.049221] usb usb2: usb_suspend_both: status -16
[ 289.065175] usb usb2: usb_suspend_both: status -16
[ 289.081228] usb usb2: usb_suspend_both: status -16
[ 289.097286] usb usb2: usb_suspend_both: status -16
[ 289.113194] usb usb2: usb_suspend_both: status -16
[ 289.129168] usb usb2: usb_suspend_both: status -16
[ 289.145214] usb usb2: usb_suspend_both: status -16
[ 289.161270] usb usb2: usb_suspend_both: status -16
[ 289.177201] usb usb2: usb_suspend_both: status -16
[ 289.193400] usb usb2: usb_suspend_both: status -16
[ 289.209319] usb usb2: usb_suspend_both: status -16
[ 289.225206] usb usb2: usb_suspend_both: status -16
[ 289.241363] usb usb2: usb_suspend_both: status -16
[ 289.257342] usb usb2: usb_suspend_both: status -16
[ 289.273262] usb usb2: usb_suspend_both: status -16
[ 289.289221] usb usb2: usb_suspend_both: status -16
[ 289.305236] usb usb2: usb_suspend_both: status -16
[ 289.321197] usb usb2: usb_suspend_both: status -16
[ 289.337247] usb usb2: usb_suspend_both: status -16
[ 289.353226] usb usb2: usb_suspend_both: status -16
[ 289.369215] usb usb2: usb_suspend_both: status -16
[ 289.385221] usb usb2: usb_suspend_both: status -16
[ 289.401176] usb usb2: usb_suspend_both: status -16
[ 289.417240] usb usb2: usb_suspend_both: status -16
[ 289.433326] usb usb2: usb_suspend_both: status -16
[ 289.449257] usb usb2: usb_suspend_both: status -16
[ 289.465332] usb usb2: usb_suspend_both: status -16
[ 289.481203] usb usb2: usb_suspend_both: status -16
[ 289.497288] usb usb2: usb_suspend_both: status -16
[ 289.513250] usb usb2: usb_suspend_both: status -16
[ 289.529232] usb usb2: usb_suspend_both: status -16
[ 289.545217] usb usb2: usb_suspend_both: status -16
[ 289.561172] usb usb2: usb_suspend_both: status -16
[ 289.577166] usb usb2: usb_suspend_both: status -16
[ 289.593239] usb usb2: usb_suspend_both: status -16
[ 289.609207] usb usb2: usb_suspend_both: status -16
[ 289.625222] usb usb2: usb_suspend_both: status -16
[ 289.641207] usb usb2: usb_suspend_both: status -16
[ 289.657201] usb usb2: usb_suspend_both: status -16
[ 289.673488] usb usb2: usb_suspend_both: status -16
[ 289.689176] usb usb2: usb_suspend_both: status -16
[ 289.705217] usb usb2: usb_suspend_both: status -16
[ 289.721207] usb usb2: usb_suspend_both: status -16
[ 289.737177] usb usb2: usb_suspend_both: status -16
[ 289.753175] usb usb2: usb_suspend_both: status -16
[ 289.769181] usb usb2: usb_suspend_both: status -16
[ 289.785215] usb usb2: usb_suspend_both: status -16
[ 289.801183] usb usb2: usb_suspend_both: status -16
[ 289.817245] usb usb2: usb_suspend_both: status -16
[ 289.833234] usb usb2: usb_suspend_both: status -16
[ 289.849216] usb usb2: usb_suspend_both: status -16
[ 289.865234] usb usb2: usb_suspend_both: status -16
[ 289.881199] usb usb2: usb_suspend_both: status -16
[ 289.897200] usb usb2: usb_suspend_both: status -16
[ 289.913203] usb usb2: usb_suspend_both: status -16
[ 289.929161] usb usb2: usb_suspend_both: status -16
[ 289.945234] usb usb2: usb_suspend_both: status -16
[ 289.961163] usb usb2: usb_suspend_both: status -16
[ 289.977222] usb usb2: usb_suspend_both: status -16
[ 289.993245] usb usb2: usb_suspend_both: status -16
[ 290.009274] usb usb2: usb_suspend_both: status -16
[ 290.025559] usb usb2: usb_suspend_both: status -16
[ 290.041256] usb usb2: usb_suspend_both: status -16
[ 290.057241] usb usb2: usb_suspend_both: status -16
[ 290.073259] usb usb2: usb_suspend_both: status -16
[ 290.089241] usb usb2: usb_suspend_both: status -16
[ 290.105179] usb usb2: usb_suspend_both: status -16
[ 290.121156] usb usb2: usb_suspend_both: status -16
[ 290.137193] usb usb2: usb_suspend_both: status -16
[ 290.153161] usb usb2: usb_suspend_both: status -16
[ 290.169192] usb usb2: usb_suspend_both: status -16
[ 290.185196] usb usb2: usb_suspend_both: status -16
[ 290.201171] usb usb2: usb_suspend_both: status -16
[ 290.217148] usb usb2: usb_suspend_both: status -16
[ 290.233194] usb usb2: usb_suspend_both: status -16
[ 290.249184] usb usb2: usb_suspend_both: status -16
[ 290.265155] usb usb2: usb_suspend_both: status -16
[ 290.281153] usb usb2: usb_suspend_both: status -16
[ 290.297179] usb usb2: usb_suspend_both: status -16
[ 290.313161] usb usb2: usb_suspend_both: status -16
[ 290.329189] usb usb2: usb_suspend_both: status -16
[ 290.345180] usb usb2: usb_suspend_both: status -16
[ 290.361161] usb usb2: usb_suspend_both: status -16
[ 290.377190] usb usb2: usb_suspend_both: status -16
[ 290.393197] usb usb2: usb_suspend_both: status -16
[ 290.409161] usb usb2: usb_suspend_both: status -16
[ 290.425154] usb usb2: usb_suspend_both: status -16
[ 290.441195] usb usb2: usb_suspend_both: status -16
[ 290.457205] usb usb2: usb_suspend_both: status -16
[ 290.473167] usb usb2: usb_suspend_both: status -16
[ 290.489156] usb usb2: usb_suspend_both: status -16
[ 290.505187] usb usb2: usb_suspend_both: status -16
[ 290.521195] usb usb2: usb_suspend_both: status -16
[ 290.537157] usb usb2: usb_suspend_both: status -16
[ 290.553251] usb usb2: usb_suspend_both: status -16
[ 290.569202] usb usb2: usb_suspend_both: status -16
[ 290.585326] usb usb2: usb_suspend_both: status -16
[ 290.601230] usb usb2: usb_suspend_both: status -16
[ 290.617237] usb usb2: usb_suspend_both: status -16
[ 290.633230] usb usb2: usb_suspend_both: status -16
[ 290.649215] usb usb2: usb_suspend_both: status -16
[ 290.665182] usb usb2: usb_suspend_both: status -16
[ 290.681234] usb usb2: usb_suspend_both: status -16
[ 290.697208] usb usb2: usb_suspend_both: status -16
[ 290.713182] usb usb2: usb_suspend_both: status -16
[ 290.729229] usb usb2: usb_suspend_both: status -16
[ 290.745197] usb usb2: usb_suspend_both: status -16
[ 290.761225] usb usb2: usb_suspend_both: status -16
[ 290.777171] usb usb2: usb_suspend_both: status -16
[ 290.793201] usb usb2: usb_suspend_both: status -16
[ 290.809176] usb usb2: usb_suspend_both: status -16
[ 290.825221] usb usb2: usb_suspend_both: status -16
[ 290.843282] usb usb2: usb_suspend_both: status -16
[ 290.857302] usb usb2: usb_suspend_both: status -16
[ 290.873252] usb usb2: usb_suspend_both: status -16
[ 290.889280] usb usb2: usb_suspend_both: status -16
[ 290.905251] usb usb2: usb_suspend_both: status -16
[ 290.921218] usb usb2: usb_suspend_both: status -16
[ 290.937359] usb usb2: usb_suspend_both: status -16
[ 290.957272] usb usb2: usb_suspend_both: status -16
[ 290.973268] usb usb2: usb_suspend_both: status -16
[ 290.989312] usb usb2: usb_suspend_both: status -16
[ 291.005265] usb usb2: usb_suspend_both: status -16
[ 291.021303] usb usb2: usb_suspend_both: status -16
[ 291.038593] usb usb2: usb_suspend_both: status -16
[ 291.053373] usb usb2: usb_suspend_both: status -16
[ 291.069220] usb usb2: usb_suspend_both: status -16
[ 291.085246] usb usb2: usb_suspend_both: status -16
[ 291.101520] usb usb2: usb_suspend_both: status -16
[ 291.117299] usb usb2: usb_suspend_both: status -16
[ 291.133216] usb usb2: usb_suspend_both: status -16
[ 291.149222] usb usb2: usb_suspend_both: status -16
[ 291.165170] usb usb2: usb_suspend_both: status -16
[ 291.185192] usb usb2: usb_suspend_both: status -16
[ 291.201161] usb usb2: usb_suspend_both: status -16
[ 291.217208] usb usb2: usb_suspend_both: status -16
[ 291.233174] usb usb2: usb_suspend_both: status -16
[ 291.249201] usb usb2: usb_suspend_both: status -16
[ 291.265298] usb usb2: usb_suspend_both: status -16
[ 291.281201] usb usb2: usb_suspend_both: status -16
[ 291.297276] usb usb2: usb_suspend_both: status -16
[ 291.313296] usb usb2: usb_suspend_both: status -16
[ 291.329167] usb usb2: usb_suspend_both: status -16
[ 291.345221] usb usb2: usb_suspend_both: status -16
[ 291.361251] usb usb2: usb_suspend_both: status -16
[ 291.377172] usb usb2: usb_suspend_both: status -16
[ 291.393194] usb usb2: usb_suspend_both: status -16
[ 291.409205] usb usb2: usb_suspend_both: status -16
[ 291.425283] usb usb2: usb_suspend_both: status -16
[ 291.441208] usb usb2: usb_suspend_both: status -16
[ 291.457204] usb usb2: usb_suspend_both: status -16
[ 291.473195] usb usb2: usb_suspend_both: status -16
[ 291.489198] usb usb2: usb_suspend_both: status -16
[ 291.505231] usb usb2: usb_suspend_both: status -16
[ 291.521208] usb usb2: usb_suspend_both: status -16
[ 291.537208] usb usb2: usb_suspend_both: status -16
[ 291.553207] usb usb2: usb_suspend_both: status -16
[ 291.569163] usb usb2: usb_suspend_both: status -16
[ 291.585166] usb usb2: usb_suspend_both: status -16
[ 291.601220] usb usb2: usb_suspend_both: status -16
[ 291.617265] usb usb2: usb_suspend_both: status -16
[ 291.633217] usb usb2: usb_suspend_both: status -16
[ 291.649280] usb usb2: usb_suspend_both: status -16
[ 291.665212] usb usb2: usb_suspend_both: status -16
[ 291.681294] usb usb2: usb_suspend_both: status -16
[ 291.681460] usb usb2: usb_suspend_both: status 0

It looks like some device is not handling a low power mode. Notice that the log ends for quite some time prior to the “usb_suspend_both” error. You could try disabling USB autosuspend for a bit to see if the error goes away. Try either/both of these:

  • Edit /boot/extlinux/extlinux.conf, find the “APPEND” line, and at the end add (space delimited) " usbcore.autosuspend=-1"

  • Edit (or create) “/etc/modprobe.d/usbcore.conf”, and add this line (if the file does not already exist and you create one, then later you can just delete the file): “options usbcore autosuspend=-1”.

If you wait for some time to pass when the system might have otherwise put some USB devices into low power mode, then the error might no longer exist. If this is the case, then you’ve narrowed it down to low power mode issues (and this is likely a problem with a USB device).

Hi linuxdev,
thanks a lot for your quick reply. I tested both suggestions. Unfortunately I did not manage to get the USB ports working.
There might be the possibility I did something wrong, so maybe you could check if the following code includes what you meant:

First I edited ext.linux.config. The block with the “APPEND” line looks originally like this:
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet

I tried:

  • APPEND ${cbootargs} quiet usbcore.autosuspend=-1
    and
  • APPEND ${cbootargs} usbcore.autosuspend=-1

Everytime I saved and restarted the Jetson Xavier. But no effect.

So I removed the changes back to original and created the new file /etc/modprobe.d/usbcore.conf, where I wrote “options usbcore autosuspend=-1”. After restart there was no effect either.

Did I execute your suggestions the right way?
Btw. if I try this:
$ cat /sys/module/usbcore/parameters/autosuspend
It gives out: 2

Finally I wanted to ask you what do you mean by putting USB devices is low power mode? I tried to connect several devices (mouse, keyboard or webcam, which are working) to the USB C ports via female USB to male USB C adapter (this cable is working too). So I would say, that this is a problem with both USB C ports (and not a problem of a device).

Thanks again for your help!

  • The test to see if autosuspend was in effect is to examine “cat /proc/cmdline”. If you see the “usbcore.autosuspend=-1” after modifying APPEND in “extlinux.conf”, then you know this argument was available the moment the kernel loaded.
  • For modules, the “modinfo <module name>” should show this in one of the “parm” lines.

A kernel “cmdline” argument should work for both built in features and module format features if autosuspend is the problem, but the module version of this would only work during a module load. If you see correct content in the “APPEND” plus “cat /proc/cmdline” combination, then I would say disabling autosuspend is not the cause of the problem.

There are other possible issues, but the “usb_suspend_both” error tends to imply a power state issue. Unfortunately, I do not know the specific meaning of “status -16”. Assuming disable of autosuspect did not help, then finding a more specific meaning to “status -16” would be the next step (and I’m hoping someone here from NVIDIA can say what specific error '“status -16” implies).

Hi linuxdev,

thanks again for your reply. I tested "cat /proc/cmdline” (with including your previous suggestions) and got the following output:

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

I am not completely sure if this is the “right” output. Do you have any idea if it should look like this? (If it is the right output then I may assume that autosuspend is not the problem?)

I do not see the “usbcore.autosuspend=-1”, and so I’d say the argument never made its way in (at least not from the “APPEND” key/value pair in “extlinux.conf”). I would not expect this if you made the change via “/etc/modprobe.d/usbcore.conf” (the modprobe mechanism passes an argument only to a particular module, whereas APPEND passes this directly to the kernel and every driver will see this with only interested drivers caring).

If you added this to extlinux.conf, and cmdline fails to show that change, then you might need to add it instead to the device tree “chosen->bootargs” node. I am surprised APPEND did not pass this through, so you might double check if extlinux.conf has this.

Hi linuxdev,

thanks for your reply and your explanations. I repeated (and double checked) the entries I made in usbcore.conf and extlinux.conf. The output does not change. (Same output as above)
Therefore I would like to ask you, what do you mean by adding ’it’ at bootargs? I found this file in /proc/chosen/ but it seems to be a binary file so it can not be opened. Do I need some special compiler for this file? What exactly should I add there?
Thanks again!

“/proc/device-tree/”, and its subdirectory content, is a result of the kernel telling you what it sees from the device tree, and is read-only. If you were to change the device tree node “chosen->bootargs” node in the actual device tree, then the change would be reflected in the mirrored “/proc/device-tree/” content.

The tool for going back and forth between source, binary, and filesystem format is “dtc”. This works the same on all architectures, and so for example, on the Xavier, you could “sudo apt-get install device-tree-compiler”.

Important: Before you overwrite an existing dtb file on your host PC save an unmodified copy somewhere safe.

On your host PC, probably the flashed device tree was “Linux_for_Tegra/kernel/dtb/tegra194-p2888-0001-p2822-0000.dtb” (this may differ depending on carrier board or other details, but as a dev kit this is probably the correct file). You could create a source code version of this binary file:

cd /where/ever/it/is/Linux_for_Tegra/kernel/dtb/
dtc -I dtb -O dts -o tegra194-p2888-0001-p2822-0000.dts tegra194-p2888-0001-p2822-0000.dtb

The tegra194-p2888-0001-p2822-0000.dts could be edited (you’d look for “chosen”, and then the “bootargs” entry, edit bootargs), and then recompiled to dtb format as follows:

dtc -I dts -O dtb -o tegra194-p2888-0001-p2822-0000.dtb tegra194-p2888-0001-p2822-0000.dts

If you were to flash a Jetson which normally uses tegra194-p2888-0001-p2822-0000.dtb, then the flash would put in place your modified version. Changes you made to “bootargs” would appear in “cat /proc/cmdline” and also in “/proc/device-tree/chosen/bootargs”.

During a flash you can expect to lose your existing rootfs partition, and thus this is a bit of a pain. You could clone your Jetson prior to flashing, and then use the cloned image during the flash…you’d still be flashing a new rootfs, but the new rootfs would be an exact copy of the old rootfs. This takes a lot of time and space to have clones sitting around, but by far this is the best backup method and you’d be advised to back up any time you do any kind of flash procedure anyway. If you don’t care about your existing rootfs, then it isn’t an issue.

If you want information on cloning and using clones for restore, just ask.

Hi linuxdev,

thanks a lot for this explanation. It really helps me to understand more details of the Xavier and the structure and function of device trees.
You were right: tegra194-p2888-0001-p2822-0000.dtb is used on my Xavier. It was located at /boot/dtb. I converted it in a .dts file (with the commands you suggested, thanks for that) and added usbcore.autosuspend=-1 in bootargs as shown in the code below:

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;
	};

Is this the right way to add the command?
In the next step I reconverted this .dts file back to a .dtb file.
To apply the changes, the next step would be to flash the kernel? (I am asking that exactly, because I really would like to understand your suggestions correctly)
Because this is the first time, that I have to flash a kernel, I plan to create a clone of the rootfs partition. I do not understand this process completely right now, therefore I will continue reading on this topic and then probably come back with some concrete questions.

Thanks again for your help and time!

Be careful to not use “/boot/dtb” content directly. I say this because in the past the DTB file was always added there, but as time went on over many years of releases, this became signed content in a partition. The “/boot” DTB content is still there due to the script copy still copying, but the particular file is usually not used.

The real running system can be examined via “dtc -I fs -O dts -o extracted.dts /proc/device-tree”, but even this is not completely reliable. The reason is that earlier bootloader stages may edit the original device tree before passing it on to a next bootloader stage. The actual file which would be a match is the one of the same name on the host PC during the flash.

If “tegra194-p2888-0001-p2822-0000.dtb” is the correct file (and there is a good chance this is what was signed and put into a partition…flashing and examining the log would be a better way to find out if you need certainty), then you could perform those steps on the host PC’s version of this file, and then put the replacement back in on the host PC prior to flashing. Maybe this is an exact match to the “/boot” version, but I cannot guarantee this.

Your actual sample modification is indeed what you would need, though I would only leave one space at the end of the string (and I’m not sure if that one space is needed). Two won’t hurt, one might not even matter, but I know that two spaces would be unnecessary in all cases.

Once you boot with this modification in place you should see this show up from “cat /proc/cmdline”.

Hi linuxdev,
thanks a lot for this explanation!
I tested the command dtc -I fs -O dts -o extracted.dts /proc/device-tree (output is here: dts_source.log (52.2 KB)). Do we see here the nodes of the device tree? Is it normal that there are so many warnings inside?

For the procedure of flashing I found some instructions, but in everyone a host machine is needed. So now my question would be, if it is theoretically possible to connect a Xavier with its USB A port to a computer? I tested it and it did not work, but also my cable could be unfitting for this.

Edit: I tested to connect Jetson Xavier via its USB C port in recovery mode and it was connected to the host computer. I had a look on the files saved by SDK Manager on the host, but I could not find the device tree file. But from your suggestions I assume that it should be there?

There is definitely an error there. I couldn’t tell you exactly why, but dtc had basically no valid output when extracting from “/proc/device-tree/”. If you cd to “/proc/device-tree/”, and look around with “ls”, then the structure should more or less match the original device tree used during flash (there could be some edits from earlier boot stages).

Note that warnings alone might not matter, but this is basically the entire file. Are you able to post “extracted.dts” directly after renaming it to “extracted.txt”? Or is this what the log file is?

The only cable useful for flashing from a host is the USB-C cable, and for actual flash steps this is only valid in recovery mode. Generally speaking this is necessary for adding a new device tree (in part because this now goes into a partition, and also because the partition must be signed prior to it going in). The other models of Jetsons tend to use the micro-B USB, but for Xavier use only the USB-C (a type-A host connector is incapable of going into device mode…type-C has extra wiring, and the micro-OTG port on Xavier is not wired for flash…other Jetson models do use the micro-B).

Note that unless you’ve flashed once with JetPack/SDK Manager on your host, or manually unpacked the driver package and sample rootfs, that some of the host side files may appear to be missing although in reality this is not necessarily an error (e.g., some files are copied from reference locations into actual location of use during a flash…reference copies would still be there, but prior to first flash some files may appear to be missing on host side).

Hi linuxdev,

thanks for explaining the USB possibilities to connect the Jetson Xavier to the host machine.
The host machine is actually the machine, on which I installed SDK Manager and flashed the jetson Xavier with.

The file I posted yesterday is the output I recieve in the terminal on Xavier after I entered
dtc -I fs -O dts -o extracted.dts /proc/device-tree
I converted it into a txt file, but by any reason I was just able to upload it as log…

I made my first attempts to backup the Jetson Xaviers image. (I try it with this tutorial) I was able to connect to the Xavier from my host computer with ssh. When I tried to copy the partition mmcblk0p1 with
dd if=/dev/mmcblk0p1 | ssh user@hostpc dd of=/directory/image.raw I recieved the error:
port 22: Invalid argument
Might this be a problem wirh SSHOpenServer? I have it installed on my Xavier. When I tried to configurate SSHOpenServer with
man sshd_config
I got an reply that no manual changes are allowed. Could it be possible, that my filesystem stays in read-only mode after I once set it with
echo u > /proc/sysrq-trigger
in the first steps for the backup with the following code?

Many thanks again for your continouus replies!

What that URL does is to put the rootfs image into read-only mode prior to using dd to copy the entire partition (which is valid and should work). The ssh side is just piping the data from the dd read operation to the dd write operation on a remote system. I have not tried that specific command, but some comments may help. There may be cases where you need to adjust with “sudo”. I personally use private keys for ssh from my PC to Jetsons, and thus no password is used. Additionally, I temporarily activated the root account, added ssh keys for that, and then deactivated the root account again…as a result I can simply “ssh root@xavier_address” and it works without sudo (making ssh development dramatically easier while keeping the root account deactivated). I would actually have to remove my keys to experiment with using sudo directly, so YMMV.

If your Xavier has address “xv” (I’m abbreviating, maybe “xv” is really 192.168.55.1), and the host PC has the address “pc” (also an abbreviation, maybe “pc” is 192.168.55.100), then from the PC side you could use the PC to see and read various commands. For example the host could see the partition sizes with:
ssh user@xv df -H
…and you would see the “df -H” output.

The host could tell dd to run and combine that with the dd line on your PC, and is a rearrangement of what I see you used:
ssh user@xv "dd if=/dev/mmcblk0p1 | dd of=image.raw

I think your earlier command may have been intended as running from the Jetson side (instead of the PC side originating), and this could simplify sudo. A rearrangement which might work (haven’t tested) is something like this:
sudo dd if=/dev/mmcblk0p1 | ssh user@pc dd of=image.raw

Keep in mind that regardless of which side originates the dd command the Jetson side must be in read-only mode to prevent your image from changing in the middle of the stream (which would give you a corrupted copy of the actual partition). This part of your URL is the part where this is accomplished:
sudo echo u > /proc/sysrq-trigger

From the PC side you could try this if you do not want to be logged in to the Jetson:
ssh user@xv sudo echo u > /proc/sysrq-trigger

Keep in mind that the image which is cloned will be the image from a running system with your user logged in. An actual clone using flash.sh and a recovery mode Jetson guarantees that not only is the partition read-only, but also that the state of the partition is without logins. If you had previously logged out and shut down correctly, then your image will reflect this. If you had previously performed an unclean shutdown, then the clone would also reflect this and try to replay the journal upon boot.

Since I cannot directly test, I’ll suggest what may have caused this:

Directly piping content to ssh may have interpreted a “-” in the data as an argument to dd or to ssh. This is where programs like cpio come in handy…they serialize this and essentially stop stray special characters from randomly being interpreted.

If I were to use cpio to edit an initrd (which is a cpio/tar archive filesystem), then it would go something like this (demonstrates unpacking an old initrd and then creating a new initrd from the edited content with cpio in the middle):
https://forums.developer.nvidia.com/t/xbox-360-controller-through-usb-hub-broken-in-jetpack-4-x-works-in-jetpack-3-x-not-enough-host-c/110621/2

For your case take a close look at inserting this in the middle of your pipe prior to going to ssh:
sudo cpio --quiet -H newc -o

Take a close look at adding this to the final write of content at the other side of the ssh:
sudo cpio -idm

These are just inserted in the correct place with piple “|” symbols.

There are other ways to make a safe stream, e.g., rsync works with binary files and streams across two computers.

The simplest way is to just clone with flash.sh. Example if host PC has a lot of spare space (over 35GB) and the Jetson is attached in recovery mode:

sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1

Clones produce both a “.img” file and a “.img.raw” file. The sparse “.img” file is much smaller than the full raw clone, but is mostly worthless since it can only be used for flashing and there is no ability to manipulate or view the content. I throw out the “.img” and keep the “.img.raw”. If I am done using this then I run “bzip2 -9” on it for storage. Due to size even a simple file copy takes a long time, and bzip2 could take a couple of hours.

The raw clone can be loopback mounted, repaired, examined, so on, and then used to directly flash from it. In theory so could the dd version of this, but I would expect more consistent success under corner cases from clone.

Hi linuxdev,
I tried your suggestion of the command sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1 and it seems that worked. Thanks for that!
This command was executed in the directory, where flash.sh is located. In my case it was SDKManager/SDKNvidia/JetPack_4.2.3_Linux_GA_P2888/Linux_for_Tegra (Just for the record and in the case, somebody might have the same issue).
Now I recieved a .raw and a .img file (as you described). I am just a bit wondering, that they are almost equally sized (.img is 29 GB, .raw is 30 GB) Is there any possibility to check, if the copy is done correctly?
From what I read I assume the .raw file contains a copy of the file system? Does that mean, if I flash with this file, the complete directory structure (including for example /home) is recreated?
When I had a look on the Jetson Xavier, there were some more partitions called dev/mmcblk0p*. Is it right, that they can be ignored for doing a clone?
I also found on my host computer the tegra194-p2888-0001-p2822-0000.dtb (as well located in /SDKManager/SDKNvidia/JetPack_4.2.3_Linux_GA_P2888/Linux_for_Tegra/kernel/dtb). After converting to .dts I changed the node chosen from:

chosen {
	bootargs = "console=ttyTCU0,115200";
	board-has-eeprom;
};

to:

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

So now, after reconverting it to .dtb I should do the kernel flash (e.g. this)?
Thanks for your detailed explanation and the suggestion for storing!

An explanation of what a raw and sparse files are may help here. A raw file is literally all of the bytes of the full partition as purely binary data (there is no awareness of ext4 filesystem formatting). A sparse file understands the filesystem type ext4, and does not treat this as purely binary data.

In the sparse file where ext4 is understood the total size of the partition is known, and then blocks of empty parts of the filesystem are discarded…along with metadata about the discarded empty blocks. “Sparse” files are (at risk of being inexact) something like a run length compression when a series of empty spots just have a number, and during flash that number of empty bytes are created by algorithm instead of being stored in memory.

The sparse file, if from a filesystem which is 100% full, will match the raw file. The emptier the filesystem, the smaller the sparse file gets. The raw file will always be an exact byte size no matter what its content is.

If you were to divide the exact byte size of the raw image by 1024, then this is the size in KiB. If you divide twice by 1024, then this is the size in MiB. If you divide three times by 1024, then this is GiB. The flash software accepts sizes only in MiB or GiB increments. If you divide twice by 1024 and this is a non-integer fraction, then the clone was in error. If you can divide the size by 10234 three times, then this too is a valid size. No other sizes are valid so far as the flash.sh script is concerned. The sparse file has no method to validate it.

There is open source software to work with sparse images, but these seem to differ from the method NVIDIA uses, and so I’ve never found any tools which actually have the ability to turn the sparse format of the NVIDIA image into a raw format. The “bootloader/mksparse” program can convert a raw file into a sparse file, but apparently not the reverse.

Note that if you use a clone to restore from, and if the clone does not match the default flash image size, then it might be useful to use the “-S size” parameter to flash.sh to specify the non-default size. Taking your 28GiB as an example:
sudo ./flash.sh -S 28GiB jetson-xavier mmcblk0p1

In a case where your filesystem is so full there wouldn’t be much of a speed advantage by flashing a sparse image. A nearly empty filesystem gets a much faster flash advantage if the sparse image is used (relative to the raw image flash time).

Does your image divide evenly by 1024 at least twice? Then it is valid. I recommend throwing away the sparse image and keeping the raw image.

Your entire rootfs is a 100% match of the clone. If you have not created some custom layout where “/home” is on its own partition, then 100% of everything is there, guaranteed.

Keep in mind that dynamically generated content, e.g., some of the device special files in “/dev”, or “/proc” or “/sys”, are not part of the partition.

You can do this to examine what is there and convince yourself:

cd /mnt/home
ls
df -H -T .
cd
sudo umount /mnt

The other non-rootfs partitions are used for boot. These include a lot of operations which people would not normally customized, for example, operations which a PC might consider BIOS setup. End users here may customize this non-rootfs content when working working with secure boot or making custom drivers which must be active prior to reaching the Linux kernel boot stage. These other partitions can normally be wiped out and restored without risk for default configurations.

The clone is just the rootfs, but just the rootfs is normally all you’d need to worry about during a restore.

For the topic of the device tree some of the details change depending on release. Mostly the way to do this would be to take your modified “.dtb” file and overwrite the PC host’s version of this in its location somewhere in either “Linux_for_Tegra/bootloader/” or “Linux_for_Tegra/kernel/”. Then do a normal command line flash (well, you would put a copy of your “my_backup.img.raw” as “Linux_for_Tegra/bootloader/system.img”, and add the option to “reuse” the image). Something like this if your image is 28GiB:

cd /where/ever/it/is/Linux_for_Tegra/bootloader
cp /where/ever/it/is/my_backup.img.raw /where/ever/it/is/Linux_for_Tegra/bootloader/system.img
cd /where/ever/it/is/Linux_for_Tegra/...either bootloader subdir or kernel subdir.../
cp /where/ever/it/is/custom_dtb.dtb /where/ever/it/is/Linux_for_Tegra/...kernel or bootloader original file...

IMPORTANT: Be careful to save a backup of any device tree you overwrite. You could simply unpack a new one later if you lose one.

Then, from the “Linux_for_Tegra/” location:

sudo ./flash.sh -S 28GiB -r jetson-xavier mmcblk0p1

If you want to log this while you flash, and use the log to verify the correct dtb was used, then you could add this:

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

(the gawk reduces progress bar spam)

if you connect usb-c port J512 of Xavier to host PC
then run
lsusb at the latter
will the Host PC see the Nvidia Corp device?

Press Power button and release
Press Force Recovery button; keep pressing it
Press Reset button and release
Release Force Recovery button
$ lsusb

@Andrey1984 Yes, this works.

@Feee

it seems that you managed to create a raw disc image;
you may like to mount it as a loopback e.g at Host PC:

  1. assign your image to a loop device:
sudo losetup -f $HOME/path/to/disk.img
  1. find the path to that it mounted
sudo losetup -j $HOME/path/to/disk.img
/dev/loop0: [xxxx]: (/home/path/to/disk.img)
3. mount the device to folder
sudo mount /dev/loop0p1 /mnt

However, it seems that you should be able to flash the jetson with sdkmanager if that will be required.

Hey @Andrey1984,
thanks for your suggestion.
Yes, I assume flashing with sdk manager should work.
I do not completely understand what is the advantage of mounting the image (Do you mean .img or .raw file in your upper post?). Is it done instead of flashing?
@linuxdev I am reading your post right now, will take some time…