5 posts tagged with "core"

I'm happy to announce that we have completed the work to upgrade ZMK to Zephyr 3.5!

petejohanson did the upgrade work to adjust ZMK for the Zephyr changes:

• Add west flash support to all UF2 capable boards.
• Adjust for LVGL DTS/Kconfig changes
• Zephyr core API changes, including CONTAINER_OF work API changes, init priority/callback, and others

Getting The Changes​

Use the following steps to update to the latest tooling in order to properly use the new ZMK changes:

User Config Repositories Using GitHub Actions​

Existing user config repositories using Github Actions to build will pull down Zephyr 3.5 automatically, however if you created your user config a while ago, you may need to update it to reference our shared build configuration to leverage the correct Docker image.

1. Replace the contents of your .github/workflows/build.yml with:

   on: [push, pull_request, workflow_dispatch]
   
   jobs:
     build:
       uses: zmkfirmware/zmk/.github/workflows/build-user-config.yml@main
   

2. If it doesn't exist already, add a new file to your repository named build.yaml:

   # This file generates the GitHub Actions matrix
   # For simple board + shield combinations, add them
   # to the top level board and shield arrays, for more
   # control, add individual board + shield combinations to
   # the `include` property, e.g:
   #
   # board: [ "nice_nano_v2" ]
   # shield: [ "corne_left", "corne_right" ]
   # include:
   #   - board: bdn9_rev2
   #   - board: nice_nano_v2
   #     shield: reviung41
   #
   ---
   

and then update it as appropriate to build the right shields/boards for your configuration.

VS Code & Docker (Dev Container)​

If you build locally using VS Code & Docker then:

• Pull the latest ZMK main with git pull for your ZMK checkout
• Reload the project
• If you are prompted to rebuild the remote container, click Rebuild
• Otherwise, press F1 and run Remote Containers: Rebuild Container
• Once the container has rebuilt and reloaded, run west update to pull the updated Zephyr version and its dependencies.

Once the container has rebuilt, VS Code will be running the 3.5 Docker image.

Local Host Development​

The following steps will get you building ZMK locally against Zephyr 3.5:

• Run the updated toolchain installation steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
• Install the latest version of west by running pip3 install --user --update west.
• Pull the latest ZMK main with git pull for your ZMK checkout
• Run west update to pull the updated Zephyr version and its dependencies

From there, you should be ready to build as normal!

Board/Shield Changes​

The following changes have already been completed for all boards/shields in ZMK main branch. For existing or new PRs, or out of tree boards, the following changes are necessary to properly work with the latest changes.

West Flash Support​

If you have a custom board for a target that has a UF2 supporting bootloader, you can easily add support for flashing via west flash. Note that using west flash isn't mandatory, it is merely a convenient way to automate copying to the mass storage device, which you can continue to do manually. To add support, add a line to your board's board.cmake file like so:

include(${ZEPHYR_BASE}/boards/common/uf2.board.cmake)

LVGL DTS/Kconfig Changes​

Two items were changed for LVGL use for displays that may need adjusting for custom shields:

DPI Kconfig Rename​

The old LV_Z_DPI Kconfig symbol was promoted to a Kconfig in upstream LVGL, and is now named LV_DPI_DEF. You will need to replace this symbol in your board/shield's Kconfig.defconfig file.

SSD1306 OLED Inverse Refactor​

Inverting black/white pixels has moved out of the Kconfig system and into a new DTS property. If you have a custom shield that uses an SSD1306, you should:

• Remove any override for the SSD1306_REVERSE_MODE from your Kconfig files.
• Add the new inversion-on; boolean property to the SSD1306 node in your devicetree file.

Maxim max17048 Sensor Driver​

Upstream Zephyr has added a driver for the max17048 fuel gauge, but using the new fuel gauge API that ZMK does not yet consume. To avoid a conflict with the new upstream and keep our existing sensor driver, our driver has been renamed to be namespaced with a ZMK prefix. The following changes are needed for any boards using the driver:

• Change the compatible value for the node to be zmk,maxim-17048, e.g. compatible = "zmk,maxim-max17048";.
• If enabling the driver explicitly via Kconfig, rename MAX17048 to the new ZMK_MAX17048 in your Kconfig.defconfig or <board>_defconfig files.

