New to Claude Skills? Learn how to install them →

Jnvidia on GitHub

Jetson Memory Optimizer

OfficialFree

Optimize DRAM usage for Jetson devices.

by nvidia2.8k stars on nvidia/skills
1 views
Updated Aug 7, 2026
Get this skill

Free · Opens the source repo

What Jetson Memory Optimizer does

The Jetson Memory Optimizer skill is designed specifically for developers and engineers working with NVIDIA Jetson platforms. It allows users to reclaim dynamic random-access memory (DRAM) by disabling unused subsystems across various boot layers, including MB1 BCT, MB2 BCT, kernel reserved-memory, and SWIOTLB. This skill is particularly useful for headless or no-camera Jetson deployments, where memory efficiency is crucial. By following the provided scenario recipes, users can effectively manage memory carveouts and ensure optimal performance of their Jetson devices.

To use the skill, users must adhere to strict guidelines that outline how to disable specific memory carveouts and clusters. The skill requires the user to issue explicit overrides for each cluster as defined in the scenario recipes. This ensures that the system is configured correctly and that unnecessary resources are not allocated, which can lead to improved performance and reduced memory usage. The skill also emphasizes the importance of verifying the merged binaries after making changes to ensure that the intended optimizations are applied correctly.

The skill is particularly beneficial for developers looking to deploy Jetson devices in environments where camera and display functionalities are not required. By disabling these unused components, users can free up valuable memory resources, which can be redirected to other critical processes. This is essential in applications where memory constraints are a significant concern, such as in edge computing or IoT scenarios.

However, users should note that this skill is not intended for CPU or GPU frequency tuning, and it is critical to follow the outlined rules and verification steps to avoid misconfigurations that could lead to system instability. The Jetson Memory Optimizer skill is a powerful tool for those seeking to maximize the efficiency of their Jetson deployments while minimizing unnecessary memory usage.

When to use it

Use this skill when deploying Jetson devices in headless or no-camera configurations to maximize available memory.

When not to use it

This skill is not suitable for general-purpose memory tuning or for scenarios requiring active camera or display functionalities.

What you can build with it

Headless Deployment

Deploy Jetson devices without a display, reclaiming memory by disabling display subsystems.

No-Camera Configuration

Optimize Jetson devices for applications that do not require camera functionality, freeing up memory resources.

Resource-Constrained Environments

Use the skill in edge computing scenarios where memory efficiency is critical for performance.

How to install Jetson Memory Optimizer

View source

1. Install with the skills CLI

npx skills add nvidia/skills/jetson-optimize-memory --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by nvidia

jetson-optimize-memory

Memory is reserved across four layers ordered by boot chronology (higher row = earlier in boot, closer to hardware):

LayerContentKey files
MB1 BCTfirmware carveoutsper-module misc DTS
MB2 BCTfirmware loading + AST controlsper-module misc DTS
Kernel DTSreserved-memory and driver bindingper-module DTS
SWIOTLBDMA bounce pool size<module>.conf.common (CMDLINE_ADD)

Critical rules:

  • Only the scenarios in Scenario recipes are validated. Refuse any request to disable a carveout/cluster/node not in that table.
  • Zeroing a carveout requires both: disabling the cluster's loading controls AND removing the AST that references it.
  • Emit explicit overrides for every cluster in the recipe, regardless of how the source #ifdef/#else looks. Verify the merged binary.
  • GPU SW stack must match the chip: T234 -> nvgpu, T264 and later -> OpenRM. Follow the shared derived-platform rule in target-platform-contract.md; stop on mismatches instead of guessing.
  • Do not set SWIOTLB to 0 — some peripherals can't use the IOMMU.

Scenario recipes

KeywordMB1 BCT carveoutsMB2 BCTKernel DTS
headlessDCE-family (see chip table)DCE auxp_controls + DCE AST(s)display@<addr> (and dce@<addr> if exposed) → disabled
no-cameraRCE/VI/ISP-familyRCE auxp_controls (each instance) + RCE AST(s)recommended: VI/ISP/NVCSI → disabled

Chip-specific carveouts

ScenarioT234 (Orin)T264 (Thor)
headlessCARVEOUT_BPMP_DCE, CARVEOUT_DCE, CARVEOUT_DCE_TSEC, CARVEOUT_TSEC_DCE, CARVEOUT_DISP_EARLY_BOOT_FBCARVEOUT_DCE, CARVEOUT_TSEC_DCE, CARVEOUT_HPSE_DCE, CARVEOUT_DISP_EARLY_BOOT_FB
no-cameraCARVEOUT_RCE, CARVEOUT_CAMERA_TASKLISTCARVEOUT_RCE, CARVEOUT_RCE1, CARVEOUT_RCE_RW, CARVEOUT_VI_TASKLIST, CARVEOUT_VI1_TASKLIST, CARVEOUT_ISP_TASKLIST, CARVEOUT_ISP1_TASKLIST

Post-boot: headlesssudo systemctl set-default multi-user.target.


MB1 BCT carveout overrides

File: Linux_for_Tegra/bootloader/generic/BCT/tegra<chip>-mb1-bct-misc-<module>.dts (e.g. tegra234-mb1-bct-misc-p3767-0000.dts for Orin Nano, tegra264-mb1-bct-misc-p3834-0008-p4071-0000.dts for Thor).

For each carveout, add inside the existing carveout node:

aux_info@<CARVEOUT_NAME> {
    pref_base = <0x0 0x0>;
    size      = <0x0 0x0>;
    alignment = <0x0 0x0>;
};

MB2 BCT cluster + AST overrides

