Jetson Orin Dev-kit: Failing flash when nvme storage device is selected

Have you validated this nvme drive on some other jetson platforms like jetson Xavier NX + jetpack4.x?

Orin is the only Jetson board I possess so no. I’m terms of validation of the SSD, I was able to format the drive with an ext4 file system after attaching it to Orin so I assume it works.

Ok, so Orin is able to detect and mount that drive if Orin boots from emmc and with nvme connected?

1 Like

Yes no issues there. Disk manager on Ubuntu has no issues with it.

We will check if we can have same nvme drive to reproduce your issue and debug. Thanks.

1 Like

BTW, can you flash emmc case with sdkmanager?

I thought about doing that but didn’t proceed in case something else was wrong so I could still have a working system.

Can you validate that too? If that goes wrong then flashing nvme may also go wrong.

We are sure that nvme could be flashed by sdkmanager because we just tested that today. But if you are totally new to this, then you better validating sdkmanager can even flash the emmc case first.

emmc flash success. I can boot into the OS and Ubuntu starts the OEM setup process. I can also see the ssd in disk manager (UUID and serial number present).

What’s odd is sdkmanager now always knows the serial device is present… Before this flash serial was never connected until I manually put it in recovery mode.

Gonna try a reflash of nvme now… Maybe the solution is to always flash the latest known good image to emmc?

1 Like

Tried the reflash on nvme and no luck I saw a bunch of write errors:

Module will still boot from eemc

During the timeout loop waiting for the board to boot up, My module start softly beeping (fan appears to be trying to rotate every time it beeps) and the monitor woke up from sleep again.

Could you also try the script tool directly?

1. $ cd ~/nvidia/nvidia_sdk/JetPack_5.0.1_DP_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra
2. Put device into recovery mode
3. $ sudo ./nvsdkmanager_flash.sh --storage nvme0n1p1

Looks to be the same result. Log is attached:

manual_script_run.log (230.0 KB)

If possible can you provide the uart log?

1 Like

Sure I can try and collect that. When I plug in the micro b cable I get ttyACM0-3 on my host OS. I’m guessing the debug console is ACM0? Also do you have insight on if hardware/software flow control should be enabled in the minicom config file?

It is ttyACM0. You don’t need to care about flow control if you just collect the log. I can set both to ‘no’

1 Like

Followed instructions posted by WayneWWW above for manual flash. UART log and flash.sh log attached:

nvme_flash_with_uart_log.tar (270 KB)

I can also tar the build artifacts dir from sdkmanager if needed

Hey @WayneWWW,

I solved this actually by unplugging my 4K monitor during the flash process as per this post (UART log showed the same error as OP. Only issue is I have to keep the DP cable unplugged until the system is booted fully:

How often is sdkmanager updated and will the next update include this fix?

Thanks for your help through this!

You mean your monitor affects the flash of nvme drive?

Yes but only because of the bug I linked in my last post. In reality there isn’t anything wrong with your nvme flashing scripts.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.