How the Jetson Configuration Checker decides supported, at risk, or not.

Contents

1. What it checks, and what it does not
2. Inputs and defaults
3. Check catalogue
4. Status vocabulary and the verdict rule
5. Verify plan
6. Evidence classes and the confidence rule
7. JetPack release table
8. Install methods
9. Runtime pairings
10. Known issues
11. Documents
12. What invalidates a result
13. Limitations and gaps
14. Method changelog

1. What it checks, and what it does not

The engine takes a Jetson module, a JetPack / L4T release, an install method, a runtime and (optionally) a power mode, an artefact CUDA/Ubuntu version, a previous JetPack (for an upgrade path) and a deployment mode (bare metal or container). It runs a fixed set of checks against the software configuration registry and the power-mode registry, each producing a status, an evidence class, a confidence label, the on-device commands that verify it, and — when the status is not PASS — a remediation and (where one applies) a known issue with symptom, cause and fix.

It does not connect to a board, run any command itself, or measure anything at runtime. It compares the requested configuration against published facts and tells you what to run to confirm it. It also does not model performance (tokens/s, FPS, latency) — that is the Camera Stream Capacity and Model Memory Fit engines' job.

2. Inputs and defaults

Every input has a stated default so a minimal request (platform only) still returns a result.

3. Check catalogue

Every check is a constraint object with a check name, status, evidence class, sources, assumptions and — when relevant — a remediation and a known-issue id. The subsections below state exactly when each status is produced.

jetpack_release

Looks up the requested JetPack in the release table and reports its L4T, CUDA, TensorRT, cuDNN, DeepStream and Ubuntu versions. PASS when CUDA, TensorRT and cuDNN are all on record for that release. REQUIRES_VALIDATION when one or more of those three is missing from the archive (JetPack 5.1.6, 5.1.7, 6.2.2, 6.2.3 — see gaps) — read the actual version off the board instead. When no JetPack was given, the latest release supporting the module is assumed and the assumption text says so.

module_support

PASS when the module is in that JetPack's published supported_modules list. UNSUPPORTED otherwise — with a remediation naming the module's minimum/maximum supported JetPack (Thor modules point at thor_requires_jetpack7; an Orin module past its last supported release points at the latest one that works).

install_method

Checks the requested install method against the method's applies_to module list and JetPack range. REQUIRES_VALIDATION when install_method is unknown (read /etc/nv_boot_control.conf to find out). UNSUPPORTED when the method is not offered for the module (e.g. SD card image on anything but the Orin Nano Developer Kit), when SD card image is requested on JetPack 7.2+ (removed — known issue no_sd_card_jp72), or when ISO image is requested before JetPack 6.0 (no ISO existed). Upgrade path (apt_upgrade): if previous_jetpack is not given, REQUIRES_VALIDATION (apt/OTA only moves within one Jetson Linux major line); if given and the major line differs, UNSUPPORTED (known issue jp5_to_jp6_no_ota); if the major line matches, PASS. Otherwise PASS with the method's notes as the assumption.

firmware_prerequisite

Orin Nano Developer Kit only (devkit not explicitly false), and only when flashing JetPack 6.x or 7.2.1 by a target-side method (not sdk_manager or flash_sh, which update firmware themselves as part of the flash). When it applies: REQUIRES_VALIDATION — some Developer Kits shipped with pre-36.0 QSPI/UEFI firmware that cannot boot those releases (known issue jp72_orin_nano_firmware_prereq); check the firmware version and run the bridge-image update first if needed. Absent entirely for other modules or when flashing from a host.

power_mode (Super enablement)

Resolves the requested (or default) nvpmodel preset from the power-mode registry for that module × JetPack. PASS when it is a standard preset, or a Super preset with super_flash: true. VERSION_RISK when a Super preset is requested with install_method: iso_image and super_flash is not explicitly false (the ISO image cannot upgrade a non-Super board into Super Mode, but may already be a Super-flashed board) — known issue iso_no_super_upgrade. UNSUPPORTED when super_flash: false is stated explicitly for a Super preset. REQUIRES_VALIDATION when a Super preset is requested on a non-ISO install without super_flash stated (confirm with cat /proc/device-tree/model and nvpmodel -q). VERSION_RISK (evidence class D) for a legacy EdgeAIStack preset id that is not an NVIDIA preset name, pointing at the nearest real preset. REQUIRES_VALIDATION for a wattage inside the module's envelope but not a preset (needs a custom nvpmodel.conf from the Power Estimator). UNKNOWN when the module has no power-mode registry entry, or the requested mode is outside the module's envelope entirely.

