>-
Automate repetitive workflows and reduce manual effort
Example: Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example: Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example: Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
Time estimate: 15-45 minutes depending on use case complexity
Prerequisites
Submit your Claude Code skill and start earning
epx add nvidia/skills/jetson-optimize-memoryCompatible with
Supported agents
| name | jetson-optimize-memory |
| description | >- Reclaim DRAM by disabling unused subsystems across MB1 BCT, MB2 BCT, kernel reserved-memory, and SWIOTLB. Use for headless or no-camera Jetson deployments; not for CPU/GPU frequency tuning. |
| version | 0.0.1 |
| license | "Apache-2.0" |
| argument-hint | "headless | no-camera | swiotlb" |
| metadata | data-classification: public author: "Jetson Team" tags: - memory - dram - carveout - swiotlb domain: memory |
Memory is reserved across four layers ordered by boot chronology (higher row = earlier in boot, closer to hardware):
| Layer | Content | Key files |
|---|---|---|
| MB1 BCT | firmware carveouts | per-module misc DTS |
| MB2 BCT | firmware loading + AST controls | per-module misc DTS |
| Kernel DTS | reserved-memory and driver binding | per-module DTS |
| SWIOTLB | DMA bounce pool size | <module>.conf.common (CMDLINE_ADD) |
Critical rules:
#ifdef/#else looks. Verify the merged binary.target-platform-contract.md; stop on mismatches instead of guessing.| Keyword | MB1 BCT carveouts | MB2 BCT | Kernel DTS |
|---|---|---|---|
headless | DCE-family (see chip table) | DCE auxp_controls + DCE AST(s) | display@<addr> (and dce@<addr> if exposed) → disabled |
no-camera | RCE/VI/ISP-family | RCE auxp_controls (each instance) + RCE AST(s) | recommended: VI/ISP/NVCSI → disabled |
| Scenario | T234 (Orin) | T264 (Thor) |
|---|---|---|
headless | CARVEOUT_BPMP_DCE, CARVEOUT_DCE, CARVEOUT_DCE_TSEC, CARVEOUT_TSEC_DCE, CARVEOUT_DISP_EARLY_BOOT_FB | CARVEOUT_DCE, CARVEOUT_TSEC_DCE, CARVEOUT_HPSE_DCE, CARVEOUT_DISP_EARLY_BOOT_FB |
no-camera | CARVEOUT_RCE, CARVEOUT_CAMERA_TASKLIST | CARVEOUT_RCE, CARVEOUT_RCE1, CARVEOUT_RCE_RW, CARVEOUT_VI_TASKLIST, CARVEOUT_VI1_TASKLIST, CARVEOUT_ISP_TASKLIST, CARVEOUT_ISP1_TASKLIST |
Post-boot:
headless→sudo systemctl set-default multi-user.target.
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>;
};
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:
auxp_controls@<index>:
auxp_controls@<index> {
enable_init = <0>;
enable_fw_load = <0>;
enable_unhalt = <0>;
};
/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.
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"; };
};
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"
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:
aux_info@<NAME> (or aux_info@<id>U post macro expansion)
has size = <0x0 0x0> and pref_base = <0x0 0x0>.auxp_controls@<idx> has all three enable_* fields <0>./delete-node/'d auxp_ast_config@<idx> is absent.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
| Scenario | Sysfs | dmesg grep |
|---|---|---|
| Display off | ls /sys/class/drm/ (empty) | tegra-drm|nvdisplay|dce|host1x|fb0 |
| Camera off | ls /dev/video* 2>/dev/null (none) | rce|nvcsi|tegra-camera|vi0|vi1|isp |
| SWIOTLB shrink | cat /sys/kernel/debug/swiotlb/io_tlb_nslabs matches cmdline | swiotlb |
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.
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.
../../context/target-platform-contract.md./jetson-init-image, /jetson-init-source complete).headless, no-camera, swiotlb) are
exposed; ad-hoc subsystem disables outside the recipe set are
refused.io_tlb_nslabs requires reverting the change.io_tlb_used exceeds io_tlb_nslabs — revert swiotlb= in
CMDLINE_ADD and re-flash the kernel DTB partition.dmesg | grep -iE 'firmware|carveout' check in this file to confirm.dmesg shows the disabled subsystem still probing —
the change probably did not promote through to bsp_image; re-run
/jetson-promote-image.AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionjetson-optimize-memoryExecute the skills CLI command in your project's root directory to begin installation:
epx add nvidia/skills/jetson-optimize-memoryFetches jetson-optimize-memory from nvidia/skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
.cursor/skills/jetson-optimize-memory
Restart Cursor to activate jetson-optimize-memory. Access via /jetson-optimize-memoryin your agent's command palette.
Learn more:View source on GitHubSkills CLI docsAbout CursorWhat are agent skills?
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
jetson-customize-mgbe
nvidia/skills · jetson · same repo
jetson-customize-uphy
nvidia/skills · jetson · same repo
jetson-set-target
nvidia/skills · jetson · same repo
jetson-quick-start
nvidia/skills · jetson · same repo
jetson-flash-image
nvidia/skills · jetson · same repo
jetson-llm-serve
nvidia/skills · jetson · same repo
I recommend jetson-optimize-memory for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
Keeps context tight: jetson-optimize-memory is the kind of skill you can hand to a new teammate without a long onboarding doc.
jetson-optimize-memory has been reliable in day-to-day use. Documentation quality is above average for community skills.
jetson-optimize-memory reduced setup friction for our internal harness; good balance of opinion and flexibility.
Registry listing for jetson-optimize-memory matched our evaluation — installs cleanly and behaves as described in the markdown.
jetson-optimize-memory fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
jetson-optimize-memory is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Keeps context tight: jetson-optimize-memory is the kind of skill you can hand to a new teammate without a long onboarding doc.
jetson-optimize-memory reduced setup friction for our internal harness; good balance of opinion and flexibility.
jetson-optimize-memory fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
showing 1-10 of 45