Upcoming Changes​

Moving to Zephyr 3.5 will unblock several exciting efforts that were dependent on that Zephyr release.

BLE Stability Improvements​

Many users have reported various BLE issues with some hardware combinations, including challenges with updated Intel drivers, and macOS general stability problems. The Zephyr 3.5 release includes many fixes for the BT host and controller portions that, combined with some small upcoming ZMK changes, have been reported to completely resolve previous issues. Further focused testing will immediately commence to fully verify the ZMK changes before making them the default.

If you'd like to test those changes, enable CONFIG_ZMK_BLE_EXPERIMENTAL_CONN=y for your builds.

Pointer Integration​

The Zephyr 3.5 release includes a new input subsystem that we will be leveraging for our upcoming pointer support. The open PR for that work is now unblocked and further testing and code review will begin to work on getting that feature integrated into ZMK as well.

Power Domains​

Several power domain related changes are now available as well, which were a necessity for continued work on the improved peripheral power handling that's planned to supersede the existing "VCC cutoff" code that currently exists but causes problems for builds that include multiple powered peripherals like Displays + RGB.

Thanks!​

Thanks to all the testers who have helped verify ZMK functionality on the newer Zephyr version.

I'm happy to announce that we have completed the work to upgrade ZMK to Zephyr 3.2!

petejohanson did the upgrade work to adjust ZMK for the Zephyr changes, with help from Nicell on the LVGL pieces.

• Upgrade to LVGL 8.x API, and move to the new Kconfig settings.
• Tons of RP2040 work.
• Zephyr core API changes, including DTS label use changes.
• Move to pinctrl Zephyr subsystem.

Getting The Changes​

Use the following steps to update to the latest tooling in order to properly use the new ZMK changes:

User Config Repositories Using GitHub Actions​

Existing user config repositories using Github Actions to build will pull down Zephyr 3.2 automatically, however if you created your user config a while ago, you may need to update it to reference our shared build configuration to leverage the correct Docker image.

1. Replace the contents of your .github/workflows/build.yml with:

   on: [push, pull_request, workflow_dispatch]
   
   jobs:
     build:
       uses: zmkfirmware/zmk/.github/workflows/build-user-config.yml@main
   

2. If it doesn't exist already, add a new file to your repository named build.yaml:

   # This file generates the GitHub Actions matrix
   # For simple board + shield combinations, add them
   # to the top level board and shield arrays, for more
   # control, add individual board + shield combinations to
   # the `include` property, e.g:
   #
   # board: [ "nice_nano_v2" ]
   # shield: [ "corne_left", "corne_right" ]
   # include:
   #   - board: bdn9_rev2
   #   - board: nice_nano_v2
   #     shield: reviung41
   #
   ---
   

and then update it as appropriate to build the right shields/boards for your configuration.

Upgrade a manual script​

If you have a custom GitHub Actions workflow you need to maintain for some reason, you can update the workflow to to use the stable Docker image tag for the build:

• Open .github/workflows/build.yml in your editor/IDE

• Change zmkfirmware/zmk-build-arm:2.5 to zmkfirmware/zmk-build-arm:stable wherever it is found

• Locate and delete the lines for the DTS output step, which is no longer needed:

  - name: ${{ steps.variables.outputs.display-name }} DTS File
    if: ${{ always() }}
    run: |
      if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
      if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
  

VS Code & Docker (Dev Container)​

If you build locally using VS Code & Docker then:

• pull the latest ZMK main with git pull for your ZMK checkout
• reload the project
• if you are prompted to rebuild the remote container, click Rebuild
• otherwise, press F1 and run Remote Containers: Rebuild Container
• Once the container has rebuilt and reloaded, run west update to pull the updated Zephyr version and its dependencies.

Once the container has rebuilt, VS Code will be running the 3.2 Docker image.

Local Host Development​

The following steps will get you building ZMK locally against Zephyr 3.2:

• Run the updated toolchain installation steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
• Install the latest version of west by running pip3 install --user --update west.
• pull the latest ZMK main with git pull for your ZMK checkout
• run west update to pull the updated Zephyr version and its dependencies

From there, you should be ready to build as normal!

Known Issues​

A few testers have reported inconsistent issues with bluetooth connections on Windows after upgrading, which can be resolved by re-pairing your keyboard by:

1. Remove the device from Windows.
2. Clear the profile on your keyboard that is associated with the Windows device by triggering &bt BT_CLR on your keymap while that profile is active.
3. Restart Windows.
4. Re-connect Windows to your keyboard.

Windows Battery Reporting Fix​

Zephyr 3.2 introduced a new Kconfig setting that can be used to work around a bug in Windows related to battery reporting. Check out our bluetooth config for the full details. The key new configuration that can be set if using Windows is:

CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION=n

Keymap Changes​

Due to conflicts with new devicetree node labels added for Zephyr's reset system, the &reset behavior has been renamed to &sys_reset.

All of the in-tree keymaps have been fixed, but you may encounter build failures about duplicate names, requiring you rename the behavior reference in your keymap. Use the Keymap Upgrader and this will get fixed for you automatically.

Board/Shield Changes​

The following changes have already been completed for all boards/shields in ZMK main branch. For existing or new PRs, or out of tree boards, the following changes are necessary to properly work with the latest changes.

Move to pinctrl driver​

Before this change, setting up the details of pins to use them for peripherals like SPI, I2C, etc. was a mix of platform specific driver code. Zephyr has moved to the newer pinctrl system to unify the handling of pin configuration, with additional flexibility for things like low power modes for those pins, etc.

Board specific shield overlays​

The main area this affects existing shields is those with board specific overrides, e.g. <shield>/boards/seeeduino_xiao_ble.overlay, that sets up additional components on custom buses, e.g. addressable RGB LEDs leveraging the SPI MOSI pin.

nRF52 Pin Assignments​

Previously in ZMK, we relied on per-driver devicetree source properties to set the alternate pin functions for things like SPI or I2C. For example, here is the I2C bus setup as it was previously on the nice_nano board:

&i2c0 {
    compatible = "nordic,nrf-twi";
    sda-pin = <17>;
    scl-pin = <20>;
};

With the move to the pinctrl system, this setup now look like:

 &i2c0 {
    compatible = "nordic,nrf-twi";
    pinctrl-0 = <&i2c0_default>;
    pinctrl-1 = <&i2c0_sleep>;
    pinctrl-names = "default", "sleep";
 };

which references the pinctrl configuration:

&pinctrl {
       i2c0_default: i2c0_default {
               group1 {
                       psels = <NRF_PSEL(TWIM_SDA, 0, 17)>,
                               <NRF_PSEL(TWIM_SCL, 0, 20)>;
               };
       };

       i2c0_sleep: i2c0_sleep {
               group1 {
                       psels = <NRF_PSEL(TWIM_SDA, 0, 17)>,
                               <NRF_PSEL(TWIM_SCL, 0, 20)>;
                       low-power-enable;
               };
       };
};

Although slightly more verbose this allows pin configuration infrastructure to be re-used, specify other modes, like sleep, etc. in a standard way across architectures.

Out of Tree Boards/Shields​

All of the in-tree boards and shields have been upgraded, but if you maintain/use an out-of-tree board or shield that uses the converted boards and overrides pins for various buses, you may need to switch to pinctrl to match ZMK's new approach.

The approach is the following when updating a board:

1. Add an entry CONFIG_PINCTRL=y to the <board>_defconfig file in the board directory.

2. Add a new file with the naming convention <board>-pinctrl.dtsi to your board directory.

3. In the new file, add your pinctrl entries that set up different pin control configurations for whatever peripherals/buses are needed. Here's the nice!nano file as an example:

   /*
   * Copyright (c) 2022 The ZMK Contributors
   * SPDX-License-Identifier: MIT
   */
   
   &pinctrl {
           uart0_default: uart0_default {
                   group1 {
                           psels = <NRF_PSEL(UART_RX, 0, 8)>;
                           bias-pull-up;
                   };
                   group2 {
                           psels = <NRF_PSEL(UART_TX, 0, 6)>;
                   };
           };
   
           uart0_sleep: uart0_sleep {
                   group1 {
                           psels = <NRF_PSEL(UART_RX, 0, 8)>,
                                   <NRF_PSEL(UART_TX, 0, 6)>;
                           low-power-enable;
                   };
           };
   
           i2c0_default: i2c0_default {
                   group1 {
                           psels = <NRF_PSEL(TWIM_SDA, 0, 17)>,
                                   <NRF_PSEL(TWIM_SCL, 0, 20)>;
                   };
           };
   
           i2c0_sleep: i2c0_sleep {
                   group1 {
                           psels = <NRF_PSEL(TWIM_SDA, 0, 17)>,
                                   <NRF_PSEL(TWIM_SCL, 0, 20)>;
                           low-power-enable;
                   };
           };
   };
   