runtime (per runtime family)

One check per requested runtime, using the runtime pairing table:

• tensorrt: PASS when the JetPack's shipped TensorRT is known and no version was requested, or matches the request (major.minor); REQUIRES_VALIDATION when the JetPack's TensorRT is not on record; VERSION_RISK when a different major.minor was requested (engines are not portable across TensorRT versions).
• deepstream: PASS on JetPack 6.1 (the only NVIDIA-confirmed pairing) or when a published DeepStream/JetPack row matches exactly; VERSION_RISK on other JetPack 6.x releases (runs unofficially per forum reports); REQUIRES_VALIDATION elsewhere (no published pairing).
• pytorch: PASS on the researched JetPack (6.2) with the Jetson AI Lab wheel-index install command; REQUIRES_VALIDATION on any other JetPack (install from the matching wheel index, never PyPI).
• jetson_containers: PASS always — images are tagged per L4T minor line, so the assumption states the tag to pull for this L4T.
• tensorrt_llm: PASS on Thor from JetPack 7.1+ (TensorRT Edge-LLM); UNSUPPORTED on Thor before 7.1; REQUIRES_VALIDATION on Orin (community build only, no NVIDIA pairing).
• vllm: PASS on Thor from JetPack 7.0+ (prebuilt container); UNSUPPORTED on Thor before 7.0; REQUIRES_VALIDATION on Orin (community container).
• onnxruntime / llama_cpp / ollama / mlc: REQUIRES_VALIDATION, evidence class E — not independently researched this pass (see gaps).
• none: no runtime check is produced; artefact checks below still run if their inputs are given.

artifact_cuda

Only runs when artifact_cuda is given. UNSUPPORTED when its major version differs from the JetPack's CUDA major (Thor/Orin CUDA 13 vs. 12 are not binary-compatible — known issue cuda13_thor_only on Thor).

artifact_ubuntu

Only runs when artifact_ubuntu is given. VERSION_RISK when it differs from the JetPack's Ubuntu version (JetPack 7.x moved to Ubuntu 24.04 — known issue ubuntu2404_jetpack7 when the JetPack is 7.x).

container_runtime

Only runs when deployment: docker and no other check already covers docker_nvidia_runtime verification (e.g. the jetson_containers or vllm runtime checks already do). REQUIRES_VALIDATION — confirm the NVIDIA Container Toolkit is installed and Docker has registered the nvidia runtime.

4. Status vocabulary and the verdict rule

The page verdict is the worst check, using this severity order (most severe first): UNSUPPORTED > VERSION_RISK > REQUIRES_VALIDATION > UNKNOWN > PASS. The public-facing verdict word maps the worst check's status:

5. Verify plan

Every check names the on-device commands that settle it (its verify list). The engine collects the commands named by every triggered check, de-duplicates them, and orders them into a numbered plan: L4T/JetPack identity first, then module/board identity, then power mode, then the compute-stack toolchain (CUDA, TensorRT), then runtime-specific commands (DeepStream, Docker), then live telemetry. Each step names which checks it settles. The l4t_release step's expected output is filled in with the requested release's actual L4T revision.

6. Evidence classes and the confidence rule

Every figure carries one of five evidence classes.

Confidence: a check is HIGH when its fact is a class-A vendor record with no ambiguity (module support, Super-flash confirmed true/false, an exact TensorRT-version match). MEDIUM when the registry has the fact but a disambiguating input was not given (JetPack defaulted, install method unknown, Super flash unconfirmed, previous JetPack for an upgrade path not stated, PyTorch/artefact requested off the one researched JetPack). LOW for class-E checks (unresearched runtimes, community best-effort verify patterns) and legacy power-mode ids. The overall result's confidence is the lowest confidence across every triggered check — one MEDIUM or LOW check caps the whole result, the same conservative rule Model Memory Fit uses.

7. JetPack release table

