Jetson Memory Optimizer
Reclaim unused DRAM on headless or no-camera Jetson deployments.
The skill scopes actions, forbids setting SWIOTLB to 0, and specifies verification and rollback; however, it modifies BCTs, DTBs, boot targets, and potentially flashed partitions without a unified pre-execution confirmation, automatic backup, or complete recovery procedure, so points are deducted. No credential handling or covert exfiltration is shown. NVIDIA's official provenance supports attribution and governance only.
The four-layer ordering, compile/decompile checks, diagnostics, and rollback paths are detailed and broadly consistent; however, execution depends on the BSP, dtc, gcc, chip-specific sources, an external target-platform-contract.md, and index discovery not supplied here. There are no skill-specific executable scripts or key-path tests, so the static score is capped at 10 and reduced for uncertainty.
The headless, no-camera, and swiotlb scenarios, T234/T264 differences, and refusal boundaries are clear, and the skill explicitly excludes frequency tuning; however, input/output contracts, negative trigger conditions, and broader Jetson/BSP version boundaries are incomplete. The material provides no Chinese-language support guidance, so points are deducted. The core function is local-BSP based rather than dependent on overseas services, so no mainland-network deduction is applied.
SKILL.md provides frontmatter, versioning, an argument hint, prerequisites, limitations, troubleshooting, and verification sections, while the skill card identifies NVIDIA as owner; however, recommended Instructions and Examples sections are absent, version 0.0.1 has no changelog or explicit maintenance update path, and the supplied license metadata is NOASSERTION while the files state both Apache-2.0 and CC-BY-4.0 AND Apache 2.0. Points are deducted for these governance inconsistencies.
The four-layer workflow, chip-specific carveout lists, verification commands, and rollback guidance can address the core memory-reclamation task, and the benchmark summary provides limited auditable evaluation evidence; however, there are no representative final outputs, quantified memory savings, or complete BSP-compatibility proof. Important results still require on-device judgment and reflashing, so the static score is capped at 7 and reduced.
The material gives concrete paths, fields, commands, checks, and two evaluation tasks with expected behaviors, providing some traceability; however, the benchmark contains only summary and single-attempt results, with no committed test suite, logs, or independent reproduction evidence, and key dependency files are absent. The score is therefore reduced and constrained by the static cap of 5.
- The workflow modifies boot firmware, device trees, and kernel boot parameters; configuration errors may prevent boot or disable peripherals. Obtain explicit user confirmation, preserve a pristine copy, and prepare a recoverable flashing path before execution.
- Verify the actual SoC, module, BSP version, and target-platform-contract.md. That contract and complete indices are not provided here, so example addresses or names must not be treated as sufficient evidence.
- License information is inconsistent between NOASSERTION metadata and the Apache/CC-BY combination; maintainers should clarify the applicable license before publication or redistribution.
- All conclusions are from static source review; the benchmark summary is not independent execution or verification for this assessment.
What does this skill do, and when should you use it?
This skill guides Jetson BSP changes for headless, no-camera, and SWIOTLB memory-reduction scenarios. It covers four boot layers: MB1 BCT, MB2 BCT, kernel device tree, and SWIOTLB. It accepts only the validated recipes and requires platform checks, merged-BCT verification, and post-boot validation. It does not flash the device itself.
Reads the resolved target-platform context, BSP source tree, and device trees; zeros selected carveout base and size fields in MB1 BCT; disables MB2 cluster-loading controls and removes related AST nodes; decompiles and edits kernel DTB display or camera nodes; adjusts SWIOTLB through CMDLINE_ADD; uses gcc and dtc to reproduce compilation, decompilation, and override checks; and validates memory reservations, device nodes, command-line settings, and logs through /proc, /sys, /dev, and dmesg.
- An Orin or Thor deployment that has no display attached and needs display-related DRAM reclaimed.
- A Jetson deployment that does not use cameras and can disable RCE, VI, ISP, or NVCSI reservations.
- A device where workload testing shows that the SWIOTLB bounce pool can be reduced safely.
- Jetson BSP customization requiring review across firmware BCTs, kernel DT, and boot-time diagnostics.
What are this skill's strengths and limitations?
- Covers four memory-reservation layers in boot chronology.
- Provides chip-specific carveout tables for T234 Orin and T264 Thor.
- Includes merged-BCT verification, boot-log checks, and SWIOTLB utilization checks.
- Explicitly requires disabling loading controls and removing AST references when zeroing a carveout.
- Only headless, no-camera, and swiotlb recipes are validated; other subsystem-disable requests are refused.
- Requires an extracted and initialized Jetson BSP, a resolved target-platform contract, and an actual target device.
- Disabling a mandatory carveout can prevent boot; an undersized SWIOTLB pool requires rollback and reflashing.
- The SKILL.md does not describe a standalone test suite, a complete supported-chip list, or automated flashing.
How do you install this skill?
Install the specific skill from NVIDIA/skills with the skills CLI:
npx skills add nvidia/skills --skill jetson-optimize-memory --yes
The README does not document a separate manual folder layout for this skill. After installation, an agent loads it when a relevant task is encountered.
How do you use this skill?
Give the agent a specific supported scenario, such as: “Apply the headless memory optimization recipe to the current Jetson BSP” or “Apply the no-camera recipe for this deployment.” Before use, resolve the target platform, initialize the BSP image and source tree, and confirm that the workload does not require display or camera. Use only the headless, no-camera, or swiotlb recipes; then perform the required compile/decompile checks and validate on the booted target.