west.yml: update Zephyr to f9f44b6dcdd (Mar 07) #8913
Conversation
kv2019i
requested review from
marc-hb,
bardliao,
marcinszkudlinski,
pblaszko,
lgirdwood,
plbossart,
mmaka1,
lbetlej and
dbaluta
as code owners
|
@iuliana-prodan Is zephyrproject-rtos#40 mandatory update for IMX, or can we do these incrementally? For Intel targets, some targets work with transitionary definitions, but at least INtel MTL targets were broken with the update as some of the SOC series Kconfig options were renamed in the process and SOF was using these in multiple places. |
|
I guess we need to cherry-pick IMX changes when updating as I can see some IMX builds failing https://github.com/thesofproject/sof/actions/runs/8171751130/job/22340660139?pr=8913 In local test, I still managed to hit zephyrproject-rtos/zephyr#69807 so this can be also a problem for merge (but lets' see whether CI agrees with my local tests or not). |
Yes, is mandatory for zephyr/main (which has hwmv2). |
|
Let me submit again, I didn't realize https://github.com/zephyrproject-rtos/sof/commits/zephyr/ has the patches. Let me squash them up and merge. |
kv2019i
force-pushed
the
202403-zephyr-mar06
branch
from
ba3900c
to
a9f6d90
Compare
|
The "sof-ci/jenkins/pr-buld" fail requires actions on SOF CI jenkins jobs, the changed path with HWMv2 trigger errors in the tools build. There's also additional error in the imx build -> https://github.com/thesofproject/sof/actions/runs/8175491141/job/22352725234?pr=8913 ? Something with imx.toml file. Can you check @iuliana-prodan ? |
I'm sorry, I forgot about this.. actually I thought is merged: zephyrproject-rtos/zephyr#69776 @kv2019i if you can merge it, it will be great! |
Installing most of the tools/ directory does not technically require building any platform, so add that possibility. This is useful because the Jenkins-based CI builds the (userspace) tools separately. So far it has been picking hardcoded source paths but of course the HWMv2 transition just broke that: thesofproject#8913 While it's too late this time (we want to keep CI able to test stable branches for some time), this commit prepares a future where all CIs can stop hardcoding Zephyr source paths and pick the output of the xtensa-build-zephyr.py installer and indirection layer instead. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
|
In https://sof-ci.01.org/sof-pr-viewer/#/build/PR8913/build13681617, the same test failed the same way on both MTL and LNL (other tests passed). That would be too much of a coincidence so it is most likely caused by this PR |
|
SOFCI TEST |
Done, https://sof-ci.01.org/sofpr/PR8913/build3193/build was successful. Thanks @keqiaozhang for testing my quick fix. Now the tests are running and you can move to the next step: looking at DSP panics... |
|
V3 attempt:
I'll mark this as DNM for now, but let's see if CI all passes (they should). |
kv2019i
changed the title
|
@iuliana-prodan can you check, there seems to be still something left, I see two failures with IMX targets. Hopefully I picked the right patches. |
|
@marc-hb It seems the HWMv2 (or some change that came here as well) has broken the Linux-windows build check |
From the error |
|
@iuliana-prodan wrote:
You are right, thanks for checking! It seems our github checks do not work correctly when the remote is overridden. I can see the extra commits are fetched, but the actual test is still run with Zephyr main (and it fails): Oh well, your patches is merged to Zephyr now, so I can update the PR using the merged commit. |
|
Looking better but failure seen in https://sof-ci.01.org/sofpr/PR8913/build3197/devicetest/index.html |
kv2019i
force-pushed
the
202403-zephyr-mar06
branch
from
35e9f90
to
96d4312
Compare
kv2019i
changed the title
|
V4:
|
kv2019i
changed the title
|
ARM64 build is failing, seems PLATFORM definition is missing: The expected fails for Intel targets in https://sof-ci.01.org/sofpr/PR8913/build3203/devicetest/index.html The fail in Internal Intel CI System/merge/build is problematic as that's a required CI check, will investigate. |
|
FYI @serhiy-katsyuba-intel this is a bit strange. The KD test is failing to (id 13685882): This is with today's Zephyr main. This looks a lot like a case of #8770 but why it's triggering herein the quickbuild test I have no idea. |
This should fix the failure for arm64 with Zephyr/main: #8918 |
Switch back to main Zephyr repository and commit f9f44b6dcdd. This includes following squashed SOF commits that are needed to adapt to HWMv2 changes in Zephyr: zephyr: app: scripts: intel_adsp: change board names to HWMv2 zephyr: sof: update board name for HWMv2 zephyr: intel_adsp: Change ACE SoC name to HWMv2 app: boards: imx93: updates for zephyr hwmv2 Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
force-pushed
the
202403-zephyr-mar06
branch
from
96d4312
to
6aa1e63
Compare
|
V5:
|
This was run EDIT: "zmain" in later run https://github.com/thesofproject/sof/actions/runs/8193558383?pr=8913 is now fine |
generated_configs.c used to be in a deterministic order. It's not any more but the content is still the same. Someone probably started using a non-deterministic Python set, it's typical. I'll bisect and fix as usual. As long as ONLY the Now racing to quickly fix this while other, much harder failures hold this for longer... |
|
@wszypelt Can you check? The quickbuild run (13687837) failed again what seems to like result copying issue, and not the actual test case. |
|
https://sof-ci.01.org/sofpr/PR8913/build3216/devicetest/index.html looks pretty bad. Submitted zephyrproject-rtos/zephyr#69937 as it likes solving this (without revert) will take more time. |
|
@kv2019i sure, there was a problem with the LNL testing machine, I've already added this PR to the queue. I think there will be new results within an hour |
|
https://sof-ci.01.org/sofpr/PR8913/build3216/devicetest/index.html is not great, but we have to progress with the HWMv2 changes and the problem on MTL has to be fixed at the source (i.e. Zephyr upstream), so I'll proceed and merge this. |
It's mostly red... |
Installing most of the tools/ directory does not technically require building any platform, so add that possibility. This is useful because the Jenkins-based CI builds the (userspace) tools separately. So far it has been picking hardcoded source paths but of course the HWMv2 transition just broke that: thesofproject#8913 While it's too late this time (we want to keep CI able to test stable branches for some time), this commit prepares a future where all CIs can stop hardcoding Zephyr source paths and pick the output of the xtensa-build-zephyr.py installer and indirection layer instead. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Installing most of the tools/ directory does not technically require building any platform, so add that possibility. This is useful because the Jenkins-based CI builds the (userspace) tools separately. So far it has been picking hardcoded source paths but of course the HWMv2 transition just broke that: thesofproject#8913 While it's too late this time (we want to keep CI able to test stable branches for some time), this commit prepares a future where all CIs can stop hardcoding Zephyr source paths and pick the output of the xtensa-build-zephyr.py installer and indirection layer instead. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Installing most of the tools/ directory does not technically require building any platform, so add that possibility. This is useful because the Jenkins-based CI builds the (userspace) tools separately. So far it has been picking hardcoded source paths but of course the HWMv2 transition just broke that: #8913 While it's too late this time (we want to keep CI able to test stable branches for some time), this commit prepares a future where all CIs can stop hardcoding Zephyr source paths and pick the output of the xtensa-build-zephyr.py installer and indirection layer instead. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Installing most of the tools/ directory does not technically require building any platform, so add that possibility. This is useful because the Jenkins-based CI builds the (userspace) tools separately. So far it has been picking hardcoded source paths but of course the HWMv2 transition just broke that: thesofproject#8913 While it's too late this time (we want to keep CI able to test stable branches for some time), this commit prepares a future where all CIs can stop hardcoding Zephyr source paths and pick the output of the xtensa-build-zephyr.py installer and indirection layer instead. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Switch back to main Zephyr repository and commit 0d5a670f4f073.
This includes multiple changes to fix compilation with Zephyr commit "hwmv2: Introduce Hardware model version 2 and convert devices".