xtensa-build-all.sh: add ipc4 build support for tgl

[XiaoyunWu6666]

Add ipc4 build support for tgl with IPC4_CONFIG_OVERLAY.

If IPC_VERSION is chosen as IPC4, then overlay configuration file for different platforms will be used automatically without assigning the configuration file with options.

Different configuration files will be used according to what platformis building firmware for.

Signed-off-by: Xiaoyun Wu(Iris) xiaoyun.wu@intel.com

[XiaoyunWu6666]

with this PR , users do not need to know what overlay configuration file should be adopted when building sof firmware IPC4 for tgl
./scripts/xtensa-build-all.sh -o tigerlake_ipc4 tgl can be replaced by ./scripts/xtensa-build-all.sh -i IPC4 tgl instead.

This is consistent with how we build for sof zephyr with xtensa-build-zephyr.py ./scripts/xtensa-build-zephyr.py -i IPC4 tgl

[sys-pt1s]

Can one of the admins verify this patch?

[lgirdwood]

@XiaoyunWu6666 this bash script is being deprecated in favor of the python script. I'm fine to merge this now (since it's needed), but lets also make sure we can do this in Python too (e.g. can you send PR to do the same for Python script).
@marc-hb it sounds like we need a deprecated warning to the bash script (we could remove in v2.3) ?
@aborisovich fyi - and I assume python script will more easily scale for updates like this.

[marc-hb]

Small fixes requested otherwise I'm fine with the approach.

@lgirdwood we don't have a python script for this, this script was never used by Windows developers, they always used CMake and ninja manually. You're confusing with the Python build.

[marc-hb]

Suggested change

	cp "$IPC4_CONFIG_OVERLAY_FILE" override.config
	cat "${SOF_TOP}/src/arch/xtensa/configs/override/$IPC4_CONFIG_OVERLAY.config \
	>> override.config

Creating a new variable gives the wrong impression that it's going to be used somewhere else. Moreover the name is very similar to the other variable which is another potential source of confusion.

Keep this next to the other override.config options, having the menuconfig in the middle of the override.config does not seem to make sense.

[XiaoyunWu6666]

@marc-hb thanks for the comments! I've updated the commit.
It's more direct and intuitive now :) no risk of variable confusion

[marc-hb]

Keep this (new lines) close to the (big block of) other override.config options

Please?

[XiaoyunWu6666]

I did not notice it because the menuconfig looks in the middle of override.config operations originally.
Now I moved the code of this commit （append something to override.config）after menuconfig change, while menuconfig change is still after the copy of the whole override.config file, is it OK ？

[marc-hb]

I did not notice it because the menuconfig looks in the middle of override.config operations originally.

Yes and this is not ideal but the first bit of override.config code that is before menuconfig is quite different from the other ones if you look carefully.

[lgirdwood]

@lgirdwood we don't have a python script for this, this script was never used by Windows developers, they always used CMake and ninja manually. You're confusing with the Python build.

ok, so Python build will only build a single target ? It seems like this "build all" should use the Python script in the future for each target ?

[aiChaoSONG]

@lgirdwood the xtensa-build-all.sh is used for XTOS, it doesn't have the python counterpart yet, the xtensa-build-zephyr.sh is used for ZEPHYR, it has the python counterpart: xtensa-build-zephyr.py

[marc-hb]

Code change looks good to me but commit c87e40ecbee43c adds two Zephyr git submodules by accident!? Maybe you did git add * or git commit -a something similar? Never ever use these commands. Or maybe it's your git client, try a better one.

[XiaoyunWu6666]

@marc-hb sorry for adding spams to the commit by accident , I've updated it

mostly OK

[lgirdwood]

Not tested by internal CI so no need to block on it.