Jetson Developer Kit Operating Software installation problem

I had some problems installing the latest Jetson Linux 36.2 in the **JetPack 6.0 DP ** on my Jetson Orin NX 16G board. I hope someone can help me.

Some Information

  1. I’m using a standalone Ubuntu 22.04 system on my host PC (not a Docker container).

    # uname -a
    Linux ax-MS 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct  9 15:34:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
    # dpkg -l | grep sdkmanager
    ii  sdkmanager 2.0.0-11405 amd64 NVIDIA SDK Manager
  2. I’ve used Jetpack 5.11 before, so I’m sure my board’s hardware is fine (except that I’m trying to install the latest system on a new NVME SSD because I want to preserve my previous data on the old SSD).

  3. I have followed both the sdkmanager and the developer guide tutorial. Both methods failed. And their error messages seem quite similar.

  4. To streamline my flash process, I wrote my scripts following the developer guide tutorial.

    tar xf ${L4T_RELEASE_PACKAGE}
    sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/
    cd Linux_for_Tegra/
    # build binary files
    sudo ./
    # Check the prerequisites environment
    sudo ./tools/
    sudo ./tools/kernel_flash/ --external-device nvme0n1p1 \
      -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
      --showlogs --network usb0 jetson-orin-nano-devkit internal

    here’s my download folder structure:

Errors from sdkmanager

Detailed output from the scripts in 4
log1.log (268.8 KB)

Logs exports by sdkmanager (173.3 KB)

For the sake of this post to help more people.

I’ll make a quick summary here, these errors were caused by Jetson not recognizing my flash cable at some stage of the flash process (not sure which one).

Even though the sdkmanager and the flash scripts can detect the board in a recovery mode in the early stages of the flash process. For example:
The sdkmanager can detect the specific board model.
Using the lsusb command shows some correct info like this:

Bus 001 Device 082: ID 0955:7323 NVIDIA Corp. APX.

The solution is simple, I changed the cable to a (USB2.0->typec) one and the whole flash process went on seamlessly!

Thanks again for WayneWWW’s help (never thought someone would spend their precious weekend solving my problem)!


Could you help use this method to dump the serial console log from device side when flash failure?

I connected the debug serial port and re-ran the installation. Here’s the output from both the terminal and the debug serial port.

Terminal: (173.7 KB)
sdkmanager_uart_debug_output_2 (copy).log (94.8 KB)

terminal_output_2.log (252.1 KB)
uart_debug_output_2 (copy).log (77.6 KB)

please add this patch to Linux_for_Tegra/tools/kernel_flash/initrd_flash/

        echo "${cfg_str:1}" > "${cfg}/strings/0x409/configuration"

  +     echo on > /sys/bus/usb/devices/usb2/power/control
        echo "${udc_dev}" > UDC

And flash again.

Thanks for the reply.
I think the patch should be added to the function set_up_usb_device_mode(), like the following.

And here is the new output:
terminal_script_output_3.log (251.2 KB)
uart_debug_output_3.log (76.5 KB)


Could you help check whether that “/sys/bus/usb/devices/usb2/power/control” node really has “on” in the initrd by using your uart console?

No problem, but I haven’t used a serial port for debugging before, can you tell me how to do it?

It is just a terminal. You can cat the node when the flash process got stuck in initrd.

Seems like it has on.

Is there anything else I can check? I’m now running the terminal.

If there are any other ideas worth trying, just let me know and I’ll get back to the topic as soon as possible.

busybox devmem 0x3520360
busybox devmem 0x355003c

Please help share above register values.

Please also try one more test. Plug any usb device to the usb hub of your jetson devkit and run flash process again. This is separate tests from above register dump.

For example, a usb mouse or keyboard.

Sorry for my late reply, here are the results, and I’ll provide the other test soon.

I haven’t done a second test yet, but just now, after I plugged in the keyboard, the terminal immediately returned some messages like the following, and they might be helpful:

After you plug the keyboard, could you also hotplug your flash cable and see if anything new printed?

Oh, I just re-edit my reply, can you see it?

I already saw that. I mean the flash cable. Not the keyboard.

Unfortunately, nothing happened. Maybe this is the reason?

Yes, that is the reason. Please also try the previous test too.

If it still fails, then we have some workaround method to flash.

With the keyboard plugged in, the installation failed too, what should I do next?

Note: The left panel is the terminal output, and the right panel is the Uart output.

If the flash still failed, please use the workaround in this post. We will use your register value for further debug. Thanks.

OK, thanks for the share.
I have three models of the new SSD in my hand right now, and I’ll try them all, but they’re all new PCIE 4.0 models so I can’t guarantee their compatibility. I’ll share their results later.
By the way, do you have any recommendations for hard drives with good compatibility?