Upgrade ZMK to v0.4 / Zephyr 4.1

[rdlu]

Warning

AI-generated research — verify before acting.
This issue was initially researched with Claude Sonnet 4.6 and then reviewed with Claude Opus 4.6 (Anthropic) in April 2026 as a planning aid. The author has no prior ZMK experience (familiar with Arduino/nice!nano hardware, but not the ZMK/Zephyr build system). The migration steps have not been tested — they were derived by inspecting the adv360pro board on ZMK main and the ZMK blog. Do not apply them blindly — cross-check against the official ZMK migration docs and real examples before touching your board definition or firmware config. Incorrect changes could result in firmware that fails to build or boots into a broken state.

Background

ZMK announced Zephyr 4.1 support in a December 2025 blog post. This is a significant upgrade from the current v0.3.0 (Zephyr 3.5.0+zmk-fixes). As of April 2026, no new tagged release exists — HWMv2 changes are only on ZMK main. This issue tracks the migration work needed once a stable release is tagged.

Current state

Item	Current
ZMK revision	v0.3.0
Zephyr (via ZMK fork)	v3.5.0+zmk-fixes
Zephyr SDK	0.17.0
GitHub Actions workflow	zmkfirmware/zmk/.github/workflows/build-user-config.yml@v0.3.0

What's changing with Zephyr 4.1 / HWMv2

The Zephyr 4.1 upgrade introduces Hardware Model v2 (HWMv2), which changes how boards and shields are identified. Key changes:

• Board identifiers now use a // variant separator (e.g. eyelash_sofle_left → eyelash_sofle_left//zmk)
• boards/arm/<board>/ directory structure → boards/<vendor>/<board>/
• New board.yml replaces <board>.yaml
• Kconfig changes: depends on SOC_* → select SOC_*, one file per board variant, plus additional select/imply lines
• CONFIG_NFCT_PINS_AS_GPIOS=y removed from .conf (moved to DTS by ZMK core)

Board migration plan

This repo (rdlu/zmk-sofle) is already a fork of a741725193/zmk-sofle, so the board HWMv2 migration can be done directly here — no separate fork needed.

File operations in eyelash_sofle/boards/

MOVE   boards/arm/eyelash_sofle/  →  boards/<vendor>/eyelash_sofle/

DELETE eyelash_sofle.yaml
ADD    board.yml  (new format, declares vendor + socs + zmk variant)

RENAME Kconfig.board
    → Kconfig.eyelash_sofle_left
    → Kconfig.eyelash_sofle_right

RENAME eyelash_sofle_left.dts              → eyelash_sofle_left_nrf52840_zmk.dts
RENAME eyelash_sofle_right.dts             → eyelash_sofle_right_nrf52840_zmk.dts
RENAME eyelash_sofle_left_defconfig        → eyelash_sofle_left_nrf52840_zmk_defconfig
RENAME eyelash_sofle_right_defconfig       → eyelash_sofle_right_nrf52840_zmk_defconfig

KEEP   eyelash_sofle.dtsi
KEEP   eyelash_sofle-layouts.dtsi
KEEP   board.cmake
KEEP   Kconfig.defconfig

Content changes

New board.yml (replaces eyelash_sofle.yaml):

boards:
  - name: eyelash_sofle_left
    vendor: <vendor-slug>
    socs:
      - name: nrf52840
        variants:
          - name: zmk
  - name: eyelash_sofle_right
    vendor: <vendor-slug>
    socs:
      - name: nrf52840
        variants:
          - name: zmk

Kconfig.eyelash_sofle_left (and equivalent for _right):

config BOARD_EYELASH_SOFLE_LEFT
    select SOC_NRF52840_QIAA
    select ZMK_BOARD_COMPAT
    imply RETAINED_MEM
    imply RETENTION
    imply RETENTION_BOOT_MODE

Based on the adv360pro reference. The ZMK_BOARD_COMPAT, RETAINED_MEM, RETENTION, and RETENTION_BOOT_MODE lines may be needed for settings reset and bootloader features.

*_defconfig files — remove 3 lines now handled by Kconfig:

-CONFIG_SOC_SERIES_NRF52X=y
-CONFIG_SOC_NRF52840_QIAA=y
-CONFIG_BOARD_EYELASH_SOFLE_LEFT=y

eyelash_sofle.zmk.yml — update siblings:

-  - eyelash_sofle_left
-  - eyelash_sofle_right
+  - eyelash_sofle_left//zmk
+  - eyelash_sofle_right//zmk

build.yaml changes

# before → after
eyelash_sofle_left   → eyelash_sofle_left//zmk
eyelash_sofle_right  → eyelash_sofle_right//zmk

Note on nice_nano / settings_reset: The nice_nano in ZMK main uses revision overlays (nice_nano_nrf52840_zmk_2_0_0.overlay). The correct board identifier for the v2 hardware may be nice_nano@2.0.0//zmk rather than nice_nano//zmk. Verify against ZMK docs at migration time.

config/west.yml changes

Bump ZMK revision to the next tagged release. For the eyelash_sofle module, the cleanest approach is to make it a local module (removing the remote URL entirely) since this repo IS the fork:

projects:
  - name: eyelash_sofle
    path: eyelash_sofle    # local path, no remote fetch
  - name: zmk
    remote: zmkfirmware
    revision: <next-tagged-release>
    import: app/west.yml

The previous suggestion to point the URL at rdlu/zmk-sofle with a branch revision would work but creates a circular reference (the repo pulling itself as a west module). A local module path is simpler.

Other files

• .github/workflows/build.yml: update workflow ref to @<next-tagged-release>
• eyelash_sofle.conf: check for CONFIG_NFCT_PINS_AS_GPIOS=y and remove if present
• mise.toml build tasks: update -b board name flags

Reference implementation

Follow app/boards/kinesis/adv360pro/ in ZMK main — it is a two-half nRF52840 split board with the same HWMv2 structure needed here. Verified April 2026.

Checklist

• Wait for a tagged ZMK release with HWMv2 support (as of April 2026, only on main)
• Perform the board HWMv2 migration in this repo (file renames + content changes above)
• Convert eyelash_sofle to a local west module (or update URL to point at this fork)
• Update config/west.yml ZMK revision to the new tag
• Update build.yaml board identifiers (including verifying nice_nano naming)
• Update .github/workflows/build.yml workflow ref
• Check eyelash_sofle.conf for CONFIG_NFCT_PINS_AS_GPIOS=y
• Confirm Zephyr SDK 0.17.0 is still compatible (or upgrade)
• Test a full build for both halves + settings_reset

References

• ZMK blog: Zephyr 4.1
• ZMK releases
• Upstream vendor board module
• Reference HWMv2 board: adv360pro

[rdlu]

Correction to migration plan: rdlu/zmk-sofle is already a fork of a741725193/zmk-sofle, so no separate fork is needed. The board HWMv2 migration can be done directly in this repo.

The config/west.yml currently points the eyelash_sofle module at the upstream:

- name: eyelash_sofle
  url: https://github.com/a741725193/zmk-sofle
  revision: main

When doing the migration, change this to point at the fork:

- name: eyelash_sofle
  url: https://github.com/rdlu/zmk-sofle
  revision: feat/hwmv2  # or whichever branch the migration lands on

Everything else in the migration plan above stands unchanged.

[rdlu]

What CONFIG_BOARD_EYELASH_SOFLE_LEFT=y is for

This symbol identifies which half is being built. It acts as a condition gate in Kconfig.defconfig:

• BOARD_EYELASH_SOFLE_LEFT alone → sets ZMK_SPLIT_ROLE_CENTRAL=y (left is the central/USB half) and ZMK_KEYBOARD_NAME
• BOARD_EYELASH_SOFLE_LEFT || BOARD_EYELASH_SOFLE_RIGHT → sets shared defaults: ZMK_SPLIT=y, DCDC converters, USB driver, display config

The symbol name (BOARD_EYELASH_SOFLE_LEFT) does not change in HWMv2. What changes is how it gets set: in HWMv1 it is declared explicitly in the defconfig file; in HWMv2 it is selected automatically by Kconfig based on the board being built. So the three lines removed from the defconfig are not lost — they are just handled differently by the build system:

-CONFIG_SOC_SERIES_NRF52X=y       # now inferred from SOC_NRF52840_QIAA
-CONFIG_SOC_NRF52840_QIAA=y       # now set via 'select' in Kconfig.eyelash_sofle_left
-CONFIG_BOARD_EYELASH_SOFLE_LEFT=y # now set automatically when building this board variant

