board-bringup
npx machina-cli add skill beriberikix/zephyr-agent-skills/board-bringup --openclawZephyr Board Bringup (HWMv2)
Bring your custom hardware into the Zephyr ecosystem using modern Hardware Model v2 standards.
Core Workflows
1. Planning the Structure
Organize your board files by vendor and board name.
- Reference: hwmv2_structure.md
- Key Tools:
board.yml, naming conventions.
2. Defining Configuration
Implement the essential Kconfig and CMake logic.
- Reference: board_files.md
- Key Tools:
Kconfig.board,_defconfig,CMakeLists.txt.
3. Managing Revisions & Variants
Handle hardware iterations and SoC variants cleanly.
- Reference: hwmv2_structure.md
- Key Tools: Multi-revision
board.yml, revision-specific overlays.
Best Practices
- Use
_common.dtsi: Share devicetree definitions across all board revisions. - Follow HWMv2: Avoid the legacy board structure (
Kconfig.defconfig, etc.). - Keep it minimal: Only define what is unique to the board; let the SoC files handle chip-level configuration.
Resources
- References:
hwmv2_structure.md: Directory layout andboard.yml.board_files.md: Kconfig, defconfig, and CMake configuration.
Source
git clone https://github.com/beriberikix/zephyr-agent-skills/blob/main/skills/board-bringup/SKILL.mdView on GitHub Overview
Guides bringing a custom board into Zephyr using Hardware Model v2. It covers organizing the directory structure, creating board.yml metadata, and implementing core configuration files (Kconfig, defconfig, CMake) along with revision management. Use it when creating new board definitions or porting Zephyr to custom hardware.
How This Skill Works
Structure your board under vendor/board with a multi-revision board.yml and revision-specific overlays. Implement essential configuration with Kconfig.board, _defconfig, and CMakeLists.txt, following the HWMv2 references. This approach emphasizes avoiding legacy Kconfig.defconfig structures and keeping revisions clearly separated.
When to Use It
- Creating a new Zephyr board definition using HWMv2
- Porting Zephyr to a custom hardware platform
- Managing multiple revisions or variants of a board
- Defining clear board metadata with board.yml
- Migrating from legacy board structure to HWMv2
Quick Start
- Step 1: Organize your files under vendor/board and draft board.yml
- Step 2: Implement Kconfig.board, _defconfig, and CMakeLists.txt for core configuration
- Step 3: Add revision overlays and test builds against RevA/RevB
Best Practices
- Use _common.dtsi to share devicetree definitions across all board revisions
- Follow HWMv2 and avoid the legacy board structure (Kconfig.defconfig, etc.)
- Keep it minimal: only define what is unique to the board; let the SoC files handle chip-level configuration
- Organize files by vendor and board name
- Use multi-revision board.yml with revision-specific overlays
Example Use Cases
- Creating a new board definition for a custom Cortex-M MCU using HWMv2
- Porting Zephyr to a custom FPGA-based development board
- Adding RevA and RevB variants with overlays for a single board
- Migrating an existing legacy board to the HWMv2 structure
- Defining board.yml metadata for a new vendor-supported board
