Can't Flash Jetson Orin Nano - SSH Server Never Starts

I’m trying to Flash a Jetson Orin Nano 8GB Development Kit. I have used the following approches:

  1. Flashing a SD Card with BalenaEtcher with jp60-orin-nano-sd-card-image.zip and putting the SD Card inside the device. Unfortunately the device ends up in a black screen mode and nothing changes.

  2. Using the NVIDIA SDK Manager. This approach downloads the necessary files and attempts to flash the Jetson. To do it, I had to put the device into the Forced Recovery Mode using a jumper. The flashing seems to finish successfully and the Jetson resets and then the NVIDIA SDK Manager tries to connect to the SSH Server on the Jetson. Unfortunately the SSH Server never starts and after too many attempts, the SDK manager fails to flash the device.

I’m uploading the Log files of both the SDK Manager and the Serial Console log here.
What should I do?

SDKM_logs_JetPack_6.0_(rev._2)_Linux_for_Jetson_Orin_Nano_modules_2024-07-01_18-04-46.zip (1013.4 KB)
Jetson Orin Nano Serial Log - Flashing From Scratch.txt (86.8 KB)

Could you take a photo of your board? Is it a brand new?

Here’s the image:

Would you mind flashing your board with jetpack5.1.3 first? Just a test.

Thanks for the quick replies.

I have also done this and the result was the same as with the Jetpack6. If you want, I can do it again just to get the logs for the Jetpack5.1.3.

Please try other kind of usb type C cable too.

Also, please share me the log when using jetpack5.

Here’s the log for JetPack_5.13:

Jetson Orin Nano Serial Log - Flashing From Scratch.txt (158.3 KB)
SDKM_logs_JetPack_5.1.3_Linux_for_Jetson_Orin_Nano_modules_2024-07-01_21-00-27.zip (1.3 MB)

Each line of your UART log is truncated. Could you adjust your terminal size and dump again…

Sure.

In the mean time, the following logs are also from booting the device using an SD Card flashed by Balena Etcher.

The first log is from when the system starts with Forced Recovery Mode and the second log is from when the system starts without Forced Recovery Mode. In the second case, the system ends up printing this over and over:

** 1121 printk messages dropped **
[ 9.051750] tegra-nvenc 154c0000.nvenc: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 115200000, volt: 0, enabled: 1. New: freq: 115200000, volt: 0, enabled: 1
** 163 printk messages dropped **
[ 9.052089] tegra-nvenc 154c0000.nvenc: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 115200000, volt: 0, enabled: 1. New: freq: 115200000, volt: 0, enabled: 1
** 193 printk messages dropped **
[ 9.052446] tegra-nvenc 154c0000.nvenc: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 115200000, volt: 0, enabled: 1. New: freq: 115200000, volt: 0, enabled: 1
** 158 printk messages dropped **

Jetpack_6_With_BalenaEtcher_ForcedRecoveryMode.txt (56.1 KB)
Jetpack_6_With_BalenaEtcher_NoForcedRecoveryMode.txt (107.6 KB)

Hi,

I just want to clarify some points because it seems you are a total newbie here.

  1. You should not see any log in “recovery mode”. The log will only appeared when the flash process starts.
    Any log shown in recovery mode only indicates one point: you are actually not in recovery mode.

  2. The flash error has nothing to do with the log you just shared.

  3. The log you just shared gives some points that your system is using rel-35.3.1 bootloader but your sdcard has rel-36.3 image and that leads to problem.
    Thus, actually you could use Balena Etcher to flash a rel-35.3.1 image to your sdcard and insert it to the board and see if it can boot.

  4. if (3) can boot, we can do some tests to check why flash process does not work.

Thanks for the detailed info.

  1. I don’t see any log in the Forced Recovery Mode state but when the NVIDIA SDK Manager starts to flash the device, the logs starts showing up.

  2. The recent log I just shared was not related to the Flashing of the device but was related to starting the device with an SD Card flashed using Balena Etcher.

  3. I’m going to start doing this. I’m downloading the jp511-orin-nano-sd-card-image.zip SD Card Image from https://developer.nvidia.com/embedded/jetpack-sdk-511 which seems to have the Jetson Linux 35.3.1 BSP image and then will flash it using Balena Etcher and upload its logs here.

Thanks for the information.

I tried flashing the SD Card with jp511-orin-nano-sd-card-image.zip which has Jetson Linux 35.3.1 BSP and the boot succeeded and I was redirected to the Ubuntu Installation page.

Nevertheless, flashing with versions higher than 5.11 fails.

Here’s the log:

Jetpack_5.11_With_BalenaEtcher.txt (89.4 KB)

Could you finish the account setting on Jetson and connect the type C cable to your jetson and the host PC you are using to flash and then share the uart log?

Yes. I finished setting up Jetpack_5.11 and its Ubuntu on the Jetson and then used NVIDIA SDK Manager to flash the Jetson which failed.

Here are the logs:

Jetpack6_Flash_With_NVIDIA_SDK_MANAGER_AFTER_Sucessful_Jetpack_5.11_Boot.txt (89.5 KB)
SDKM_logs_JetPack_6.0_(rev._2)_Linux_for_Jetson_Orin_Nano_modules_2024-07-02_16-25-47.zip (1.7 MB)