All the logic in Kconfig.defconfig that depends on these symbols continues to work unchanged.

[rdlu]

Opus 4.6 review of Sonnet 4.6 research (April 2026)

Independent verification of the 8 major technical claims against actual files on ZMK main branch (using adv360pro and nice_nano as references):

#	Claim	Verdict	Evidence
1	boards/<vendor>/<board>/ replaces boards/arm/<board>/	Correct	boards/arm/ returns 404 on main; boards are under boards/kinesis/, boards/nicekeyboards/, etc.
2	board.yml replaces <board>.yaml	Correct	adv360pro/board.yml exists on main; no .yaml present
3	DTS files renamed to *_nrf52840_zmk.dts	Correct	adv360pro_left_nrf52840_zmk.dts, nice_nano_nrf52840_zmk.dts confirmed
4	defconfig renamed to *_nrf52840_zmk_defconfig	Correct	adv360pro_left_nrf52840_zmk_defconfig confirmed
5	Kconfig splits into per-variant files with select	Correct	Kconfig.adv360pro_left and Kconfig.adv360pro_right exist; both use select SOC_NRF52840_QIAA
6	defconfig drops CONFIG_SOC_* and CONFIG_BOARD_* lines	Correct	nice_nano v0.3.0 defconfig had all 3 lines; main defconfig has none
7	//zmk suffix in siblings and board identifiers	Correct	adv360pro.zmk.yml siblings: adv360pro_left//zmk, adv360pro_right//zmk
8	ZMK v0.4.0 tag exists	Incorrect	Only tags are v0.3.0, v0.3, v0.2.1, v0.2.0, v0.1.0

Corrections applied to the issue body

1. v0.4.0 references removed — replaced with "next tagged release" throughout, since this version doesn't exist and the version number is unknown
2. Kconfig examples were incomplete — Sonnet only showed select SOC_NRF52840_QIAA; the real adv360pro also has select ZMK_BOARD_COMPAT, imply RETAINED_MEM, imply RETENTION, imply RETENTION_BOOT_MODE
3. board.yml was missing vendor field — the real adv360pro includes vendor: kinesis
4. West module self-reference was circular — pointing eyelash_sofle URL at rdlu/zmk-sofle means the repo pulls itself as a module; changed to local module path instead
5. nice_nano_v2 → nice_nano//zmk was oversimplified — nice_nano on main uses revision overlays (nice_nano_nrf52840_zmk_2_0_0.overlay); the correct build.yaml identifier for v2 hardware may be nice_nano@2.0.0//zmk, flagged as "verify at migration time"

[rdlu]

Testing with ZMK main using a spare nice_nano as canary

The blog discourages using main for daily use:

"For all users, except those willing to accept periodic breaks they need to track down, we highly recommend pinning your ZMK version."

But it's feasible as an experiment on a branch to validate the toolchain before committing to the full board migration. Since there's a spare nice_nano v2 (no keys attached), it can serve as a canary — the nice_nano is already HWMv2-migrated in ZMK main, so no custom board migration is needed for this test.

What the canary test proves

