Note: What I’m describing is for the older Nano. There are also Xavier Nano and Orin Nano and TX2 Nano; TX2 Nano uses the same software, but Xavier and Orin are much newer designs and can use some newer software. I assume that you are describing the original Nano 2GB, but if this happens to be Orin or Xavier, then the L4T releases which work change.
On the NVIDIA developer kits which do not have eMMC, an SD card is mandatory, and only the operating system is on the SD card. The rest of the boot chain is on QSPI memory on the module itself. This means you have to flash the Jetson once, and then you can use several different SD cards.
The L4T release is just the name given to Ubuntu after NVIDIA drivers are added. This is what actually flashed, although you could just refer to it as “Ubuntu” if you’re not talking about the boot chain. You can find the SD card’s L4T release with “head -n 1 /etc/nv_tegra_release”; if you’ve mounted this on the host PC, then you can simply adjust to the mount point. Assuming this is ext4, then other operating systems (such as Windows) will not have any ability to read this. Or, the documentation which came with the content you put onto the SD card will simply tell you the L4T release. You can find a list of URLs for your release here:
https://developer.nvidia.com/linux-tegra
You’ll also see a reference to SDK Manager and JetPack. This is just an installer front end to the flash software (the actual flash software is called the “driver package”). This runs on your host PC, not the Jetson, and is designed to flash Jetsons. This can flash the QSPI of the Jetson module itself. The URL for your L4T release (which actually got an update just a few days ago for the last update of the old Nano) also has a URL or download link for JetPack/SDKM (incidentally, SDKM is just a smart network layer on top of the JetPack installer).
If you have a JetPack 4.x flash the QSPI of the module once, then you should be able to use most any L4T R32.x release on that Jetson without flashing QSPI again.
Since this runs on an Ubuntu host PC (and there are even restrictions on which release of Ubuntu; L4T R32.x from JetPack 4.x can use an Ubuntu 18.04 host PC), some people use a VM. This can be rather problematic. For one thing, VMs rarely handle USB disconnect/reconnect correctly, and it is up to the end user to set up a VM. Also, the amount of disk space required is quite large, so you’d need significant disk space, and that disk space needs to be formatted as ext4, and not a Windows filesystem type. Some places will show how to use the WSL2 VM, and if you follow that information, then you are more likely to succeed with a VM.
When you’ve installed JetPack/SDKM to your host PC, then your home directory has an abbreviation “~” (tilde). The flash software will live at “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/”. Most instructions simply mention going to “Linux_for_Tegra/”.
From Linux_for_Tegra/ you can run this command to find out something interesting:
ls -l *.conf
You’ll see all of the flash targets. Some are symbolic links with more intuitive names, while the others are named after the carrier board model plus the module module. The more human naming conventions are just links to the technical name. If you remove the “.conf” from the name, then all of those are flash targets. If you were to flash on command line (and I’m not suggesting you do that), then you’d find the alias describing your 2GB Nano model’s QSPI. The JetPack GUI (started on command line with “sdkmanager” by your regular user without using sudo) should be able to detect a recovery mode Jetson and see what your target options are.
Incidentally, recovery mode itself does nothing to change the Jetson. If you go to recovery mode, and then reboot, then nothing will have changed. Recovery mode turns the Jetson into a custom USB device understood by the custom driver (which is the earlier mentioned “driver package” that runs on the Linux host PC). There is a recovery pin, and if either the power goes up or is reset while the recovery pin is shorted to ground, then it goes into recovery mode. There is no requirement to hold the recovery pin for any length of time (it is like the SHIFT key on a keyboard; you don’t have to keep holding the SHIFT key after typing a capital letter in).
If you have issues with flashing QSPI via JetPack/SDKM, then you can easily flash on command line, so just ask. Note that there are many useful options on JetPack/SDKM, and those can be checked or unchecked, but the GUI does not make this obvious in many cases. For example, if you don’t want to install developer tools to the host PC, then you can uncheck this. You have your own SD card pre-compiled release, so you also don’t need to add optional software to that; you can strip the options down to the minimum of what you need.
If you were using JetPack/SDKM to also create a custom SD card image, then after flash completes the Jetson would automatically reboot, and would no longer be in recovery mode. The first boot would result in an admin user account name/password setup, and then JetPack/SDKM would install optional software via ssh to that fully booted Jetson. Technically, if the SD card did not have some option available from JetPack, then you could simply boot the Jetson normally, and uncheck everything in JetPack except for adding that optional content, and it would install over ssh to the Jetson without ever needing to be in recovery mode.
Start with documentation at your L4T release; pick the most recent compatible L4T release when flashing QSPI.