Skip to content

Conversation

@kv2019i
Copy link
Collaborator

@kv2019i kv2019i commented Aug 21, 2025

We've had multiple issues minor config differences between different Intel boards, that it's time to remove some of the duplication and make adding new boards easier.

Other options considered:

  • set the defaults in the main Kconfig definition -> doesn't scale well if we let's say have ten familiies of SoCs at some point
  • use an overlay -> will break "west build board_file" usage, you would need to know to use a specific overlay e.g. to build a functional Intel target, not good, "west build board" should do the right thing
  • use board family concept on Zephyr side -> cannot be used to set SOF side Kconfig settings
  • use SOF platform concept (src/platform), SOF still has the concept of "platform" (Zephyr doesn't recognize platform concept, completely on SOF side), and we've had some debates whether to keep a small version of it, or remove altogehter. we could still add the Kconfig.defconfig's under platforms, but in this PR I chose the simpelr route bypassing SOF platform concept altogheter. more discussion in [FEATURE][Zephyr] Clarify expectations of platform.h for Zephyr SOF builds #7248

Kconfig default is 'n' by default. Remove redundant definition.
This also allows later use of board/family specific Kconfig.defconfig
files that provide additional rules to set defaults.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
SOF builds currently use the board Kconfig file to set any
target specific build options. This includes modifying Zephyr
build options (if different from Zephyr defaults for the SoC) and
setting SOF specific options.

There is currently no way to share definitions. For Intel ADSP boards,
there starts to be a lot of boards and a lot of duplication of
settings.

Add a new mechanism to include common Kconfig.defconfig for a family
of boards. Start with addition of boards/intel_adsp/Kconfig.defconfig
and move defaults for CONFIG_COMP_ARIA and CONFIG_IPC4_BASE_FW_INTEL
to the common file. These are options that are not related to hardware
features, but we want to set them in the same way for all Intel ADSP
targets.

Follow-up patches will move more options to the common Kconfig.defconfig
and other vendors can add their own board family defconfig files.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@kv2019i
Copy link
Collaborator Author

kv2019i commented Aug 21, 2025

@thesofproject/nxp @thesofproject/mediatek @thesofproject/amd please check whether this would be aligned with your needs to set common options for your product lines.

config IPC4_BASE_FW_INTEL
def_bool y

config COMP_ARIA
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks unorthodox with config COMP_ARIA present in src/audio/aria/Kconfig also.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ujfalusi this is used in Zephyr to set board defaults: e.g. https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/nxp/imx943_evk/Kconfig.defconfig , https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/ruuvi/ruuvitag/Kconfig.defconfig and others.
This does build on the convention to not set redundant "default n" in the main Kconfig definition.

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kv2019i I assume you are proposing a platform/family config with an optional sku config to differentiate from the platform/family ? How would you add OS differentiation ?

Long term we also have the minimal RTOS baseFW and the llext application and modules, so any solution need to work here too.

@kv2019i
Copy link
Collaborator Author

kv2019i commented Aug 21, 2025

@lgirdwood wrote:

@kv2019i I assume you are proposing a platform/family config with an optional sku config to differentiate from the platform/family ? How would you add OS differentiation ?

We currently have three level of settings:

  • Zephyr: hw/arch defaults -> set in Zephyr based on hw properties
  • SOF app wide settings -> app/prj.conf
  • SOF board settings -> .conf file for each board in sof/app/boards/

I'm proposing to add a layer above board settings to have common settings defined in a single place.
95% of the settings in app/boards/intel_adsp*conf are the same. It would be less error-prone and easier
to maintain just those settings that are really different among different Intel boards.
E.g. recently we had misconfiguration of thread stack sizes, and enabling/disabling winconsole (#10180 ).

Then orthogonal to all this, we have overlays that can be applied to all SOF targets. We have one for debug, one for performance tracing and most recently, "Host OS Linux" variant that selects features used by the Linux SOF driver. I'm not proposing any changes to the overlays.

Long term we also have the minimal RTOS baseFW and the llext application and modules, so any solution need to work here too.

I don't see any immediate conflict with this.


config COMP_ARIA
def_tristate m if LIBRARY_DEFAULT_MODULAR
def_tristate y
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like a very modest beginning, but a good start

Copy link
Contributor

@tmleman tmleman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, I like the concept of default values for a family of platforms to avoid duplicating them in platform-specific Kconfigs. I think it's a good direction.

@kv2019i
Copy link
Collaborator Author

kv2019i commented Sep 1, 2025

Thank you all for reviews. Seem no showstoppers to go ahead with this. Let me work on a PR that moves more of the common options. I'll keep this draft until I have replacement ready in case there is more feedback.

@kv2019i
Copy link
Collaborator Author

kv2019i commented Sep 1, 2025

Replaced by #10209

@kv2019i kv2019i closed this Sep 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants