feat: add support for Jetson Orin Nano and AGX Orin SBCs

[gooosetavo]

Goal: add support for Jetson Orin Nano and AGX Orin SBCs

I added two new installers, jetson_orin_nano and jetson_agx_orin, with their own model-specific configs.
The big change under the hood is switching from the OE4T U-Boot fork to U-Boot v2026.01. This gives the project better upstream support going forward, since OE4T hadn't been updated in some time. Mainline U-Boot doesn't have Tegra234 configs needed for the Orin boards yet, so I'm pulling the binaries from NVIDIA's L4T r36.4.4 BSP. Not ideal long-term, but it works and uses NVIDIA's validated device trees. The original nano project does have these defined in the u-boot project, though.

Summary:

1. Project has three installers total now: original Jetson Nano plus two new Orin variants
2. Build system handles multiple targets - common U-Boot build gets shared across models
3. There's some efficiency that could probably be gained by doing a multi-stage docker file, or sharing files between stages, but I'm not sure how to do this with the Sidero build system (no idea where the documentation is for this). Hope someone can help clean that up.

I'll give this a spin on my Orin Nano (p3766) board later this week and let you guys know how that goes!

Additional references:

• Relevant Tegra board U-boot listings.
• https://developer.nvidia.com/embedded/jetson-linux-archive
  • latest release compatible w/ orin nano is 36.4.4 GA. Last update: June 26, 2025
• 36.4.4 build bundle: https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v4.4/release/Jetson_Linux_r36.4.4_aarch64.tbz2
  • docs: https://developer.nvidia.com/embedded/jetson-linux-r3644
  • jetson-linux-r3644 dev guide: https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/index.html

[smira]

I'll give this a spin on my Orin Nano (p3766) board later this week and let you guys know how that goes!

thank you, please let us know how it goes!

[frezbo]

@gooosetavo doesn;t these boards support native UEFI boot? If so I'm inclined to go in that direction

[gooosetavo]

@gooosetavo doesn;t these boards support native UEFI boot? If so I'm inclined to go in that direction

I'm not sure, but I'll give that a shot!

[gooosetavo]

I finally got a chance to verify and yeah, like @frezbo said, these new boards support UEFI.

I was able to flash an SD card with a vanilla Talos image (see link for the factory config used) and it booted right up, allowing me to connect w/ talosctl. Awesome!

I haven't completed the bootstrapping, but looking good so far.

[github-actions]

This PR is stale because it has been open 45 days with no activity.

[mmalyska]

@gooosetavo any success? I was trying to make it work for a long time. I've already tried UEFI option, but the nvidia extensions are not supporting jetson modules due to the differences in kernel modules(nvidia modules build for jetson are built as OOT modules with manual changes in linux kernel to make them work).
Here are some PR from my trial and error siderolabs/pkgs#1166 and siderolabs/extensions#624, but non of them in the end worked for me due to the limited time.

[schwankner]

Hi all,

Confirming that UEFI boot works great on the Orin NX 16 GB (same T234 SoC).

On the GPU/nvidia extension side — I have a working solution to the OOT module problem described in this thread. The blocker is that CONFIG_TEGRA_GK20A_NVHOST=y in the mainline kernel can't be overridden by an extension. I solved it with a small shim module (nvhost-ctrl-shim) that provides /dev/nvhost-ctrl without any host1x dependency, so nvgpu builds cleanly with CONFIG_TEGRA_GK20A_NVHOST=n.

Full setup running on Talos v1.12.6 with CUDA inference in Kubernetes pods, no privileged: true:
https://github.com/schwankner/talos-jetson-orin

Just posted details on pkgs#1166 as well — happy to help get this unblocked.

[frezbo]

@schwankner great work, Talos 1.13 moved to using cdi and gpu-operator, some questions, I'm trying to understand:

• what if CONFIG_TEGRA_GK20A_NVHOST is set to m, since y means it's hard to disable
  and disable loading of kernel one by modules.load.d denylist?
• is there some docs on host1x, i'm trying to understand what it provides

I'm also suprised the l4t now builds mostly fine with LTS kernel 😅

[mmalyska]

@frezbo unfortunately Nvidia Jetson is not supported by gpu-operator https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/platform-support.html#supported-arm-based-platforms (information in note).
I'm working on enabling jetson using CSV as CDI is not supported by default by nvidia-toolkit for tegra iGPU.

