RDK S-Series Heterogeneous Development & Board Delegation

S100/S100P/S600 are not "X-series with more TOPS". They are a single SoC with three heterogeneous compute domains that close the perception→decision→control loop on-chip: CPU (Acore, the "big brain") + BPU (decision) + MCU (the "little brain", hard real-time). The single most important thing to get right is which domain a task belongs to and how the two brains talk — put a millisecond joint loop on the MCU over IPC, never on a Linux RT thread, and never confuse the MCU's remoteproc firmware load with MCU0's fastboot/Xburn flashing.

Scope: RDK S100 / S100P / S600 only (Nash BPU, .hbm artifacts). X3/X5/Ultra have no MCU subsystem and none of this applies. Sources are the official D-Robotics rdk_s_doc repo (docs/07_Advanced_development/05_mcu_development, 02_linux_development, 03_multimedia_development) and developer.d-robotics.cc. Every non-trivial claim was re-verified against those docs.

The three compute domains (the foundation)

Two facts that catch everyone:

• MCU firmware is not in apt. You develop MCU1 (open-source business firmware on FreeRTOS), cross-compile a .elf, and load it with Linux remoteproc — no JTAG, no flashing for day-to-day iteration. JTAG / fastboot / Xburn are only for MCU0 (closed-source: boot, power management, OTA).
• CAN on S100/S600 lives in the MCU domain via CANHAL, not Linux SocketCAN. (Only X5 is Linux SocketCAN.)

Decision cheat-sheet — which domain owns the task?

Workflows

Workflow 1 — Develop & load MCU1 firmware (the most common MCU task)

Use when: building/iterating MCU1 firmware, "how do I flash the MCU", "my new firmware won't run".

1. Confirm board + version — S100 vs S100P vs S600, and debug vs release. The build command's argument order differs between S100 and S600 (a classic trap):
   • S100: python build_freertos.py lite matrix B s100 mcu1 gcc <debug|release>
   • S600: python build_freertos.py lite matrix B s600 gcc mcu1 <debug|release> (gcc and mcu1 swapped)
2. Build → produces the MCU1 .elf (e.g. S100_MCU_DEBUG.elf, S600_MCU_DEBUG.elf).
3. Push & load via remoteproc (no flash, no JTAG):

   scp S100_MCU_DEBUG.elf root@<board>:/lib/firmware/
   cd /sys/class/remoteproc/remoteproc_mcu0
   echo S100_MCU_DEBUG.elf > firmware   # S600: S600_MCU_DEBUG.elf
   echo start > state                   # stop with: echo stop > state

4. The wfi trap — after echo stop, you must wait for the system to enter wfi mode before echo start again. Restarting too early reloads firmware over running code in MCU SRAM and the system crashes/runs wild.
5. Debug — read MCU log on Acore via /proc/remoteproc_mcu0 / /proc/remoteproc_mcu1, or over the shared MCU-COM debug UART at 921600 8-N-1 (S100 = Uart4, S600 = Uart8). Check alive/taskcounter/cpuloads sysfs nodes; read crash with cat /sys/devices/platform/soc/soc:mcu_crash/crash.

Full toolchain, build-system files, IPC API, interrupt rules, and S100/S600 diffs: mcu-development.md.

Workflow 2 — Acore-side S-series subsystem (hbmem / IPC / EtherCAT / PTP / PCIe / OTA / VDSP)

Use when: the task is on the Linux side and uses an S-series-only capability.

1. Pick the subsystem from the cheat-sheet, then open the matching section of s-advanced.md.
2. Check the platform gate — most subsystems cover the whole S family, but a few facts differ by board (verified by the docs' <DocScope> tags):
   • hbmem — S100/S100P + S600 (S600 has its own sample guide; board code at /app/communication_demo/hbmem_demo/sample_hbmem).
   • EtherCAT — Native (hobot) driver default on S100 V4.0.7+ and S600 V5.1.0+.
   • IPC instance ranges differ: S100 Acore [0-34] (MCU [0-8] usable); S600 Acore [0-63] (MCU [0-15]/[50-53], BPU [32-39]).
   • OTA partition table — S100 = s100-ota-gpt.json, S600 = s600-ota-gpt.json.
   • VDSP — S100 single core (vdsp0); S600 dual core (vdsp0 + vdsp1, VDSP1 is S600-only).
3. For real-time control, combine: IPC core-pinning/isolation (§IPC) + PTP time sync (§PTP) + EtherCAT or MCU CAN. This is what makes multi-axis loops deterministic.

Workflow 3 — Delegate a board task to the OpenClaw agent

Use when: calling board_openclaw_chat / board_openclaw_delegate, or a handoff got bounced for being too thin.

A board delegation must carry all five fields — a one-line goal, a thin packet gets rejected. A fill-in-the-blanks template is in assets/templates/openclaw_delegation_packet.md.

Worked examples

Example 1 — "我在 S100 上编了新的 MCU 固件，推上去 echo start 之后系统直接挂了 / 跑飞" This is almost always the wfi trap (W1.4). Ask whether they did echo stop > state, then echo start again without waiting for wfi. Restarting before the system enters wfi reloads firmware over running code in MCU SRAM and crashes the board. Recovery on S-series: you cannot power-cycle MCU1 alone — echo stop > state, let it reach wfi, then echo start. Also confirm the right argument order was used to build (S100 = s100 mcu1 gcc).

Example 2 — "S600 上要做多轴伺服运动控制,EtherCAT 怎么起?跟 S100 一样吗?" Yes, S600 is covered — but mind the gate: S600 V5.1.0+ defaults to the Native (ec_hobot) EtherCAT driver (S100 is V4.0.7+). The Native driver is mutually exclusive with the hobot_eth_super gmac driver — starting ethercat.service unloads it, the bound port's MAC disappears from ip a, and Native config must use the MAC address (not the interface name). Then sudo ethercat master shows master/slaves/frame stats. Pair with PTP time sync and IPC core-pinning for deterministic multi-axis loops. Details in s-advanced.md §EtherCAT.

Example 3 — "相机出来的图要送进 BPU 推理,怎么不拷贝大块内存?" Use hbmem zero-copy shared memory (libhbmem / hb_mem_mgr.h). One module's buffer is import-ed into the next thread/process; a consume-count keeps it alive until everyone is done — camera/ISP → BPU input → post-process with no large copies. Use graph_buf for images (planar YUV components are non-contiguous), com_buf for plain featuremaps/audio. hbmem APIs require root. Never mmap a raw physical address — that doesn't bump the reference count and you'll read freed memory. S600 has its own sample at /app/communication_demo/hbmem_demo/sample_hbmem.

Example 4 — "只想更新 bootloader,不想整片重烧整个系统,可以吗?" Yes — miniboot standalone upgrade works even on non-OTA images and applies on reboot. sudo apt-get install -y hobot-miniboot auto-triggers it, or run sudo rdk-miniboot-update --build release --reboot y. It only touches BAK + AB miniboot partitions (SBL/spl/uboot/bl31/optee/MCU/…), never the Permanent partitions, and cannot upgrade the partition table (table changes need D-Robotics' full-flash tool). Caveat: miniboot upgrade has no built-in auto-rollback — a failed dd or power loss mid-write can brick boot; for safety-critical fields prefer the full system OTA (AB + overlayfs) flow. See s-advanced.md §OTA.

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