Jetson Validate Image

Validate BSP Image

Status: the DUT-access contract is stable; the rest of the validation procedure is a skeleton.

Purpose

Confirm that a freshly customized BSP landed correctly — both as a static artifact on disk and as a running system on the target — without re-promoting or re-flashing. Forms the validation tail of Deploy in the Setup → Customize → Build → Deploy pipeline (see ../../context/bsp-customization-workflow.md for the pipeline view) and is independently re-runnable.

Prerequisites

• Active target-platform profile with bsp_image: resolved (run /jetson-init-image first).
• For static-only scope: nothing further; the skill reads <bsp_image.root_path> directly.
• For on-target scope:
  • /jetson-flash-image already pushed the staged BSP to the DUT.
  • dut_access: block authored in the active profile (or filled interactively at runtime — see ## DUT access).
  • Host tooling per transport: ssh + sshpass for SSH; Python 3.6+ with pyserial for UART.
  • Required env vars resolvable on the host when auth=password or sudo.method=password (password_env / sudo.password_env name the env var; never inline the secret in YAML).

When to invoke

• After jetson-flash-image has put the BSP onto a target.
• The user explicitly asks to validate, test, or run smoke / regression checks on a flashed device.
• As a CI gate before declaring a customization batch shippable.

Instructions

The procedure below is a skeleton.

1. Read the active target per the prerequisite contract.
2. Choose validation scope — static (against bsp_image on disk, no DUT needed) and/or on-target (DUT must be booted from the just-flashed image).
3. Static checks (if in scope):
   • Required artifacts present at expected paths in <bsp_image.root_path>/Linux_for_Tegra/.
   • DTB / module checksum or signature verification.
   • Partition-layout sanity vs. the per-board .conf's XML.
   • Cross-check overlay-staged outputs against bsp_image (they should be identical post-promotion).
   • Initramfs ↔ kernel + rootfs module coherence. Extract <bsp_image>/Linux_for_Tegra/bootloader/l4t_initrd.img and <bsp_image>/Linux_for_Tegra/rootfs/boot/initrd; verify three invariants against the promoted bsp_image state: (a) <bsp_image>/Linux_for_Tegra/kernel/Image matches <bsp_image>/Linux_for_Tegra/rootfs/boot/Image byte-for- byte — drift here means the "Mirror kernel Image into rootfs" step was skipped and any subsequent initramfs refresh built against the previous kernel. (b) for each module path the two initrd images ship, the bytes / md5 match the file under <bsp_image>/Linux_for_Tegra/rootfs/lib/modules/<ver>/ — any drift means modules will be shadowed at early boot. (c) the vermagic stamped on every initramfs *.ko matches the UTS_RELEASE reachable from <bsp_image>/Linux_for_Tegra/kernel/Image (e.g. parse the Linux version … string with strings) — a vermagic skew means the kernel Image was refreshed without rerunning l4t_update_initrd.sh, and modules will fail to load with "disagrees about version of symbol …". All three failure modes are closed by /jetson-promote-image's gate on either kernel/Image or rootfs/lib/modules/ plus the kernel-Image mirror; surface drift here and route the user back to a clean promote. See ../jetson-promote-image/SKILL.md.
4. On-target checks (if in scope):
   • Connect to the DUT per the ## DUT access section below — resolve transport (ssh / uart), credentials, and sudo method from the active profile's dut_access: block (with interactive fallback when fields are missing / marked prompt), then run the connection probe and refuse if it fails.
   • Confirm boot reached userspace.
   • Run the selected test suite (smoke, regression, focused per-customization, ad-hoc).
   • Loaded-module srcversion drift. For modules a customization is known to have rebuilt, compare cat /sys/module/<name>/srcversion on the DUT against the modinfo /lib/modules/$(uname -r)/.../<name>.ko | awk '/srcversion/ {print $2}' reading. A mismatch means the kernel is running an older copy than the rootfs ships — almost always a stale initramfs (the bootloader-side initrd shipped a pre-customize module, it loaded first, and the rootfs copy cannot replace a live module). Recommend re-running /jetson-promote-image and re-flashing. Note: some modules don't emit srcversion; fall back to an md5 check against the binary the kernel loaded by extracting the region under /sys/module/<name>/sections/ or by comparing behaviorally (printk / sysfs nodes / DT properties the new version is known to expose).
   • Running kernel vs. rootfs kernel Image. Compare cat /proc/version (or uname -v) on the DUT against the Linux version … string extracted from /boot/Image (strings /boot/Image | grep -m1 'Linux version'). A mismatch — usually the build timestamp / LOCALVERSION — means the bootloader is running an older kernel Image than the rootfs holds, almost certainly because a fresh Image was promoted but the initramfs / extlinux.conf / QSPI boot partition wasn't refreshed. Modules in the rootfs will then have a different vermagic and any subsequent modprobe of a built-against-the-new-kernel .ko will fail. Recommend /jetson-promote-image and re-flash.
   • Userspace dmesg readability. Ubuntu 22.04 sets kernel.dmesg_restrict=1; non-root dmesg reads return "Operation not permitted" and silently zero hits. Every dmesg-based check must run with sudo (or temporarily lower the restriction via sudo sysctl kernel.dmesg_restrict=0). Surfacing this in the validate layer keeps printk-based customization checks honest.
   • Collect results, logs, artifacts.
5. Summary: per-check pass/fail, overall verdict, where logs and artifacts landed.

DUT access

The on-target leg needs a way to reach the just-flashed DUT. Two transports are supported as full peers: ssh (primary) and uart (fallback for DUTs with no network).

The contract is locked in but lives in references/dut-access.md to keep this SKILL.md under the agent-routing budget. That reference covers:

• The dut_access: profile schema (ssh, uart, sudo, workdir).
• Resolution order (profile → env var → interactive prompt) with the full refusal-trigger table.
• The mandatory connection probe (uname -r + cat /etc/nv_tegra_release) and its output-validation rules.
• File transfer per transport (scp vs. base64-over-tty, with the >100 KB warning).
• Sudo invocation matrix per sudo.method × transport.
• UART implementation contract that scripts/uart_session.py honors (state machines for login / exec / push / pull, exit codes, robustness notes).
• Security notes (password handling, host-key pinning).