en un clic
hisi-riscv-rs
hisi-riscv-rs contient 13 skills collectées depuis hispark-rs, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
Maintain hisi-hal register access through SVD/PAC truth sources. Use when changing HAL MMIO/register code, reviewing raw PAC usage, fixing check-register-access CI failures, adding or correcting SVD/PAC fields/access types, regenerating ws63-pac or bs2x-pac, deciding whether a register should be modeled in SVD versus handled in HAL, or auditing read/modify/write behavior for write-only or dynamically masked registers.
Commit + push changes that span ws63-rs git submodules in dependency order, then bump the parent repo's submodule pointers. Use when you've edited files inside one or more submodules (ws63-pac/hal/rt/examples/guide, chips/ws63/rf/ws63-RF, ws63-pac/ws63-svd) and need to land them correctly.
Make a hisi-hal driver's CONFIG surface "if it compiles, it runs on silicon" — design, review, or tighten a Config / new() / configure() so a value you can WRITE is a value that RUNS, with no parameter that compiles but is silently clamped, truncated, left without a clock, or dependent on an unenforced precondition. Use when adding a driver, reviewing/PR-ing a config API, tightening one for the 0.5.0 config pass, or diagnosing a "compiles but wrong/dead on hardware" bug. Applies the project's primary API convention (see root Agent Instructions "Typed config").
Create, modify, audit, build, or run on-target embedded-test HIL tests for hisi-hal and tests-hil. Use when adding HAL driver silicon evidence, writing crates/hisi-hal/tests/hil/*.rs cases, registering
Diagnose a HIL CI failure on real WS63/BS2X silicon — compare the failed CI run against the last passing run, identify whether the regression is caused by a code change, toolchain update, or rig issue, and output a triage report. Use when a HIL CI job fails on the main branch or a PR.
Build a ws63-rs example for a HiSilicon chip, flash it to a REAL board via the repo HIL flash path, read UART, and assert the example marker — the silicon twin of qemu-smoke. Use for example-level hardware smoke; HAL driver-level evidence uses embedded-test via hil/embedded-test-runner.sh instead.
Build a ws63-rs example for a HiSilicon chip (ws63/bs21/bs21e/bs22/bs20) and boot it in the hisi-riscv-qemu fork, asserting the expected UART banner / GPIO toggle / embassy interleave / IRQ delivery. Use to validate firmware end-to-end in emulation, or after touching a driver/example/the QEMU model.
Drive one hispark-rs repo's tag-triggered release to the finish line — push the v* tag, watch the multi-platform CI matrix to completion, report every leg, and verify the published GitHub release assets (or note a crates.io publish). Use to cut or babysit a release of the QEMU fork or a library crate; the old custom Rust toolchain tarball release path is legacy.
Build, check, lint, and test the ws63-rs embedded HAL for HiSilicon WS63 (RISC-V). Use when asked to build, verify, run checks, or test hisi-hal, ws63-pac, or any crate in this workspace.
Run SAFETY comment audit, unsound-encapsulation scan, and Kani verification on hisi-hal unsafe code. Use during the safe/unsafe verification cycle (P0–P3) to validate soundness before a release.
Manage the stable/unstable API gating in hisi-hal: add a new unstable surface, graduate one to stable (write HIL + remove the gate), or audit which items should be gated. Use when adding a driver/API, reviewing a PR that touches pub items, or checking gating compliance.
Run the same ws63-rs example through both QEMU (qemu-smoke) and real silicon (hil-smoke) and diff the UART markers — the QEMU↔silicon parity check. Use to prove the emulator matches hardware, especially the timing-sensitive checks QEMU can't validate (160 MHz UART baud, 24 MHz TCXO timer period). With no board it fills the QEMU column only.
Review, write, restructure, and maintain Markdown/mdBook/repository documentation using the Diataxis framework. Use when asked to audit documentation organization, create or edit docs, choose tutorial/how-to/reference/explanation placement, prevent documentation drift, enforce a single source of truth, update SUMMARY/navigation, or verify docs after changes.