SDKManager Install - No ARM files.


I am trying to download the source files for Jetpack 4.2.2. When I run the most recent version of the SDK manager from the command line, with the following command…

sdkmanager --cli downloadonly --user $NV_USER \
--view live --host --logintype devzone --product Jetson --version 4.2 \
--targetos Linux --target $DEVICE_ID --flash all --license accept \
--downloadfolder /tmp/cuda_pkg

From what I have read, there should be a file, “cuda-repo-l4t-10-0-local-<CUDA_PKG_VERSION>_arm64.deb”. However, I only see
cuda-repo-cross-aarch64-10-0-local-10.0.326_1.0-1_all.deb and cuda-repo-ubuntu1804-10-0-local-10.0.326-410.108_1.0-1_amd64.deb.

Could you please help me resolve this?

The SDK Manager runs only on the host PC and acts as a front end to installing or flashing software to the Jetson. Did you run this from the Ubuntu PC command line?

I am building a docker container for jetsons. I used the l4t image from NVIDIA, but it is missing some binaries pytorch is looking for (I understand you’re supposed to mount some files for CUDA, but I don’t want to). I therefor was going to install CUDA 10 directly into the container.

I created an Ubuntu 18 container to run the SDK in. I run that command and get the following files…

  • 2019_06_23_2352-26660552-NVIDIA_Nomad_2019.2.19174.2352_Release_External-L4T.linux.deb, libopencv-dev_3.3.1-2-gb3f86dcd5_amd64.deb, Jetson_Linux_R32.2.1_aarch64.tbz2, libopencv-python_3.3.1-2-gb3f86dcd5_amd64.deb, libopencv-samples_3.3.1-2-gb3f86dcd5_amd64.deb NsightSystems-linux-public-2019.4.1.10-a76094a.deb libopencv_3.3.1-2-gb3f86dcd5_amd64.deb Tegra_Linux_Sample-Root-Filesystem_R32.2.1_aarch64.tbz2 libvisionworks-repo_1.6.0.500n_amd64.deb cuda-repo-cross-aarch64-10-0-local-10.0.326_1.0-1_all.deb libvisionworks-sfm-repo_0.90.4_amd64.deb cuda-repo-ubuntu1804-10-0-local-10.0.326-410.108_1.0-1_amd64.deb libvisionworks-tracking-repo_0.88.2_amd64.deb sdkml3_jetpack_l4t_422_rev1_b30.json

Any help would be greatly appreciated.

I have no experience with docker, but I know others on the forum do use docker and will probably answer.

With your knowledge of Linux, It may be worth looking into. It’s basically a glorified chroot and you probably know more about good container design than most people who start with it. The same rules apply. Don’t use root when you don’t need to. Create system accounts to run stuff. Set permissions properly. You can run any distro you want. It’s handy, but also incredibly easy to blow your foot off with.

You’re thinking of making a container to build images for Jetsons? I’ve looked into this and can point out a few problems you might run into:

  • Last I checked, SDKM requires a working X server, even when --cli is off. This seems to be a bug and I ahve reported it. I haven't checked recently whether it is fixed or not. There are ways around this inside a container, but they will increase the size of your image and add extra complexity.
  • IIRC, SDKM has two download folders. One for the host and one for the Jetson. I am not sure if the second can be specified at the CLI. That may be why you don't see the files you are looking for. I am not at my Linux workstation right now so I can't run a --help to tell if such an option exists or not.
  • If the above option does not exist, SDKM is not super hard to reverse engineer. If you want to download files more directly you only need look at the log for all you need (json urls). The database with stored oauth credentials and a lot of other useful things can be found at ~/.nvsdk/sdkm.db IIRC. Then you just pass through your skdm.db to your container or the credentials more directly. Getting that working is a fair bit of work more than the X workaround above, however. You'll need a working knowledge of something like requests_oauthlib.

I’d be happy to help, regardless of the path you choose, if you post your progress here. It’s been on my to-do list for a while to automate image building and this is the other half of the work I’ve been working on (the other half being an app to customized the kernel and rootfs).