I used the SDK manager to flash the Jetpack 6.2 onto the Jetson Orin Nano Dev. Kit 8GB. The SDK manager is installed on Ubuntu 24.04 LTS. However, after flashing the kernel, the host computer could not detect the Jetson board when prompted to enter the Jetson’s IP, username, and password. I also tried running lsusb and sudo dmesg -w on the host computer, but there was no response.
Could you access device through minicom or plug the monitor with your Orin Nano?
Also change other cable supporting data transfer to check whether lsusb can succeed to detect.
Same here, I’ve been struggling for 4 days in a row to flash 6.2. Version 5.1.4 flashes well but for 6.2 it goes up to a certain point when it says it waits for the board to boot up, then times out. On the UART side, the board boots but but is not detected by sdkmanager and eventually ends up in the UEFI prompt.
I think I may not have described it precisely, so I’d like to clarify with more details.
The kernel image flash, including in-tree and out-of-tree modules as well as DTBs, was successfully completed using both the SDK Manager and manual build-and-flash methods. The Jetson Orin Nano Developer Kit board can now be used normally. Therefore, I don’t believe there is any issue with my USB-C cable.
In JetPack 5.x, when the USB-C cable is connected to the host computer while the board is booting normally, the host detects it as an external storage device. You can then mount the partition to access the data on the board.
In this state, the SDK Manager can be used to install additional packages such as CUDA, cuDNN, and nvidia-jetpack, but it cannot flash the kernel image since the board is not in force recovery mode. Users only need to provide the IP, username, and password of the Jetson board, and the SDK Manager will handle the installation of additional packages using apt install.
However, this does not work at all in JetPack 6.2. When the board is booted normally, the host computer cannot detect it. The board does not appear in the output of lsusb on the host, sudo dmesg -w shows no response when plugging or unplugging the board, and it is not listed under /dev/ttyUSB* or /dev/ttyACM*. Therefore, we cannot access the board via minicom, mount it to retrieve data, or install packages using the SDK Manager.
What I want to know from this forum is how to make the Jetson board’s USB-C function the same way in JetPack 6.2 as it did in JetPack 5.x.
Yes, the host successfully detected the board, and the output of lsusb is shown below:
Bus 001 Device 025: ID 0955:7523 NVIDIA Corp. APX
Note that since the board is now in force recovery mode, the SDK Manager cannot access the board via SSH and, as a result, cannot install packages, even though it can detect the board.
This cannot be done in force recovery mode, so we will skip this part.
Yes, when plugging the board into the host, the output of sudo dmesg -w includes:
[12538.591393] usb 1-1.1: new high-speed USB device number 36 using xhci_hcd
[12538.694485] usb 1-1.1: New USB device found, idVendor=0955, idProduct=7523, bcdDevice= 4.01
[12538.694490] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12538.694491] usb 1-1.1: Product: APX
[12538.694492] usb 1-1.1: Manufacturer: NVIDIA Corp.
When unplugging the board from the host, the output of sudo dmesg -w includes:
[12632.282282] usb 1-1.1: USB disconnect, device number 36
Normally Booting
No.
This is the log from sudo dmesg | grep usb on the Orin Nano device: usb.log (5.4 KB)
No, the output of sudo dmesg -w on the host remains unchanged.
Then could you dump your log based on pure sdkmanager result?
As David already told, we don’t see such error on our side and we are using sdkmanager image everyday.
I need your log based on this image first to make sure there is nothing broken on your board.
After this is confirmed then we can check your github steps. Is it okay for you?
Sure, I can flash another Jetson Orin Nano board using only the SDK Manager.
Additionally, this board is running JetPack 6.1, and the host can retrieve data from the board via USB-C normally when the board is booted normally. Below is the log from sudo dmesg -w on the host:
[19396.215661] usb 2-1.1: new SuperSpeed USB device number 4 using xhci_hcd
[19396.231813] usb 2-1.1: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[19396.231816] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[19396.231816] usb 2-1.1: Product: Linux for Tegra
[19396.231817] usb 2-1.1: Manufacturer: NVIDIA
[19396.231818] usb 2-1.1: SerialNumber: 1421523024193
[19396.240480] rndis_host 2-1.1:1.0 eth0: register 'rndis_host' at usb-0000:00:14.0-1.1, RNDIS device, 4a:ba:bc:00:36:b4
[19396.242015] cdc_acm 2-1.1:1.2: ttyACM0: USB ACM device
[19396.242760] usb-storage 2-1.1:1.4: USB Mass Storage device detected
[19396.243079] scsi host8: usb-storage 2-1.1:1.4
[19396.268036] cdc_ncm 2-1.1:1.5: MAC-Address: 4a:ba:bc:00:36:b6
[19396.268154] cdc_ncm 2-1.1:1.5 eth1: register 'cdc_ncm' at usb-0000:00:14.0-1.1, CDC NCM (NO ZLP), 4a:ba:bc:00:36:b6
[19396.274148] rndis_host 2-1.1:1.0 enx4ababc0036b4: renamed from eth0
[19396.275379] cdc_ncm 2-1.1:1.5 enx4ababc0036b6: renamed from eth1
[19397.247772] scsi 8:0:0:0: Direct-Access Linux File-Stor Gadget 0515 PQ: 0 ANSI: 2
[19397.248050] sd 8:0:0:0: Attached scsi generic sg0 type 0
[19397.248902] sd 8:0:0:0: Power-on or device reset occurred
[19397.251287] sd 8:0:0:0: [sda] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[19397.251691] sd 8:0:0:0: [sda] Write Protect is on
[19397.251693] sd 8:0:0:0: [sda] Mode Sense: 0f 00 80 00
[19397.252090] sd 8:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[19397.263661] sda:
[19397.263684] sd 8:0:0:0: [sda] Attached SCSI removable disk
When unplugging the board from the host, the output of sudo dmesg -w includes:
[19600.810662] usb 2-1.1: USB disconnect, device number 4
[19600.810834] rndis_host 2-1.1:1.0 enx4ababc0036b4: unregister 'rndis_host' usb-0000:00:14.0-1.1, RNDIS device
[19600.877724] cdc_ncm 2-1.1:1.5 enx4ababc0036b6: unregister 'cdc_ncm' usb-0000:00:14.0-1.1, CDC NCM (NO ZLP)
Also, the log for lsblk on the host includes:
sda 8:0 1 16M 1 disk
Please wait a moment while I flash the pure JetPack 6.2 kernel image.
I switched to a simple USB-A to USB-C cable, and it worked properly. I have no idea why this happened.
This A-to-C cable came from our depth camera, and it is working fine now.
The original cable I used was a PHILIPS DLC4585C USB-C to USB-C cable. It works properly for everything except communication between the host computer and JetPack 6.2.
Yes, and I also tested this PHILIPS cable by connecting the host computer to my iPad, but it failed.
Then, I switched to the USB-A to USB-C cable, and it worked properly.
Finally, I switched the USB-A to USB-C adapter from the left one to the right one, and the PHILIPS USB-C to USB-C cable worked properly for both JetPack 6.2 and my iPad.
The only difference between these two USB-A to USB-C adapters is that the left one is USB 3.2 Gen 1, while the right one is USB 3.2 Gen 2.
I still find it bizarre that the original setup only worked properly in specific situations. Anyway, changing the USB-A to USB-C adapter solved all the problems.
I apologize for wasting your time on debugging this.