JetPack, L4T, Ubuntu, Kernel, UEFI: What’s the Relationship?
When you first start using Jetson, there’s one question almost everyone hits: how many “system versions” does a Jetson actually have?
You may have seen completely different numbers in different places:
JetPack 6.2.3
L4T / Jetson Linux R36.5.2
Ubuntu 22.04
Linux Kernel 5.15
UEFI 36.5.2
Looks like five systems. But actually, these are all different layers of the same Jetson software stack.
The most important thing about these concepts isn’t memorizing definitions — it’s building this awareness:
Jetson’s software isn’t just “Ubuntu + NVIDIA GPU drivers.” It’s a complete platform that spans boot firmware, the Linux kernel, the Ubuntu user space, all the way up to CUDA / TensorRT acceleration packages.
Let’s start with one diagram showing how they include each other.
JetPack
|
+-- Jetson Linux / L4T
| |
| +-- UEFI
| +-- Linux Kernel
| +-- NVIDIA Drivers
| +-- Ubuntu RootFS
|
+-- CUDA
+-- TensorRT
+-- cuDNN
+-- VPI
+-- ...
This diagram isn’t complete, but it captures the relationships between the terms in this article. A more comprehensive architecture diagram is at the end.
JetPack
You can think of JetPack as the full software development environment NVIDIA provides for Jetson edge computing devices. It doesn’t just include OS-related components — it also bundles security packages and AI acceleration packages.
So when someone asks “what JetPack are you using?”, they’re really asking:
Which NVIDIA Jetson software platform are you currently running?
JetPack is, in effect, the top-level “software collection.”
If you have a Jetson with a system already on it, you can query the JetPack version directly in the terminal:
seeed@ubuntu:~$ dpkg -l | grep nvidia-jetpack
ii nvidia-jetpack 6.2.1+b38 arm64 NVIDIA Jetpack Meta Package
ii nvidia-jetpack-dev 6.2.1+b38 arm64 NVIDIA Jetpack dev Meta Package
ii nvidia-jetpack-runtime 6.2.1+b38 arm64 NVIDIA Jetpack runtime Meta Package
The output shows the current device is running JetPack 6.2.1.
Jetson Linux / L4T
If JetPack is Jetson’s “complete software”, then Jetson Linux / L4T is the underlying system that Jetson actually needs to run. Let’s first clear up the relationship between Jetson Linux and L4T:
L4T is the old/technical name; Jetson Linux is the name NVIDIA now prefers. You can treat them as the same thing.
For brevity, we’ll use L4T to mean Jetson Linux / L4T for the rest of this article.
L4T stands for: Linux for Tegra.
Tegra is the SoC platform that NVIDIA Jetson uses, so L4T can be understood as:
A Linux BSP (Board Support Package) customized by NVIDIA specifically for Jetson hardware.
Here a new term appears: BSP, Board Support Package. Its job isn’t simply to provide a Linux desktop — it’s to connect Linux to the actual Jetson hardware.
You can think of it as:
Jetson Linux / L4T
|
+---------------+---------------+
| | |
v v v
UEFI Linux Kernel Ubuntu RootFS
| | |
Boots the Manages hardware User space
system |
|
NVIDIA Drivers
|
Jetson Hardware
So L4T isn’t a single software component — it’s a whole underlying system environment.
It typically includes:
- UEFI / Bootloader: handles early boot and bootstrapping once power is on.
- Linux Kernel: the core of Linux — CPU scheduling, memory management, process management, and the hardware driver framework.
- Device Tree: describes what hardware exists on the board and how it’s wired up.
- NVIDIA Drivers: NVIDIA-provided drivers for Jetson hardware, supporting GPU, ISP, NVCSI, and more.
- Ubuntu RootFS: Jetson’s user space — the Ubuntu desktop environment we see and use daily.
- …
The important point: Jetson isn’t an ordinary ARM Linux machine. It has a lot of NVIDIA-specific hardware — GPU, NVCSI, VI, etc. For these to work, you need Device Tree, Kernel drivers, Firmware, and NVIDIA drivers working together. And this low-level support isn’t part of stock Ubuntu — L4T is what provides it.
So:
What actually lets Ubuntu run on Jetson hardware is L4T.
This article introduces a lot of new terms. You don’t need to deeply understand every component yet — just build a rough mental map first. We can dive into the details when they actually come up in real troubleshooting work.
Use the following command to check your Jetson’s L4T version:
seeed@ubuntu:~$ cat /etc/nv_tegra_release
# R36 (release), REVISION: 4.3, GCID: 38968081, BOARD: generic, EABI: aarch64, DATE: Wed Jan 8 01:49:37 UTC 2025
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
The output shows the current device is running L4T version 36.4.3.
Note: JetPack and L4T have a strict one-to-one correspondence. You can look up all NVIDIA-released JetPack versions at https://developer.nvidia.com/embedded/jetson-linux-archive.
Ubuntu: the user space you interact with most on Jetson
On Jetson, Ubuntu is the layer we see and use most directly in our daily work.
When you boot into the desktop, open a terminal, and run:
apt install
python3
docker
systemctl
cd /home
All of these operations happen in the Ubuntu user space. That’s why many people think “the system running on Jetson is Ubuntu.” If you’ve read this far, you can already tell that statement isn’t wrong — but it’s incomplete. The more accurate version is: L4T uses Ubuntu as its RootFS and user-space base, but Ubuntu is not the entire Jetson system.
In other words: Ubuntu provides the channel through which users and applications actually use the machine.
What directly manages Jetson hardware, on the other hand, is mainly:
Linux Kernel
NVIDIA Drivers
Device Tree
Firmware
We’ll go deeper into those in later articles. For now, two key points to remember:
- When people say
the system is installed on NVMe, they usually meanthe Ubuntu RootFS lives on NVMe. - Ubuntu is only the user-space part of Jetson Linux — not the whole system. That’s why two Jetsons can both run Ubuntu 22.04 yet behave quite differently. For example, both L4T R36.4.x and L4T R36.5.x use Ubuntu 22.04 as their filesystem, but their Kernel and NVIDIA Driver versions differ.
Run cat /etc/os-release on the Jetson to check the Ubuntu version:
Linux Kernel
If Ubuntu is the “user space” we see and use every day, then the Linux Kernel is the core that actually manages hardware and system resources.
It sits between Ubuntu and the hardware: Application -> Ubuntu -> Linux Kernel -> Drivers -> Jetson
Simply put:
Ubuntu talks to the user; the Kernel talks to the hardware.
The Linux Kernel does a lot — the most important are CPU scheduling, memory management, process management, and so on.
As an example, look at what happens when you plug in a USB camera — before /dev/video0 appears, this is roughly what runs:
USB Camera
|
v
USB Controller
|
v
Kernel USB Driver
|
v
/dev/video0
|
v
Application
In the Jetson terminal, uname -r shows the Linux Kernel version:
seeed@ubuntu:~$ uname -r
5.15.148-tegra
UEFI
If Ubuntu is the user space and the Linux Kernel is the system core, then UEFI is the critical layer that “gets the system up” before Linux actually starts. UEFI stands for Unified Extensible Firmware Interface — think of it as the modern replacement for the legacy BIOS.
On Jetson, UEFI takes the device from “hardware just powered on” to “Linux Kernel is ready to run.” This work includes initializing the boot environment, identifying bootable devices, reading boot configuration, loading the Kernel, loading initrd, loading the Device Tree, and finally handing control over to Linux.
For now, just keep this simple picture in mind:
Power On -> UEFI -> Linux Kernel -> Ubuntu RootFS
That means:
While UEFI is running, the Linux Kernel hasn’t actually started yet — and Ubuntu certainly hasn’t.
A few things worth noting:
- Many Jetson Orin devices keep their boot firmware in QSPI NOR Flash. Even if your Ubuntu RootFS is on NVMe, the device still needs UEFI in QSPI before it can boot.
- If your Jetson doesn’t boot, the first thing to check is the UEFI logs at startup — the root cause is very often hiding there.
- UEFI decides where to boot the Linux Kernel from. When the NVIDIA logo appears on Jetson power-on, you can press
ESCorF1on a keyboard to enter the UEFI Setup page.
In the Jetson terminal, run cat /sys/class/dmi/id/bios_version to check the UEFI version:
Wrapping up: a map of the stack
Today’s article grouped the most common boot-related concepts in the Jetson software stack together. The point was to give you a quick mental map. The most important takeaway isn’t memorizing every term’s definition — it’s the basic understanding that these concepts aren’t independent systems; they’re layers of the same Jetson software stack. Once you have that foundation, both troubleshooting Jetson boot issues and communicating technical details with other developers becomes much smoother.
Of course, today only covered a small slice of the Jetson boot story. More details are available on NVIDIA’s website.
Image source: https://developer.nvidia.com/embedded/jetpack
We’ll continue along this boot chain in upcoming articles — gradually unpacking the full process from power-on, firmware initialization, and Kernel loading all the way to entering Ubuntu — then transitioning to hardware interfaces, cameras, robot control, and more. If there’s a topic you’d like covered, leave a comment or send a message.
Next article, we start from the most basic question:
From power-on to Ubuntu, what exactly does Jetson go through?