Can not flash or boot Orin Nano 8gb developer kit to SD or nvme

If there is a current best recommended method to flash Orin Nano 8gb developer kit?

I’ve tried sdkmanager dp6 and 5.1.2, flash.sh, l4t_initrd_flash.sh to both sd card and nvme0n1.
I’ve also tried l4t_initrd_flash.sh with ----no-systemimg and that at least finally appeared to succeed at flashing bootloader/generic/cfg/flash_t234_qspi.xml. But OrinNano still won’t boot even with dp6 sdcard. or
JetPack_6.0_DP.zip (51.8 KB)
jetson_board_spec.cfg.txt (7.0 KB)
flash_1-6.1_0_20240215-141451.log (9.2 KB)

This was emitted by flash.sh
Board ID(3767) version(300) sku(0005) revision(L.1)
Chip SKU(00:00:00:D5) ramcode(00:00:00:02) fuselevel(fuselevel_production) board_FAB(300)
ECID is 0x80012344705E36436400000009018040

and that does not seem to match the orin nano 8gb from JetPack_6.0_DP_Linux_DP_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/ jetson_board_spec.cfg

jetson-orin-nano-devkit:

# orin-nano 8GB

‘boardid=3767;fab=000;boardsku=0003;boardrev=;chiprev=;board=jetson-orin-nano-devkit;rootdev=mmcblk3p1;bup_type=kernel’
‘boardid=3767;fab=000;boardsku=0005;boardrev=;chiprev=;board=jetson-orin-nano-devkit;rootdev=mmcblk3p1;bup_type=kernel’

for jetpack6, please check this post when you hit flash failure with nvme. (jetpack5 has no such error)

I did everything discussed in the referenced postings and finally got a result “target generic has been flashed successfully”. I’ve attached that flash log.

Then booted the orin nano and no display. So I’ve attached serial console log that shows that boot attempt. That boot froze on the last line in that log.

Went back in with serial console and the boot was set to ‘Normal’ so I did not experiment there. I believe everything looks like my running Orin AGX developer kit.

I tried without and with Fumiya Fujinaka’s tegra-xudc.ko file but it made no difference.

If you have a more recently compiled tegra-xudc.ko file with the updated tegra-xudc.c I’ll try it. The one linked above is 5 times the size of the original which seems a large difference for a few lines of code.

021824flash.txt (90.8 KB)
021924_initialboot.txt (60.6 KB)

Thank you,
Scott

I am not sure about what you are doing. The flash command is wrong.

You should use initrd flash instead of flash.sh.

I am trying to get orin nano running with dp6.2 so that I can install ros.org/iron.

Yes I did first try initrd_flash over the time period since your reply to my initial post. I succeeded with qspi flash --no-systemimg. but every other initrd_flash failed. I’ve attached 4 logs showing some of those failures.

I also tried several of the versions for initrd_flash that are listed here FlashingSupport.html and they too failed.

flash_1-6.1_0_20240218-183035.log (9.5 KB)
flash_1-6.1_0_20240218-170854.log (9.5 KB)
flash_1-6.1_0_20240216-183633.log (5.9 KB)
flash_1-6.1_0_20240215-163154.log (9.5 KB)

Hi,

Then it is back to my previous post.

If you don’t want to build your own kernel, could you just connect some usb devices to the hub to make usb power supply stable? This is a workaround.

Please note that I’ve tried everything twice that is suggested in your cited post. I had actually done everything referenced in it before I posted my first thread above.

Thanks for suggestion. I’ll plug some different usb devices than what has been previously attached and see if it will boot and if not will again try initrd_flash with the higher load.

If you still cannot flash with initrd, please share the uart serial console log.

It could be something else if above changes all fail.

Thank you. Attached to my first post tonight is a serial console log titled 021924_initialboot.txt

I’ll post a new one tomorrow if my nano doesn’t boot. I also found the information to manually rebuild the kernel
and will do that if the usb devices doesn’t work.

Thank you for your help.

Hi,

