stable-v2.0: .github/zephyr: hardcode zephyr container version to v0.21.0

[marc-hb]

The container v0.22.0 changed the toolchain locations, for instance
for APL it changed from

/opt/toolchains/zephyr-sdk-0.13.1/xtensa/intel_apl_adsp/...

to

/opt/toolchains/zephyr-sdk-0.14.0/xtensa-intel_apl_adsp_zephyr-elf/...

The new location is not found by the old Zephyr version fd089b361d8aebbc
that is currently hardcoded for this branch by previous SOF commit
b678a4d. This causes the failure shown below, see real build
failure example in #5641.

The docker image v0.21.0 is the last one that has the old location.
https://hub.docker.com/r/zephyrprojectrtos/zephyr-build/tags

I suspect the name change happened in this commit:
zephyrproject-rtos/sdk-ng@c701e23bcce86f27f3a7

-- Using toolchain: zephyr 0.14.0 (/opt/toolchains/zephyr-sdk-0.14.0)
-- Found dtc:
/opt/toolchains/zephyr-sdk-0.14.0/sysroots/x86_64-pokysdk-linux/usr/bin/dtc
(found suitable version "1.6.0", minimum required is "1.4.6")
  ...
  ...
CMake Error at
/workdir/zephyrproject/zephyr/cmake/compiler/gcc/target.cmake:10
-- Configuring incomplete, errors occurred!
  C compiler
/opt/toolchains/zephyr-sdk-0.14.0/xtensa/intel_apl_adsp/ \
 xtensa-intel_apl_adsp_zephyr-elf/bin/xtensa-intel_apl_adsp_zephyr-elf-gcc
      not found - Please check your toolchain installation
      Call Stack (most recent call first):
/workdir/zephyrproject/zephyr/cmake/target_toolchain.cmake:57
/workdir/zephyrproject/zephyr/cmake/app/boilerplate.cmake:599
/.../zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24
/.../zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35

Signed-off-by: Marc Herbert marc.herbert@intel.com

[stephanosio]

@marc-hb This rather strange behaviour is observed in the Zephyr version 2.5 through 2.7 for the Xtensa targets because of the Zephyr commit zephyrproject-rtos/zephyr@483b4ff.

That commit was reverted in zephyrproject-rtos/zephyr@92a1ca6, so updating to the Zephyr 3.0 release should resolve this issue.

p.s. Meanwhile, I will also look into reverting that commit in the LTS2 (2.7) as well so that people can make use of the latest Zephyr SDK for building Xtensa targets.

[greg-intel]

Is this a hotfix? Or long-term?

PR is super simple, approving regardless.

[marc-hb]

Thanks @stephanosio for the very detailed and expert info, much appreciated.

so updating to the Zephyr 3.0 release should resolve this issue.

That's not really an option here because this is a stable branch. Instead, I cherry picked locally the two zephyr/cmake/toolchain/zephyr/target.cmake reverts zephyrproject-rtos/zephyr@e747fe73cdd67 (which reverts zephyrproject-rtos/zephyr@b557bd9 unlike what its commit message says) and zephyrproject-rtos/zephyr@92a1ca61eb1b and I confirm that these two make this stable branch compatible with the latest SDK 0.14.0 without breaking compatibility with 0.13.1. This is very similar to what backport zephyrproject-rtos/zephyr#44616 does.

So cherry-picking these two reverts is a more flexible and better solution than this PR, but... this stable SOF branch can only point at upstream Zephyr for now! Bummer.

tl;dr: I know how to fix this interesting cascade of dependencies and it's not rocket-science at all (just a few more cherry-picks) but I would like the build to be fixed first to stop driving blind. So let's please merge this container version hardcoding first, can be reverted later.

[marc-hb]

Un-hardcoding the Zephyr container and SDK in this stable-v2.0 branch in new PR #5740