I have a Jetson Orin Nano all set up & working fine with jetpack 6. However I need to go back and put in an SD card from when we were originally using Jetpack5 a year ago. The Jetson shows a bit of the logo bootup, but just seems to be in an endless boot cycle. Is there some reason this is occurring–some setting?
Jetsons don’t have an actual BIOS, this is all in software. The BIOS equivalent and boot chain have to be from the same major release as the operating system, so this is just a difference in major release. One major release for the boot content supports pretty much every minor release of the o/s itself.
On eMMC models this content is in partitions of the eMMC, but on SD card models which don’t have eMMC this content lives in the QSPI memory. The QSPI memory itself is on the Jetson module, and can only be updated with flash. So basically must use JetPack/SDK Manager and flash the module itself (you could skip flashing any SD card since you already have one).
Incidentally, if you have flash software installed on a host PC from using JetPack/SDKM before, then you will have this content on the host PC:
~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/
If you cd to that location, and then run this command:
ls -l jetson*.conf
…you will find that removing the “.conf” from the file name is a flash target (not necessary to know if you use JetPack/SDKM, but on command line, you would need this). There will be some Orin Nano targets, and at least one which has QSPI in the name.
You can’t get around flashing this because flash is the only way to update the QSPI, and flash requires the Jetson to be in recovery mode. Recovery mode turns the Jetson into a custom USB device understood only by the custom USB driver, and that driver runs only on a desktop PC Linux. JetPack/SDKM adds further requirements on which Ubuntu release can be used (JetPack/SDKM is the GUI on top of the flash driver).
Do note that newer JetPacks can be started like this to see older releases:
sdkmanager --archived-versions
Thanks so much for the reply. To summarize (please point out if not correct): You can’t just swap a formerly working SD card based on Jetpack 5, into a system currently working under jetpak6, the QSPI needs reverted as well. Is there a way to easily do so—We don’t have a linux PC setup, yet we were able at some point to successfully move up from jetpack5 to 6 & update the QSPI as well (I do recall it was a multistep process involving a few reboots—can it do a revert as well?).
I am working on setting up a dual bootPC, but there is some arm-wrestling going on there (I already have a virtual machine PC linux, but not the correct version & VM not recommended).
I don’t know if there was an OTA update capable of moving forward across major versions, but this is quite possible. During JetPack 5.x there was a lot of work on OTA. Obviously this worked quite well going from earlier minor releases of JP 5.x to later releases of JP 5.x. However, any update, including OTA, which changes the major release cannot be reversed without flash. We’re assuming this unit does not have eMMC (eMMC always requires flash to change the boot content, but that is in eMMC partitions instead of QSPI). So, QSPI had moved forward a major release, and you cannot go back without flashing.
Do note that command line flash is more flexible for host than what you can accomplish with JetPack/SDKM; you can flash QSPI on command line from most any Linux host PC. You would have to manually install the “driver package” (a Jetson is a custom USB device in recovery mode, and this is the custom USB driver), and then unpack the sample rootfs and add NVIDIA drivers. Technically I don’t think you’d even need the sample rootfs content for QSPI flash, but I wouldn’t bet on it (although you probably wouldn’t see any change to a blank SD card during flash of purely QSPI).
Here is where you find L4T releases:
https://developer.nvidia.com/linux-tegra
(remember that the L4T release is what actually gets flashed, and is Ubuntu plus drivers; you can see the L4T release from the file “/etc/nv_tegra_release” on the SD card)
If you want to use another distribution or release of a desktop PC Linux for host, then you would see that L4T R35.x corresponds to JetPack 5.x. The most recent QSPI release is advised, although most any of the L4T R35.x would work. You would go to the most recent R35.x release which corresponds to your QSPI major release, and download the “driver package” and “sample root filesystem”. Then:
- Find an empty location, probably create an empty directory similar to what the default is, “
~/nvidia/nvidia_sdk/JetPack...version.../”. - Unpack this there without using
sudo, and it will create the subdirectory “Linux_for_Tegra/”. - Go into “
Linux_for_Tegra/rootfs/”. - Now unpack the sample rootfs with
sudo. - Go back to “
Linux_for_Tegra/” - Add NVIDIA drivers via “
sudo ./apply_binaries.sh”.
At this point you are set for command line flash as many times as you want, but only on command line (which lacks many optional install items to the o/s itself, but works fully for QSPI or basic flash). Take a look at this files in “Linux_for_Tegra/”:
ls jetson*.conf
Each of those names are command line flash arguments, and the content is a combination of the module and carrier board. The SD card models are all devkits, and would also normally have the dev kit carrier board. If you want to see the “technical” description of module plus carrier board for each, consider that these are symbolic links pointing to the name of the less human-friendly name: “ls -l jetson*.conf”. When you remove the “.conf” from the name of the file, this becomes a command line flash target. When you see something with “orin” in the name, and “nano” and “qspi”, you have your target. I don’t have the Nano target list handy, so I’ll pretend the name is “jetson-orin-nano-devkit-qspi.conf”. This would be a QSPI flash command line if that name is correct, and if the Jetson is attached via the correct USB and in recovery mode (VMs will often fail at this point if their USB is not set up correctly):
sudo ./flash.sh -r jetson-orin-nano-devkit-qspi mmcblk1p1
The “-r” tells it to not build a new system image, which you already have. The mmcblk1p1 is the boot target, which in turn is the first partition of the SD card for that Jetson model.
If you have anything go wrong and want a log, then command line flash can add " 2>&1 | tee log_flash.txt" to get a log. Example:
sudo ./flash.sh -r jetson-orin-nano-devkit-qspi mmcblk1p1 2>&1 | tee log_flash.txt
Thanks—that’s quite a lot to digest and some very good tips… By OTA, do you mean over the air?
Yes, Over The Air.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.