For unknown reasons flashing the Jetson the first time worked without any problem. Reflashing the same Jetson device with the same configuration failed. I already tried different usb cables, but this doesn’t seem to be the problem. Flashing the Jetson from another PC worked once but after this the same problem occurred.
For flashing I use a Jetson Orin Nano Developer Kit with only NvMe storage (500G) on it (no sd card). I set the Jetson into Recovery Mode than add power and connect it to the Ubuntu 22.04 host machine. In the SDK Manager Gui configuration I deselect the host machine and select OEM Configuration Pre Config and the storage type NvMe.
I don’t understand why running exactly the same flash config lead to different results. If the flashing fails most of the time it just stops after “Flash Jeston Linux - flash: Formatting App partition done” multiple “Flash Jeston Linux - flash: tar: Read checkpoint x”, “Flash failure”, “Either the device cannot mount the NFS server on the host or a flash command has failed.”
12:20:35.514 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: Flash failure
12:20:35.537 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: Either the device cannot mount the NFS server on the host or a flash command has failed. Debug log saved to /tmp/tmp.45i8WejFVG. You can access the target's terminal through "sshpass -p root ssh root@fc00:1:1:0::2"
12:20:35.628 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: Cleaning up...
Could you try to disable the firewall setting on your host PC to see if it can help?
Have you also tried using the initrd flash command to flash the devkit?
It’s a plain Ubuntu 22.04 installation with no firewall explicit installed or enabled.
I also tried to run the following initrd_flash command with different flags:
when I runned
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg” jetson-orin-nano-devkit external
The flashing was successful but it got stuck in the oem configuration. Everytime I booted the jetson it asked to configure user, password, etc… When I rebooted the jetson the same screen were showing up, I never could get out of this loop.
If I called it like the following the flashing failed:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-only --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml jetson-orin-nano-devkit external
Also I am not sure if I use the correct flags to flash the jetson with only an nvme storage on it. Maybe you can explain some of the parameters e.g. what is the difference between using ‘–external-only’ and ‘-p “-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg”’. Do I explicit need to specify flash_t234_qspi.xml? And what is the difference between ‘jetson-orin-nano-devkit external’ and ‘jetson-orin-nano-devkit internal’. Also is it needed to set the concrete bord type like this: 'sudo BOARDID=3767 BOARDSKU=0005 FAB=300 ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” ./tools/kernel_flash/l4t_initrd_flash.sh … ’ ?
Thanks for the command and the explanation how to skip the oem-config.
If I uninstall everything in the sdk-manager and reboot the pc I can now flash the jetson reliable with the command you gave me. But reflashing still does not work if I don’t call the uninstall in the sdk manager and reboot the pc. Is there somewhere a cache that I need to clean up? Or do I need to create a backup of the /nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra folder and replace it?
Thanks for your help.
Yes the issue is specific to re-flash.
Are the logs of the flash command ./tools/kernel_flash/l4t_initrd_flash.sh saved somewhere?
Yes I tested both with the ./tools/kernel_flash/l4t_initrd_flash.sh script and the sdk-manager.
Just rebooting the PC w/o uninstalling the SDK Manger does not work…
Beside the two folders “/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra” and “~/Downloads/nvidia” are there any other tmp folder the script creates that needs to be deleted?
Yes, it should be saved to <Linux_for_Tegra>/initrdlog/flash_3-6_0_<date>-<time>.log on your host.
We cannot reproduce your issue locally.
Could you tried using the command I shared with you to flash the board twice to check if it would still fail in 2nd times?