4. From the main <board>.dts file, add an #include "<board>-pinctrl.dtsi" to have the C-preprocessor combine the files.

5. Update the various peripheral nodes to use the new pinctrl configurations. For example, the following old configuration:

   &i2c0 {
       compatible = "nordic,nrf-twi";
       sda-pin = <15>;
       scl-pin = <17>;
   };
   

   would be changed to:

   &i2c0 {
       compatible = "nordic,nrf-twi";
       pinctrl-0 = <&i2c0_default>;
       pinctrl-1 = <&i2c0_sleep>;
       pinctrl-names = "default", "sleep";
   };
   

Because pinctrl configuration is very dependent on the specific target SoC, you will rarely need to consider it for a shield overlay that leverages a pro micro or XIAO abstraction. As noted, you're more likely to need to fix up pinctrl settings is using a board specific shield overlay, e.g. <shield>/boards/<board>.overlay to set things up.

LVGL Kconfig changes.​

With the update to LVGL 8.x, Zephyr now leverages an upstream Kconfig file for most LVGL settings. Due to this, the naming for many existing configs has been adjusted. For any configs moved upstream, the naming mostly involves a prefix change from LVGL_ to the shorter LV_. For any that are still Zephyr specific configs, they are now prefixed with LV_Z_ prefix.

If you maintain or use an out of tree board/shield with a display, the following will need to be changed in your Kconfig files:

• LVGL_VDB_SIZE -> LV_Z_VDB_SIZE
• LVGL_DPI -> LV_DPI_DEF
• LVGL_BITS_PER_PIXEL -> LV_Z_BITS_PER_PIXEL

Other than those specific examples, most other Kconfig values can simply change the LVGL_ prefix to LV_.

Raspberry Pi Pico/RP2040 Support​

This Zephyr update allows ZMK to support the new(-ish) RP2040 SoC found in the Raspberry Pi Pico.

Supported Controllers​

The following RP2040 powered controllers have board definitions for folks to test:

• Raspberry Pi Pico (rpi_pico)
• SparkFun Pro Micro RP2040 (sparkfun_pro_micro_rp2040)
• Adafruit Keyboar/KB2040 (adafruit_kb2040)
• Seeeduino XIAO RP2040 (seeeduino_xiao_rp2040)
• Adafruit Qt PY RP2040 (adafruit_qt_py_rp2040)
• BoardSource blok (boardsource_blok)
• Elite-Pi (compatible with the sparkfun_pro_micro_rp2040 board)

Upcoming Changes​

Display re-init​

Zephyr's improved power domain support is a foundation upon which we can provide a proper fix for the longstanding display re-init bug which has prevented ZMK from formally supporting our display code.

There is work still remaining to fully leverage the power domain system within ZMK to fix the bug, but upgrading Zephyr is the first necessary step.

Thanks!​

Thanks to all the testers who have helped verify ZMK functionality on the newer Zephyr version.

I'm happy to announce that we have completed the work to upgrade ZMK to Zephyr 3.0!

petejohanson did the upgrade work to adjust ZMK for the Zephyr changes.

• Moving to Zephyr's UF2 build integration that was submitted upstream by petejohanson
• Additional color-mapping property needed for ws2812 LED strep devicetree nodes
• Zephyr core API changes, including delayed work, USB/HID
• Adjust for pinctrl changes on stm32
• Fixes for power management and log formatter changes

Getting The Changes​

Use the following steps to update to the latest tooling in order to properly use the new ZMK changes:

User Config Repositories Using GitHub Actions​

