jetson-validate-image

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Validate BSP Image

验证BSP镜像

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

状态： DUT访问协议已稳定；其余验证流程为框架性内容。

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.

确认刚定制的BSP已正确部署——包括作为磁盘上的静态工件，以及作为目标设备上的运行系统——无需重新推广或重新烧录。构成Setup → Customize → Build → Deploy流程中Deploy环节的验证收尾步骤（查看

../../context/bsp-customization-workflow.md

了解流程视图），且可独立重新运行。

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).

已解析
```
bsp_image:
```
的活跃目标平台配置文件（先运行
```
/jetson-init-image
```
）。
仅静态检查场景：无需额外条件；该工具直接读取
```
<bsp_image.root_path>
```
。
目标端检查场景：
- ```
/jetson-flash-image
```
  已将预部署的BSP推送至DUT。
- 活跃配置文件中已编写
```
dut_access:
```
  块（或在运行时交互式补充——查看
```
## DUT访问
```
  ）。
- 对应传输方式的主机工具：SSH方式需
```
ssh
```
  +
```
sshpass
```
  ；UART方式需Python 3.6+及
```
pyserial
```
  库。
- 当
```
auth=password
```
  或
```
sudo.method=password
```
  时，主机需可解析所需环境变量（
```
password_env
```
  /
```
sudo.password_env
```
  指定环境变量名称；切勿在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.

在
```
jetson-flash-image
```
已将BSP烧录至目标设备之后。
用户明确要求对已烧录设备进行验证、测试，或运行冒烟/回归检查时。
作为CI关卡，用于确认定制批次可交付之前。

Instructions

操作步骤

The procedure below is a skeleton.

