bare-metal-bringup
Use when bringing up bare-metal or kernel code on a new architecture, SoC, or board (RISC-V, ARM, x86, ESP32) and it won't boot, hangs after boot, or faults…
Use when composing an SoC from peripherals and a bus fabric, or when generating device trees, ACPI tables, docs, or pin lists from a hardware description and they keep drifting out of sync
$ npx -y skills add Midstall/claude-for-hardware --skill soc-integration --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/soc-integrationContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when composing an SoC from peripherals and a bus fabric, or when generating device trees, ACPI tables, docs, or pin lists from a hardware description and they keep drifting out of sync
name: soc-integration description: Use when composing an SoC from peripherals and a bus fabric, or when generating device trees, ACPI tables, docs, or pin lists from a hardware description and they keep drifting out of sync
An SoC is a CPU, a bus fabric, and a set of peripherals connected by an address map. The integration job is to make that map the single source of truth and derive everything else (RTL wiring, device trees, ACPI, docs, firmware headers) from it.
**Core principle:** Describe the SoC once in a neutral structure. Every output is a consumer of that structure, never a producer of its own truth. The day a device tree and the RTL disagree about a base address is the day you debug ghosts.
Skip for a single fixed-function block with no bus and no software-visible map.
Model each peripheral as a first-class hardware module that exposes its bus interface, its register block, and its metadata (compatible string, interrupt number, address size). Because it is a real module, you can elaborate it, test it, and read its metadata to generate a device tree node.
Avoid a "plugin" that is just a config blob with no hardware behind it. If the device tree generator and the RTL both have to know a peripheral exists, they should learn it from the same module, not from two parallel lists that rot independently.
Do not couple the generators to each other or to one CPU implementation. Define a neutral type that captures what every consumer needs (cores, memory regions, peripherals, interrupts, the address map) and have each generator read from it.
SoC description (neutral)
/ | \
RTL DeviceTree ACPI / docs / headers
wiring generator generatorsThe thing that hosts peripherals and builds the fabric must be per-instance, not a global registry. Two SoCs (or two test cases) being elaborated at once must not stomp each other. Per-instance state is also what lets you build many configurations in parallel.
| Smell | Do instead | |-------|------------| | DTS list and RTL list of peripherals maintained separately | Derive both from the peripheral modules | | Generator imports another generator | Both read the neutral description | | Global peripheral registry | Per-instance host | | Base addresses assigned ad hoc | One validated address-map allocator | | Generator hardcodes one CPU type | Generators take a neutral SoC type |
Claude Code skills for hardware design, validation, and bring-up. A plugin of focused skills that teach Claude how to do real hardware work: designing reusable HDL, integrating an SoC, bringing up FPGAs and bare-metal targets, building firmware boot chains,
Repo: Midstall/claude-for-hardware
Use when bringing up bare-metal or kernel code on a new architecture, SoC, or board (RISC-V, ARM, x86, ESP32) and it won't boot, hangs after boot, or faults…
Use when building or debugging a compiler backend, codegen, or assembler and you need to prove the generated machine code is correct by executing it on a real…
Use when verifying a hardware DUT (a CPU core, FPGA, or netlist) against a golden reference model, building coverage-guided fuzzing, or detecting where silicon…
Use when building or debugging a firmware and boot chain (RISC-V SBI, UEFI, ACPI, a bootloader handoff like Limine to an OS) or adding measured boot with a…
Use when loading a bitstream onto a physical FPGA and driving or observing it over JTAG or GPIO, especially bit-banged JTAG from a host like a Raspberry Pi, or…
Use when synthesizing RTL to an FPGA with yosys/nextpnr (ECP5/Lattice and similar), fighting area or routing congestion, measuring Fmax, deciding why a design…