Existing user config repositories using Github Actions to build will pull down Zephyr 3.0 automatically, however to build properly, the repository needs to be updated to use the stable Docker image tag for the build:

• Open .github/workflows/build.yml in your editor/IDE

• Change zmkfirmware/zmk-build-arm:2.5 to zmkfirmware/zmk-build-arm:stable wherever it is found

• Locate and delete the lines for the DTS output step, which is no longer needed:

  - name: ${{ steps.variables.outputs.display-name }} DTS File
    if: ${{ always() }}
    run: |
      if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
      if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
  

VS Code & Docker (Dev Container)​

If you build locally using VS Code & Docker then:

• pull the latest ZMK main with git pull for your ZMK checkout
• reload the project
• if you are prompted to rebuild the remote container, click Rebuild
• otherwise, press F1 and run Remote Containers: Rebuild Container
• Once the container has rebuilt and reloaded, run west update to pull the updated Zephyr version and its dependencies.

Once the container has rebuilt, VS Code will be running the 3.0 Docker image.

Local Host Development​

The following steps will get you building ZMK locally against Zephyr 3.0:

• Run the updated toolchain installation steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
• pull the latest ZMK main with git pull for your ZMK checkout
• run west update to pull the updated Zephyr version and its dependencies

From there, you should be ready to build as normal!

Board/Shield Changes​

The following changes have already been completed for all boards/shields in ZMK main branch. For existing or new PRs, or out of tree boards, the following changes are necessary to properly work with the latest changes.

RGB Underglow​

Zephyr's WS2812 led_strip driver added a new required property. When adding underglow to a board, you now must also add the additional include #include <dt-bindings/led/led.h> at the top of your devicetree file, and add a color-mapping property like:

led_strip: ws2812@0 {
  compatible = "worldsemi,ws2812-spi";

  /* SPI */
  reg = <0>; /* ignored, but necessary for SPI bindings */
  spi-max-frequency = <4000000>;

  /* WS2812 */
  chain-length = <10>; /* number of LEDs */
  spi-one-frame = <0x70>;
  spi-zero-frame = <0x40>;
  color-mapping = <LED_COLOR_ID_GREEN
                   LED_COLOR_ID_RED
                   LED_COLOR_ID_BLUE>;
};

Display Selection​

Zephyr moved to using a chosen node named zephyr,display to select the display device to be used with LVGL, the underlying display library we use.

For example, for a shield with:

&pro_micro_i2c {
  status = "okay";

  oled: ssd1306@3c {
    compatible = "solomon,ssd1306fb";
    reg = <0x3c>;
    width = <128>;
    height = <32>;
    segment-offset = <0>;
    page-offset = <0>;
    display-offset = <0>;
    multiplex-ratio = <31>;
    com-invdir;
    segment-remap;
    com-sequential;
    prechargep = <0x22>;
  };
};

You would add a chosen node like:

/ {
  chosen {
    zephyr,display = &oled;
  };
};

USB Logging​

Zephyr unified the way the console/logging device is selected, removing the hacks that special-cased the USB CDC ACM output. Now, the CDC ACM device is configured in the devicetree as well. To ensure that USB logging properly works with custom board definitions, two sections of the <board>.dts file need updating.

Underneath the USB device, add the CDC ACM node:

&usbd {
  status = "okay";
  cdc_acm_uart: cdc_acm_uart {
    compatible = "zephyr,cdc-acm-uart";
  };
};

Then, an additional chosen node (near the top of the file) will mark the CDC ACM device as the console:

/ {
  chosen {
    ...
    zephyr,console = &cdc_acm_uart;
  };
  ...
};

UF2 Builds​

Previously, to get ZMK to build a UF2 image to flash to a given board required adding a CMakeLists.txt file that added a custom post build command. Now, the only thing necessary to have Zephyr build a UF2 is to add the following to your <board>_defconfig file:

CONFIG_BUILD_OUTPUT_UF2=y

If updating an existing board, be sure to remove the previous CMakeLists.txt file to avoid generating the UF2 twice during a west build.

For more details on the implementation, see zephyr#31066.

STM32 Clock Configuration​

Clock configuration moved to devicetree as well, out of the Kconfig files. Here is a sample config for a board that uses the HSI for the PLL source:

&clk_hsi {
  status = "okay";
};

