Failure to flash Jetson Orin Nano Devkit, currently bricked

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
,
1

Having real trouble getting my Orin Nano devkit back to life.

I started off with using the SD card flashed images, upgrading as instructed. That all worked great.

I then decided that I wanted to install to an NVME drive (P5 Plus Gen4 x4). That didn’t work. At this point, I’m trying to get to any working state. I’ve tried the jp62-orin-nano-sd-card-image.zip, JP513-orin-nano-sd-card-image_b29.zip (both flashed with balena), and neither image gets me to even see the nvidia UEFI splash screen.

There are a number of things I’ve tried at this point (manual flash.sh, different NVMEs, flashing to USB, flashing to SD), etc etc, but I’ll keep it brief:

Trying to flash 6.2 or 6.1 in SDK Manager has been less than fruitful. I’ve got a UART attached, and I’m seeing some messages that look concerning, and I’m not sure how to work around:

In particular, on the UART I see (in no particular order, just snippets):

[0003.099] W> Firewall readback mismatch
…
I> Secondary storage device: SDMMC_BOOT instance: 3
E> Error in command_complete 18001 int_status
E> OCR failed, error = 39390706
E> STORAGE: Failed to open SDMMC: 3.
W> Ignoring init failure for device 0-3
I> Secondary storage device: SDMMC_USER instance: 3
E> Error in command_complete 18001 int_status
E> OCR failed, error = 39390706
E> STORAGE: Failed to open SDMMC: 3.
W> Ignoring init failure for device 1-3
I> Secondary storage device: QSPI_FLASH instance: 0
…
I> Populate eeprom info for module cvm
I> dump bct
I> strt_pg_num(0) num_of_pgs(16) read_buf(0x40071738)
E> LOADER: Invalid value Header magic.
E> Validation failed for 1 copy of BRBCT @ 0
I> strt_pg_num(512) num_of_pgs(16) read_buf(0x40071738)
E> LOADER: Invalid value Header magic.
E> Validation failed for 2 copy of BRBCT @ 262144
I> strt_pg_num(1024) num_of_pgs(16) read_buf(0x40071738)
E> LOADER: Invalid value Header magic.
E> Validation failed for 3 copy of BRBCT @ 524288
I> strt_pg_num(1536) num_of_pgs(16) read_buf(0x40071738)
E> LOADER: Invalid value Header magic.
E> Validation failed for 4 copy of BRBCT @ 786432
E> NV3P_SERVER: Failed to get address for br bct from nv3p helper.
I> Rebooting : reboot-recovery
…
�NOTICE: BL31: v2.8(release):e12e3fa93
NOTICE: BL31: Built : 17:14:28, Jan 7 2025
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 4.2 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Wed Jan 4
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecturl
I/TC: Primary CPU initializing
I/TC: Test OEM keys are being used. This is insecure for shipping products!
I/TC: fTPM ID is not enabled.
I/TC: ftpm-helper PTA: fTPM DT or EKB is not available. fTPM provisioning is n.
I/TC: Primary CPU switching to normal world boot
��
JetsonMinimal UEFI firmware (version 36.4.3-gcid-38968081 built on 2025-01-0)
…
[ 7.366272] tegra-qspi 3270000.spi: Adding to iommu group 9
[ 7.366781] tegra-qspi 3270000.spi: Prod config not found for QSPI: -19
[ 7.367843] spi-nor spi0.0: mx25u51279g (65536 Kbytes)
[ 8.386195] using random self ethernet address
[ 8.386200] using random host ethernet address
[ 11.277580] usb usb2-port2: Cannot enable. Maybe the USB cable is bad?
[ 11.277606] usb usb2-port2: config error
[ 15.349581] usb usb2-port2: Cannot enable. Maybe the USB cable is bad?
[ 15.349785] usb usb2-port2: config error
[ 15.350119] usb0: HOST MAC 26:b5:79:65:18:c6
[ 15.350123] usb0: MAC 8a:03:1d:ff:dc:36
[ 15.351940] tegra-xudc 3550000.usb: EP 0 (type: ctrl, dir: out) enabled
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1# [ 15.832121] tegra-xudc 3550000.usb: EP 5 (type: intr, dir: in) end
[ 15.832141] tegra-xudc 3550000.usb: EP 3 (type: bulk, dir: in) enabled
[ 15.832153] tegra-xudc 3550000.usb: EP 2 (type: bulk, dir: out) enabled
[ 15.832271] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 19.421551] usb usb2-port2: Cannot enable. Maybe the USB cable is bad?
[ 93.153983] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 94.176626] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 95.200809] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 96.223771] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 97.248927] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 98.272703] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 99.296409] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 100.320333] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 101.344888] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 102.368368] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 103.392359] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 104.416733] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
[ 105.440501] NFS: state manager: check lease failed on NFSv4 server fc00:1:13
…

Thughts? Ideas?

