How do I install the Qcom Boot Validate skill?

Run npx skillmds@latest add qualcomm-linux/qcom-boot-validate in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Qcom Boot Validate safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: executes scripts, reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Qcom Boot Validate?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Qcom Boot Validate free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Qcom Boot Validate?

qualcomm-linux (@qualcomm-linux) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Qcom Boot Validate by qualcomm-linux

Name: Qcom Boot Validate
Rating: 4.2 (5 reviews)
Author: qualcomm-linux

Qcom Boot Validate

Validate that a Qualcomm Linux board boots to a working login shell by watching its serial console: wait for the login prompt, log in with the image's default credentials, and check uname, /etc/os-release (incl. BUILD_ID) and systemd state, reporting BOOT-VALIDATION: PASS/FAIL. Use after flashing, when asked to "validate the board boots", "check the board over serial", "did the new image come up", or "watch the boot console". Needs the serial console attached to this host (or reachable over ssh). Do NOT use for flashing (see qcom-flash-qdl) or for diagnosing a healthy-but-degraded system.

File contents

Validate a board boots over the serial console

Drives the board's serial console to prove a boot actually reached a usable shell — the natural follow-up to qcom-flash-qdl. Everything is done by scripts/boot-validate.py (paths relative to this skill's directory).

Prerequisites

The board's debug UART attached to a host you can run Python on, at 115200 baud (check dmesg | grep tty for the device, e.g. /dev/ttyUSB0).
python3 with pyserial on that host; the user in the dialout group (or equivalent) so the port opens without root.
Nothing else holding the serial port (close screen/picocom/minicom sessions first — the validator warns if it reads no output).
The image's login credentials (see matrix below).

Credentials matrix

Image	username	password
nodistro `core-image-base` (debug image)	`root`	empty
qcom-distro images (`qcom-console-image`, ...)	`root`	`oelinux123`

Usage

Local serial port:

python3 scripts/boot-validate.py --port /dev/ttyUSB0 --password oelinux123 \
    [--timeout 300] [--power-cycle-cmd '<host command>'] [--logfile PATH]

Serial port on a remote host (nothing is copied to it — the script is piped over ssh):

ssh <host> "python3 - --port /dev/ttyUSB0 --password oelinux123" \
    < scripts/boot-validate.py

With no --power-cycle-cmd, the script watches the console and tells you to power-cycle/reset the board — start it right before (or immediately after) resetting, e.g. right after a flash completes.
--power-cycle-cmd runs a host command once at startup for setups that can drive board power programmatically (lab automation, smart PDU). Keep site-specific automation in that command, not in this skill.
Exit code 0 on BOOT-VALIDATION: PASS, non-zero on failure. The full console capture is mirrored to the log file (default /tmp/qcom-boot-validate-<timestamp>.log) for evidence.

How validation works

Optionally power-cycle, then discard any stale console output so an old login prompt cannot satisfy the check.
Wait (default 300 s) for a fresh login: prompt.
Log in; handle both password and no-password images, and wait for the shell to actually be ready before typing (early commands get swallowed during session setup).
Run fenced sanity checks: uname -a, PRETTY_NAME/VERSION/BUILD_ID from /etc/os-release, systemctl is-system-running.
Verdict: PASS for running/starting; PASS(warn) for degraded (booted, but some unit failed) or non-systemd images; FAIL otherwise, with the last 40 console lines printed for triage.

Compare the reported BUILD_ID with the build you just flashed — a PASS on a stale image is not a validation of the new one.

Notes / gotchas

"no output at all" almost always means the wrong tty device, a console muxed away by DIP switches, or another process holding the port.
OE images enable bash's semantic prompt escapes; the validator strips ANSI/OSC sequences before parsing, so don't be surprised that the raw log file looks noisier than the parsed report.
degraded is reported as PASS(warn) on purpose: the board booted. Chase the failing units separately (systemctl --failed) rather than treating the boot as broken.
The script is read-only on the target apart from logging in and running the three sanity commands; it logs out (exit) when done.

