hwmv2: intel_adsp: Port to HWMv2

[golowanow]

Port intel_adsp SoC family: ace and cavs SoC series, and related board configurations:

• intel_adsp_cavs25
• intel_adsp_cavs25_tgph changed to intel_adsp_cavs25/intel_tgl_adsp/tgph
• intel_adsp_ace15_mtpm
• intel_adsp_ace20_lnl

cc:

• Hardware model v2 #51831

[golowanow]

@tejlmand, @nashif, @dcpleung - for your early feedback as a draft.

[golowanow]

1. adjusted to hwmv2: move all non-ported legacy boards and socs to legacy folders #68346
2. intel_adsp_cavs25_tgph board configuration is converted to a HWMv2 variant intel_adsp_cavs25/intel_tgl_adsp/tgph

[golowanow]

this move from intel_adsp/common/include to intel_adsp/cavs/ resolves build issue when this header file was applied with the HWMv2 for adsp builds as well

[nashif]

• intel_adsp_cavs25_tgph changed to intel_adsp_cavs25/intel_tgl_adsp/tgph

oh wow, not nice at all, @tejlmand, we need away for this to be shorter and to the point, lots of redundancy in that name.

[nordicjm]

• intel_adsp_cavs25_tgph changed to intel_adsp_cavs25/intel_tgl_adsp/tgph

oh wow, not nice at all, @tejlmand, we need away for this to be shorter and to the point, lots of redundancy in that name.

As said before, if there is only one soc then you can omit the soc, i.e. intel_adsp_cavs25//tgph, that should only be omitted by users on the command line though, .yaml files and sample.yml/testcase.yml should use the full name

[nashif]

As said before, if there is only one soc then you can omit the soc, i.e. intel_adsp_cavs25//tgph, that should only be omitted by users on the command line though, .yaml files and sample.yml/testcase.yml should use the full name

as said before, this context aware board naming and guessing is not ideal and is going to be very error-prone. The fact is that for reference we will need one unique and authorative name for boards and should not rely on the context, i.e. for tooling and what not. Such long names with lots of redundancy are not user or developer friendly at all. I am sure this can be solved in the definition of the board or soc itself, but we are giving a people a rope to hang themselves with and we will end up with 1m long board names with lots of redunancy that is not as intuitive as it may seem.

[nashif]

@tejlmand @nordicjm btw, there is something very wrong here, SOF failing to build and picking kconfigs from some completely unrelated _defconfig file (for CONFIG_MULTICORE defined in SOF). Looks like some handling of ARCH is not quite right.

[golowanow]

@tejlmand @nordicjm btw, there is something very wrong here, SOF failing to build and picking kconfigs from some completely unrelated _defconfig file (for CONFIG_MULTICORE defined in SOF). Looks like some handling of ARCH is not quite right.

the proposed fix will be in this PR soon.
I just need to respond to all comments here as well and test it again.

[golowanow]

SOF failing to build and picking kconfigs from some completely unrelated _defconfig file (for CONFIG_MULTICORE defined in SOF). Looks like some handling of ARCH is not quite right.

it is where CORE_COUNT is set to default 1 at SOF module when its Kconfig is processed by the HWMv2 altered build sequence (without ARCH set):
https://github.com/zephyrproject-rtos/sof/blob/0606152d4aafc1f7ed43df1b1813252bfc74e154/src/arch/host/Kconfig#L5-L9

so the workaround's idea is to just re-align to MAX_CORE_COUNT MP_MAX_NUM_CPUS of the SoC similar to
https://github.com/zephyrproject-rtos/sof/blob/0606152d4aafc1f7ed43df1b1813252bfc74e154/src/platform/Kconfig#L240-L247

[golowanow]

CI checks with twister fail currently only on non-related to this change boards: mps2_an521_remote, nrf5340bsim_nrf5340_cpuapp, qemu_x86_tiny.

[golowanow]

@tejlmand, @nashif, @dcpleung - up to your attention.

[golowanow]

re-assign reviewers according to the current Intel Xtensa MAINTAINERS and for HWMv2 check

[tejlmand]

Thanks for this porting, but please update the board's Kconfig.

[tejlmand]

approved, but as it turns out board.cmake is created new, then fixing indentation in the process would be nice, but can also be done later.

[golowanow]

approved, but as it turns out board.cmake is created new, then fixing indentation in the process would be nice, but can also be done later.

indentation fixed

[ceolin]

Can't we get rid of this now since we already have to do changes in SOF side ?