west.yml: update zephyr to a805a054fe1f

[tmleman]

Total of 935 commits.

Changes include:

a13fd968e132 soc: intel: Add support for dts RAM configuration
1d935da70029 kernel: Add support for dts RAM configuration
96d1142210e3 arch: Add support for dts RAM configuration
8509270a0e34 kernel: poll timeout: Fix race condition
1b8c7a3038d9 kernel: thread timeout: Fix race condition
667c3184d6e8 logging: log_output: Fix formatting of function prefix
e1434e141ecf logging: fix immediate clean output locking on SMP
1296dc85e332 kernel: timer: make k_timer_start duration match documented semantics
2e2202af616c kernel: timeout: make z_add_timeout round-up conditional on announce
d157b3da193d kernel: timeout: keep announce_remaining stable across same-tick group
827ce93035bc soc: kernel: use configdefault for CONFIG_SMP
603fa4818e8f drivers: timer: assert sys_clock lock held where required
1dc47344d0a2 kernel: use arch_cpu_irqs_are_enabled() for IRQ-state probes
01b3821fd933 kernel: spinlock: provide z_spin_is_locked() for UP builds
c91e5e1390f3 kernel: move atomic_c.c to lib/os
cc6136628341 kernel: move errno from kernel to lib/libc/common
81ccaca788db kernel: ensure kheap.c is linked for static heap initialization
39b23fa582d8 kernel: bypass k_heap_free() in k_free() to avoid scheduler locking
db7a5e80a47b kernel: move bootargs out of kernel into lib/os.
9fe4cc20a2b5 kernel: move boot banner into lib/os
f7c6f1d92110 soc: intel_adsp: ace30: extend hwreg0 MMU range
814cfb41191a soc: intel_adsp: ace40: extend hwreg0 MMU range
1bc5f0543c4d drivers: counter: introduce counter capture api
e81266be2bfe arch: add arch_cpu_irqs_are_enabled() primitive

[Copilot]

Pull request overview

This PR bumps the Zephyr project revision pinned in SOF’s west.yml manifest to a805a054fe1f59a21259d0975dced68169974954, pulling in the upstream Zephyr changes enumerated in the PR description (935 commits) for the SOF Zephyr-based build/workflow.

Changes:

• Update the zephyr project revision in west.yml from c162980efd9a... to a805a054fe1f....

[kv2019i]

@thesofproject/nxp there's a imx95 fail with recent Zephyr main:

/__w/sof/sof/zephyr/include/zephyr/sys/clock.h:223:2: error: #error "SYS_CLOCK_HW_CYCLES_PER_SEC must be non-zero!"
  223 | #error "SYS_CLOCK_HW_CYCLES_PER_SEC must be non-zero!"
      |  ^~~~~

[lgirdwood]

@dbaluta can you fix this incrementally in a followup ?

[tmleman]

@lgirdwood There's also a regression in SOF's build system on Windows caused by changes in Zephyr. We should also address this somehow. Currently investigating, initially it looks like changes in LLEXT.

[tmleman]

@lgirdwood @lyakh FYI zephyrproject-rtos/zephyr#98348 (comment)

[pillo79]

Thanks for the investigation and pinpointing the issue.
Is it possible for you to try replacing ${CMAKE_COMMAND} below with '${CMAKE_COMMAND}'?

https://github.com/zephyrproject-rtos/zephyr/blob/a97b5f221bf178c3427d3031e8f2a2d5ca922644/misc/llext_edk/CMakeLists.txt#L24-L26

[tmleman]

Thanks for the investigation and pinpointing the issue. Is it possible for you to try replacing ${CMAKE_COMMAND} below with '${CMAKE_COMMAND}'?

https://github.com/zephyrproject-rtos/zephyr/blob/a97b5f221bf178c3427d3031e8f2a2d5ca922644/misc/llext_edk/CMakeLists.txt#L24-L26

@pillo79 , thanks for taking interest. I tested the proposed solution but unfortunately it didn't solve the problem. I asked AI for help and it was able to prepare two solutions but only one works. Below you'll find links to drafts in Zephyr and to pull requests in SOF that point to them to confirm the effectiveness of the solution. If you find time, please take a look at them and comment. If the working solution suits you, I'll file an issue and prepare a PR.