All 16 JetPack releases in the registry. "Supported modules" is the count of the 9 registry module ids that release supports (Thor modules only appear from JetPack 7.0; Orin modules are absent from 7.0 and 7.1, which were Thor-only, and resume at 7.2). Full detail, with the JSON-LD Dataset record and a link back to every affected page: /compatibility/.

8. Install methods

9. Runtime pairings

TensorRT and DeepStream pairings also come from the JetPack release table itself (§7); the rows below are the additional runtimes with a dedicated pairing record. Rows marked "no — class E gap" were not independently researched this pass; the check still returns REQUIRES_VALIDATION with a stated basis rather than a silent guess.

10. Known issues

11. Documents

12. What invalidates a result

• A new JetPack release. Every result URL carries mv (method version) and dv (dataset version); when either differs from the current values the result page says the data has changed since the link was made.
• An unresearched compute-stack figure filled in later. JetPack 5.1.6, 5.1.7, 6.2.2 and 6.2.3 currently report REQUIRES_VALIDATION for CUDA/TensorRT/cuDNN because the archive listing does not state them; a future research pass may confirm exact versions and change the status to PASS.
• A board flashed with a non-default configuration. The power-mode check assumes the module's default nvpmodel preset when none is given; a board custom-flashed with a non-standard nvpmodel.conf will not match.
• An install method the engine cannot see. install_method: unknown always returns REQUIRES_VALIDATION for that check — the result changes once the real method is known.
• A runtime pairing filled in by future research. onnxruntime, llama_cpp, ollama and mlc are class-E gaps (§6, §9); a research pass adding a confirmed pairing will raise those checks to PASS/VERSION_RISK with sources.
• DeepStream beyond JetPack 6.1. Only the 6.1 pairing is NVIDIA-confirmed; forum reports of DeepStream/JetPack 7.x incompatibility (see gaps) could firm up into a documented UNSUPPORTED in a future pass.

13. Limitations and gaps

• JetPack 5.1.6 and 5.1.7 compute-stack versions (CUDA/TensorRT/cuDNN/VPI) not verified — only L4T mapping confirmed from the JetPack Archive listing page.
• JetPack 6.2.2 and 6.2.3 compute-stack versions not verified beyond the L4T mapping already present in edgeaistack-api/src/v2/data/power_modes_data.js JETPACK_L4T.
• JetPack 5.1.5 has two L4T revisions listed across sources (35.6.1 and 35.6.2); which is canonical/latest for the 5.1.5 label is unresolved.
• DeepStream version mapping is only confirmed for JetPack 6.1 (DeepStream 7.1, official) and inferred/unconfirmed for 6.2, 6.2.1, 7.0, 7.1, 7.2 — no NVIDIA-published DeepStream↔JetPack 7.x compatibility matrix was found; forum threads (e.g. "DeepStream 8.0/7.1 compatibility issue on Jetson Orin Nano Super with JetPack 7.2") suggest active incompatibility as of this writing.
• No official JetPack release date found for 5.1.3, 5.1.6, 5.1.7, 6.2.2, or 6.2.3 (left null).
• onnxruntime, llama_cpp, ollama, and mlc runtime/version/install specifics were not independently researched this pass — flagged with jetpack:null in runtime_compat and should be a follow-up topic.
• `ls /dev/nvhost*` expected output and the ollama/llama.cpp CUDA-detection verify commands have no NVIDIA-published canonical reference; recorded as best-effort community patterns or left as explicit gaps.
• Jetson T3000 is mentioned in JetPack 7.2.1 release material only as "emulation" support, not a shipping module — deliberately excluded from module_ids per the task's module list; a real T3000 launch (if any) is a gap for future research.
• Legacy modules (jetson_xavier_nx, jetson_agx_xavier, jetson_nano) "last supported JetPack" facts: Xavier NX and AGX Xavier last appear in JetPack 5.1.7 (L4T 35.6.5) per the archive listing; Jetson Nano's last JetPack (4.6.6, L4T 32.7.6) was not independently re-verified this pass (carried over from general JetPack Archive listing, 4.x series, not deep-checked against a dedicated Nano EOL notice).

14. Method changelog

Method changes bump the method version; registry updates (new JetPack releases, corrected compute-stack figures, newly researched runtime pairings) bump the dataset version. Both appear in the citation block under every result and in the provenance object of every API response.