jetson-print-bsp-info
Use when you need to print Jetson BSP info (L4T version, board configs, rootfs state) from a Linux_for_Tegra root on the host PC. This is an example skill.
Skill body
jetson-print-bsp-info
Prints a concise summary of a Jetson Linux_for_Tegra (BSP) tree on the host PC.
This skill is intended as a reference example for the jetson-bsp-skills repo and the NVIDIA-wide skills CI. It performs read-only inspection — no flashing, no rootfs changes.
Purpose
Capture a baseline snapshot of a Linux_for_Tegra BSP tree (release, board configs, rootfs state) before flashing, so issues like “wrong L4T version” or “rootfs never populated” are caught early.
When to use
- A user has unpacked a Jetson BSP tarball and wants to confirm the L4T version, supported boards, and rootfs state before flashing.
- You need a quick sanity check that a
Linux_for_Tegra/directory looks valid (expected scripts and config files present).
Prerequisites
- Running on the host PC (Linux), not on the Jetson target.
- A
Linux_for_Tegra/directory extracted from a Jetson BSP tarball. - Standard CLIs available:
ls,head,cat,paste,sed.
Inputs
L4T_ROOT(optional): absolute path to theLinux_for_Tegra/directory. If unset, use the current working directory.
Instructions
Run each step in order and print the captured values into the report shown under Output format.
- Resolve
L4T_ROOTand validate the directory is a Linux_for_Tegra root — exit early otherwise.flash.shandnv_tegra/are the two anchor artifacts that every BSP ships:L4T_ROOT="${L4T_ROOT:-$PWD}" if [ ! -f "$L4T_ROOT/flash.sh" ] || [ ! -d "$L4T_ROOT/nv_tegra" ]; then echo "Not a Linux_for_Tegra root: '$L4T_ROOT' (missing flash.sh or nv_tegra/)" exit 1 fi echo "$L4T_ROOT" - Extract the L4T release header line. The canonical host-side location is
nv_tegra/nv_tegra_release; the same file is copied into the rootfs byapply_binaries.sh. Only the first line is useful — the rest is a long list of library SHAs:head -1 "$L4T_ROOT/nv_tegra/nv_tegra_release" 2>/dev/null \ || head -1 "$L4T_ROOT/rootfs/etc/nv_tegra_release" 2>/dev/null \ || echo "L4T release info not found" - List supported board config files and join them onto one comma-separated line:
(cd "$L4T_ROOT" && ls *.conf 2>/dev/null) | paste -sd, - - Check whether the rootfs has been populated. An empty
rootfs/meansapply_binaries.shhas not been run yet:if [ -f "$L4T_ROOT/rootfs/etc/passwd" ]; then echo "populated" else echo "empty" fi
Output format
Print a short report with these sections, one line each where possible:
L4T root: <path>
L4T release: <release header line>
Board configs: <comma-separated list>
Rootfs: populated | empty
Examples
Example output on an Orin AGX BSP (L4T R36):
L4T root: $HOME/Linux_for_Tegra
L4T release: # R36 (release), REVISION: 3.0
Board configs: jetson-agx-orin-devkit.conf,jetson-orin-nano-devkit.conf
Rootfs: populated
Example output on a freshly untarred BSP where apply_binaries.sh has not been run yet:
L4T root: /tmp/Linux_for_Tegra
L4T release: # R39 (release), REVISION: 0.0
Board configs: jetson-agx-thor-devkit.conf
Rootfs: empty
Error handling
Each command falls back to a clearly labeled "... not found" string if the underlying file is missing — the skill never errors out mid-report. If L4T_ROOT does not contain flash.sh and nv_tegra/, exit early with a clear “not a Linux_for_Tegra root” message rather than printing misleading info.
Limitations
- Read-only inspection only — does not validate signatures, kernel images, or device-tree overlays.
- Only checks the presence of
rootfs/etc/passwdas a populated-rootfs proxy; will not detect a half-populated rootfs. - Lists all
*.confboard configs inL4T_ROOT/; does not try to infer which one the user intends to flash.
Troubleshooting
-
Error:
Not a Linux_for_Tegra root: '...' (missing flash.sh or nv_tegra/)Cause:L4T_ROOTpoints at a parent directory, an extracted rootfs, or an unrelated path. Solution: PointL4T_ROOTat the directory that containsflash.sh(typicallyLinux_for_Tegra/). -
Error:
L4T release info not foundCause: Neithernv_tegra/nv_tegra_releasenorrootfs/etc/nv_tegra_releaseexists — the BSP tarball may be incomplete orapply_binaries.shwas never run. Solution: Re-extract the BSP tarball or runapply_binaries.shto populate the rootfs.
Notes
- Do not modify any files. This skill is read-only.
- If multiple board config files exist, list all of them — do not try to guess which one the user intends to flash.