1. cmake: llext-edk: quote CMAKE_COMMAND to fix MSYS2 path mangling zephyrproject-rtos/zephyr#109134
   • [SKIP SOF-TEST] [CIONLY] For test #10776
2. cmake: llext-edk: fix build portability on Windows zephyrproject-rtos/zephyr#109129
   • [SKIP SOF-TEST] [CIONLY] For test #10774
3. (working) llext: edk: fix Windows build failure due to ccache and path quoting zephyrproject-rtos/zephyr#109146
   • [SKIP SOF-TEST] [CIONLY] For test #10778

[pillo79]

The working solution looks good to me and has no side effects AFAICS, so +1 on that!

Note that my objective with that PR was to fix missing compile flags (especially module ones) that were not exported previously by the EDK. It should improve the match between the Zephyr build and any EDK-built binaries, but this may have unexpected side effects on SOF builds (I hope not!).

[lyakh]

The working solution looks good to me and has no side effects AFAICS, so +1 on that!

Note that my objective with that PR was to fix missing compile flags (especially module ones) that were not exported previously by the EDK. It should improve the match between the Zephyr build and any EDK-built binaries, but this may have unexpected side effects on SOF builds (I hope not!).

@pillo79 I'm not aware of any SOF builds using the Zephyr LLEXT EDK. Does that PR affect non-EDK builds too?

[pillo79]

Note that my objective with that PR was to fix missing compile flags (especially module ones) that were not exported previously by the EDK. It should improve the match between the Zephyr build and any EDK-built binaries, but this may have unexpected side effects on SOF builds (I hope not!).

@pillo79 I'm not aware of any SOF builds using the Zephyr LLEXT EDK. Does that PR affect non-EDK builds too?

No, zephyrproject-rtos/zephyr#98348 only affects the llext-edk target*. But then I don't understand why the issue discussed here is happening in SOF CI, if not by running a west build -t llext-edk somewhere? Maybe the Zephyr test suite?

(EDIT: (*) for context, the issue is in misc/llext_edk/CMakeLists.txt and that is only called by cmake/llext-edk.cmake which is only ever included when -t llext-edk is run).

[dbaluta]

@dbaluta can you fix this incrementally in a followup ?

@lgirdwood Addressing this today.

[tmleman]

@pillo79 @lyakh I read your comments and came to the conclusion that something here must not add up because our workflows are failing so this change must affect us.

I reviewed the code a bit in terms of dependencies and these are my conclusions:

only affects the llext-edk target*

True

the issue is in misc/llext_edk/CMakeLists.txt and that is only called by cmake/llext-edk.cmake which is only ever included
when -t llext-edk is run

False

I'm not aware of any SOF builds using the Zephyr LLEXT EDK.

False

On every platform where we enabled CONFIG_LLEXT in SOF, CONFIG_LLEXT_EDK is automatically enabled.

• Sets CONFIG_LLEXT_EDK=y if CONFIG_LLEXT=y:
  https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/llext/Kconfig#L317-L319

• includes the broken CMakeLists.txt if CONFIG_LLEXT_EDK=y:
  https://github.com/zephyrproject-rtos/zephyr/blob/main/CMakeLists.txt#L2406-L2425

[pillo79]

💡 Thanks again for the investigation. `

the issue is in misc/llext_edk/CMakeLists.txt and that is only called by cmake/llext-edk.cmake which is only ever included when -t llext-edk is run

False

Right, my mistake; it is in fact called at every build if LLEXT_EDK config is enabled. The -t llext-edk bit only collects the output files.

CONFIG_LLEXT_EDK is independent of LLEXT, but that default y if LLEXT was added to keep backwards compatibility (originally they were intertwined). It is perfectly fine to disable CONFIG_LLEXT_EDK in SOF if you don't need it (and it makes the build slightly faster).

[tmleman]

@lgirdwood, after explicitly disabling LLEXT_EDK in all ACE platforms we no longer need to wait for the fix to be merged. Question: do we wait for fix for IMX95?

[lyakh]

I'm not aware of any SOF builds using the Zephyr LLEXT EDK.

False

@tmleman I didn't say that we never enable the Kconfig option, I said that AFAIK we never use it. Which is also confirmed by the fact that disabling it doesn't break SOF. So, yes, please, let's disable it.

[lyakh]

a good change, but can we do it in prj.conf? On "main" we only support Zephyr builds.