---name: qcom-boot-validatedescription: Validate that a Qualcomm Linux board boots to a working login shell by watching its serial console: wait for the login prompt, log in with the image's default credentials, and check uname, /etc/os-release (incl. BUILD_ID) and systemd state, reporting BOOT-VALIDATION: PASS/FAIL. Use after flashing, when asked to "validate the board boots", "check the board over serial", "did the new image come up", or "watch the boot console". Needs the serial console attached to this host (or reachable over ssh). Do NOT use for flashing (see qcom-flash-qdl) or for diagnosing a healthy-but-degraded system.---# Validate a board boots over the serial consoleDrives the board's serial console to prove a boot actually reached a usableshell — the natural follow-up to `qcom-flash-qdl`. Everything is done by`scripts/boot-validate.py` (paths relative to this skill's directory).## Prerequisites- The board's debug UART attached to a host you can run Python on, at 115200 baud (check `dmesg | grep tty` for the device, e.g. `/dev/ttyUSB0`).- `python3` with `pyserial` on that host; the user in the `dialout` group (or equivalent) so the port opens without root.- Nothing else holding the serial port (close `screen`/`picocom`/`minicom` sessions first — the validator warns if it reads no output).- The image's login credentials (see matrix below).## Credentials matrix| Image | username | password ||---|---|---|| nodistro `core-image-base` (debug image) | `root` | empty || qcom-distro images (`qcom-console-image`, ...) | `root` | `oelinux123` |## UsageLocal serial port:```bashpython3 scripts/boot-validate.py --port /dev/ttyUSB0 --password oelinux123 \ [--timeout 300] [--power-cycle-cmd '<host command>'] [--logfile PATH]```Serial port on a remote host (nothing is copied to it — the script is pipedover ssh):```bashssh <host> "python3 - --port /dev/ttyUSB0 --password oelinux123" \ < scripts/boot-validate.py```- With no `--power-cycle-cmd`, the script watches the console and tells you to power-cycle/reset the board — start it right before (or immediately after) resetting, e.g. right after a flash completes.- `--power-cycle-cmd` runs a host command once at startup for setups that can drive board power programmatically (lab automation, smart PDU). Keep site-specific automation in that command, not in this skill.- Exit code `0` on `BOOT-VALIDATION: PASS`, non-zero on failure. The full console capture is mirrored to the log file (default `/tmp/qcom-boot-validate-<timestamp>.log`) for evidence.## How validation works1. Optionally power-cycle, then discard any stale console output so an old login prompt cannot satisfy the check.2. Wait (default 300 s) for a fresh `login:` prompt.3. Log in; handle both password and no-password images, and wait for the shell to actually be ready before typing (early commands get swallowed during session setup).4. Run fenced sanity checks: `uname -a`, `PRETTY_NAME`/`VERSION`/`BUILD_ID` from `/etc/os-release`, `systemctl is-system-running`.5. Verdict: `PASS` for `running`/`starting`; `PASS(warn)` for `degraded` (booted, but some unit failed) or non-systemd images; `FAIL` otherwise, with the last 40 console lines printed for triage.Compare the reported `BUILD_ID` with the build you just flashed — a PASS ona stale image is not a validation of the new one.## Notes / gotchas- "no output at all" almost always means the wrong tty device, a console muxed away by DIP switches, or another process holding the port.- OE images enable bash's semantic prompt escapes; the validator strips ANSI/OSC sequences before parsing, so don't be surprised that the raw log file looks noisier than the parsed report.- `degraded` is reported as PASS(warn) on purpose: the board booted. Chase the failing units separately (`systemctl --failed`) rather than treating the boot as broken.- The script is read-only on the target apart from logging in and running the three sanity commands; it logs out (`exit`) when done.

Frequently asked questions