SDKM_logs_2024-12-06_13-40-48.zip (1.7 MB)
It only proceeds until ‘OS image ready,’ and then Flash Jetson Linux shows an error.
Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device:
Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs:
Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system:
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!
minicom.zip (14.3 KB)
flash NVMe
minicom_1.zip (206 Bytes)
Hi,
Please execute the following commands on your host PC and then try running the SDK Manager again with minicom recording UART log:
sudo -s
echo -1 > /sys/module/usbcore/parameters/autosuspend
Additionally, I would like to confirm the following:
- Is your host PC running Ubuntu 20.04 on a physical machine rather than a virtual environment (e.g., WSL, VirtualBox, VMware, etc.)?
- Is your AGX Orin a developer kit or a custom carrier board?
Thank you!
cat /sys/module/usbcore/parameters/autosuspend
-1
then flash eMMC
it’s real physical ubuntu 20.04 , and developer kit.
And all these unfortunate events happened after following this guide (GitHub - jetsonhacks/rootOnNVMe: Switch the rootfs to a NVMe SSD on the Jetson Xavier NX and Jetson AGX Xavier).
I have already tried flashing more than 20 times.
minicom_5.zip (11.1 KB)
Could you also provide latest fail sdk manager log?
Thanks
Even when I barely manage to boot, neither the ESC nor F11 keys work
SDKM_logs_2024-12-06_16-58-05.zip (1.7 MB)
i can only see black screen…again again…
Is this a NV developer kit or a custom board?
Or you are not sure about what does my question indicate here?
this
not a custom board
But your log looks more like a unstable hardware to me.
Do you have other Jetson there that can cross check?
Also, I saw your sdkmanager log flashed jetpack5 and jetpack6 already and the flash seems all fine.
Is the UART log you shared to us based on jetpack5 or 6? How did you capture the UART log? I saw some unrecognized ASCII inside of it. This should not happen.
I don’t have another Jetson device. Could it be a record of JetPack 5 being flashed previously? I flashed version 5 a few months ago. The UART logs were captured during the installation of JetPack 6.1. The UART logs were recorded using the command:
sudo minicom -b 115200 -D /dev/ttyACM0
Yes, the timestamp of your jetpack5 is record in July.
Could you flash your board with jetpack5 too and share us the UART log again if it can be flashed without error?
Which one should I choose between eMMC and NVMe before attempting to flash again? I’ve experienced so many failures that I’m feeling very confused.
Do you have a NVMe SSD connected on your board? If not, then you could flash eMMC only.
Just to clarify, your previous log is also for eMMC and they were all successful.
I think I’ve solved it. The cause of 9 hours of frustration was the wired LAN cable. After unplugging the LAN cable and flashing, the endless rebooting issue was resolved… I feel empty inside. Anyway, thank you.
Actually this should not happen.
I think we should look more into this issue if this bothers you. A NV devkit shall not hit such problem.
For example, I boot my Jeton with Wired LAN everyday but I never hit this…