RDK Command Manual (RDK-specific commands + Linux command index)

This is the command-as-anchor lookup. The user already knows the command name (or a fragment) and wants its exact syntax, options, typical use, which boards it applies to, and the official source. If instead they have an error/symptom and don't know which command to run, that is rdk-board-knowledge, not this skill.

Sources: D-Robotics official docs. RDK-specific commands come from rdk_doc docs/09_Appendix/rdk-command-manual/ (X-series, category label 9.1 RDK专属命令用法) and rdk_s_doc / rdk_doc docs_s/09_Appendix/rdk-command-manual/ (S-series). srpi-config lives in 02_System_configuration/02_srpi-config.md. The Linux appendix is 09_Appendix/linux-command-manual/ (label 9.2 Linux命令用法). Every fact below was re-verified against these files on main.

The one thing that matters most

The same command name can behave differently per board. hrut_boardid on X3 has g/s/G/S/c/C sub-options; on X5 it only prints (-h is the sole flag); on S-series it just emits 0x6A84-style output. hrut_somstatus adds a multi-rail voltage block on S-series that X-series never shows. Never recite a command's behavior without first pinning the board. When unsure, tell the user to run which <cmd> or <cmd> -h on the actual board, then explain from the matching doc.

Board → command-availability cheat-sheet

Confirm the board family first, then read the row. "Same" means the command exists with the same core behavior; differences are called out.

BPU profiling / monitoring commands (hrut_bpuprofile, hrut_smi, bputop, cat /sys/devices/system/bpu/bpu0/ratio, etc.) carry per-board and risk-tier nuances and are maintained in rdk-board-knowledge (references/diagnostic-commands.md), not here. Don't duplicate them.

Workflows

Workflow 1 — Answer "what does command X do / what are its options?"

1. Pin the board family (X3 / X5 / Ultra / S-series). If the user didn't say, ask, or tell them to run which <cmd> / <cmd> -h.
2. Open the matching row in the cheat-sheet, then the full entry in rdk-commands.md for exact syntax, every option, typical usage, and the source path.
3. Call out per-board differences explicitly — e.g. "on X5 hrut_boardid only prints, the g/s set is X3-only."
4. Give the official doc URL when the user wants to read more (URL pattern in the reference header).

Workflow 2 — Answer "which command checks temperature / status / board id on this board?"

1. Map the intent to the command: temperature/freq/BPU-load → hrut_somstatus; full system snapshot for a bug report → rdkos_info; board id → hrut_boardid; SoC UID → hrut_socuid; rich process info → hrut_ps.
2. If the intent is "the command errored, what's wrong" → stop and route to rdk-board-knowledge (symptom triage). This skill explains what a command is, not why it failed.
3. For collecting evidence before filing an issue, recommend sudo rdkos_info -d (300 log lines) — it bundles hardware model, CPU/BPU status, memory, OS/kernel/miniboot versions.

Workflow 3 — Answer "how do I update miniboot / back up the system?"

1. X-series: sudo rdk-miniboot-update (latest) or -f <file>; preview the default image with rdk-miniboot-update -l. Back up with sudo rdk-backup [dir] — must be online first, produces rdk-<datetime>.img.
2. S-series: rdk-miniboot-update/rdk-backup are not in the S appendix. Route miniboot updates to the OTA flow (rdk_doc docs_s/07_Advanced_development/02_linux_development/06_OTA/02_ota_miniboot.md) and full flashing to xburn. See the source note in rdk-commands.md.

Workflow 4 — Answer "what's in srpi-config / how do I configure Wi-Fi/SSH/interfaces?"

1. Reject Ultra immediately: srpi-config is documented only for X3, X5, X3 Module — not RDK Ultra.
2. Map the request to a menu (full menu tree in rdk-commands.md): Wi-Fi/password/hostname/login → System Options; SSH/VNC/40-pin bus → Interface Options; overclock/ION memory → Performance Options; locale/timezone → Localisation; expand filesystem/boot order → Advanced.
3. 40-pin peripheral bus: interfaces on the same row share pins — only one can be active at a time. X5 adds PWM. For deeper driver/devicetree setup, hand off to rdk-peripheral-cookbook.
4. S100 also has srpi-config but a leaner Interface menu (VNC being adapted; peripheral config points to config.txt).

