Repository navigation
[RFC][CI] Build SOF on Zephyr with IPC4 #5357
Description
We can already build SOF+Zephyr+IPC4+XCC manually with some hack or workaround, some issues need to be addressed before adding the build support in our build script.
SOF Application Kconfig is here: intel_adsp_cavs25.conf it is for IPC3. We cannot make this one file flexible for both IPC3 and IPC4 support. There are two ways to add kconfig overlay:
- Use board revision: we can add
intel_adsp_cavs25_ipc4.confkconfig revision in the same folder on zephyr side, then usewest build --board intel_adsp_cavs25@ipc4to build firmware. With this,intel_adsp_cavs25.conf,intel_adsp_cavs25_ipc4.confandprj.confwill be merged together into.config - Use OVERLAY_CONFIG env: we can specified OVERLAY_CONFIG like this:
export OVERLAY_CONFIG=folder-contains-the-overlay/intel_adsp_cavs25_ipc4.conf, the file suffix has to be.conf. If we use this options, where should be put the overlay file, in zephyr tree or sof tree? - Use selectable *.prj file for software config like XTENSA_CORE, XTENSA_TOOLS_VERSION, RIMAGE_KEY, this is disscussed in the meeting, seems everyone is good with this.
Talking about TGL and TGL-H, I think board revision is a good choice, but for IPC4+zephyr, I am not sure.
@lgirdwood @kv2019i @lyakh @marc-hb
@XiaoyunWu6666 FYI
Where should we store SOF application kconfig overlays, zephyr tree or sof tree?
Related Docs: https://docs.zephyrproject.org/2.7.0/guides/build/kconfig/setting.html#the-initial-configuration
https://docs.zephyrproject.org/latest/application/index.html#important-build-system-variables
Activity
lgirdwood commentedon Feb 14, 2022
@kv2019i @mwasko @nashif @andyross whats the preference here that would work for Zephyr ?
My understanding is that the board naming is resolved, but how do we differentiate the same board and carry upstream ?
mwasko commentedon Feb 14, 2022
@aiChaoSONG using board revision looks good to me.
andyross commentedon Feb 14, 2022
This seems like it really wants to be application configuration to me, no? "arch", "soc", and "board" should obviously reflect hardware configuration. Which protocol to speak is a software thing. It's possible to have variant prj.conf files in an app directory and select from them at runtime via west and twister, though so far that's mostly been used for test management.
Another option I guess would be to move most of the meat of the sof application (which is already pretty minimal) into a "subsys" directory somewhere and have SOF build from tiny/stub out-of-tree app directories in its own tree that contain nothing but kconfig changes and a one-line main().
Basically: we might very well have to come up with a cleaner scheme for you, but putting it in the board seems almost certainly wrong.
lgirdwood commentedon Feb 14, 2022
So IIUC, this looks like a Zephyr "application" or Zephyr "module" configuration that could apply to any (or most) boards that run the SOF application / module. @andyross this would point more to a collection of overlays that would exist in the SOF module repo and be combined with the Zephyr config at build time ?
andyross commentedon Feb 14, 2022
I hesitate to jump into the bikeshed on exactly what the right way to do things is, except to say that splitting it out by board is likely wrong. :)
There is a lot of flexibility/complexity involved in how the initial kconfig file is selected, the docs are reasonably clear: https://docs.zephyrproject.org/latest/guides/build/kconfig/setting.html#initial-conf
But yeah, they give a lot of latitude for an application to make its own decisions.
plbossart commentedon Feb 14, 2022
I think there's a definition/language issue here @aiChaoSONG @andyross
intel_adsp_cavs25_ipc4.conf cannot be a board definition, it's an IP description.
A board description would be skl-hda-generic-4mics or adl-max98387-ssp2. The board makes use of the IP along with a subset of interfaces, gpios, external audio codecs, you name it.
andyross commentedon Feb 14, 2022
Indeed, it's a jargon collision. In Zephyrese, device configurations live in a hierarchy of (in order of increasing specificity) "arch", "soc", and "board". The file referenced above was the board configuration for this particular device in the Zephyr tree. And the suggestion above was to use a board variant definition (which is certainly possible) to hold the "use IPC4" cookies. And I'm saying no, that's a bad idea and that software configuration belongs in the application layer somewhere. (Though I take no position as to where exactly!)
plbossart commentedon Feb 14, 2022
intel_adsp_cavs25_ipc4.conf can't be a "board" definition but may not even be a 'soc' definition.
Examples to prove my point:
JSL is cAVS 2.0 but has fewer cores and memory than ICL which is also cAVS2.0.
TGL-H is cAVS 2.5 but have less memory than TGL
So yes, the split between arch, soc and board is a very good one, and our configs ought to follow that model.
aiChaoSONG commentedon Feb 15, 2022
IPC4 kconfig is SOF application level configuration, so it should stay with SOF, right? @andyross
@lgirdwood if we are going to put such overlays in SOF tree, should I put them in
arch/xtensa/configs/override, or create a new overlay folder special for zephyr?marc-hb commentedon Feb 16, 2022
I believe you're commenting on the hardware part of this name:
intel_adsp_cavs25_...but this issue is about the software part..._ipc4which according to @andyross belongs to a totally different place (cause it's software). Do you think we should change the way hardware is named / configured before even looking at the software part?Related 2020 doc issue
aborisovich commentedon Feb 16, 2022
Guys I think we should start with creation of "platform" directory in the SOF.
This config approach is great but we also have some data in script files that in my opinion should not be there but rather bound to CMake. I am talking about: XTENSA_CORE, XTENSA_TOOLS_VERSION, RIMAGE_KEY, name dictionary entries in the xtensa-build-zephyr scripts. Those are well-known values. So I would put prj.conf files which @andyross mentioned in Setting initial configuration in the platform directory tree to create something like this:
platforms:
TGL
** platform.cmake
** prj.conf
TGL-H
** platform.cmake
** prj.conf
lgirdwood commentedon Feb 22, 2022
@kv2019i @mwasko @marcinszkudlinski @mmaka1 @aborisovich @andyross @nashif topic for Wednesday. Need to resolve soon.
XiaoyunWu6666 commentedon Feb 24, 2022
lgirdwood commentedon Feb 24, 2022
Zephyr fixed now merged, SOF side passing CI.
aiChaoSONG commentedon Feb 28, 2022
close this RFC by #5412