Home › SDK migration

SDK upgrade guide

Zephyr 4.0 to Zephyr 4.1: what needs attention

Migratorisk's knowledge base lists 28 documented changes between Zephyr 4.0 and Zephyr 4.1. 27 of them are rated likely to break code, configuration or builds that use them. Below is each change, what a scan also reviews on this path, and how to see which ones apply to your project.

28documented changes
27rated will or likely to break
11review checks on this path

Find which of these affect your firmware

Migratorisk scans your project on your own computer and reports only the changes your code, configuration and build actually touch. Your source code is not uploaded.

python -m pip install migratorisk
migratorisk scan --project ./your-firmware --from zephyr-4.0.0 --to zephyr-4.1.0 --out report.html

Requires Python 3.12 or newer. Results are free and complete without sign-up; sharing a report with us is optional.

Set up the local scanOr answer a few questions instead

Where the changes are

Hardware description · 17Build settings · 6Application code · 5

What changes between Zephyr 4.0 and Zephyr 4.1

Ordered by impact. Each item names the release that introduced it and links to the official source. A change only matters if your project uses what changed; the scan checks that.

Likely to break

Kconfig options CONFIG_DISABLE_SSBD and 1 more were removed

Build settings · Zephyr 4.1.0 · Source

Kconfigs CONFIG_DISABLE_SSBD and CONFIG_ENABLE_EXTENDED_IBRS have been deprecated since v3.7. These were removed. Use CONFIG_X86_DISABLE_SSBD and CONFIG_X86_ENABLE_EXTENDED_IBRS instead. Covers 2 names.

Likely to break

Kconfig options SB_CONFIG_MCUBOOT_MODE_SWAP_WITHOUT_SCRATCH and 1 more were replaced

Build settings · Zephyr 4.1.0 · Source

The Kconfig SB_CONFIG_MCUBOOT_MODE_SWAP_WITHOUT_SCRATCH has been deprecated and replaced with SB_CONFIG_MCUBOOT_MODE_SWAP_USING_MOVE, applications should be updated to select this new symbol if they were selecting the old symbol. Covers 2 names.

Likely to break

API MGMT_CB_ERROR_RET was removed

Application code · Zephyr 4.1.0 · Source

The deprecated macro MGMT_CB_ERROR_RET has been removed.

Likely to break

API stepper_enable_constant_velocity_mode was renamed

Application code · Zephyr 4.1.0 · Source

Renamed the stepper_enable_constant_velocity_mode function to stepper_run. The function does not take a velocity parameter anymore. Set the desired speed using the stepper_set_microstep_interval function beforehand.

Likely to break

API stepper_set_actual_position was renamed

Application code · Zephyr 4.1.0 · Source

Renamed the stepper_set_actual_position function to stepper_set_reference_position.

Likely to break

API stepper_set_max_velocity was renamed

Application code · Zephyr 4.1.0 · Source

Renamed the stepper_set_max_velocity function to stepper_set_microstep_interval. The function now takes the step interval in nanoseconds. This allows for a more precise control.

Likely to break

API stepper_set_target_position was renamed

Application code · Zephyr 4.1.0 · Source

Renamed the stepper_set_target_position function to stepper_move_to.

Likely to break

CONFIG_BT_CTLR deprecated in favour of HAS_BT_CTLR

Build settings · Zephyr 4.1.0 · Source

Zephyr 4.1 deprecates CONFIG_BT_CTLR; the link layer is now chosen by HCI driver options that select HAS_BT_CTLR. Setting CONFIG_BT_CTLR in prj.conf or a sysbuild image config fails on later releases.

Likely to break

Devicetree compatible nxp,imx-lpi2c was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,imx-lpi2c to nxp,lpi2c.

Likely to break

Devicetree compatible nxp,imx-lpspi was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,imx-lpspi to nxp,lpspi.

Likely to break

Devicetree compatible nxp,kinetis-adc12 was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-adc12 to nxp,adc12.

Likely to break

Devicetree compatible nxp,kinetis-dspi was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-dspi to nxp,dspi.

Likely to break

Devicetree compatible nxp,kinetis-ftm was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-ftm to nxp,ftm and relocate it under dts/bindings/timer.

Likely to break

Devicetree compatible nxp,kinetis-ftm-pwm was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-ftm-pwm to nxp,ftm-pwm.

Likely to break

Devicetree compatible nxp,kinetis-lpuart was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-lpuart to nxp,lpuart.

Likely to break

Devicetree compatible nxp,kinetis-mpu was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-mpu to nxp,sysmpu and added its corresponding binding.

Likely to break

Devicetree compatible nxp,kinetis-pinctrl was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-pinctrl to nxp,port-pinctrl.

Likely to break

Devicetree compatible nxp,kinetis-pinmux was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-pinmux to nxp,port-pinmux.

Likely to break

Devicetree compatible nxp,kinetis-rtc was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-rtc to nxp,rtc.

Likely to break

Devicetree compatible nxp,kinetis-wdog32 was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from nxp,kinetis-wdog32 to nxp,wdog32.

Likely to break

Devicetree compatible renesas,ra8-pwm was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from renesas,ra8-pwm to renesas,ra-pwm.

Likely to break

Devicetree compatible silabs,gecko-spi-eusart was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from silabs,gecko-spi-eusart to silabs,eusart-spi.

Likely to break

Devicetree compatible silabs,gecko-spi-usart was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from silabs,gecko-spi-usart to silabs,usart-spi.

Likely to break

Devicetree compatible ti,ads114s0x-gpio was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from ti,ads114s0x-gpio to ti,ads1x4s0x-gpio.

Likely to break

Devicetree compatible zephyr,gpio-steppers was renamed

Hardware description · Zephyr 4.1.0 · Source

Renamed the compatible from zephyr,gpio-steppers to zephyr,gpio-stepper.

Likely to break

Kconfig option CONFIG_MAX_FILES was renamed

Build settings · Zephyr 4.1.0 · Source

The EXT2 Kconfig symbol CONFIG_MAX_FILES has been renamed to CONFIG_EXT2_MAX_FILES.

Likely to break

Kconfig option CONFIG_SOC_SERIES_RP2XXX was renamed

Build settings · Zephyr 4.1.0 · Source

CONFIG_SOC_SERIES_RP2XXX is renamed to CONFIG_SOC_SERIES_RP2040.

Worth checking

Kconfig option CONFIG_NET_TC_SKIP_FOR_HIGH_PRIO is deprecated

Build settings · Zephyr 4.1.0 · Source

CONFIG_NET_TC_SKIP_FOR_HIGH_PRIO was deprecated in favour of CONFIG_NET_TC_TX_SKIP_FOR_HIGH_PRIO to avoid naming ambiguity.

What a scan of this path also reviews

Beyond the documented changes, Migratorisk reviews these upgrade risks for Zephyr projects on this path. Each one is reported only when the project shows the trigger.

Zephyr build logs need first-error triage after version changes

When it applies: Build logs often contain the highest-confidence migration breakage evidence.

Why it matters: First errors identify missing headers, renamed APIs, devicetree binding errors, and Kconfig failures.

What to do: Fix the first build error before chasing downstream compile or linker failures.

Zephyr devicetree and board files need target-version review

When it applies: Custom board and overlay files may depend on bindings or hardware model conventions from the source release.

Why it matters: Devicetree binding and board model changes commonly block Zephyr upgrades.

What to do: Validate custom board files, overlays, chosen nodes, and bindings against the target Zephyr release.

Zephyr Kconfig symbols need target-version review

When it applies: Project Kconfig files may contain symbols renamed, removed, or moved across Zephyr releases.

Why it matters: Zephyr version jumps often expose configuration drift before source changes compile.

What to do: Compare project Kconfig symbols against the target Zephyr release notes and build output.

Devicetree binding error in build log

When it applies: The build log reports a devicetree binding error.

Why it matters: Compatibles and bindings are renamed or split between releases; overlay and board errors must be fixed before source errors are meaningful.

What to do: Update overlays and board files to the target release bindings before addressing source errors.

Undefined Kconfig symbol in build log

When it applies: The build log reports an assignment to an undefined Kconfig symbol.

Why it matters: Zephyr renames and removes Kconfig options between releases, and Kconfig warnings abort the build before later errors appear.

What to do: Look up each undefined symbol in the migration guide of every release on the path and replace or remove it.

Zephyr source APIs need migration review

When it applies: Application source may use APIs whose signatures or headers changed between Zephyr releases.

Why it matters: Source API drift is common across major and multi-minor jumps.

What to do: Review source includes, driver APIs, Bluetooth APIs, kernel APIs, and subsystem-specific migration notes.

Zephyr west manifest revisions need target-version review

When it applies: Project manifests may pin modules that are incompatible with the target Zephyr release.

Why it matters: Module revisions, imports, and remotes can silently keep old APIs in the workspace.

What to do: Align manifest remotes, imports, and module revisions to the target Zephyr baseline.

Custom board needs the target Zephyr release devicetree and Kconfig review

When it applies: The project contains a custom board definition.

Why it matters: Board files track SoC devicetree, pinctrl, Kconfig and hardware model changes between releases.

What to do: Compare the custom board with a similar in-tree board in the target release (board.yml, chosen nodes, pinctrl, partitions, SoC Kconfig).

Verify OTA from the current field firmware

When it applies: The project uses MCUboot, so devices in the field keep their current bootloader after the upgrade.

Why it matters: The upgraded image must still be accepted by the existing bootloader (signature type, key, slot layout and image header).

What to do: Keep the signing key, signature type and slot layout unchanged, and test an OTA update from the current production image on hardware.

West manifest pins an older Zephyr revision

When it applies: west.yml pins a Zephyr or module revision.

Why it matters: The manifest must point at the target release, and pinned modules (HALs, MCUboot, Mbed TLS) must match it.

What to do: Update the zephyr revision in west.yml to the target tag, re-check pinned modules, then run west update.

Fix the first build error first

When it applies: The build log contains errors.

Why it matters: Later errors in an SDK upgrade are often caused by the first configuration or devicetree failure.

What to do: Resolve the first reported error, rebuild, and re-run the scan with the new build log.

VelocityCreate

Want us to handle the upgrade?

VelocityCreate can review your assessment, agree on the migration scope, and carry out the firmware changes and agreed verification. Discuss your deadline, hardware, and requirements with an embedded engineer.

Discuss my migrationBook a technical call

The initial discussion is free. Implementation is quoted separately.

Related upgrade paths

Generated from the rule catalog of Migratorisk 0.3.0. This is an automated summary of published SDK changes, not a review of your project, and it does not replace builds and device tests. How the scanner is validated.