@schwankner That's nice achievement. I'll take a look at your solution :)

[frezbo]

@frezbo unfortunately Nvidia Jetson is not supported by gpu-operator https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/platform-support.html#supported-arm-based-platforms (information in note). I'm working on enabling jetson using CSV as CDI is not supported by default by nvidia-toolkit for tegra iGPU.

@schwankner That's nice achievement. I'll take a look at your solution :)

got it, I'm looking forward to getting this merged

[schwankner]

@frezbo Thanks for the questions — and to correct my earlier post which mentioned Talos v1.12.6, I'm already running v1.13.0-rc.0.

CONFIG_TEGRA_GK20A_NVHOST=m + denylist

CONFIG_TEGRA_GK20A_NVHOST is part of nvgpu's own OOT Kbuild, not a standard kernel Kconfig. Since nvgpu itself is CONFIG_GK20A=m (an OOT module), NVHOST=y/n just controls what gets compiled into nvgpu.ko — there is no =m that would produce a separately denylistable .ko.

The deeper issue: the mainline drivers/gpu/host1x/ does not have the HOST1X_SYNCPT_GPU allocation flag that nvgpu needs when it allocates syncpoints for GPU channels (NVHOST=y path). The OE4T linux-nv-oot tree provides a patched host1x that adds this.

The approach that works:

1. Build nvgpu with CONFIG_TEGRA_GK20A_NVHOST=y against the OE4T host1x
2. Install the OE4T host1x.ko at kernel/drivers/gpu/host1x/ in the extension rootfs — Talos's squashfs overlay loads this instead of the in-tree module at boot
3. The OE4T host1x exports the kernel-internal API nvgpu needs: host1x_syncpt_alloc (with HOST1X_SYNCPT_GPU), host1x_fence_create, etc.
4. nvhost-ctrl-shim separately provides /dev/nvhost-ctrl — the userspace-facing character device that libnvrm_host1x.so (JetPack 6 CUDA runtime) calls directly

The separation matters: nvgpu uses the OE4T host1x internally for GPU syncpoint operations. The shim provides the /dev/nvhost-ctrl ioctl interface that CUDA userspace calls independently for stream synchronization.

What host1x provides (and where the shim fits)

host1x is Tegra's syncpoint controller — hardware 32-bit counters the GPU increments when it finishes a kernel, which the CPU can wait on via interrupt. In L4T, the full nvhost companion (drivers/video/tegra/host/) exposes these syncpoints to userspace via /dev/nvhost-ctrl. That framework is proprietary and not in the OE4T tree.

nvhost-ctrl-shim fills exactly that gap: a standalone cdev that registers on module_init (no nvgpu dependency) and implements the NVHOST ioctl interface over the OE4T host1x kernel API. CUDA 12.6's (libnvrm_host1x.so) actual call sequence:

1. GET_CHARACTERISTICS (nr=14) — once at init, discovers num_syncpts=704 for Orin
2. SYNCPT_WAITMEX (nr=9) — per token, interrupt-driven wait via dma_fence_wait_timeout() — this is what replaces CPU polling
3. POLL_FD_CREATE (nr=16) — once during GPU frequency-scaling init (gk20a_scale_init)

The shim implements 8 ioctls total; the three above are what CUDA 12.6 actually calls.

Talos 1.13 / CDI

After posting that initial comment I put together a test branch targeting Talos 1.13.0-rc.0 to verify everything end-to-end and clean up what's no longer needed. The upgrade went through without issues.

The biggest simplification: CDI is enabled by default in containerd in Talos 1.13 (enable_cdi = true, cdi_spec_dirs = ["/run/cdi"]), so the containerd.toml override I had before is gone entirely. machine-patch-cdi.yaml now only sets node labels — CDI itself needs no configuration. The nvidia-cdi-setup DaemonSet writes /run/cdi/nvidia-jetson.yaml at boot and that's all containerd needs.

No gpu-operator involved — as @mmalyska noted, Jetson isn't supported there. The CDI path works directly with containerd's built-in support.

[frezbo]

yup let's work on getting this merged

@schwankner if you're on the community slack, mind sending me a hi?

[schwankner]

I created the PR siderolabs/pkgs#1518.