You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] remove XTOS support from SOF mainline #9983
Is your feature request related to a problem? Please describe.
Since 2022, SOF has been moving to Zephyr as its primary RTOS with work tracked in #5794
Most SOF users have either completed the transition to Zephyr, or are in progress of adding support for Zephyr for their platforms.
This ticket is for removal of XTOS support from SOF main, leaving XTOS support only supported in release stable branches. There is a set of cleanups we can proceed with, once XTOS support is removed, so having a ticket to mark as a dependency is useful for tracking.
Describe the solution you'd like
XTOS support removal from "main" branch
Feature Breakdown
This feature cannot be performed as a single large PR as we have many platforms, drivers, features and abstractions based around the legacy xtos code and this means we will need to remove section by section and make any necessary adaptations as needed for each removal.
These lists are not exhaustive, but the starting point for xtos removal.
Xtos Platform removals
Intel - platform headers and some platform drivers remain for Intel platforms.
NXP - platform headers and some drivers remain for NXP platforms.
AMD - platform headers and some drivers remain for AMD platforms.
MTK - platform headers and some drivers remain for MTK platforms.
Xtos Peripheral Driver removals
Intel - DMA drivers remain for Intel platforms.
NXP - DMA, SAI, IPC drivers remain for NXP platforms.
AMD - DAI, DMA, interrupt drivers remain for AMD platforms.
MTK - DAI, DMA, interrupt drivers remain for MTK platforms.
@bhiregoudar ok, do you have a schedule for fixing timer scheduling on AMD ?
Fwiw, we found DMA based scheduling would not scale beyond a few streams as stream start ordering meant DMA IRQs would fire in different sequences/times and could cause a lot of thrash and glitches...
Timer based scheduling works best when the DSP is clock master for the codecs (otherwise you need to add the ASRC), as all pipelines are executed from a single synchronous tick in a deterministic order. Feel free to create an issue and it should gather comments from others who have transitioned to timers for debug.
IMO all good from NXP's side. Although @lgirdwood already mentioned this I want to stress out the fact that all IMX platforms are still using the XTOS IPC driver so we need to watch out for that.
IMO all good from NXP's side. Although @lgirdwood already mentioned this I want to stress out the fact that all IMX platforms are still using the XTOS IPC driver so we need to watch out for that.
Yeah - that's something that @kv2019i is working on with Zephyr folks. We also need Zephyr clock driver too. We would need to keep the legacy drivers until Zephyr replacements were upstream.
IMO all good from NXP's side. Although @lgirdwood already mentioned this I want to stress out the fact that all IMX platforms are still using the XTOS IPC driver so we need to watch out for that.
Yeah - that's something that @kv2019i is working on with Zephyr folks. We also need Zephyr clock driver too. We would need to keep the legacy drivers until Zephyr replacements were upstream.
@bhiregoudar ok, do you have a schedule for fixing timer scheduling on AMD ?
Fwiw, we found DMA based scheduling would not scale beyond a few streams as stream start ordering meant DMA IRQs would fire in different sequences/times and could cause a lot of thrash and glitches...
Timer based scheduling works best when the DSP is clock master for the codecs (otherwise you need to add the ASRC), as all pipelines are executed from a single synchronous tick in a deterministic order. Feel free to create an issue and it should gather comments from others who have transitioned to timers for debug.
@bhiregoudar ok, do you have a schedule for fixing timer scheduling on AMD ?
Fwiw, we found DMA based scheduling would not scale beyond a few streams as stream start ordering meant DMA IRQs would fire in different sequences/times and could cause a lot of thrash and glitches...
Timer based scheduling works best when the DSP is clock master for the codecs (otherwise you need to add the ASRC), as all pipelines are executed from a single synchronous tick in a deterministic order. Feel free to create an issue and it should gather comments from others who have transitioned to timers for debug.
We have started working on timer scheduler. One question is that, if XTOS is removed, can the already existing platforms continue with XTOS? What about the ToT driver support to the older platforms which uses XTOS? any dependency?
@bhiregoudar ok, do you have a schedule for fixing timer scheduling on AMD ?
Fwiw, we found DMA based scheduling would not scale beyond a few streams as stream start ordering meant DMA IRQs would fire in different sequences/times and could cause a lot of thrash and glitches...
Timer based scheduling works best when the DSP is clock master for the codecs (otherwise you need to add the ASRC), as all pipelines are executed from a single synchronous tick in a deterministic order. Feel free to create an issue and it should gather comments from others who have transitioned to timers for debug.
We have started working on timer scheduler. One question is that, if XTOS is removed, can the already existing platforms continue with XTOS? What about the ToT driver support to the older platforms which uses XTOS? any dependency?
Yes, already existing platforms can continue with SOF v2.13 release branch (Intel does this with SOF v2.2 release branch for older IPC3 platforms).
The main branch is for future/current platforms where we want to accelerate velocity and save effort using Zephyr RTOS.
@lgirdwood You added a list of tasks including removal of SOF abstractions for dma/trace/memory. Do you want to track them here, or in #5794 . I don't think we need to track in both places. XTOS is now removed, and remaining work is to reduce abstractions on SOF side.
We have started working on timer scheduler. One question is that, if XTOS is removed, can the already existing platforms continue with XTOS? What about the ToT driver support to the older platforms which uses XTOS? any dependency?
Yes, already existing platforms can continue with SOF v2.13 release branch (Intel does this with SOF v2.2 release branch for older IPC3 platforms).
The main branch is for future/current platforms where we want to accelerate velocity and save effort using Zephyr RTOS.
Could I regard this as the SOF mainline will no more support XTOS after v2.13. In other words, if one on main branch would like to build XTOS, it should base on the commit no later than v2.13 tag.
By the way, is the use of IPC4 bound together with Zephyr? From my understanding, they should be independent which means Zephyr build + IPC3 should be expected to work as well, is that correct? Is there a plan to remove IPC3?
We have started working on timer scheduler. One question is that, if XTOS is removed, can the already existing platforms continue with XTOS? What about the ToT driver support to the older platforms which uses XTOS? any dependency?
Yes, already existing platforms can continue with SOF v2.13 release branch (Intel does this with SOF v2.2 release branch for older IPC3 platforms).
The main branch is for future/current platforms where we want to accelerate velocity and save effort using Zephyr RTOS.
Could I regard this as the SOF mainline will no more support XTOS after v2.13. In other words, if one on main branch would like to build XTOS, it should base on the commit no later than v2.13 tag.
Yes, that correct. The v2.13 stable branch should be used for any xtos based platforms.
By the way, is the use of IPC4 bound together with Zephyr? From my understanding, they should be independent which means Zephyr build + IPC3 should be expected to work as well, is that correct? Is there a plan to remove IPC3?
No plans to remove IPC3 and Zephyr works well with IPC3.
Updated the checkbox list for current work done in v2.14. Basicly XTOS platform support is completely removed, but there v2.14 keeps ability to use XTOS drivers in Zephyr and there are many drivers in the tree that use this. We have moved to many native APIs, but some SOF side abstractions remains.
Updated the checkbox list for current work done in v2.14. Basicly XTOS platform support is completely removed, but there v2.14 keeps ability to use XTOS drivers in Zephyr and there are many drivers in the tree that use this. We have moved to many native APIs, but some SOF side abstractions remains.
@thesofproject/amd @thesofproject/nxp @thesofproject/mediatek whats your status with Zephyr native drivers ? Are you able to start deleting SOF FW drivers in SOF codebase ?
Updated the checkbox list for current work done in v2.14. Basicly XTOS platform support is completely removed, but there v2.14 keeps ability to use XTOS drivers in Zephyr and there are many drivers in the tree that use this. We have moved to many native APIs, but some SOF side abstractions remains.
We have moved to Native Zephyr drivers for DAI, DMA and interrupt. We haven't up streamed the code yet. We are in process of upstream. We need to look into other drivers like mailbaox drivers to move to native driver.
Activity
kv2019i commentedon May 7, 2025
@lgirdwood opened discussion at https://github.com/orgs/thesofproject/discussions/9993
lgirdwood commentedon May 7, 2025
@thesofproject/amd @thesofproject/nxp @thesofproject/intel @thesofproject/google @thesofproject/mediatek pls comment/review and provide any feedback.
bhiregoudar commentedon May 7, 2025
lgirdwood commentedon May 7, 2025
@bhiregoudar ok, do you have a schedule for fixing timer scheduling on AMD ?
Fwiw, we found DMA based scheduling would not scale beyond a few streams as stream start ordering meant DMA IRQs would fire in different sequences/times and could cause a lot of thrash and glitches...
Timer based scheduling works best when the DSP is clock master for the codecs (otherwise you need to add the ASRC), as all pipelines are executed from a single synchronous tick in a deterministic order. Feel free to create an issue and it should gather comments from others who have transitioned to timers for debug.
iuliana-prodan commentedon May 8, 2025
From NXP's point of view, we have all platforms supported with Zephyr and timer domain.
We can remove the XTOS.
@dbaluta @LaurentiuM1234 do you see any issues with this?
dbaluta commentedon May 8, 2025
@iuliana-prodan all good from my point of view.
lgirdwood commentedon May 8, 2025
@andrew-mtk pls reply with any comments for Mediatek team. @andyross feedback welcome too.
LaurentiuM1234 commentedon May 9, 2025
IMO all good from NXP's side. Although @lgirdwood already mentioned this I want to stress out the fact that all IMX platforms are still using the XTOS IPC driver so we need to watch out for that.
lgirdwood commentedon May 9, 2025
Yeah - that's something that @kv2019i is working on with Zephyr folks. We also need Zephyr clock driver too. We would need to keep the legacy drivers until Zephyr replacements were upstream.
kv2019i commentedon May 9, 2025
lgirdwood commentedon May 19, 2025
@bhiregoudar any update here ?
lgirdwood commentedon May 19, 2025
@andrew-mtk @andyross ping.
bhiregoudar commentedon May 20, 2025
We have started working on timer scheduler. One question is that, if XTOS is removed, can the already existing platforms continue with XTOS? What about the ToT driver support to the older platforms which uses XTOS? any dependency?
lgirdwood commentedon May 23, 2025
Yes, already existing platforms can continue with SOF v2.13 release branch (Intel does this with SOF v2.2 release branch for older IPC3 platforms).
The main branch is for future/current platforms where we want to accelerate velocity and save effort using Zephyr RTOS.
kv2019i commentedon Jul 1, 2025
Work started in #10075
kv2019i commentedon Jul 3, 2025
@lgirdwood You added a list of tasks including removal of SOF abstractions for dma/trace/memory. Do you want to track them here, or in #5794 . I don't think we need to track in both places. XTOS is now removed, and remaining work is to reduce abstractions on SOF side.
johnylin76 commentedon Jul 5, 2025
Could I regard this as the SOF mainline will no more support XTOS after v2.13. In other words, if one on main branch would like to build XTOS, it should base on the commit no later than v2.13 tag.
By the way, is the use of IPC4 bound together with Zephyr? From my understanding, they should be independent which means Zephyr build + IPC3 should be expected to work as well, is that correct? Is there a plan to remove IPC3?
lgirdwood commentedon Jul 7, 2025
Yes, that correct. The v2.13 stable branch should be used for any xtos based platforms.
No plans to remove IPC3 and Zephyr works well with IPC3.
kv2019i commentedon Sep 30, 2025
Updated the checkbox list for current work done in v2.14. Basicly XTOS platform support is completely removed, but there v2.14 keeps ability to use XTOS drivers in Zephyr and there are many drivers in the tree that use this. We have moved to many native APIs, but some SOF side abstractions remains.
lgirdwood commentedon Sep 30, 2025
@thesofproject/amd @thesofproject/nxp @thesofproject/mediatek whats your status with Zephyr native drivers ? Are you able to start deleting SOF FW drivers in SOF codebase ?
bhiregoudar commentedon Oct 7, 2025
We have moved to Native Zephyr drivers for DAI, DMA and interrupt. We haven't up streamed the code yet. We are in process of upstream. We need to look into other drivers like mailbaox drivers to move to native driver.
dbaluta commentedon Oct 7, 2025
We are running with native interfaces on all NXP platforms. There is still the
${SOF_DRIVERS_PATH}/imx/ipc.cwe are using from SOF code.lgirdwood commentedon Oct 13, 2025
@thesofproject/steering-committee lets make the removal of non Zephyr drivers a topic for next call.
lyakh commentedon Jan 30, 2026
@thesofproject/amd one of the features that are being deprecated here is
CONFIG_TRACEand the only platform enabling it is vangogh:sof/src/arch/xtensa/configs/vangogh_defconfig
Line 24 in 0187fc5