• ZMK main + Zephyr 4.1 builds successfully with the local toolchain (Zephyr SDK 0.17.0)
• The new board naming (nice_nano//zmk or nice_nano@2.0.0//zmk) works
• The GitHub Actions reusable workflow on @main is functional
• Firmware boots on real hardware (USB enumeration, BLE advertising)

What it does NOT prove

• Whether the eyelash_sofle HWMv2 board migration is correct (that requires the actual board migration)
• Whether keymap features work (no keys to test)
• Long-term stability of main

Steps

1. Create a feat/hwmv2-canary branch
2. In config/west.yml, change ZMK to revision: main
3. In build.yaml, add a canary entry:

   - board: nice_nano//zmk          # try this first
     shield: settings_reset
   # if the above fails, try:
   # - board: nice_nano@2.0.0//zmk
   #   shield: settings_reset

4. In .github/workflows/build.yml, change workflow ref to @main
5. Push and check if GitHub Actions builds successfully
6. If it builds: download the .uf2, flash to the spare nice_nano (double-tap reset), verify it enumerates over USB
7. If USB works: the toolchain and Zephyr 4.1 are confirmed working — proceed with the full eyelash_sofle board migration on a separate branch

If the canary fails

• Check if Zephyr SDK 0.17.0 is still compatible with Zephyr 4.1 (may need 0.17.x+)
• Check if the reusable workflow on @main has different input requirements
• Check ZMK Discord / GitHub issues for known main breakage

[rdlu]

How many nice_nanos for the canary?

One is enough. The canary only needs to validate:

• ZMK main + Zephyr 4.1 builds with the current toolchain
• New board naming works
• Firmware boots on real hardware (USB enumeration)

Two nice_nanos would only matter for testing split BLE communication, but that requires a full keyboard definition (central + peripheral halves). A bare nice_nano running settings_reset is just a utility firmware — it doesn't do split.

The split BLE stack is the same Zephyr BLE regardless of board. If it works on the eyelash_sofle today on v0.3.0, it should work on Zephyr 4.1 once the board migration is done. Test split on the actual keyboard after the full migration.

Plan: one nice_nano → settings_reset shield → confirm build + boot → proceed to eyelash_sofle migration.

[rdlu]

Zephyr SDK 1.0.x investigation

TL;DR: SDK 1.0.x cannot be used — stick with 0.17.0

Findings

SDK Version	Requires Zephyr	Works with ZMK v0.3.0 (Zephyr 3.5)	Works with ZMK main (Zephyr 4.1)
0.17.0 (current)	3.5+	✅ Yes	✅ Yes (confirmed by canary build)
1.0.0 (AUR current)	4.2.0+	❌ No	❌ No

What changed in SDK 1.0.0

From the SDK 1.0.0 release notes:

"This requires Zephyr 4.2.0 or above (or the latest collab-sdk-dev)."

Breaking changes:

• CMake restructuring for GNU + LLVM toolchain support — this is the breaking change requiring Zephyr 4.2+
• Picolibc is now the only C library (newlib and newlib-nano removed)
• GCC upgraded from 12.x to 14.3
• LLVM/Clang 19.1.7 toolchain added

AUR status (verified locally April 2026)

Both AUR packages are at 1.0.0-1:

• zephyr-sdk (builds from source) — 1.0.0
• zephyr-sdk-bin (binary) — 1.0.0

There is no AUR package providing SDK 0.17.x anymore. The local install at tools/zephyr-sdk-0.17.0 remains the correct approach.

When can we upgrade to SDK 1.0.x?

Only when ZMK moves to Zephyr 4.2+. The timeline would be:

1. ZMK is currently on Zephyr 4.1 (main)
2. Zephyr 4.2 must be released first
3. ZMK must adopt it
4. Only then is SDK 1.0.x usable

Impact on this migration

The Zephyr 4.1 / HWMv2 migration (#2) can proceed with SDK 0.17.0 — the canary build in #3 already confirmed this works. SDK 1.0.x is a separate, future upgrade.

[rdlu]

SDK version deep-dive: what's the newest usable version?

Compatibility matrix (from Zephyr SDK releases)

SDK	Zephyr 3.5 (ZMK v0.3.0)	Zephyr 4.1 (ZMK main)	Zephyr 4.2+
0.17.0 (installed)	✅ Full	✅ Full	⚠️ Partial
0.17.1	✅	⚠️ Partial	✅ Full
0.17.2	✅	⚠️ Partial	✅ Full
0.17.3	✅	⚠️ Partial	✅ Full
0.17.4	✅	⚠️ Partial	✅ Full
1.0.0–1.0.1	❌	❌	❌ (needs 4.4+)

SDK 0.17.0 is the officially recommended version for Zephyr 4.1 — it's the only 0.17.x with full "Y" compatibility. The 0.17.1–0.17.4 releases were tuned for Zephyr 4.2/4.3.

What 0.17.1–0.17.4 changed (none relevant to nRF52840)

• QEMU updates (9.2.3 → 10.0.2)
• Picolibc fixes (crt0, module linking)
• New architecture toolchains (Renesas RX, MediaTek Xtensa)
• OpenOCD updated to 0.12.0
• Host tools rebased on Poky 5.0.7

None of these affect ARM/nRF52840 firmware builds. The "partial" compatibility for Zephyr 4.1 likely means minor QEMU/host-tool divergence, not build failures for real hardware.

Conclusion

No SDK upgrade needed. 0.17.0 is the best match for both ZMK v0.3.0 and ZMK main (Zephyr 4.1). The canary build already confirmed this. Upgrade to 0.17.4 only if you hit a specific bug; upgrade to 1.0.x only after ZMK moves to Zephyr 4.2+.

[rdlu]

What does upgrading Zephyr 3.5 → 4.1 actually buy us?

For an nRF52840 split keyboard with SSD1306 OLED, EC11 encoder, BLE HID, and NVS bond storage, here's what's relevant across the four Zephyr releases between ZMK v0.3.0 (Zephyr 3.5) and ZMK main (Zephyr 4.1).

Real wins (concrete improvements)

BLE stability & security

• 4.0: Host now disconnects peer on ATT timeout (fixes half-dead links on flaky HID-over-GATT sessions)
• 4.0: L2CAP LTK derive bug fixed — affects bond persistence across resets
• 4.0: SMP CT2 flag support + remote CID 0x0007 check — better interop with modern hosts
• 4.0: New CONFIG_BT_CONN_TX_NOTIFY_WQ — moves BLE TX completion off the system workqueue
• 4.1: Three BLE CVEs fixed (CVE-2025-1673/1674/1675)

BLE internals (biggest behavioral change)

• 3.7: Transmission path redesigned — dedicated "BT TX" thread removed, all controller comms now run on the system workqueue. Less context switching, less RAM, but biggest validation risk.
• 3.7: HCI driver interface fully redesigned (legacy API removed in 4.1)

Power management (relevant to soft-off / sleep)

• 3.7: Device PM decoupled from system PM (PM_DEVICE_SYSTEM_MANAGED)
• 3.7: PM_POLICY_DEVICE_CONSTRAINTS — devices declare which system states cause power loss
• 3.7: zephyr,pm-device-disabled DT property for per-power-state device suspend
• 4.0: Power management added to all keyboard matrix drivers
• 4.0: no-disconnect property on gpio-keys for PM on GPIO drivers that can't disconnect pins

Display / LVGL (SSD1306)

• 3.7: LVGL 8.4.0 — encoder button now correctly emits LV_KEY_ENTER
• 3.7: LVGL fixes for invert-x/y and swap-xy
• 3.7: SSD1306 supports display_set_pixel_format() (runtime color invert)
• 4.1: New SSD1309 driver (sibling of SSD1306) — option for future display upgrades

NVS / settings reliability (bond storage)

• 3.7: CONFIG_NVS_DATA_CRC — CRC protection for stored data (opt-in, breaks forward compat)
• 3.7: nvs_calc_free_space() bug fixed (was reporting too-large values)
• 4.0: LittleFS bug fixes (block-cycles ignored, lookahead buffer mismatch)

Encoder (EC11)

• 3.6: Power management added to gpio-qdec; optical encoder support
• 4.0: New zephyr,input-double-tap feature

Required migration work

These break on the 4.1 jump and must be addressed:

• 4.1: HWMv1 board aliases removed (the HWMv2 migration covered above)
• 4.1: Legacy HCI driver API removed (deprecated in 3.7)
• 4.1: bt_le_set_auto_conn() deprecated — apps must reconnect in disconnected callback
• 4.1: CONFIG_BT_BUF_ACL_RX_COUNT → _EXTRA
• 4.1: CONFIG_PM_DEVICE_RUNTIME_EXCLUSIVE removed (use PM_DEVICE_SYSTEM_MANAGED)
• 4.1: stream_flash_erase_page() deprecated → flash_area_erase()/flash_erase()
• 4.1: TinyCrypt fully deprecated → PSA Crypto / Mbed TLS
• 3.7: LVGL kscan-to-input wrapper removed (only if ZMK touched it)

Most of these are handled inside ZMK itself — the keymap config in this repo doesn't directly use any of the deprecated APIs. The HWMv2 board changes are the only user-config-visible work.

Not relevant to this project

WiFi, CAN, Thread/Matter, LoRa, LE Audio/BAP/CAP, video, networking stack, POSIX, new SoC families (nRF54, STM32N6/H7RS/WB0, RP2350, SiWx917, RA8, MAX32, ESP32-C6).

Verdict

The upgrade is worth doing primarily for the BLE stability fixes (4.0 ATT timeout, L2CAP LTK), power management improvements, and three BLE CVE fixes (4.1). The biggest validation risk is the 3.7 BT TX path consolidation onto the system workqueue — soak-test BLE under typing load after the migration.

---

Sources

Zephyr release notes

• Zephyr 3.6.0
• Zephyr 3.7.0
• Zephyr 4.0.0
• Zephyr 4.1.0 (note: some per-subsystem "Changes" sections are missing on this page)

Zephyr SDK

• Zephyr SDK releases
• SDK 1.0.0 release notes
• Zephyr 4.1 SDK installation docs
• SDK compatibility issue #1040

ZMK

• ZMK Zephyr 4.1 blog post (Dec 2025)
• ZMK pinned version blog post (Jun 2025)
• ZMK releases
• ZMK native setup docs
• Reference HWMv2 board: adv360pro
• nice_nano in ZMK main

Vendor / upstream

• Upstream eyelash_sofle board module
• AUR zephyr-sdk
• AUR zephyr-sdk-bin

[rdlu]

What about Zephyr 4.2?

Status

• Zephyr 4.2.0 was released 2025-07-19 (already a full release behind tip — Zephyr 4.4.0-rc3 is current as of April 2026)
• Zephyr 4.3 is also out
• LTS remains 3.7.x (not 4.x)
• ZMK has not announced any plan to adopt Zephyr 4.2. Last ZMK Zephyr blog post is "Zephyr 4.1 Update" (2025-12-09). ZMK historically lags Zephyr by multiple releases (~1.5–2 years per bump).

SDK requirement

• Zephyr 4.2 docs reference SDK 0.17.2 as the recommended version
• SDK 0.17.0 (current install) still works — SDK 1.0.x is only forward-required, not mandatory for 4.2 itself
• Both AUR zephyr-sdk 1.0.0 packages would work with Zephyr 4.2, unlike with 4.1

What 4.2 brings on top of 4.1 (relevant subset)

Bluetooth Host — breaking API changes (handled inside ZMK, not user config)

• HCI buffer type indicator moved to H:4 prefix byte; bt_buf_set_type() / bt_buf_get_type() deprecated
• bt_hci_cmd_create() deprecated → bt_hci_cmd_alloc()
• GATT CCC rename: struct _bt_gatt_ccc → struct bt_gatt_ccc_managed_user_data, BT_GATT_CCC_INITIALIZER → BT_GATT_CCC_MANAGED_USER_DATA_INIT (affects ZMK's split transport / HID service code)

Nordic / nRF52840

• Boards default to nrfutil instead of nrfjprog for west flash (irrelevant — UF2 mass-storage flashing here)
• New HFXO clock-control bindings for nRF51/nRF52 (existing bindings still work)
• No breaking changes to nRF52 flash, I2C, SPI, or PM drivers

LVGL / SSD1306

• LVGL now supports multiple simultaneous displays with proper input-device-to-display binding (additive, not breaking)
• SSD1306 driver: no breaking changes
• New SSD1320, SSD1331, ST7701 drivers (not relevant)

USB / HID

• No breaking changes to USB HID or device stack
• New UVC (webcam) class — irrelevant

NVS / settings

• No breaking changes — existing bonds will survive a 4.1 → 4.2 bump
• New flash_area_copy() API (optional)

Build system

• HWMv1 fully removed (deprecated 3.7, removed 4.1 — 4.2 is consistent here)
• Devicetree property naming: underscores → hyphens (custom bindings only; standard ZMK bindings already use hyphens)

Verdict for this project

Don't chase 4.2. Reasons:

1. ZMK upstream isn't there yet — and never will be on a user-config schedule. You can't run Zephyr 4.2 unless ZMK does.
2. No major BLE stability/security wins in 4.2 over 4.1 for HID-over-GATT use cases. The big BLE wins were in 3.7/4.0 (TX path consolidation, ATT timeout fix, L2CAP LTK fix) and 4.1 (3 BLE CVEs).
3. The 4.2 changes are mostly developer-facing API refactors — internal ZMK work, not user config.
4. Current SDK 0.17.0 works for 4.2 if/when ZMK ever bumps.

The Zephyr 4.1 / HWMv2 migration tracked in this issue is the right target. Zephyr 4.2 is a future "free upgrade" once ZMK adopts it — no preparation needed in this repo.

Sources

• Zephyr 4.2.0 release tag (2025-07-19)
• Zephyr 4.2 migration guide
• Zephyr 4.2 release notes
• Zephyr 4.2 SDK installation docs