SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsfw-core

fw-core

Design & creation

View repository

Updated 10-15 21:48

About this skill

Firmware Task Master Router (fw-core)

This Skill is theentry routerof the firmware-skills package: it first classifies the task, then hands it to a dedicated Skill within the package or explicitly hands it off to a Skill outside the package. This Skill does not directly produce images or firmware code.

Determine Task Type

First determine the deliverable type, then route:

  1. Linux gateway firmware (OpenWrt family) — the goal is a flashable OpenWrt image or its rootfs contents → OpenWrt chain (see routing-openwrt）。
  2. MCU firmware (ESP-IDF family) — the goal is on-chip firmware for ESP32/ESP32-S/C series → ESP32 chain (see routing-esp32）。
  3. Rust no_std firmware — the user requests firmware written in Rust using no_std/embedded-hal/Embassy/RTIC → not covered by this package, explicitly hand off to rust-skills/rust-embedded(see the last row of the Hand-off table: refuse and route).
  4. Only want a "runnable" simulation verification — no hardware, just want to get it running in QEMU/simulation first → fw-emulation。

For classification criteria details (by keyword or by deliverable, what to ask when unsure), see task-typing。

Prerequisites / Preflight

Before routing, two things must be confirmed first; if the user has not said, ask,do not guess：

  1. Target platform: which device/chip? (e.g. "N1 box", "x86 soft router", "ESP32-S3", "mt7981 router")
  2. Deliverable type: a complete image, rootfs modification, runtime configuration, or a piece of application code?

Runtime verification (must still be re-verified after entering a specific Skill):

# 构建 OpenWrt 镜像需 Linux x86_64（或 Docker 内 Linux）
uname -m && make --version | head -1
# ESP-IDF 工程需确认 IDF 版本
idf.py --version 2>/dev/null || echo "IDF not in PATH"

Mantra (recite silently before every routing): "A successful build ≠ hardware usable." An image being compiled only represents Build Verification; without real hardware evidence, do not claim "verified on device" (CONVENTIONS §5).

Offline Baseline

  • OpenWrt baseline = 25.12.5(upstream walkthrough date 2026-09-02, not auto-updated).
  • ophub (amlogic-s9xxx-openwrt) baseline = upstream HEAD c593d56。
  • The ESP-IDF baseline is subject to the Phase 2 baseline document (declared within esp32-idf).
  • For behavior changes after the above versions, refer to official sources; do not assert from memory.

Contracts (device contracts)

  • PROFILE and the target device must be empirically verified: for OpenWrt, the PROFILE name is based on the make info output; the device model is based on the physical model/bootlog provided by the user. If the two do not match, stop and ask,when uncertain, fabricating is prohibited。
  • For questions involving DTB file names, pin multiplexing, partition offsets, memory layout, registers:when uncertain, stop, route to runtime verification (fw-hil-testing / openwrt-serial-recovery) or official sources; do not give values from memory (CONVENTIONS §2 anti-hallucination red line).
  • Writing to eMMC/flashing flash is a destructive operation: before executing, the target drive letter must be repeated back and user confirmation obtained.

Capability Boundaries + Hand-off routing table

This Skill only does classification and routing. The table below covers all 19 dedicated Skills in this package and 1 out-of-package hand-off:

User Intent Skill
Build OpenWrt image / FILES overlay injection openwrt-image-build
N1 / Amlogic box / write to eMMC (repackaging) openwrt-amlogic-remake
Boot autostart / init script (procd) openwrt-procd-init
First-boot configuration / UCI / uHTTPd / firewall openwrt-uci-defaults
Hard disk mounting / USB storage openwrt-storage-mount
Bricked / serial recovery openwrt-serial-recovery
ESP-IDF project structure / partition table esp32-idf
FreeRTOS tasks / queues / synchronization esp32-freertos
Peripherals / pins (GPIO/I2C/SPI/UART/PWM/ADC) esp32-peripherals
Network provisioning (SmartConfig/BluFi/AP provisioning) esp32-wifi-provision
OTA upgrade esp32-ota
Low power (Deep Sleep/light sleep) esp32-lowpower
Secure boot / Flash encryption esp32-secureboot
coredump / JTAG / GDB debugging esp32-debug
Chip selection (ESP32 series comparison) esp32-variants
Cross toolchain (common to both chains) fw-toolchain
Boardless simulation (QEMU/Wokwi, get it running before going on board) fw-emulation
Hardware acceptance (HIL hardware-in-the-loop testing) fw-hil-testing
Release process / artifact naming / checksum fw-release-gate
Rust no_std / embedded-hal / Embassy / RTIC firmware Out of scope:rust-skills/rust-embedded(refuse and hand off)

How to choose among the three chains inside OpenWrt (official IB direct output vs ophub repackaging vs runtime configuration only), read routing-openwrt; for the ESP32 chain selection tree read routing-esp32。

Workflow

  1. Classification: determine 1/2/3/4 according to Determine Task Type; when unsure, ask follow-up questions based on the criteria in task-typing .
  2. Ask about the platform: confirm the target device/chip and the deliverable type (see Prerequisites).
  3. Look up the routing table: on hitting a row → load the corresponding Skill and bring the context (platform, version, constraints) along.
  4. Cross-chain task splitting: e.g. "make firmware with a custom service for N1" = openwrt-image-build(rootfs side) + openwrt-amlogic-remake(eMMC image side), hand off serially in chain order, do not mix them in one Skill.
  5. Refusal and handoff: Rust no_std request → clearly state that this package does not cover it, hand off to rust-skills/rust-embedded; platforms other than OpenWrt/ESP32 (e.g. bare-metal STM32 bare-metal C firmware) → state that it is out of scope, give only general advice and point to the official documentation.

Validation Gates

  • The routing result must match one row in the table; for anything that does not match, clearly say "out of scope" rather than forcing it.
  • When handing off, restate the three elements: target platform, deliverable type, confirmed constraints/baseline.
  • Before any artifact claims to be "usable", check: is there hardware evidence? If not → mark Build Verification Only or Pending HIL。

Pitfalls

  1. Do notstart "helping write configurations" before asking about the platform and deliverable type—OpenWrt's UCI configuration and ESP-IDF's sdkconfig are two different worlds.
  2. Do notroute N1/Amlogic box requirements to openwrt-image-build and stop there—official IB direct output does not include the box eMMC layout, you must continue handing off to openwrt-amlogic-remake。
  3. Do nottake on Rust no_std tasks with this package—rather refuse and hand off to rust-skills/rust-embedded, than force an answer using general C/ESP-IDF knowledge.
  4. Do notfabricate PROFILE/DTB/partition offsets—when unsure, route to runtime verification.
  5. Do notreport "build succeeded" as "ready to flash and use".

Official Sources

Privacy

This Skill only performs local classification and routing; it does not collect, store, or send out user data, device serial numbers, or credentials. Accessing the above official links must comply with the network policy of the user's environment.