SDKM_logs_JetPack_6.2_Linux_for_Jetson_Orin_Nano_[8GB_developer_kit_version]_2025-03-01_15-42-14.zip (550.3 KB)
serial_log_SD_6_2.txt (159.7 KB)

2

Also:

This is on a 22.04 Laptop. I’ve tried multiple ports (USB C - USB C, USB C - USB A, USB C - Hub - USB A - USBC), etc etc.

I saw a bug that complained about USB being powered down, so I attached (and tried without) a keyboard and mouse attached to the USB A ports. I do notice that they don’t get powered up until a later stage in the flashing. I also think those are the “USB Cable Bad?” points – in a previous flashing attempt, I disconnected and reconnected the KB/M.

Also; this SDK install has managed to flash an Orin AGX dev kit without much fuss.

3

OK, I’ve made some progress.

Was able to use sudo ./tools/kernel_flash/l4t_initrd_flash.sh -p "--no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml" --network usb0 jetson-orin-nano-devkit nvme0n1p1 to at least flash QSPI. Flashing the SD card manually using balena-etcher and the 6.2 image resulted in a working system.

Some gripes.

  1. please have some sort of timeout or progress bar for all stages. For example, running sudo ./flash.sh jetson-orin-nano-devkit nvme0n1p1 ended up stuck (I think? I waited for 15 minutes without any additional progress) on [ 8.1940 ] tegrarcm_v2 --chip 0x23 0 --oem platformdetails storage storage_info.bin. I happened to have the UART open, and saw it was showing:

I> QSPI Flash: Macronix 64MB
I> QSPI-0l initialized successfully
I> Secondary storage device: QSPI_FLASH instance: 0
I> Secondary storage device: SDCARD instance: 0
E> Error in command_complete 18001 int_status
E> Sending CMD_SD_SEND_IF_COND failed
E> Error opening sdcard-0
E> STORAGE: Failed to initialize device: 6, instance: 0.
C> Secondary storage init failed
C> Task 0x0 failed (err: 0x39390706)
E> Top caller module: SDMMC, error module: SDMMC, reason: 0x06, aux_info: 0x07
I> Busy Spin

Not sure why it’s expecting an SDMMC card, but I assume this meant it was truly stuck, so I gave up. Without the UART, I’d have no way of knowing.

  1. To my sleep deprived brain, it’s not that clear that $ sudo <env-var> ./tools/kernel_flash/l4t_initrd_flash.sh [ -S <rootfssize> ] -c <config> --external-device nvme0n1p1 --direct <nvmeXn1> <board> external is attempting to overwrite the NVME drive on the host PC, rather than the NVME on the Jetson board… While in hindsight, reading the documentation does suggest this, it would be nice to have a “This command will erase /dev/nvme0n1p1 attached to this PC. Do you wish to continue Y/N?” …

  2. Please. Please: On pages such as Flashing Support — NVIDIA Jetson Linux Developer Guide 1 documentation , please have a banner at the top saying “ARCHIVED DOCUMENTATION; Current version of page: ”. Or even better, a drop down with different revs (r35, r36, etc). This would save so much time when following old forum posts that point to outdated pages.

  3. "For more information, read Workflow 3 in the README_initrd_flash.txt file, which is in the Linux_for_Tegra/tools/kernel_flash directory." Why not just include that “more information” in the document as a collapsible section? Or include a link to github / whatever repo? This is a bit of a nitpick, but its frustrating when you have multiple potential flashing scripts, each with a different way of doing things, and then multiple references to separate documents, each with yet another slightly different take on the same thing…

======

I’m still not at a stage where I have yet successfully flashed the NVME while it’s in the Jetson. I don’t understand why the SDK manager / flash.sh seem to fail.

At least I’m able to get back to a point in which it isn’t completely bricked.

5

OK, for those in a similar situation to me, this is how I flashed the NVME drive. Note that this is after the unbricking mentioned above (QSPI flashed, SD card flashed with balena-etcher, was able to boot in that configuration). For the steps below, the SD card is removed.

  1. Use a USB caddy with the drive, connect to host PC, format ext4.
  2. In my case, the USB caddy showed up as /dev/sdc → I pointed the flashing utility at the first partition sdc1 using this command: ~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh -c tools/kernel_flash/flash_l4t_t234_nvme.xml --external-device nvme0n1p1 --direct sdc1 jetson-orin-nano-devkit-super external
  3. Once done, insert drive back into the nano. Et voila, a working system.
  4. You can now use sdk-managerto update/flash all the other goodies on there if needed.

Alternatively:

  1. With the NVME drive in the jetson, run

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk0p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 jetson-orin-nano-devkit-super internal

6

Hi,

Glad your original issue resolved.

About the super mode issue, please file a new topic and we will review it.

Thanks

8

Realized that jetson-orin-nano-devkit should be jetson-orin-nano-devkit-superin the instructions above. Editing accordingly.

Still not really understanding why SDK Manager broke so completely…