Move BOARD_* and SOC_* configuration to unselectable Kconfigs

[nordicjm]

These commits change how BOARD_* and SOC_* Kconfig variables are selected from being freely selectable in a build, e.g. if a build is configured for an STM32 platform then from menuconfig, it is possible to change to an atmel platform which results in a completely broken build - to a system whereby those variables can no longer be changed after a project is configured.

This is needed for future sysbuild integration work whereby filtering can be performed from a SOC_* and ARCH_* level.

Note: Conversion of nordic soc is currently absent

[tejlmand]

quick early glance.

Minor nit on the commit messages:

Make SOC Kconfig options unselectable

technically speaking the setting is still selectable (using select <config>), but it's not user selectable.

So a small proposal:

Make SOC Kconfig options internal

[tejlmand]

i'm very much in favor of help texts, especially because they are rendered into the official documentation, but a help text which simply just adds the SoC name is not of much value, so for those I prefer to simply keep the config as-is, that is without a help text.

[nashif]

that does not apply everywhere, Nuvoton M48X Series MCU is much more descriptibe than SOC_SERIES_M48X. This commit is removing valuable information IMO.

[tejlmand]

i'm only requesting not to add dummy help text where it is not existing.
(or improve the help text to be meaningful)

SoCs that has relevant help text should definitely keep that existing text.

[nordicjm]

The text was already there, in the selection field, this just moves it from the selection field (as it is no longer selectable) to the help field

[tejlmand]

this effectively changes Kconfig.defconfig from being mandatory to being optional.

The alternative approach is to keep the source and then boards not having any default to override must create an empty file, maybe containing # Intentionally left empty.

I have a slight preference for keeping the source and then an empty file for those boards not needing to override anything.

Reason being:

• most downstream users of Zephyr will at some point need to create a custom board of there own, and having a source helps them to place board specific defconfigs the right place.
• It prevents stupid user mistakes like writing kconfig.defconfig / Kconfig.defconfinstead of Kconfig.defconfig.
• If board is later updated to override defaults then it's clearer where to do this if the file is already empty (but present)

[galak]

I'd prefer we use osource, we shouldn't create empty files if they aren't needed. I get the points you make, but there are enough boards that will have a Kconfig.defconfig that custom boards can see what the pattern is.

[tejlmand]

fair enough, we have different opinion on this.

Another risk is that someone later wants to add a new default to a board which doesn't have a Kconfig.defconfig already.
Contributor looks around in that board folder and decides to place it in Kconfig.$(BOARD) because lack of knowledge.
Such PR can easily approved and be merged, resulting in inconsistency.

Whereas a Kconfig.defconfig with content:

# Kconfig.defconfig file for board specific overload of default settings.

# No board specific defaults.

will help to ensure that such defaults goes to the right location.

Contributors will often look for an existing file to place small suggestions, rather than create new files.

[nordicjm]

@stephanosio Is it possible to get an exclusion on needing copyright headers on these Kconfig files?

[stephanosio]

@stephanosio Is it possible to get an exclusion on needing copyright headers on these Kconfig files?

To be discussed here: https://discord.com/channels/720317445772017664/989195595572973648/1019570877895036970

[stephanosio]

Move BOARD_* and SOC_* configuration to unselectable Kconfigs

promptless would be a more correct wording.

[tejlmand]

if in anyway possible, we should only deprecated the old way of handling boards (and SoCs), as to still allow downstream users to keep using their existing, and old style boards.

A deprecation warning could be issued if we discover old style Kconfig.board and a missing Kconfig.${BOARD} file.

Feel free to ping directly for ideas on how this might be achieved, or provide reasons if this is not possible.

[andyross]

Some drive-by comments to clarify my position, though I really don't want to be dragged into a bikeshed and promise I'll resist continuing:

SOC selection is a feature which can be added to sysbuild, at present, sysbuild has no knowledge of the SOC it is being built for

So... platform selection might need to be at a higher level than raw kconfig, right? If it was something you could get via cmake via a short-circuit/trivial target before the build starts, that would fix all your problems, right?

The method zephyr is using is no different than the method that the linux kernel itself is using

But it is! Linux specifies architecture via an ARCH= variable passed to make[1], not via kconfig (though it mirrors it in kconfig). And while I don't know the history I strongly suspect it's for exactly this reason, to fix the chicken-and-egg dependency issues between platform layers that can't port like that. And this is exactly what I'm suggesting you investigate if you have the same problem.

Basically: if we're looking at a 2000-file PR, we need to be really sure we're solving the problem in the best way. I don't think this is what we want.

[1] And to be fair, Linux doesn't even try to solve the whole problem. The Linux equivalent to sysbuild is a bunch of distro/OS-supplied kernel/initrd packing/signing tools. And those know their platform a priori, they don't demand that Linux tell them. Which... is something I guess I'm not understanding about sysbuild, shouldn't it be starting with a solution to this problem rather than trying to squeeze it out of Zephyr?

[nordicjm]

But it is! Linux specifies architecture via an ARCH= variable passed to make[1], not via kconfig (though it mirrors it in kconfig). And while I don't know the history I strongly suspect it's for exactly this reason, to fix the chicken-and-egg dependency issues between platform layers that can't port like that. And this is exactly what I'm suggesting you investigate if you have the same problem.

We do the same but from a board concept instead of arch, -DBOARD=x, hence why with the introduction of this PR you can no longer change the board, because doing so breaks the build, likewise in linux to change the arch would break the build, so needs to be done afresh.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.