No… I didn’t ask you to flash the board by using sdkmanager…

I just told you to boot up the board and connect usb cable. That’s all…

Just to clarify what we are doing now… Your flash process always failed in detecting usb device mode (Jetson is a usb device in this case) from your host PC.

What we are doing now is “ok, we don’t flash board. We just boot up the board first and check what is going on with usb device mode”…

And another clarification… Balena Etcher "does not " really flash anything to your board.

Balena Etcher succeeded does not represent you can flash old BSP…
That is, I believe your sdkmanager cannot even flash your board with jetpack5.1.1…

I am only using Etcher to let you boot up first so that we can check what is going on with usb device mode.

Thanks for the clarification. I booted up the system into Ubuntu and then connected the USB Type C to the device while getting the UART log. Unfortunately nothing was sent to the log console. But to make sure if the connection has been made between the Host PC and the Jetson, I ran NVIDIA SDK Manager and it could detect the Jetson.

Here’s an screenshot:

I also booted up the system twice with the USB Type C cable connected and unconnected and took the logs in case they were needed:

Jetpack_5.11_Sucessful_Boot_USB_Type_C_Was_Connected_After_Login.txt (89.9 KB)
Jetpack_5.11_Sucessful_Boot_USB_Type_C_Was_Connected_From_The_Start.txt (93.5 KB)

Thanks

Are you saying that when you hotplug the type C cable on your jetson and dump dmesg command then there won’t be new log printed out from that?

I mean, hotplug the type C cable and check if dmesg has any new log from xudc driver.

Sure, here’s the log of dmesg after connecting the USB Type C cable:

[ +12.670967] fusb301 1-0025: fusb301_work_handler: int_sts[0x05]
[  +0.001302] fusb301 1-0025: sts[0x1f], type[0x08]
[  +0.000012] fusb301 1-0025: fusb_update_state: 6
[  +1.821398] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[  +0.000030] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[  +0.000017] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[  +0.000102] tegra-xudc 3550000.xudc: EP 9 (type: intr, dir: in) enabled
[  +0.000018] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[  +0.000015] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
[  +0.000142] tegra-xudc 3550000.xudc: EP 15 (type: intr, dir: in) enabled
[  +0.000184] l4tbr0: port 1(rndis0) entered blocking state
[  +0.000007] l4tbr0: port 1(rndis0) entered forwarding state
[  +0.000207] IPv6: ADDRCONF(NETDEV_CHANGE): l4tbr0: link becomes ready
[  +0.008260] tegra-xudc 3550000.xudc: EP 13 (type: bulk, dir: in) enabled
[  +0.000021] tegra-xudc 3550000.xudc: EP 8 (type: bulk, dir: out) enabled
[  +0.000195] l4tbr0: port 2(usb0) entered blocking state
[  +0.000008] l4tbr0: port 2(usb0) entered forwarding state
[  +0.002293] tegra-xudc 3550000.xudc: ep 13 disabled
[  +0.000109] tegra-xudc 3550000.xudc: ep 8 disabled
[  +0.017988] tegra-xudc 3550000.xudc: EP 13 (type: bulk, dir: in) enabled
[  +0.000018] tegra-xudc 3550000.xudc: EP 8 (type: bulk, dir: out) enabled
[  +1.099401] tegra-xudc 3550000.xudc: ep 13 disabled
[  +0.000157] tegra-xudc 3550000.xudc: ep 8 disabled
[  +0.055703] tegra-xudc 3550000.xudc: ep 3 disabled
[  +0.000038] tegra-xudc 3550000.xudc: ep 2 disabled
[  +0.000022] tegra-xudc 3550000.xudc: ep 5 disabled
[  +0.000018] tegra-xudc 3550000.xudc: ep 4 disabled
[  +0.000014] tegra-xudc 3550000.xudc: ep 7 disabled
[  +0.000058] tegra-xudc 3550000.xudc: ep 9 disabled
[  +0.000029] tegra-xudc 3550000.xudc: ep 15 disabled
[  +0.000062] tegra-xudc 3550000.xudc: ep 11 disabled
[  +0.000019] tegra-xudc 3550000.xudc: ep 6 disabled
[  +0.230071] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[  +0.000020] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[  +0.000014] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[  +0.000079] tegra-xudc 3550000.xudc: EP 9 (type: intr, dir: in) enabled
[  +0.000014] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[  +0.000012] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
[  +0.000033] tegra-xudc 3550000.xudc: EP 15 (type: intr, dir: in) enabled
[  +0.000016] tegra-xudc 3550000.xudc: EP 11 (type: bulk, dir: in) enabled
[  +0.000017] tegra-xudc 3550000.xudc: EP 6 (type: bulk, dir: out) enabled
[  +0.004023] tegra-xudc 3550000.xudc: EP 13 (type: bulk, dir: in) enabled
[  +0.000014] tegra-xudc 3550000.xudc: EP 8 (type: bulk, dir: out) enabled
[  +0.001738] tegra-xudc 3550000.xudc: ep 13 disabled
[  +0.000075] tegra-xudc 3550000.xudc: ep 8 disabled
[  +0.020182] tegra-xudc 3550000.xudc: EP 13 (type: bulk, dir: in) enabled
[  +0.000019] tegra-xudc 3550000.xudc: EP 8 (type: bulk, dir: out) enabled