west.yml: update Zephyr to 9d1df132b1c + one revert #8903
Conversation
This changes the secondary core power up routine to use the newly
introduced k_smp_cpu_start() and k_smp_cpu_resume(). This removes
the need to mirror part of the SMP start up code from Zephyr, and
no longer need to call into Zephyr private kernel code.
West update includes :
eefaeee061c8 kernel: smp: introduce k_smp_cpu_resume
042cb6ac4e00 soc: intel_adsp: enable DfTTS-based time stamping
on ACE platforms
6a0b1da158a4 soc: intel_adsp: call framework callback function for restore
e7217925c93e ace: use a 'switch' statement in pm_state_set()
c99a604bbf2c ace: remove superfluous variable initialisation
a0ac2faf9bde intel_adsp: ace: enable power domain
4204ca9bcb3f ace: fix DSP panic during startup (fixes c3a6274bf5e4)
d4b0273ab0c4 cmake: sparse.template: add COMMAND_ERROR_IS_FATAL
ca12fd13c6d3 xtensa: intel_adsp: fix a cache handling error
0ee1e28a2f5f xtensa: polish doxygen and add to missing doc
035c8d8ceb4b xtensa: remove sys_define_gpr_with_alias()
a64eec6aaeec xtensa: remove XTENSA_ERR_NORET
Signed-off-by: Daniel Leung <[email protected]>
Signed-off-by: Rander Wang <[email protected]>
[[email protected]: update Zephyr hversion]
Signed-off-by: Guennadi Liakhovetski <[email protected]>
z_soc_uncached_ptr() / z_soc_cached_ptr() have been removed from Zephyr and replaced with sys_cache_uncached_ptr_get() and sys_cache_cached_ptr_get() respectively. Signed-off-by: Guennadi Liakhovetski <[email protected]>
kv2019i
requested review from
dabekjakub,
tmleman,
lgirdwood,
plbossart,
mmaka1,
lbetlej and
dbaluta
as code owners
|
SOF Ci test looks good. There's is one pause-resume fail on a multicore MTL configuration, but this is somethign we can live with as we have fixed coming up via newer Zephyr -> https://sof-ci.01.org/sofpr/PR8903/build3114/devicetest/index.html?model=MTLP_RVP_NOCODEC&testcase=multiple-pause-resume-50 cAVS2.5 run has one system-pm fail https://sof-ci.01.org/sofpr/PR8903/build3115/devicetest/index.html -> we can ignore. Let's wait for Internal Intel CI results (still running) and if good, we can merge this. |
kv2019i
changed the title
|
@dbaluta @LaurentiuM1234 Assuming all tests pass, ok to go with this PR (use a local copy of Zephyr so we can revert one upstream patch )? |
|
Bug filed for the revert zephyrproject-rtos/zephyr#69807 |
Should be fine. I'm assuming this is only temporary (i.e: by 2.10 we'll go back to mainline Zephyr), right? Prepared #8904 for the 64-bit CI build failure caused by this. Should we include it in this PR or merge it later on? |
Zephyr commit b985442829dd ("dts: mimx93_evk_a55: avoid conflict
with Ethos-U NPU reserved memory") changes SRAM0's address to
0xd0000000. This breaks the i.MX93 SOF build because the SRAM0
node is no longer deleted so west build complains about having
2 SRAM0 nodes with different addresses.
To fix this, update the deleted node's base address.
Signed-off-by: Laurentiu Mihalcea <[email protected]>
Signed-off-by: Kai Vehmanen <[email protected]>
Update to Zephyr in sof/main-rebase-20240305 branch of SOF project's clone of Zephyr upstream repository. Revert one Zephyr commit "pm: Remove CURRENT_CPU macro" that is leading to failed tests in SOF CI test suite. The revert allows us to update Zephyr to a newer version and tackle the SMP boot and cache interface changes in SOF. The latest Zephyr upstream has further changes needed in SOF for platform configuration and these will require separarate changes. Link: thesofproject#8818 Link: zephyrproject-rtos/zephyr#69807 Signed-off-by: Kai Vehmanen <[email protected]>
kv2019i
force-pushed
the
202403-zephyr-mar05
branch
from
91bafdc
to
1821869
Compare
|
@LaurentiuM1234 wrote:
At least for now temporary, although comments are welcome on how to improve the process. This is not the first time when we've had a cascade of issues blocking Zephyr updates for a longer time in SOF, and we really need to tackle these faster. One concrete improvement has been getting rid of some internal API use in SOF (like the SMP API that is now removed with this PR), and ideally these decouple SOF and Zephyr better in the future, but this still leaves a category of problems that, if caught too late, will cause problem to all SOF users.
Thanks, I cherry-picked that and pushed one more update. I didn't merge the git commits, but at least these are in the same pull request. Let's see if the CI is happy with this. |
|
Results still good, or at least good enough for merge in SOF main now that we've started 2.10: The single multiple-pause fail on Intel MTL is known and will be fixed by later commits in Zephyr. Need one more approval for merge... |
I understand this is temporary, but having a fork for zephyr in Maybe we should monitor closer the Also, when we create a stable branch in sof, can we do that also in Zephyr ? |
|
@iuliana-prodan thanks for the response. Let's take this into discussiong at https://github.com/orgs/thesofproject/discussions/8909 -- I answered some of the points there. W.r.t. stable branches, that we do already. E.g. for SOF2.9, I now backported a couple of fixes from Zephyr upstream to sof/stable-v2.9 branch of Zephyr: I do think in upstream releases we need to keep a strick policy of only having patches that have been merged to upstream (either SOF or Zephyr) and not have patches in the stable branches that are not in main. |
We don't need branching policies more complex than the above. |
|
#8913 was next and just merged. |
Modified #8901 to address the failures seen in CI.