Sdkmanager on ubuntu 20 does not support Jetson Nano, nor TX2, nor TX1

I work with Jetson Nano and TX2 boards and Jetson Orin NX boards. On my dedicated PC I had ubuntu 18.04 and the latest sdkmanager and could flash Jetson Nano and TX2 boards with Jetpack-4.6.4 and Jetson Orin NX boards with Jetpack-5.1.2.

I wanted to use sdkmanager to flash a Orin NX board with Jetpack 6.0, but sdkmanager requiredI my PC to run ubuntu 20.04 to do that. I have thus upgraded my host’s system from ubuntu 18.04 to ubuntu 20.04, but now sdkmanager refuses to flash my Jetson Nano and TX2 boards :(

When will that be fixed ?

https://docs.nvidia.com/sdk-manager/sdkm-command-line-install/index.html

sdkmanager --archived-versions

Does it help?

Or you can download the BSP and flash manually:

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3274/index.html

No :(.

Actually, the jp464 bsp has already been downloaded by sdkmanager while host OS was 18.04, and I prefer the simplicity of the GUI of sdkmanager over the cli.

And frankly, I do not understand why the version of the host OS, especially an upgraded one, impacts the choice of target hardware and SDK version.

There’s nothing different between the GUI SDK Manager and CLI command. SDK Manager is only a frontend of those underlying flashing commands.

That’s simply because we don’t quite test old BSP with new host OS, so we just block it from being selected.

Is there an option for sdkmanager to allow to use the untested BSP’s ?

NO.
Please just use the command way for flashing.

I will add some trivia which you might be interested in…

In recovery mode a Jetson is a custom USB device, and needs a custom driver (a Jetson cannot self-flash because it does not have a BIOS, thus custom USB device instead). The “driver package” is appropriately named because it is what understands that custom USB device, and it runs on the host PC (most of what you find in “Linux_for_Tegra/” is the driver package). The “sample root filesystem” is what actually gets flashed. In the past there was no GUI, no JetPack, and no SDK Manager. One would download the driver package, unpack the sample rootfs into the “Linux_for_Tegra/rootfs/” directory (which is purely Ubuntu), and then overlay the NVDIA content onto the “rootfs/” (which is when it becomes “Linux for Tegra” instead of just “Ubuntu”) using the apply_binaries.sh script. All flashing on command line worked after that.

One of the limitations was that installing many of the optional software items (such as CUDA) was a separate step. This is when host PC had to be a specific release since it was also installing optional tools on the host PC and not just optional content on the Jetson, e.g., it also can install the NVIDIA video driver and CUDA development tools on the host PC, not just the Jetson. It might have been better to not have that requirement, but to simply gray out/neutralize the checkboxes for installing host PC items.

However, the “Linux_for_Tegra/” content is itself not changed by much over the years. The command line tools, e.g., flash.sh, still deal only with flash, and not with options, and so these do not have any particular host PC requirement other than being Linux desktop PC.

Note that you can still find the “driver package” and “sample root filesystem” on any given L4T release page. You don’t actually need JetPack/SDK Manager to install this. So if you were to find your L4T release version here:
https://developer.nvidia.com/linux-tegra

Then you could download and unpack the driver package anywhere as a regular user. You’d then download and unpack the sample rootfs in the resulting empty “Linux_for_Tegra/rootfs/”, and finally, add NVIDIA drivers with the “Linux_for_Tegra/” directories command “sudo ./apply_binaries.sh”. After that you could run the command line flash, and it should work even from other distributions, e.g., Fedora. You’d have to know what to install though in terms of options like CUDA, which would be a more manual operation.

Interestingly enough, you could update a newly installed Jetson, clone it, and put that in to replace “Linux_for_Tegra/rootfs/” content. Flash might alter extlinux.conf, user accounts, the device tree, or kernel, but the rest would be a verbatim copy of what is in “rootfs/”.

1 Like

look at here for the explanation: (roll a bit down for the compatibility matrix: https://developer.nvidia.com/sdk-manager

2 Likes

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