Build fails the ZMK compat check: xiao_ble needs its ZMK board variant #1

New issue

Closed

opened 2026-08-15 00:13:01 +02:00 by ma3s7r0 · 1 comment

ma3s7r0 commented

2026-08-15 00:13:01 +02:00

Owner

Firmware builds fine, then the job is failed deliberately by upstream's guard rail:

::error file=build/zephyr/.config,title=Missing ZMK Compat::The selected board is not set up for
ZMK and there is a ZMK variant available.
See https://zmk.dev/blog/2025/12/09/zephyr-4-1#zmk-board-variant

The build itself succeeds — same log, before the check:

Memory region         Used Size  Region Size  %age Used
Wrote 510976 bytes to zmk.uf2

So this is purely a migration prompt, not a broken build. Upstream's
build-user-config.yml runs Check if building a board without explicit ZMK compat with
if: always() and exits 1 when the board lacks CONFIG_ZMK_BOARD_COMPAT=y while a ZMK variant of
that board exists.

Cause

build.yaml selects the plain board:

include:
  - board: xiao_ble
    shield: totem_left
    cmake-args: -DCONFIG_ZMK_STUDIO=y
  ...

and config/west.yml rides upstream unpinned:

- name: zmk
  remote: zmkfirmware
  revision: main

so ZMK's Zephyr 4.1 board-variant change arrived automatically. Under hardware model v2 the board
needs its ZMK variant qualifier rather than the bare xiao_ble.

Options

Migrate build.yaml to the ZMK variant of xiao_ble for all four entries
(totem_left, totem_right, totem_dongle, settings_reset). Correct fix, keeps us on main.
Exact qualifier per the blog post above.
Pin ZMK — set revision: to a release predating the change; see
pinning your ZMK version.

ma3s7r0/zmk-sofle#1 is the same root cause — riding ZMK main — with a different symptom: that
repo defines its own eyelash_sofle_* boards, which current Zephyr no longer resolves at all, so it
fails earlier, at Kconfig generation. Worth deciding pin-vs-migrate once for both repos.

Unrelated to the Forgejo migration (ma3s7r0/nix-config#78): CI on git.cl12.de is working — this
run scheduled on the errata runner, started the zmkfirmware/zmk-build-arm:stable toolchain
container, ran west and cmake, and linked working firmware.

Firmware builds fine, then the job is failed deliberately by upstream's guard rail: ``` ::error file=build/zephyr/.config,title=Missing ZMK Compat::The selected board is not set up for ZMK and there is a ZMK variant available. See https://zmk.dev/blog/2025/12/09/zephyr-4-1#zmk-board-variant ``` The build itself succeeds — same log, before the check: ``` Memory region Used Size Region Size %age Used Wrote 510976 bytes to zmk.uf2 ``` So this is purely a migration prompt, not a broken build. Upstream's `build-user-config.yml` runs `Check if building a board without explicit ZMK compat` with `if: always()` and exits 1 when the board lacks `CONFIG_ZMK_BOARD_COMPAT=y` while a ZMK variant of that board exists. ## Cause `build.yaml` selects the plain board: ```yaml include: - board: xiao_ble shield: totem_left cmake-args: -DCONFIG_ZMK_STUDIO=y ... ``` and `config/west.yml` rides upstream unpinned: ```yaml - name: zmk remote: zmkfirmware revision: main ``` so ZMK's Zephyr 4.1 board-variant change arrived automatically. Under hardware model v2 the board needs its ZMK variant qualifier rather than the bare `xiao_ble`. ## Options 1. **Migrate `build.yaml`** to the ZMK variant of `xiao_ble` for all four entries (`totem_left`, `totem_right`, `totem_dongle`, `settings_reset`). Correct fix, keeps us on `main`. Exact qualifier per the blog post above. 2. **Pin ZMK** — set `revision:` to a release predating the change; see [pinning your ZMK version](https://zmk.dev/blog/2025/06/20/pinned-zmk). ## Related `ma3s7r0/zmk-sofle#1` is the same root cause — riding ZMK `main` — with a different symptom: that repo defines its own `eyelash_sofle_*` boards, which current Zephyr no longer resolves at all, so it fails earlier, at Kconfig generation. Worth deciding pin-vs-migrate once for both repos. Unrelated to the Forgejo migration (`ma3s7r0/nix-config#78`): CI on git.cl12.de is working — this run scheduled on the errata runner, started the `zmkfirmware/zmk-build-arm:stable` toolchain container, ran west and cmake, and linked working firmware.

ma3s7r0 referenced this issue from a commit

2026-08-15 00:18:26 +02:00

build: select the zmk variant of xiao_ble

ma3s7r0 closed this issue

2026-08-15 00:18:26 +02:00

ma3s7r0 commented

2026-08-15 02:16:14 +02:00

Author

Owner

Fixed by selecting the ZMK variant of the board in build.yaml:

- board: xiao_ble//zmk

app/boards/seeed/xiao_ble/board.yml in zmk extends the stock Zephyr board with a variant named
zmk, qualified on nrf52840 — so the target is xiao_ble/nrf52840/zmk, shortened to
xiao_ble//zmk since the board has only one SoC. Building the plain board got Zephyr's version
without ZMK's defaults, which is what the compat check was rejecting.

All four matrix entries now build green, and the run publishes a firmware artifact
(1,442,816 bytes). Unlike the sofle repos, this one stays on zmk main — it uses an in-tree board,
so there is no HWMv1 board definition holding it back.

Ref: zmk.dev/blog/2025/12/09/zephyr-4-1#zmk-board-variant

Fixed by selecting the ZMK variant of the board in `build.yaml`: ```yaml - board: xiao_ble//zmk ``` `app/boards/seeed/xiao_ble/board.yml` in zmk extends the stock Zephyr board with a variant named `zmk`, qualified on `nrf52840` — so the target is `xiao_ble/nrf52840/zmk`, shortened to `xiao_ble//zmk` since the board has only one SoC. Building the plain board got Zephyr's version without ZMK's defaults, which is what the compat check was rejecting. All four matrix entries now build green, and the run publishes a `firmware` artifact (1,442,816 bytes). Unlike the sofle repos, this one stays on zmk `main` — it uses an in-tree board, so there is no HWMv1 board definition holding it back. Ref: [zmk.dev/blog/2025/12/09/zephyr-4-1#zmk-board-variant](https://zmk.dev/blog/2025/12/09/zephyr-4-1#zmk-board-variant)

ma3s7r0 referenced this issue

2026-08-27 14:16:15 +02:00

Explore: dongle display (Prospector/OLED), Zephyr 4 line, DE/EN/programming keymap, training plan #2

ma3s7r0 referenced this issue

2026-08-27 15:31:55 +02:00

Explore: dongle display (Prospector/OLED), Zephyr 4 line, DE/EN/programming keymap, training plan #2

ma3s7r0 referenced this issue

2026-08-27 20:29:00 +02:00

Explore: dongle display (Prospector/OLED), Zephyr 4 line, DE/EN/programming keymap, training plan #2

ma3s7r0 referenced this issue

2026-08-27 21:11:40 +02:00

Explore: dongle display (Prospector/OLED), Zephyr 4 line, DE/EN/programming keymap, training plan #2