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.
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 insteadWhere the changes are
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.
Kconfig options CONFIG_DISABLE_SSBD and 1 more were removed
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.
Kconfig options SB_CONFIG_MCUBOOT_MODE_SWAP_WITHOUT_SCRATCH and 1 more were replaced
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.
API MGMT_CB_ERROR_RET was removed
The deprecated macro MGMT_CB_ERROR_RET has been removed.
API stepper_enable_constant_velocity_mode was renamed
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.
API stepper_set_actual_position was renamed
Renamed the stepper_set_actual_position function to stepper_set_reference_position.
API stepper_set_max_velocity was renamed
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.
API stepper_set_target_position was renamed
Renamed the stepper_set_target_position function to stepper_move_to.
CONFIG_BT_CTLR deprecated in favour of HAS_BT_CTLR
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.
Devicetree compatible nxp,imx-lpi2c was renamed
Renamed the compatible from nxp,imx-lpi2c to nxp,lpi2c.
Devicetree compatible nxp,imx-lpspi was renamed
Renamed the compatible from nxp,imx-lpspi to nxp,lpspi.
Devicetree compatible nxp,kinetis-adc12 was renamed
Renamed the compatible from nxp,kinetis-adc12 to nxp,adc12.
Devicetree compatible nxp,kinetis-dspi was renamed
Renamed the compatible from nxp,kinetis-dspi to nxp,dspi.
Devicetree compatible nxp,kinetis-ftm was renamed
Renamed the compatible from nxp,kinetis-ftm to nxp,ftm and relocate it under dts/bindings/timer.
Devicetree compatible nxp,kinetis-ftm-pwm was renamed
Renamed the compatible from nxp,kinetis-ftm-pwm to nxp,ftm-pwm.
Devicetree compatible nxp,kinetis-lpuart was renamed
Renamed the compatible from nxp,kinetis-lpuart to nxp,lpuart.
Devicetree compatible nxp,kinetis-mpu was renamed
Renamed the compatible from nxp,kinetis-mpu to nxp,sysmpu and added its corresponding binding.
Devicetree compatible nxp,kinetis-pinctrl was renamed
Renamed the compatible from nxp,kinetis-pinctrl to nxp,port-pinctrl.
Devicetree compatible nxp,kinetis-pinmux was renamed
Renamed the compatible from nxp,kinetis-pinmux to nxp,port-pinmux.
Devicetree compatible nxp,kinetis-rtc was renamed
Renamed the compatible from nxp,kinetis-rtc to nxp,rtc.
Devicetree compatible nxp,kinetis-wdog32 was renamed
Renamed the compatible from nxp,kinetis-wdog32 to nxp,wdog32.
Devicetree compatible renesas,ra8-pwm was renamed
Renamed the compatible from renesas,ra8-pwm to renesas,ra-pwm.
Devicetree compatible silabs,gecko-spi-eusart was renamed
Renamed the compatible from silabs,gecko-spi-eusart to silabs,eusart-spi.
Devicetree compatible silabs,gecko-spi-usart was renamed
Renamed the compatible from silabs,gecko-spi-usart to silabs,usart-spi.
Devicetree compatible ti,ads114s0x-gpio was renamed
Renamed the compatible from ti,ads114s0x-gpio to ti,ads1x4s0x-gpio.
Devicetree compatible zephyr,gpio-steppers was renamed
Renamed the compatible from zephyr,gpio-steppers to zephyr,gpio-stepper.
Kconfig option CONFIG_MAX_FILES was renamed
The EXT2 Kconfig symbol CONFIG_MAX_FILES has been renamed to CONFIG_EXT2_MAX_FILES.
Kconfig option CONFIG_SOC_SERIES_RP2XXX was renamed
CONFIG_SOC_SERIES_RP2XXX is renamed to CONFIG_SOC_SERIES_RP2040.
Kconfig option CONFIG_NET_TC_SKIP_FOR_HIGH_PRIO is deprecated
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 callThe 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.