west.yml: update Zephyr to efc32081893

[dbaluta]

Update Zephyr to pull in imx8ulp support. This includes following zephyr commits:

• cfb68f827202 ("boards: xtensa: adsp: add support for imx8ulp board")
• a9a0c28282c3 ("dts/xtensa/nxp: Add dtsi for imx8ulp")
• 4b33c65f7108 ("soc: xtensa: adsp: add support for NXP ADSP for i.MX8ULP")
• ceae1d83ca4b ("west: sign: add support for NXP i.MX8ULP board")

[marc-hb]

I checked the internal site and the only MTL failure in https://sof-ci.01.org/sofpr/PR8582/build800/devicetest/index.html is the well known GSC firmware problem

I'm more worried about https://sof-ci.01.org/sofpr/PR8582/build801/devicetest/index.html?model=ADLP_RVP_NOCODEC-ipc4&testcase=multiple-pause-resume-50

[dbaluta]

@marc-hb@lgirdwood Can someone at Intel have a look?

@lgirdwood let me try with an older Zephyr, I don't need main exactly for imx8ulp changes

[kv2019i]

@wszypelt I checked the Intel internal test and I can see test 000_01_TestMulticoreHostTopology failing. The FW log shows not data received by the pipeline and the resulting wave file for the secondary pipe is empty. However, I see same test failing with this PR and also with #7688 , so it would seem this is not related to the pull-requests, but either issue in the DUT or a regression that has slipped him.

[dbaluta]

SOFCI TEST

[dbaluta]

@kv2019i I se that build job is also failing but cannot see any details at: https://sof-ci.01.org/sof-pr-viewer/#/build/PR8582/build13236928

[wszypelt]

@kv2019i@dbaluta You're right, this error is strange, I think the problem may be with the test execution, I ran PR again and the results should be available soon, I will also check this test carefully on this FW on another machine with a larger number of iterations

[kv2019i]

Thanks @wszypelt , now seems to indeed pass! Proceeding with merge.