Some terms to help…
L4T is Linux for Tegra, and this is just what you call Ubuntu after it has the NVIDIA drivers. L4T is what gets installed. JetPack/SDK Manager is a GUI front end flash tool which can do a few things beyond just flash. The two tend to have their versions tied together, so if you pick one release, you’ve more or less picked the other release. What you want to do right now is pick the most recent L4T R35.x release:
https://developer.nvidia.com/linux-tegra
When you get to that URL you will find documents and downloads (make sure you get the NX downloads if that is what you have; or just the Orin Nano downloads if that is what you have; some content is the same for all of the Jetsons at that release). Mostly what you’re interested in is JetPack/SDK Manager, but for JetPack 5 (which is L4T R35.x) unfortunately you will need an Ubuntu 20.04 host PC (Ubuntu 20.04 will work with both JP 5 and JP 6). There is a trick though that the command line tools don’t have that requirement and will work on a much wider range of Linux host PCs (though you will lose some of the JetPack/SDKM advantages).
If you can, then I suggest downgrading the host PC to Ubuntu 20.04. If not, then consider installing manually without JetPack/SDKM. The “docs” section of the L4T URL contains most of what you want, but for the case of manual install to the host PC and command line flash, keep reading.
A manual install to the host PC is to find an empty directory location, usually somewhere in your home directory. Then:
- Unpack the “driver package” as a regular user. Note: A Jetson in recovery is a custom USB device, and the driver package is what understands that custom USB device. The unpack will create a “
Linux_for_Tegra/” subdirectory.
- Within “
Linux_for_Tegra/” there will be an empty “rootfs/” subdirectory (it might contain a README file). Go to that directory, and unpack the “sample root filesystem” as root, using sudo. This is a purely Ubuntu starting point.
- Go back to “
Linux_for_Tegra/”, and run “sudo ./apply_binaries.sh”. This is what applies the NVIDIA content, and this is when it becomes “L4T”. From this point on you can flash on command line without any more of the above preparation.
- You can optionally skip first boot account setup and precreate your admin user if you want, but if you use a prebuilt SD card, then that is irrelevant. Should you want to do this, then from “
Linux_for_Tegra/”:
sudo ./tools/l4t_create_default_user.sh
Note that within “Linux_for_Tegra/” you have many “.conf” files named after various Jetson targets:
ls -l jetson*.conf
All of those, if you remove the trailing “.conf”, are flash targets to different hardware. Notice that the ones starting with jetson are symbolic links pointing at others with less known names. These are all combinations of module version and carrier board version. If you don’t have a developer’s kit, and instead have a third party carrier board, then those targets would most likely be incorrect. The module part would be valid, but the device tree would be wrong for the carrier board layout.
In the case of a dev kit Orin Nano there is no eMMC memory. The SD card slot is directly mounted to the module. If this were a third party unit, then there might be an SD card slot, but it would be on the carrier board, not on the module. The NX is similar, and there are versions which are dev kits that have the SD card slot on the module itself, and no eMMC. These use QSPI memory directly on the module for boot content. Only the rootfs would go onto the SD card of those models, so the only target you are really interested in is the QSPI target for your hardware.
I’ll suggest a candidate is something like “jetson-orin-nano-devkit-qspi” (file jetson-orin-nano-devkit-qspi.conf). I’m not looking at the actual file name, but that’s how you would find the right target. The documentation with a given L4T release also tells you the name. If that is the target, then with the Orin Nano in recovery mode, you would flash the module itself via flash of the QSPI target. This would be something like this:
sudo ./flash.sh jetson-orin-nano-devkit-qspi mmcblk1p1
If you have a problem with this flash, then you could log it like this:
sudo ./flash.sh jetson-orin-nano-devkit-qspi mmcblk1p1 2>&1 | tee log_flash.txt
(and you could post the log on the forums)
Once that is flashed, then several of the prebuilt SD card releases will work. The boot content is not universal, but it does typically work for several SD card releases. That same L4T URL would have some prebuilt SD cards listed. Other commands are available if you want to build a custom SD card based on the sample rootfs.
That same documentation should show some information on which pins are for recovery mode. It is basically just one pin, and a ground pin next to it. Shorting the recovery pin to ground is much like the shift key on a keyboard whereby you’d only hold it down when modifying a letter to be a capital letter, only in this case, it is for a power event instead of a key press. This means that if recovery is held down during either a “power on” event, or a “power reset” event, you can then let go of the recovery pin; the Jetson will be in recovery mode. This means it is a custom USB device, and will show up as such to the host PC if the correct port is used.
It is simpler if you can just use JetPack/SDK Manager. This also will add other optional content which requires more steps with the above manual approach, but if you are using a prebuilt SD card, this might not matter to you. You can always try it and find out.