You don’t need to post the same log again. I already saw that and that one is based on a wrong flash. Thus, we don’t consider checking that log for now.

Added a external usb ssd, a usb Astra-pro camera to my usb keyboard and mouse.
initrd_flash’ed the Nano. Initial boot never made it past the last line in this console log.
flash_1-8_0_20240220-141324.log (9.5 KB)
022024_consolelog.txt (116.4 KB)
This console log made it one more line than others before it stopped.

I tried a different initrd_flash.sh command_line and here are its logs.
flash_1-8_0_20240220-182449.log (9.5 KB)
022024_B_consolelog.txt (57.8 KB)

I looked at the logs and nothing was obvious to me. The first one mentions sda1 which is odd it wasn’t a target of the installation attempts.

Tonight or tomorrow I’ll compile the tegra-xudc.ko.

Hi

What is the exact flash command you are using?

The 2 uart log you shared only indicates a “boot” log but not a flash log.

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml –showlogs --network usb0 jetson-orin-nano-devkit nvme0n1p1

I have tried many variations of sdkmanager, flash.sh, and I4t_initrd_flash.sh over the last couple of weeks.
orinFLASH.txt (4.2 KB)

Here’s the logs from todays attempt. Lots of activity in console flash log. The usb-c to usb-a cable I am using is the one included with the orin nano developer kit.

flash_1-8_0_20240221-143242.log (9.5 KB)
022124_S.log (79.4 KB)

Just a clarification in case you are not able to read your own log…

  1. Your manual flash command is wrong… please directly copy and paste commands from this page.
    Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation

  2. The flash log finally gets into correct way today. None of your previous log has any attempt to flash the board…

  3. The issue is still same as post
    Flashing L4T 36.2 on orin Nano/NX - #2 by WayneWWW

Your attempt to toggle the power is failed due to permission denied…

Add[ ev/nvme0n6] LUN
emovable file: (no medium)
[ 70.002362] LUN: removable file: (no medium)
/bin/nv_enable_remote.sh: line 223: /sys/bus/usb/devices/usb2/power/control0: Permission denied
[ 70.005492] usb0: HOST MAC d6:47:00:95:16:00
[ 70.005497] usb0: MAC f2:9d:18:2e:04:af

Thus, the situation I saw here is

  1. Your previous try seems mostly in vain because your flash command is wrong or the flash totally didn’t happen.

  2. Please just keep in this situation that the board really get into flash state, recover every software change you added back to default. Just connect a usb device like mouse or keyboard to the usb hub to make it always power on and start the flash process…

Did every suggestion. Still failed.

22224sdkflsh.log (79.1 KB)
flash_1-8_0_20240222-183504.log (9.5 KB)

If you don’t see anything diagnostic in the logs I’ll wait for Jetpack6 in March.

Thank you,
Scott

Do you have any USB 2.0 devices connected to Jetson during flashing?
Anything like a mouse/keyboard.

Another question here. Does this board ever get flashed with jetpack5.1.2 or not?

I notice you mentioned jp5 in the beginning and we didn’t focus too much on it.
If even your jetpack5 is not able to get flashed with initrd flash, then the issue could be something else.

If the issue is something else, then waiting for next release might not help. Thus, please clarify this too.

Yes I have usb keyboard, mouse and added an astra_pro usb camera. This time tegra_xudc.ko did not error out.

Would it make any sense to try this usb3-recovery-mode What stopped me from trying it was it is unreversable.

When I tried jetpack5.1.2 it failed. I’ll try it again tomorrow with my ubuntu20.04 computer using sdkmanager5 and also a plain l4t_initrd_flash.sh with flash and console logs.

Hi,

No, no need to try usb3-recovery mode. We can check your jetpack5 situation first.

Flashed succesfully with JetPack 5.1.3 / Jetson Linux 35.5.0
to nvme with l4t_initrd_flash.sh.

My ubuntu 20.04 computer chose to use /dev/ttyUSB1 for serial console so I missed oportunity to get console/flash log.

Thank you for all of your assistance and guidance. I learned a lot. Please close this issue.