Nano A02 - Latest SDK and Ubuntu O/S versions?

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Greetings!

I am attempting to set up the Nvidia SDK for a first-generation Jetson Nano (A02).

When I select “Download SDK” from the Jetson Nano home page, it eventually leads me to the 6.n version of the SDK. However, according to the list of SDK installer images for Ubuntu, these latest versions don’t support the Nano, instead they seem to be for the Orion boards. It appears that the latest version that explicitly supports the Nano is the 4.6.1 SDK/OS image.

Likewise, I attempted to install it on a copy of Mint 21.3 and it installed, but claimed there were no SDK downloads for Mint, so I am downloading Ubuntu 18.0.4, as that is the version of Ubuntu loaded on the Nano from the 4.6.1 SD card OS image.

Question:

  • Is JetPack 4.6.1 the absolutely latest version that can be run on the Nano?
  • Is it necessary to run the SDK on the same version of Ubuntu that the Jetson Nano uses, or can I use a later version?

Thanks!

2

Some older versions are available if you use “sdkmanager --archived-versions”. The actual flash content, which is “L4T” (Ubuntu plus NVIDIA drivers), further limits what host PC releases can be used. The L4T release is in turn also a subset of what sdkmanager can flash, and depends on the hardware being flashed. All JetPack/SDKM requires an Ubuntu host PC (command line does not if you are interested in manual install on the host PC; this makes much more available for host PCs, but it does not allow flashing versions onto hardware not compatible). I think JetPack 4.x, in combination with a Nano, works with an Ubuntu 16.04 host PC or an Ubuntu 18.04 (obviously everyone picks 18.04 unless they were working with older TK1 hardware and already have 16.04).

JetPack 4.x corresponds to L4T R32.x. This is the most recent original Nano can use, and no more feature releases will exist for that Nano. You will not be able to flash newer than Ubuntu 18.04 onto a Nano (which is L4T R32.x). You might see security or bug fix updates, but they will remain Ubuntu 18.04/L4T R32.x.

1 Like
3

:rofl:

I discovered that if I downloaded the 4.6.1 SDK it wouldn’t authenticate so, I decided to download the version 6 and use that.  The funny part was after version 6 let me log in, it slowly but surely - through several update cycles, back-rev’d itself to 4.6.1.

I created my own launcher with the --archived-versions parameter which allowed me to select the Nano.

Corollary questions:
The SDK wants to “flash” the Nano, and then “download” a lot of SDK stuff to it.  I am assuming “flash the operating system” is identical to flashing the SD card using etcher with everything destroyed in the process.  Since I have already heavily modified the robot’s OS working on porting over a bunch of Raspberry Pi libraries, completely re-writing the SD card would be a total disaster without an excellent reason for doing it.

Question 1.
Is there any benefit to allowing the SDK to re-flash the OS?  Will it do things to the Nano that a mere Etcher flashed SD card can’t?

Question 2.
Assuming I have downloaded the SD image for the Nano (JP4.6.1) and am using that, is allowing the SDK to install the various SDK components sufficient?  Or is the SDK flashed OS really necessary?

Thanks!

4

You can uncheck most of the downloads. This includes downloads to the host o/s, like CUDA. Leave only the “flash” checked.

SD card models are different than eMMC models. With SD cards the boot content, and the equivalent of a BIOS, is in QSPI memory on the module itself. eMMC modules tend to have this in partitions. Flashing an SD card module using the “qspi” target does not alter the SD card, so some flashes do not destroy the SD card. You could always put an empty SD card in to see what happens, but the need for SD card is usually because the Jetson automatically reboots after a flash, and it is in the non-recovery mode full boot that JetPack/SDKM will attempt to install optional packages (such as CUDA) using ssh over an admin account (thus first boot setup might have to occur prior to optional package install).

Think of boot content flash as also flashing the BIOS (Jetsons don’t have a BIOS, so they cannot be bricked like a desktop motherboard, but they still have the functions of a BIOS) and the boot content. For SD card models, this is QSPI flash. In your Linux_for_Tegra/ directory, examine this output:
ls -l jetson*.conf

Each of those is a symbolic link to a less human friendly file name. That name is a combination of the designation of the module and some carrier board. For command line flash, if you remove the “.conf” suffix, each of those are flash targets. They’re human readable scripts, and so you can see what is being done.

The boot content has to be compatible with the o/s (rootfs). One set of QSPI (or eMMC partitions) tends to work with several SD card releases. You are advised to always flash QSPI at least once when you get a Nano. After that several L4T releases of SD card will work before you need to change boot/BIOS content. Many bugs are often fixed with newer boot content (the Linux kernel inherits the boot environment, so a faulty boot environment can have consequences). Try with an SD card which is partitioned, but has no content other than being formatted to see what happens, but know ahead of time that automatic reboot prior to attempting optional package install would fail since the SD card is empty.

If you have an SD card release that works, then you can uncheck flash and uncheck install of anything to host PC; just keep the optional content, e.g., CUDA, and fully boot the Jetson. Networking would be used, and so either the virtual wired ethernet over USB does this, or you could use the local LAN IP address, so on. You don’t need to flash the o/s. You don’t need to flash the QSPI more than once, and maybe you can get away without flashing that at all if it shipped with a new enough QSPI, but it is recommended to flash this.

1 Like
5

I am afraid that I’m a bit confused.

I found instructions describing how to flash the QSPI. How do I know if it’s current? How do I update it?

Since I have booted with a virgin SD card with Jet Pack 4.6.1 on it, does that automagically update the QSPI? And since it will, (if I jiggle things around), boot from USB, does that mean I am current?

How would I check the QSPI version and where would I get a new one?

7

If you are able to boot up with an SD card, then there is nothing more you need to do with this QSPI stuff.

8

Update:

I had the idea of using a small SD card, (actually too small), and attempted to flash the Jetson O/S, to see if that would update the QSPI flash memory

Result:

  • It failed.  This was expected because the SD card was much too small.
  • The Jetson Nano must have had the QSPI updated when I flashed it because it now boots much more reliably to the external USB SSD, without having done anything else to either the Nano or the SSD.

Interesting!

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.