Workflow 5 — Answer Linux-appendix command questions

The appendix (apt / dmesg / dpkg / dpkg-deb / find / grep / ifconfig / ip / mount / netstat / nohup / ps / route / rsync / scp / ssh / tar / top / zip) is generic Linux usage that D-Robotics bundled for beginners. Index back to the official page (linux-commands.md) or explain from standard man semantics. Do not invent RDK-specific behavior for these. If the user's real problem is an RDK-board symptom (APT key failure, TROS package not found), that's rdk-board-knowledge.

Worked examples

Example 1 — "hrut_boardid 在我的 X5 上为什么没有 g/s 这些选项？" "Because the g/s/G/S/c/C sub-options are X3-only. On X5 hrut_boardid is print-only — its only flag is -h, and it just prints the current boardid. The full 32-bit bitfield (DDR vendor/type/freq/capacity/SOM type/base-board) you may have seen is the X3 definition. On S-series it instead prints a 0x6A84-style code (chip id / power design / board revision)." Point to the hrut_boardid entry in references/rdk-commands.md.

Example 2 — "rdkos_info -d 和默认输出有什么区别?" "-d is detailed mode: it appends the latest 300 lines of system log, vs the default -s simple mode which shows 30. -b collects no logs at all. The body is the same: [Hardware Model], [CPU And BPU Status], memory, [RDK OS Version], [RDK Kernel Version], [RDK Miniboot Version]. On X-series you also get [ION Memory Size]; on S-series the board id shows as 0x6A84 and there's no ION line. Run sudo rdkos_info -d and paste the output — it's the single best snapshot for a bug report."

Example 3 — "S100 上怎么更新 miniboot?" "rdk-miniboot-update is documented for X-series; it's not in the S-series command appendix. On S100, update miniboot through the OTA flow (docs_s/07_Advanced_development/.../06_OTA/02_ota_miniboot.md), and do full-image flashing with xburn. Don't assume the X-series rdk-miniboot-update -f path exists unchanged on S100 — verify with which rdk-miniboot-update on the board first."

Example 4 — "srpi-config 里在哪开 SSH 和 40pin 的 I2C？" "Both are under Interface Options. SSH is a direct enable/disable (on by default). For I2C use Peripheral bus config — it edits the devicetree bus status and takes effect after reboot. Note interfaces sharing a pin row are mutually exclusive (only one active); X5 adds PWM to that table. Heads-up: srpi-config is X3/X5/X3-Module only — not Ultra. For driver-level peripheral bring-up, use rdk-peripheral-cookbook."

Common pitfalls

Anti-hallucination guardrails

When answering from this skill, follow these rules — never fabricate facts, commands, or file paths:

1. Report only observed data. Quote what scripts/commands actually return, not what you remember. If the probe says board_id: X5, answer for X5 — even if the user insists it's an S100.
2. No fabrication when tools are missing. If a script or reference doesn't exist, say "not found" — don't invent from memory. Route to the appropriate skill or doc instead.
3. Preserve null/false/empty on failure. If a probe returns null or false, report that — don't substitute a plausible value. Empty output is data, not an error to "fix".
4. No substitution off-platform. If off_platform: true, say "probe didn't run on an RDK board" — don't guess what it would have returned. Ask for on-board logs.
5. No hand-editing JSON. Scripts emit structured JSON; never hand-craft output. If the contract says {ok,off_platform,reason,fields}, that's what goes to the user.
6. Acknowledge sandbox limits. If you can't run a command, say so — don't pretend you did. Offer the command for the user to run.
7. Read-only boundary. Never modify the system — no dd, mkfs, rm -rf, apt install, reboot, or GPIO output without explicit user confirmation.

Reference map