I’ve been having an issue the past few days getting my dev kit to boot.
I first tried flashing the SD card with the image provided, and the device would stay stuck at the nvidia screen. so i tried another sd card, same thing.
Next thing i did was go from ubuntu 22 to 20 to 18 in order to use sdk manager.
managed to get the device detected, but after an hour of flashing and being stuck at 99% i called it quits and tried to do it via install.sh
that also didnt work
and now trying sdk manager again, im for the third time stuck at 99% / Saved platform info in storage_info.bin…
Any solutions? I tried multiple SD cards, Cables, power supplies. I don’t have another host. Getting ubuntu 18.04 working on this host was a pain since i had to manually compile and install a custom version of the 5.15 kernel which is the oldest one with support for my hardware.
Are you using a VM? Ubuntu 18 is the correct choice, but a VM very often causes loss of USB (USB disconnects and reconnects during a flash; if reconnect fails, it can get stuck, and VMs will do this if not set up correctly).
Assuming this is an older Nano, and not an Orin Nano, then a 5.x kernel won’t work. L4T R32.x is the highest release which works, and this is Ubuntu 18 with a 4.x kernel. And yes, back porting would be a real pain.
No, the 4.x kernel is for the Jetson (one specifically modified by NVIDIA for running on a Jetson using that L4T release version). I think when you mentioned “install a custom version of the 5.15 kernel” I was thinking you modified this on the Jetson, but if it is the host, then ignore my statements.
Incidentally, most of the restrictions for the host PC when flashing a Nano are from JetPack/SDK Manager. These, in turn, are just GUI front ends to the actual flash software (the “driver package”). The driver package itself has fewer restrictions (but you’d have to use command line and completely manual setup). In the end, if working on a Nano, you’ll be far less frustrated with an Ubuntu 18 host PC.
If you try on command line, the log that with: sudo ./flash.sh ...whatever the command is... 2>&1 | tee log_flash.txt
Simultaneously, run a serial console on the Nano itself with logging running. Post the log from the Nano during the flash, and also from the command line flash (the two which are paired together from one flash attempt).
One tip which likely won’t matter is to be sure to reset the Jetson into recovery mode each attempt. You cannot flash twice or clone twice or combine clone and flash without a new reboot into recovery mode each time.
Yeah nothing I do can get this thing to work. I tried multiple versions, sdk manager, custom flashing from command line, multiple sd cards and images from the site. i just get stuck at the nvidia logo on boot. I cannot continue to develop my software. I can’t get any output from the UART as it only shows up as unknown device. I think the firmware or whatever that is on the device itself is dead. I’m not sure where to go from here.
What is the exact L4T release in the flash software? Normally you could use “head -n 1 /etc/nv_tegra_release”, but if you are on the host PC and at the “Linux_for_Tegra/rootfs/etc/” subdirectory, you can just “head -n 1 nv_tegra_release”.
Then, do monitor “dmesg --follow” on the host PC, put the Jetson in recovery mode, and examine what the new log lines are for that plug-in event. It does sound like a USB issue, and maybe that log will show something. It could be a number of things, but we’ll need to know exact messages at every step that fails. If the flash software cannot find the device in recovery mode, we’d also need to know what the exact message is on command line flash and the error reply, along with the exact command. Example for a Nano dev kit (varies with other Nano models):
head -n 1 rootfs/etc/nv_tegra_release
# dmesg --follow, now plug in the recovery mode Jetson and watch the new log lines;
# Mouse copy and paste the log lines which appear as a result of the plug-in.
# Note that the dev kit has QSPI on it, so if one fails, check the other:
sudo ./flash.sh jetson-nano-devkit mmcblk1p1 2>&1 | tee log_devkit_flash.txt
# Note: You have to restart the Jetson in recovery mode each time you run a new
# flash or clone operation. That means there will be a second plug-in event, but
# the log for that only matters if it is different from the first dmesg log.
sudo ./flash.sh jetson-nano-qspi-sd mmcblk1p1 2>&1 | tee log_devkit_flash.txt
And as suggested by @WayneWWW, maybe a picture of the UART connection for the serial console.