&pll {
  prediv = <1>;
  mul = <12>;
  clocks = <&clk_hsi>;
  status = "okay";
};

&rcc {
  clocks = <&pll>;
  clock-frequency = <DT_FREQ_M(72)>;
  ahb-prescaler = <1>;
  apb1-prescaler = <2>;
};

After adding the nodes, be sure to remove the clock/PLL related configuration from the <board>_defconfig file.

Seeeduino XIAO​

The Seeed(uino) XIAO has gained in popularity for use on smaller boards, and gained more traction with the release of the new XIAO BLE board, powered by the popular nRF52840 SoC. As part of the 3.0 update, we've also more fully integrated the XIAO and XIAO BLE to make it easier to build keyboard (shields) using either controller.

Future Hardware​

One of the exciting items that's one step closer as part of this work is support for Raspberry Pi Pico/RP2040. With Zephyr 3.0 merged, this start the process for getting those controllers/chips supported by ZMK. Follow the issue to keep track of progress. This will also enable us to support the XIAO compatible Adafruit Qt Py RP2040 and XIAO RP2040.

Thanks!​

Thanks to all the testers who have helped verify ZMK functionality on the newer Zephyr version.

Article Updates​

• 12/2023: Removed the deprecated label property from code snippets.

As preparation for completing the work to upgrade ZMK to Zephyr 3.0, users with user config repositories who wish to avoid future build failures with their GitHub Actions workflows can take steps to adjust their repositories now.

GitHub Actions needs to use our latest Docker image to ensure continued compatibility with the ZMK codebase on Zephyr 3.0 (and beyond). You should:

• Open .github/workflows/build.yml in your editor/IDE
• Change zmkfirmware/zmk-build-arm:2.5 to zmkfirmware/zmk-build-arm:stable wherever it is found

Once the changes are committed and pushed, the build will run as expected.

A future blog post will outline the complete Zephyr 3.0 changes once that work is finalized.

I'm happy to announce that we have completed the work to upgrade ZMK to Zephyr 2.5!

A big part of this work was some major refactors and improvements by innovaker to our zmk-docker Docker image and GH Actions automation.

• Faster build times with improved caching.
• Integration tests which automatically verify new images.
• PRs to the repo now build properly and run the tests as well.
• Build images for multiple target architectures, e.g. zmk-build-riscv64, all in parallel.
• Nightly builds to be sure we're pulling in the latest OS/package updates, to ensure we keep our images up to date, address any reported vulnerabilities, etc.
• Faster upgrade paths for future Zephyr SDK and Zephyr versions.

In addition, petejohanson did the upgrade work to adjust ZMK for the Zephyr changes.

• Updated to newer devicetree/driver Zephyr API
• Adjustment for Zephyr pinmux changes
• Fixes for power management, LVGL, and formatter changes

Getting The Changes​

Use the following steps to update to the latest tooling in order to properly use the new ZMK changes:

User Config Repositories Using GitHub Actions​

Existing user config repositories using Github Actions to build will pull down Zephyr 2.5 automatically, and should work, fine as is. However, to upgrade to the newer Docker image, you should:

• Open .github/workflows/build.yml in your editor/IDE
• Change zmkfirmware/zmk-build-arm:2.4 to zmkfirmware/zmk-build-arm:2.5 wherever it is found

VS Code & Docker (Dev Container)​

If you build locally using VS Code & Docker then:

• pull the latest ZMK main with git pull for your ZMK checkout
• reload the project
• if you are prompted to rebuild the remote container, click Rebuild
• otherwise, press F1 and run Remote Containers: Rebuild Container
• Once the container has rebuilt and reloaded, run west update to pull the updated Zephyr version and its dependencies.

Once the container has rebuilt, VS Code will be running the 2.5 Docker image.

Local Host Development​

The following steps will get you building ZMK locally against Zephyr 2.5:

• Run the updated toolchain installation steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
• pull the latest ZMK main with git pull for your ZMK checkout
• run west update to pull the updated Zephyr version and its dependencies

From there, you should be ready to build as normal!

Thanks!​

Thanks again to innovaker for all the hard work, and to all the testers who have helped verify ZMK functionality on the newer Zephyr version.