JetPack 4.4 - L4T R32.4.3 production release

We are pleased to announce the JetPack 4.4 production release supporting Jetson AGX Xavier series, Jetson Xavier NX, Jetson TX2 series, Jetson TX1, and Jetson Nano. (JetPack 4.4 replaces JetPack 4.3 as the latest production release.)

Please read an important NOTE at the end of this announcement

The JetPack 4.4 production release builds on top JetPack 4.4 Developer Preview, and includes production versions of TensorRT 7.1 and cuDNN 8.0.

Along with JetPack 4.4, we are introducing a web based Power Estimator tool to simplify creation of custom nvpmodel power profiles for Jetson.

Please refer to the JetPack Release Notes and L4T Release Notes for additional info.

JetPack 4.4 Highlights:

JetPack 4.4 components:

  • L4T R32.4.3
  • CUDA 10.2
  • cuDNN 8.0.0
  • TensorRT 7.1.3
  • VisionWorks 1.6
  • OpenCV 4.1
  • Vulkan 1.2
  • VPI 0.3 (Developer Preview)
  • Nsight Systems 2020.2
  • Nsight Graphics 2020.1
  • Nsight Compute 2019.3

Existing installations of JetPack 4.4 Developer Preview and JetPack 4.3 can be upgraded in-place to the JetPack 4.4 production release without re-flashing the device. For more information about upgrading JetPack via the Debian package management tool, please refer to the JetPack documentation here.

Download JetPack…https://developer.nvidia.com/embedded/jetpack

JetPack Release Notes…https://docs.nvidia.com/jetson/jetpack/release-notes/index.html

L4T Release Notes…https://developer.nvidia.com/embedded/secure/tools/files/jetpack-sdks/jetpack-4.4-ga/Jetson_Linux_Driver_Package_Release_Notes_R32.4.3_GA.pdf

Note: Jetpack/L4T upgrade using debian package management tool is now fixed and reenabled.

We had temporarily disabled the feature of upgrading JetPack or L4T using debian package management tool due to an issue we found in one of our debian packages causing the device to not boot properly. We have fixed this issue now and have reenabled this feature. We are sorry for the inconvenience caused.

Re: update issue breaking boot. Out of curiosity, that wouldn’t happen to be an error like:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device

I’ve had one person on my issues reporting it, and I experienced it myself yesterday. Oddly, it fixed itself for me after several reboots.

Anyway, I would appreciate any insight into what caused this since how exactly it fixed itself is a mystery to me.

Edit: my NX won’t boot after the bootloader upgrade either. I haven’t checked the serial console yet, but I expect it’s the same error. I just ran the update and upgrade, so it appears whatever package (bootloader?) is causing this is still available.

Return to sender.

Is it possible to install lightweight linux package on jetson nano and xavier nx? because in jetson nano the start up jetpack of linux used 800 MB, this is very high. How I can reduce this value?

1 Like
sudo systemctl isolate multi-user.target

Will switch to command line mode.

If you want to make the change persistent across reboots:

sudo systemctl set-default multi-user.target

Change multi-user.target to graphical.target if you want to go back.

For more savings you can turn off services like docker and sshd. To stop a service:

sudo systemctl stop docker

To disable a service across reboots:

sudo systemctl disable docker

Thanks,
What’s difference between service gdm stop with your first suggest command?

Yw, @LoveNvidia

Stopping the gdm service will only work if you’re using gdm, and it’ll only stop gdm, not any other services graphical.target might depend on. .target units are the systemd equivalent of runlevels, basically.

An added note about this beyond what @mdegans mentioned…

Gdm is a login service designed to run in X and to overwrite itself with a desktop manager after authentication is complete. Stopping this stops the login manager from creating a GUI login screen. The desktop manager could in theory still be called. If you were to disable the desktop manager, then the GUI would still run a login screen, but launching the desktop manager would in theory not work (in reality, if gdm calls the binary executable and not the service, then the desktop manager would still run, but it is all about the idea).

@linuxdev @mdegans Thanks.
Which ones are efficient way for reduce the memory usage and only work with ssh, but show some results like cv2.imshow() methods in ssh mode ?

cv2.imshow() will not work effeciently no matter what you do over ssh (or any remote desktop method). My best adivice for this is to encode a video stream, and send the video stream over the network. You can use cv2.VideoWriter and a GStreamer pipeline for that. Then you can connect to the output with vlc (or your favorite player supporting network sources). Please start a new thread and @ me if you want an example pipeline string to stick in VideoWriter.

Hello

Good News for this new production release

i want to ask if with this new release we can use FFmpeg for Decode & encode with Gpu

h264_nvnec & h264_ cuvid

nvenc hardware acceleration with jetson nano

How do you check/confirm this release version on the command line? Thx

Hi @amirtousa, if you check the /etc/nv_tegra_release file, you should see the L4T version:

$ cat /etc/nv_tegra_release
# R32 (release), REVISION: 4.3, GCID: 21589087, BOARD: t186ref, EABI: aarch64, DATE: Fri Jun 26 04:34:27 UTC 2020

In this case, JetPack 4.4 production release is L4T R32.4.3.

For later releases, see also the command:
dpkg -l | grep 'nv-l4t-core'

/etc/nv_tegra_release has been added back in for a few releases now (it now just contains the L4T version info from my post above, as opposed to hashes of all the L4T files like previously)

But linuxdev is correct, there may be some previous releases without that file, and for those you can check the dpkg version. In this script I check for both.