taishanpi

name	taishanpi
description	Use for TaishanPi Linux-board work through DBT tools, including 1M-RK3566, 1F-RK3566, and 3M-RK3576 capability constraints, chip-control probes, WiFi/Bluetooth probes, environment checks, and build-run flows.

TaishanPi

Rules

• When the user explicitly invokes @dbt-agent, [@dbt-agent](plugin://dbt-agent@plugins), or the Embed Labs plugin for TaishanPi work, treat the message as a DBT tool intent and prefer MCP tools over shell commands.
• For plugin/runtime version requests such as 本地插件版本号, 服务器最新版本号, 当前插件版本, latest plugin version, or plugin version, call dbt_get_plugin_versions directly. Do not inspect the workspace, read plugin files, probe dbtctl, or run shell commands for version lookup.
• For plugin/runtime update requests such as 更新插件, 升级插件, 更新 Embed Labs, 检查插件更新, or update plugin, do not inspect the workspace, read plugin files, probe dbtctl, or run shell commands. If the user asks to update, call dbt_update_plugin directly; if the user only asks whether an update exists, call dbt_check_plugin_update.
• For macOS GUI requests such as 安装 GUI, 安装 mac 端 GUI, 安装图形界面, 卸载 GUI, or uninstall GUI, call dbt_install_gui or dbt_uninstall_gui directly. These tools only manage the optional DBT-Agent.app; they must not remove the shared runtime, dbt-agentd, board environments, Codex plugin, or OpenCode plugin.
• If the user writes a DBT MCP tool name such as dbt_current_board_status, including with a leading $, backticks, or command-like wording, call the matching MCP tool directly. Never run DBT MCP tool names through zsh.
• If the board is already identified and the task is capability lookup or code generation, use dbt_get_capability_context and dbt_get_board_config directly instead of re-checking status first.
• For direct live-board status requests such as 开发板状态, 当前开发板状态, or 查看当前开发板状态, call the MCP tool dbt_current_board_status immediately as the first action; do not run dbtctl status, shell commands, web search, workspace probes, memory-file searches, or repository/skill-file reads before that MCP tool.
• Keep the last confirmed TaishanPi board, variant, and fetched capability context sticky within the current conversation. Reuse them for follow-up turns unless the user says the hardware changed or asks for a fresh live check.
• If capability summaries or capability context were already fetched earlier in the conversation, do not re-call dbt_get_capability_context just to confirm support.
• If board config was already fetched for the same board and variant in the current conversation, reuse it instead of calling dbt_get_board_config again.
• For broad capability or feature prompts such as 开发板有什么能力, 当前开发板有什么能力, 这个开发板支持什么功能, or 这块板能做什么, use dbt_list_capability_summaries for the confirmed TaishanPi board and variant. Do not use Search, Read, rg, memory files, repository docs, GUI docs, DBT-Agent-Project.md, or local handoff files for user-facing answers.
• For user-facing feature or characteristic questions, summarize the board from DBT status/config/capability data. Do not quote local source-checkout docs, GUI docs, or private host paths; omit paths unless the user asks where an installed runtime artifact lives.
• For TaishanPi pin, 40PIN header, pinmux, GPIO, PWM, UART, I2C, or SPI questions, use DBT capability summaries/context first. If DBT tools are unavailable and the request is knowledge-only, use installed published knowledge under ~/Library/development-board-toolchain/agent/{vault,registry}/published, not the current source checkout.
• Treat pin_header_40pin as reference-only: it maps physical pins and default mux, but it is not an execution contract. Do not promise PWM output from the pin table alone; require a published PWM capability or a live check of /sys/class/pwm plus the running device-tree/pinmux state.
• Use dbt_get_board_config and dbt_get_capability_context before generating code.
• Use dbt_get_board_config with probe_env=true before TaishanPi build or environment work. For generated program build/run, prefer omitting build_mode or using auto; the runtime must probe the running board rootfs/sysroot ABI and match docker or local-llvm to that userland ABI before compiling. Do not infer the application compiler from the kernel compiler string alone.
• Pass build_mode=docker or build_mode=local-llvm only when the user explicitly selected a mode, when installing/checking a specific environment, or when flashing/downloading a specific image family. If the runtime reports a rootfs/sysroot ABI mismatch, stop and tell the user to switch to the matching mode; flash a matching image only when they intend to change the board's running rootfs/userdata ABI.
• For Qt or QtQuick application requests, do not route through linux_program, do not look for qmlscene, and do not hand-assemble compiler/linker commands. Treat the result as an engineered Qt app project: create source/assets/config in the current user workspace, maintain embedlabs-app.json for reusable or release-bound apps, then call dbt_qt_build_run_app with project_dir and workspace only when the user asks to deploy or run on the board.
• QtQuick apps should be compiled executables, usually with CMake and qt_add_qml_module; the board image may only contain the Qt runtime under /userdata/qt6-rk3566-llvm, not developer launchers such as qmlscene.
• Keep Main.qml preview-compatible with an Item/Rectangle root, then make the compiled board executable visible with a C++ QQuickView launcher (SizeRootObjectToView plus showFullScreen()). Do not load an Item/Rectangle root with QQmlApplicationEngine alone; it can build and start but create no visible board window.
• The default TaishanPi Qt display backend is eglfs from /userdata/qt6-rk3566-llvm/qt6-env.sh. Do not force linuxfb unless the panel/display stack was explicitly diagnosed. If rotation is needed, prefer QML/C++ layout rotation or a tested explicit qpa_platform.
• Treat board deployment as successful only after dbt_qt_build_run_app returns the remote app dir and runner, the app process is still present after a short delay, and the board log has no QML/QPA errors. A preview screenshot or one initial launch line is not enough.
• If the screen is blank, use dbt_list_board_processes, inspect remote_log_path, confirm runner QPA, and verify the C++ entrypoint is QQuickView before trying new build flags.
• QtQuick has two target modes: host-qt-app for local macOS Qt applications and UI fine-tuning, and board-qt-app for cross-compiled board applications. Both use local preview and annotation-driven edits; only board-qt-app uses board build/deploy.
• Before generating a TaishanPi QtQuick UI, make sure the target display resolution and orientation are known. If missing, ask for width x height plus portrait/landscape before writing UI code, then pass those values as screen_width, screen_height, and orientation to preview tools.
• For local QtQuick preview/design work, create or edit QML in the current user workspace, call dbt_qml_preview_validate, call dbt_qml_board_runtime_start when a connected board should mirror the preview, start dbt_qml_preview_start, then use dbt_qml_preview_feedback after the user marks a control, container, or region. The preview host persists user rotation, window position, and per-rotation window sizes for each project, so toolbar rotation must preserve the user's adjusted window scale instead of resetting to defaults. Make targeted QML edits from semantic_item/item/container_item/selection, validate again, and do not treat a preview session as final release.
• After implementing UI changes, ensure a preview is running and call dbt_qml_preview_capture; inspect the returned screenshot path when available and compare it with the user's UI goal before finalizing. For board-side linkage, use backend=board-runtime with the host/port returned by dbt_qml_board_runtime_start; otherwise keep local preview on native-qquickview and say it is local-only.
• dbt_qt_build_run_app deploys a standalone compiled board app. It is not a live-linked preview session, so local preview actions, user annotations, and preview toolbar rotation do not affect that deployed process. Use it only after the user confirms the live-preview result should be packaged/run as the final app. For real live linkage, verify the returned session backend is exactly board-runtime.
• backend=board-runtime must fail clearly when the board runtime host/port is missing, unreachable, or blocked by an already-running preview session with another backend. Do not report local preview screenshots as board evidence and do not claim board synchronization from a native-qquickview session.
• Board-runtime linkage is a Runtime Message Center feature, not a per-demo QML contract. The runtime syncs QML files, hot reloads, generates ui.manifest, uses UiControlBinder to convert stable standard input-control notify signals into ui.event, applies lightweight changed-path app.state.patch messages on both sides with state_revision, captures board evidence, and applies default display rotation/coordinate mapping from board input_width/input_height rather than raw framebuffer size. state_hash/app_state_hash is only a low-frequency hello/status/full-state diagnostic and must not be required for every realtime control update. Runtime-managed pointer/focus/key mirroring is only a diagnostic/compatibility path for non-bound controls and text focus/key handling; continuous controls must stay state-authoritative. ComboBox popups are synchronized by currentIndex plus popupVisible/popupStatePath, not by raw pointer forwarding; verify the board manifest or screenshot after rotation includes the dropdown options. Button, hardware action, and business-command controls must still use explicit appRuntime.state / appRuntime.dispatch; do not trigger board side effects with raw pointer mirroring. Runtime suppresses board echo loops by ignoring source=preview-host echoes, giving recently host-written continuous-control paths, ui.rotation, and jobs.active.progress paths short host authority, and coalescing stale queued continuous-control values to the latest value on both host and board while keeping ComboBox open-state paths bidirectional. Generated QML may read boardRuntimeDisplay.rotation for fine-grained layout adaptation, but ordinary input controls should work without hand-written synchronization. Use explicit appRuntime.state / appRuntime.dispatch for Button actions, Popup/Dialog business state, View scroll commit, ProgressBar/task status, hardware actions, long jobs, errors, custom controls, and durable business state.
• TextField/TextArea must expose statePath, cursorStatePath, and focusStatePath when host and board need live linkage. Treat text + cursorPosition + activeFocus as one atomic state batch, especially for middle deletion and insertion. Slider/Dial/SpinBox must stream value changes during drag through ui.event/app.state.patch in both directions; do not accept a release-only update, raw-pointer-only dragging, or alternating host/board values as realtime linkage evidence. ComboBox dropdown tests must verify host->board and board->host opening from the board manifest/screenshot after display rotation, not just local preview state.
• For QtQuick release or delivery requests, write a release manifest in the workspace with target mode, main QML, Qt version, validation/build results, board/deploy/runner fields when applicable, and keep build artifacts under workspace release/build directories.
• User Qt projects deploy to /userdata/qt-project/<ProjectName> by default. Use qpa_platform only for board display backend options such as linuxfb rotation; app-level layout or rotation should normally be implemented in the generated QML/C++ source.
• For board-app autostart requests, call dbt_configure_autostart after deployment. Use app_type=qt with remote_runner_path from dbt_qt_build_run_app, and use app_type=native with remote_binary_path/remote_artifact_path from dbt_build_run_program. Do not inspect systemd/SysV/OpenRC, do not create per-app systemd units, and do not write custom /etc/init.d app scripts; DBT owns the fixed /userdata/.dbt-autostart broker and single boot hook.
• Treat rgb_led as a capability contract, not as a built-in application feature. For simple atomic LED state changes such as a single solid color or off, dbt_apply_effect may be used as a compatibility/direct-control path. For any request with user logic, timing, blinking, breathing, repeat counts, multi-step sequences, or traffic-light behavior, generate self-contained C/C++ source in the current workspace and use dbt_build_run_program with capability=rgb_led.
• Use dbt_build_run_program for code-generation, compile, upload, and run flows; always pass workspace as the current user/project directory so generated source and local artifacts are created directly there, not in a fixed temp path or private source checkout.
• Use capability linux_program with dbt_build_run_program for generic Linux C/C++ diagnostics, finite CPU stress tests, benchmarks, and board-side probes.
• Do not use capability chip_control with dbt_build_run_program; chip_control live CPU, DDR, temperature, memory, and storage checks should use dbt_probe_chip_control.
• Use dbt_probe_chip_control for CPU, DDR, temperature, memory, and storage.
• Use dbt_list_board_processes for Linux-board process and daemon inspection requests.
• Use dbt_probe_wifi_bluetooth, dbt_scan_wifi_networks, and dbt_scan_bluetooth_devices for wireless checks.
• Use dbt_ensure_usbnet when USB ECM host configuration is relevant.
• For 进入 Loader, 进入下载模式, loader mode, or download mode, call dbt_reboot_loader directly. Do not route this through dbt_get_capability_context.
• For normal reboot, or for returning from Loader USB back to the normal runtime state, call dbt_reboot_device.
• In TaishanPi work, phrases such as 下载初始化镜像, 恢复初始镜像, 烧录初始化镜像, 刷写初始化镜像, 恢复出厂镜像, or factory image mean factory full-image burning to the board unless the user explicitly says "只下载到本机" or "只检查本地缓存".
• For real factory/init image burning, first call dbt_current_board_status, then call dbt_start_flash_image with image_source=factory and scope=all, then call dbt_get_job_status with the returned job_id so the user sees progress. The installed runtime is responsible for moving between USB ECM runtime and Loader/Maskrom USB modes.
• For direct burning of one complete .img file, call dbt_start_flash_image with scope=raw and host_image_file=<path-to-img>, then poll dbt_get_job_status. Do not unpack the image, do not search for partition files, and do not run rkdeveloptool or dbtctl manually. The runtime detects Rockchip RKFW/RKAF update packages, rewrites their GPT/parameter layout, and flashes their contained partition image set internally; only true raw disk images are written from LBA 0.
• Use dbt_flash_image only for dry_run=true, short blocking validation, or when the user explicitly asks to wait for final completion in one blocking tool call.
• Do not call dbt_install_board_environment, plugin-list tools, filesystem listing, or source checkout docs for factory/init image burning. Environment installation is only for local compiler/runtime environments.
• For startup-logo, boot-logo, splash-logo, or logo replacement requests, call dbt_update_logo directly with the user-provided host image path plus requested rotate, scale, build_mode, and flash options. Do not inspect or edit boot workspace files, do not manually convert the image, and do not manually run rebuild_boot.sh; the runtime update-logo method owns image conversion, sizing, boot/resource rebuild, and optional boot flashing.