/jetson-validate-image

name: jetson-validate-image
description: >-
  Use after jetson-flash-image to run static BSP checks, on-target
  smoke/regression tests on a flashed DUT, or both. Not for build
  or flash steps. Triggers: validate bsp, on-target validation.
version: 0.0.1
license: "Apache-2.0"
metadata:
  data-classification: public
  author: "Jetson Team"
  tags:
    - bsp
    - validation
    - test
    - deploy
  domain: meta

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`](../../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`](#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](../jetson-promote-image/SKILL.md#mirror-kernel-image-into-rootfs-when-kernel-changed) 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`](../jetson-promote-image/SKILL.md#refresh-initramfs-when-kernel-or-modules-changed). 4. **On-target checks** (if in scope):

• **Connect to the DUT** per the [`## DUT access`](#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 b