File: Linux_for_Tegra/bootloader/generic/BCT/tegra<chip>-mb2-bct-misc-<module>.dts (includes tegra<chip>-mb2-bct-common.dtsi).

For each target cluster:

  1. Override auxp_controls@<index>:
    auxp_controls@<index> {
        enable_init    = <0>;
        enable_fw_load = <0>;
        enable_unhalt  = <0>;
    };
    
  2. /delete-node/ auxp_ast_config@<idx>;

Look up indices in common.dtsi: auxp_controls@N carries a comment naming its cluster; auxp_ast_config@N has ast_region children whose carveout = <CARVEOUT_…>; lines identify the owner.


Kernel DT reserved-memory

DTB=Linux_for_Tegra/kernel/dtb/<platform-dtb-name>.dtb
dtc -I dtb -O dts -o /tmp/platform.dts $DTB
# edit: status = "disabled" on target nodes
dtc -I dts -O dtb -o $DTB /tmp/platform.dts

Display — disable display@<addr>, plus dce@<addr> if exposed as a separate kernel node.

Camera — under host1x@<addr>, disable whichever of vi* / isp* / nvcsi exist on the BSP (only emit present nodes):

Locate the display controller node in the decompiled DTS and disable it. The node's unit address is chip-specific — find it by compatible string (e.g. nvidia,tegra234-display) rather than hard-coding the address.

host1x@<addr> {
    vi0@<addr>   { status = "disabled"; };
    vi1@<addr>   { status = "disabled"; };
    isp@<addr>   { status = "disabled"; };
    isp1@<addr>  { status = "disabled"; };
    nvcsi@<addr> { status = "disabled"; };
};

SWIOTLB DMA bounce pool

The NVIDIA IOMMU covers peripheral DMA, so SWIOTLB is rarely used. Edit CMDLINE_ADD (never CMDLINE) in Linux_for_Tegra/<module>.conf.common:

# Total bytes = swiotlb_value × 2048; 4 MiB pool:
CMDLINE_ADD="... swiotlb=2048"

Override verification (mandatory)

After every patched MB1/MB2 BCT .dts, reproduce the BSP's compile + decompile using the same -D… flags from bct_flags.append(...) in bootloader/tegraflash_impl_t<chip>.py:

gcc -E -nostdinc -x assembler-with-cpp \
    -DENABLE_<FLAG_1> -DENABLE_<FLAG_2> \
    -I bootloader -I bootloader/generic/BCT \
    -o /tmp/cpp.dts <patched-bct.dts>
dtc -q -I dts -O dtb -o /tmp/cpp.dtb /tmp/cpp.dts
dtc -q -I dtb -O dts /tmp/cpp.dtb | less

Confirm in the merged output:

  • Each zeroed aux_info@<NAME> (or aux_info@<id>U post macro expansion) has size = <0x0 0x0> and pref_base = <0x0 0x0>.
  • Each disabled auxp_controls@<idx> has all three enable_* fields <0>.
  • Each /delete-node/'d auxp_ast_config@<idx> is absent.

Verification (on booted target)

sudo cat /proc/iomem | grep -iE 'nv-reserved|cma|fb|carveout'
ls /proc/device-tree/reserved-memory/
dmesg | grep -iE 'firmware|carveout|bpmp|reserved|fail|error' | head -20
free -m
ScenarioSysfsdmesg grep
Display offls /sys/class/drm/ (empty)tegra-drm|nvdisplay|dce|host1x|fb0
Camera offls /dev/video* 2>/dev/null (none)rce|nvcsi|tegra-camera|vi0|vi1|isp
SWIOTLB shrinkcat /sys/kernel/debug/swiotlb/io_tlb_nslabs matches cmdlineswiotlb

For SWIOTLB: /proc/cmdline must contain swiotlb=<value>, and watch -n5 cat /sys/kernel/debug/swiotlb/io_tlb_used must stay under io_tlb_nslabs during full workload — if exceeded, restore original CMDLINE_ADD and re-flash kernel-dtb.

Purpose

Cut the unused DRAM carveouts that ship enabled in the reference BSP when a Jetson deployment skips display, camera, or other peripherals, freeing the freed bytes for the application. Always edits the four layers in boot order so an early-stage carveout never outranks a later-stage shrink.

Prerequisites

  • Active target profile resolved per ../../context/target-platform-contract.md.
  • BSP image extracted and source tree initialized (/jetson-init-image, /jetson-init-source complete).
  • For headless / no-camera recipes: confirm the workload truly does not need display or camera.

Limitations

  • Only the validated recipes (headless, no-camera, swiotlb) are exposed; ad-hoc subsystem disables outside the recipe set are refused.
  • SWIOTLB shrink is bounded by peak in-flight DMA — exceeding the new io_tlb_nslabs requires reverting the change.
  • BPMP-DTB edits land in the overlay tracker only after Customize + Build + Deploy run; this skill does not flash on its own.

Troubleshooting

  • Boot fails after MB1 BCT carveout disable — restore the pristine misc DTS and re-flash; the missing carveout is mandatory for the active SoC.
  • io_tlb_used exceeds io_tlb_nslabs — revert swiotlb= in CMDLINE_ADD and re-flash the kernel DTB partition.
  • Reclaimed delta smaller than expected — verify the recipe truly matched the deployment (e.g. display still attached); use the dmesg | grep -iE 'firmware|carveout' check in this file to confirm.
  • Validation dmesg shows the disabled subsystem still probing — the change probably did not promote through to bsp_image; re-run /jetson-promote-image.

Frequently asked questions about Jetson Memory Optimizer

Similar skills