Read the active target per the prerequisite contract.
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).
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
```
  .
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.
Summary: per-check pass/fail, overall verdict, where logs and artifacts landed.

以下流程为框架性内容。

读取活跃目标配置：遵循前提条件中的协议。
选择验证范围——静态检查（针对磁盘上的
```
bsp_image
```
，无需DUT）和/或目标端检查（DUT必须从刚烧录的镜像启动）。
静态检查（若包含在范围内）：
- 确认
```
<bsp_image.root_path>/Linux_for_Tegra/
```
  下的预期路径中存在必需的工件。
- DTB/模块校验和或签名验证。
- 分区布局与对应板卡的
```
.conf
```
  文件中的XML是否一致。
- 交叉检查预部署的覆盖输出与
```
bsp_image
```
  （推广后两者应完全一致）。
- Initramfs ↔ 内核 + rootfs模块一致性。提取
```
<bsp_image>/Linux_for_Tegra/bootloader/l4t_initrd.img
```
  和
```
<bsp_image>/Linux_for_Tegra/rootfs/boot/initrd
```
  ；针对已推广的
```
bsp_image
```
  状态验证三个不变量： (a)
```
<bsp_image>/Linux_for_Tegra/kernel/Image
```
  与
```
<bsp_image>/Linux_for_Tegra/rootfs/boot/Image
```
  逐字节匹配——若此处存在差异，说明“将内核Image镜像至rootfs”步骤被跳过，后续任何initramfs刷新都是基于旧内核构建的。 (b) 对于两个initrd镜像中的每个模块路径，其字节/md5值需与
```
<bsp_image>/Linux_for_Tegra/rootfs/lib/modules/<ver>/
```
  下的文件匹配——若存在差异，说明模块在早期启动时会被覆盖。 (c) 每个initramfs
```
*.ko
```
  文件上的vermagic需与
```
<bsp_image>/Linux_for_Tegra/kernel/Image
```
  中的
```
UTS_RELEASE
```
  匹配（例如，使用
```
strings
```
  解析
```
Linux version …
```
  字符串）——vermagic不匹配说明内核
```
Image
```
  已刷新但未重新运行
```
l4t_update_initrd.sh
```
  ，模块加载时会失败并提示“disagrees about version of symbol …”。这三种失败模式均可通过
```
/jetson-promote-image
```
  在
```
kernel/Image
```
  或
```
rootfs/lib/modules/
```
  变更时的关卡，以及内核Image镜像步骤来避免；若此处发现差异，需引导用户重新执行完整的推广流程。查看
```
../jetson-promote-image/SKILL.md
```
  。
目标端检查（若包含在范围内）：
- 连接至DUT：按照下文
```
## DUT访问
```
  部分的说明——从活跃配置文件的
```
dut_access:
```
  块解析传输方式（ssh/uart）、凭据和sudo方法（当字段缺失或标记为
```
prompt
```
  时，交互式补充），然后运行连接探测，若失败则终止操作。
- 确认设备已启动至用户空间。
- 运行选定的测试套件（冒烟测试、回归测试、定制专项测试、临时测试）。
- 已加载模块的srcversion差异：对于定制过程中已知已重建的模块，将DUT上的
```
cat /sys/module/<name>/srcversion
```
  输出与
```
modinfo /lib/modules/$(uname -r)/.../<name>.ko | awk '/srcversion/ {print $2}'
```
  的读取结果进行比较。若不匹配，说明内核运行的是旧版本模块，而rootfs中是新版本——几乎总是因为initramfs过期（bootloader端的initrd包含定制前的模块，先加载了该模块，rootfs中的副本无法替换已加载的模块）。建议重新运行
```
/jetson-promote-image
```
  并重新烧录。注意：部分模块不会输出
```
srcversion
```
  ；可通过提取
```
/sys/module/<name>/sections/
```
  下的区域，或通过行为对比（新版本已知会输出的printk信息、sysfs节点、DT属性）来替代md5校验。
- 运行中的内核与rootfs内核
  Image
  对比：将DUT上的
```
cat /proc/version
```
  （或
```
uname -v
```
  ）输出与
```
/boot/Image
```
  中提取的
```
Linux version …
```
  字符串（
```
strings /boot/Image | grep -m1 'Linux version'
```
  ）进行比较。若不匹配——通常是构建时间戳/
```
LOCALVERSION
```
  不同——说明bootloader运行的内核
```
Image
```
  比rootfs中的旧，几乎可以肯定是因为新的
```
Image
```
  已推广但initramfs/
```
extlinux.conf
```
  /QSPI启动分区未刷新。此时rootfs中的模块vermagic会不同，后续任何针对新内核构建的
```
.ko
```
  文件执行
```
modprobe
```
  都会失败。建议运行
```
/jetson-promote-image
```
  并重新烧录。
- 用户空间dmesg可读性：Ubuntu 22.04设置了
```
kernel.dmesg_restrict=1
```
  ；非root用户执行
```
dmesg
```
  会返回“Operation not permitted”且无输出。所有基于
```
dmesg
```
  的检查必须以
```
sudo
```
  运行（或通过
```
sudo sysctl kernel.dmesg_restrict=0
```
  临时降低限制）。在验证层中明确这一点，可确保基于printk的定制检查准确有效。
- 收集结果、日志和工件。
总结：每个检查项的通过/失败状态、整体结论，以及日志和工件的存储位置。

DUT access

DUT访问

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).

目标端检查环节需要连接至刚烧录的DUT。支持两种传输方式：

ssh

（首选）和

uart

（无网络DUT的备选方案）。

Available Scripts

可用脚本

Script	Purpose	Arguments
`scripts/uart_session.py`	UART transport black box for the on-target leg: login, command exec (with optional sudo), and base64-over-tty file transfer. Replaces ssh when the DUT has no network or ssh is broken.	`--tty <dev> [--baud <n>] --user <name> --password-env <ENVVAR> [--sudo-password-env <ENVVAR>] [--shell-prompt <regex>] [--lock-strategy refuse\|wait] <probe\|exec\|push\|pull> [...]`

Invocation (the skill calls scripts as a subprocess —

run_script()

in agent-runtime terminology):

bash

undefined

脚本用途参数

脚本	用途	参数
`scripts/uart_session.py`	目标端环节的UART传输黑盒：登录、命令执行（可选sudo）、基于tty的base64文件传输。当DUT无网络或ssh故障时替代ssh。	`--tty <dev> [--baud <n>] --user <name> --password-env <ENVVAR> [--sudo-password-env <ENVVAR>] [--shell-prompt <regex>] [--lock-strategy refuse\|wait] <probe\|exec\|push\|pull> [...]`

scripts/uart_session.py

目标端环节的UART传输黑盒：登录、命令执行（可选sudo）、基于tty的base64文件传输。当DUT无网络或ssh故障时替代ssh。

--tty <dev> [--baud <n>] --user <name> --password-env <ENVVAR> [--sudo-password-env <ENVVAR>] [--shell-prompt <regex>] [--lock-strategy refuse|wait] <probe|exec|push|pull> [...]

调用方式（工具以子进程形式调用脚本——在代理运行时术语中为

run_script()

）：

bash

undefined

run_script: probe the DUT over UART

run_script: 通过UART探测DUT

DUT_UART_PASSWORD_ENV=DUT_UART_PWD
DUT_UART_PWD="$(read -rs -p 'UART login pw: '; echo "$REPLY")"
scripts/uart_session.py
--tty /dev/ttyACM0 --baud 115200
--user ubuntu --password-env DUT_UART_PASSWORD_ENV
probe

DUT_UART_PASSWORD_ENV=DUT_UART_PWD
DUT_UART_PWD="$(read -rs -p 'UART登录密码: '; echo "$REPLY")"
scripts/uart_session.py
--tty /dev/ttyACM0 --baud 115200
--user ubuntu --password-env DUT_UART_PASSWORD_ENV
probe

run_script: exec a sudo command and capture exit code

run_script: 执行sudo命令并捕获退出码

scripts/uart_session.py --tty /dev/ttyACM0 --user ubuntu
--password-env DUT_UART_PASSWORD_ENV
--sudo-password-env DUT_SUDO_PWD
exec --use-sudo 'dmesg | tail -200'


The script's exit code is the contract — see the exit-code table in
[`UART implementation contract`](references/dut-access.md#uart-implementation-contract).

scripts/uart_session.py --tty /dev/ttyACM0 --user ubuntu
--password-env DUT_UART_PASSWORD_ENV
--sudo-password-env DUT_SUDO_PWD
exec --use-sudo 'dmesg | tail -200'


脚本的退出码为协议的一部分——查看[`UART实现协议`](references/dut-access.md#uart-implementation-contract)中的退出码表。

Examples

示例

Static-only validation (no DUT needed):

/jetson-validate-image
> static checks only against the staged BSP

On-target validation over SSH after a freshly flashed DUT:

/jetson-flash-image
   ↓
/jetson-validate-image
> on-target checks via dut_access.ssh

On-target validation over UART (no network on the DUT):

/jetson-validate-image
> use the uart transport at /dev/ttyACM0; the dut_access.uart block
  in the profile already has the tty and login_password_env wired up

仅静态验证（无需DUT）：

/jetson-validate-image
> 仅对预部署的BSP执行静态检查

已烧录DUT后的SSH目标端验证：

/jetson-flash-image
   ↓
/jetson-validate-image
> 通过dut_access.ssh执行目标端检查

UART目标端验证（DUT无网络）：

/jetson-validate-image
> 使用/dev/ttyACM0的uart传输方式；配置文件中的dut_access.uart块已设置好tty和login_password_env

Limitations

局限性

Placeholder skill — only the DUT-access contract and the
```
uart_session.py
```
helper are locked in. The static-check list, test-suite selection, result-sink layout, and pass/fail policy are tracked under
```
## Open items
```
and may change.
UART file transfer is byte-banged base64 at ~10 KB/s on 115200 baud — emits a warning for sources > 100 KB but proceeds. For high-volume transfers, switch to the SSH transport.
```
uart_session.py
```
opens and closes the tty per subcommand invocation (~1–2 s login per call). Validation passes running

10 commands amortize poorly on UART; prefer SSH.
SSH uses
```
StrictHostKeyChecking=accept-new
```
with a per-profile
```
known_hosts
```
file. A fingerprint change refuses — typically means the DUT was reflashed (host keys regenerated) or the IP was reassigned. Remove the per-profile entry manually rather than auto-accepting.
Passwords are never inlined in the profile YAML — only
```
password_env
```
(env-var name) is persisted.
```
auth=prompt
```
/
```
sudo.method=prompt
```
exposes the password in the conversation log, which is the user's responsibility to manage.
```
transport=uart
```
with
```
lock_strategy=steal
```
is not implemented (would require sending control characters that could corrupt the holder's state).

框架性工具——仅DUT访问协议和
```
uart_session.py
```
辅助工具已锁定。静态检查列表、测试套件选择、结果存储布局及通过/失败策略在
```
## 待办事项
```
中跟踪，可能会变更。
UART文件传输为字节流base64，在115200波特率下约为10 KB/s——当源文件大于100 KB时会发出警告但仍会继续。对于大体积传输，建议切换至SSH传输方式。
```
uart_session.py
```
每次子命令调用都会打开并关闭tty（每次调用约1-2秒登录时间）。若验证需运行超过10个命令，UART方式的耗时会很高；优先选择SSH。
SSH使用
```
StrictHostKeyChecking=accept-new
```
及每个配置文件对应的
```
known_hosts
```
文件。若指纹变更则会终止操作——通常意味着DUT已重新烧录（主机密钥重新生成）或IP已重新分配。需手动删除配置文件对应的条目，而非自动接受。
密码永远不会内嵌在配置文件YAML中——仅
```
password_env
```
（环境变量名称）会被持久化。
```
auth=prompt
```
/
```
sudo.method=prompt
```
会在对话日志中暴露密码，用户需自行负责管理。
```
transport=uart
```
搭配
```
lock_strategy=steal
```
未实现（需要发送控制字符，可能会破坏当前持有者的状态）。

Troubleshooting

故障排除

Error	Cause	Solution
`no DUT transport configured` (refuse)	On-target scope requested but `dut_access.transport` unresolved across profile / env / interactive prompt	Author `dut_access:` in the active profile, or rerun with static-only scope.
`$PASSWORD_ENV is unset` (refuse)	`auth=password` (or `sudo.method=password` ) names an env var that isn't exported on the host	`export <ENVVAR>=...` before invoking the skill; do NOT inline the password in YAML.
`tty held by another process` (refuse, exit 3)	`lock_strategy=refuse` and `fuser` reports another holder (minicom, picocom, getty)	Close the holding process ( `sudo fuser -k <tty>` only if you know what's there), or rerun with `lock_strategy=wait` .
`pyserial import failed` (exit 4)	UART transport selected but `pyserial` not installed in the skill's Python	`apt install python3-serial` or `pip install pyserial` .
SSH fingerprint refused	DUT's host keys changed since the per-profile `known_hosts` was pinned (typically a reflash)	Remove the matching line from `<workspace>/target-platform/<profile-stem>.known_hosts` and rerun — the new key will be accepted on first connect.
`login failed` (exit 128)	UART probe couldn't match a login or shell prompt within timeout	Confirm the DUT is powered + booted to userspace; check `--shell-prompt` override if the DUT carries an unusual `PS1` ; verify the `--user` matches a real account.
`DUT not booted from the just-flashed BSP` (warn / refuse)	`/etc/nv_tegra_release` on the DUT doesn't match `bsp_image.version`	Re-run `/jetson-flash-image` and confirm the DUT actually power-cycled into the new BSP, not the previous one.
`sudo prompt detected but no sudo password configured` (exit 130)	`--use-sudo` passed to `uart_session.py exec` but `--sudo-password-env` not set, and DUT user lacks NOPASSWD	Set `sudo.method=password` + `sudo.password_env` in the profile, or grant NOPASSWD on the DUT via `/etc/sudoers.d/` .
`command timed out` (exit 129)	Long-running DUT command exceeded the script's timeout	Run the command directly via `ssh` transport, or split into shorter steps.

错误	原因	解决方案
`no DUT transport configured` （终止）	请求目标端范围但 `dut_access.transport` 未通过配置文件/环境变量/交互式提示解析完成	在活跃配置文件中编写 `dut_access:` ，或重新运行并选择仅静态检查范围。
`$PASSWORD_ENV is unset` （终止）	`auth=password` （或 `sudo.method=password` ）指定的环境变量未在主机上导出	在调用工具前执行 `export <ENVVAR>=...` ；切勿在YAML中直接写入密码。
`tty held by another process` （终止，退出码3）	`lock_strategy=refuse` 且 `fuser` 检测到其他进程占用（minicom、picocom、getty）	关闭占用进程（仅当你清楚进程用途时使用 `sudo fuser -k <tty>` ），或重新运行并设置 `lock_strategy=wait` 。
`pyserial import failed` （退出码4）	选择了UART传输方式，但工具的Python环境中未安装 `pyserial`	执行 `apt install python3-serial` 或 `pip install pyserial` 。
SSH指纹被拒绝	自配置文件的 `known_hosts` 固定后，DUT的主机密钥已变更（通常是重新烧录）	从 `<workspace>/target-platform/<profile-stem>.known_hosts` 中删除对应行并重新运行——首次连接时会接受新密钥。
`login failed` （退出码128）	UART探测在超时内未匹配到登录或shell提示符	确认DUT已通电并启动至用户空间；若DUT使用非标准 `PS1` ，检查 `--shell-prompt` 覆盖设置；验证 `--user` 是否为真实账户。
`DUT not booted from the just-flashed BSP` （警告/终止）	DUT上的 `/etc/nv_tegra_release` 与 `bsp_image.version` 不匹配	重新运行 `/jetson-flash-image` 并确认DUT确实已重启并进入新BSP，而非之前的版本。
`sudo prompt detected but no sudo password configured` （退出码130）	向 `uart_session.py exec` 传递了 `--use-sudo` 但未设置 `--sudo-password-env` ，且DUT用户无NOPASSWD权限	在配置文件中设置 `sudo.method=password` + `sudo.password_env` ，或通过 `/etc/sudoers.d/` 在DUT上授予NOPASSWD权限。
`command timed out` （退出码129）	DUT上的长运行命令超出了脚本的超时时间	通过 `ssh` 传输方式直接运行命令，或拆分为更短的步骤。

References

参考文档

```
references/dut-access.md
```
— full DUT-access contract: profile schema, resolution order, probe, file transfer, sudo, UART implementation, security.

../../context/target-platform-contract.md

— target-platform contract.

```
../../context/bsp-customization-workflow.md
```
— Workspace edit protocol (this skill is the Deploy tail).
```
../jetson-build-source/SKILL.md
```
— Build builder; produces the artifacts this skill validates.

```
references/dut-access.md
```
— 完整的DUT访问协议：配置文件schema、解析顺序、探测、文件传输、sudo、UART实现、安全。

../../context/target-platform-contract.md

— 目标平台协议。

```
../../context/bsp-customization-workflow.md
```
— 工作区编辑协议（本工具为Deploy环节的收尾步骤）。
```
../jetson-build-source/SKILL.md
```
— 构建工具；生成本工具验证的工件。