I currently have an Orin NX 16Gb that is running L4T 35.3.1. I need L4T 35.2.1, so I attempted to flash it using the SDKManager but Jetpack 5.1 (rev 1) is no longer an option and it says “Not available for Jetson Orin NX modules” despite the 5.1 release notes explicitly state that it is supported. I’d appreciate any help or work around; thanks!
Try starting the newest JetPack/SDK Manager with:
sdkmanager --archivedversions
This should show some previous releases.
Unfortunately the archived version only had up to Jetpack 4.5, which isn’t recent enough. Could there be any fix for the current SDKManager not supporting the Orin with the previous Jetpack version like it should?
Share a screenshot for what you saw on your sdkmanager GUI.
If you go here, is there a specific L4T release you are looking for? L4T is what gets flashed, and its version is tied to the specific JetPack/SDK Manager release, and you could also go here and cross reference the L4T release (both point to the same URL in the end):
Note that you would not want to use L4T R34.x, this was more or less a pre-release. Nothing prior to R34.x will work with Orin. If you have a specific R35.x release, then it is possible to also flash on command line (not as convenient).
I am looking for L4T 35.2.1 which is tied to JetPack 5.1, but it will not allow me to flash that despite Orin Nx 16G being supported by 35.2.1.
If you use the most recent JetPack 5.x, and start via:
sdkmanager --archivedversions
…does R35.2.1 not show up?
Incidentally, the NX 16 GB might not work with all of the same releases. Someone from NVIDIA would have to comment on whether the 16 GB model is compatible with R35.2.1. I don’t know. However, in JetPack, you can select to manually pick the type of Jetson. Your screenshot shows it is not auto detecting. Can you pick the Orin NX manually and get it to go forward?
In the very first screenshot, the board is autodetected and JP 5.1 is still grayed out. the 5.1 release notes specifically state that Orin NX 16 should be supported.
If there is a write up for how to flash the Orin from command line I would greatly appreciate it!
In the L4T release page for the release you are interested in, you would download these:
- Driver Package (BSP)
- Sample Root Filesystem
You would then:
- Find a place to unpack the driver package. Do not use
sudoduring the unpack. This will result in creating subdirectory “Linux_for_Tegra/”. - Then
cdto “Linux_for_Tegra/rootfs/”. - Within
rootfs/you will unpack the sample rootfs using sudo. - You will now
cdback to “Linux_for_Tegra/”. - Run the command “
sudo ./apply_binaries.sh”. - From this point forward you can flash from “
Linux_for_Tegra/” without repeating the above steps. - The basic command, with the Jetson attached and in recovery mode:
sudo ./flash.sh <target name> mmcblk0p1
(the above is assuming eMMC flash; SD card models tend to bemmcblk1p1; documents give information)
If you look in that directory at “ls *.conf”, then you will see the targets supported. The target name is just that .conf name, but with the .conf removed. So for example, you might examine:
ls *orin*nx*.conf
There happens to be this file:
jetson-agx-orin-devkit-as-nx-16gb.conf
So if you remove the suffix, a valid flash target is “jetson-agx-orin-devkit-as-nx-16gb”. Example, assuming SD card model (this is not quite true, don’t flash this yet):
sudo ./flash.sh jetson-agx-orin-devkit-as-nx-16gb mmcblk1p1
My example came from an earlier JetPack 5.1 prior to NX. The above target was to use an AGX Orin to pretend to be a 16GB NX. However, the method for finding this in your “Linux_for_Tegra/” directory is valid and you should find a target if the software supports that target.
Trivia: Most of the “.conf” files are symbolic links. The hard links are named after the specification of the module and the carrier board, and the symbolic link is just an alias to a more common name. Sometimes people copy the hard link to a custom name if they want to modify the target for some customization, e.g., a third party manufacturer will do that.
Please note that this will flash, you still need to do the first boot login setup. Prior to flashing, and after the “sudo ./apply_binaries.sh”, you could fill in that information ahead of time (you don’t want to do that if shipping to customers and using a “default” name/pass…California does not like that):
sudo ./tools/l4t_create_default_user.sh
(if you do this once, then every flash will contain the name/pass setup and first boot account setup will not be required)
Also, this does not install optional components, e.g., CUDA. The apt command should already be set up though to see the repositories containing those optional packages, so you can use “sudo apt-get install ...package...” to complete that.
SDK Manager is just a network layer on top of JetPack. JetPack is just a GUI front end to the driver package. The content of “Linux_for_Tegra/” is the driver package, and is named as such because it understands the custom USB device which a Jetson turns into when in recovery mode.
I just tried to recall what was going on there.
In rel-35.2, there was no official support for “Orin NX devkit” at that time. Only Orin NX + Xavier NX devkit was ready at that time. That is why SDKM blocked Orin NX devkit.
Need to do manual flash for this kind.
Hey thanks for the help. I was able to follow the quick start guide so thanks for that direction. It says it successfully flashes but it does not reboot on its own and if I cycle the power it doesn’t display anything on the monitor even though the board is on. Here is the final output, and I am including the only things in the log that I think may be of note. Is there a proper way to reboot it in this case?
[ 337]: l4t_flash_from_kernel: Warning: skip writing B_reserved_on_boot partition as no image is specified
[ 337]: l4t_flash_from_kernel: Warning: skip writing uefi_variables partition as no image is specified
[ 337]: l4t_flash_from_kernel: Warning: skip writing uefi_ftw partition as no image is specified
[ 337]: l4t_flash_from_kernel: Warning: skip writing worm partition as no image is specified
&
[ 338]: l4t_flash_from_kernel: Successfully flash the qspi
[ 338]: l4t_flash_from_kernel: Flashing success
[ 338]: l4t_flash_from_kernel: The device size indicated in the partition layout xml is smaller than the actual size. This utility will try to fix the GPT.
Flash is successful
Reboot device
Cleaning up…
I also have looked into trying to find how to dump the uart on this but the current information I have been able to find does not apply to the Orin NX on the Xavier NX board. Thank you!
I don’t know what does that mean cannot apply. The method to dump uart log on xavier nx board is still same when you have Orin NX connected.
You need to dump the log right after you power on the board. You cannot wait for a moment and then dump.
I guess current situation is somehow the GUI fails to show up so that you cannot tell whether the system boots up or not. In this situation, UART log matters.
If you cannot see anything from UART, then most of cases I ever saw
-
Your UART setup is not right
-
You dumped the uart log too late. Since first boot will get stuck to wait for you to configure user account, if you dumped the log in a late situation, it will already be in the stuck situation so you cannot see any log.
The log is like below:
boot up log line 1
boot up log line 2
…
…
…
boot up log line 10000
“Please configure your user account by connecting xxxx” → there won’t be any log printed after this line
If you tried to dump the log after this line, then uart will be empty.
Hello, this is the message I got:
[ 25.692578] Please complete system configuration setup on the serial port provided by Jetson’s USB device mode connection. e.g. /dev/ttyACMx where x can 0, 1, 2 etc.
How do I complete that from the serial console?
I have the Type-C connection from the Jetson to my host but the /dev/ttyACM0 doesn’t exist when I try to minicom into it.
Does your host side “dmesg” show any error when you connect the type C cable to it?
No it does not. It actually does not show anything, but the same cable has been used to flash other devices so I think the cable is fine. It is a Type C to Type A if that makes a difference.